Before you answer, yes I know that other languages have no native javascript object support, but neither do they have native support for json.
So wouldn’t it make much more sense to modify the json spec to allow identifiers without “” and allow comments? Very sensible things because you don’t have to serialize/deserialize when working in javascript, no?
4
JSON is a data interchange/serialization format. It’s not code intended to be written by humans, but human-readability is important. Given these requirements, JSON is the simplest subset of JavaScript that could possibly work.
For example, we need to allow quoted keys in objects. But if we already have a quoted syntax, there is no need to support unquoted keys as well. Likewise, JSON knows only "..." double quoted strings, single quoted strings '...' do not exist.
The result is that it’s really easy to implement a JSON parser (maybe 20 lines with a nice parser generator). We wouldn’t want to throw that advantage away (which helped become JSON so accepted. Contrast with the complexities of parsing XML). Of course, a production-ready implementation should be lenient in what it accepts.
Could a change like this be retro-fitted into the standard? No, because backwards compatibility. Feel free to write a JSON implementation that accepts unquoted keys, but you can never emit such a string, in case the receiver uses a stricter implementation. And because you generate all your JSON via a library instead of writing it per hand, adding those quotes isn’t any extra burden.
5
The reason for this is because you would still have to do an eval for deserialization and you would still have to somehow deserialize the javascript object into a string, which it doesnt just to by default. Also there is a general argument against using eval – particularly for an exchange format, since javascript objects are also functions.