JSON is great already. I don't really see this as necessary. I could understand the comments (but use // instead of # as per Javascript comments) to increase clarity to people who don't know the original design syntax. But the others do not seem really useful.
If there's one thing JSON has proven it's that having a standard way for data-interchange is not very important. Having a format that's easily parse- and usable is much more important, being accessible to human inspection is a good advantage as well.
(if having a standard was important we'd all still be using XML)
At the end of the day, in a data format, you need the following things:
+ Some way of associating records with keys
+ Some way of storing records in a particular order
+ Some way of nesting records within records
+ Some simple way of pathing through a record
+ Some way of delimiting the start and end of a record
+ Some way of storing numbers and strings
XML picked an overly verbose way of nesting and delimiting records, as well as presenting three options for storing data: attributes, body, and CDATA sections when one would have sufficed.
The comments thing in HJSON really annoys me, because comments are not needed in an interchange format--and if you need them because you're using it as a config file format, you can just add a comment key and name your variables better. Moreover, the temptation to use comments for, say, type annotations, is huge, and an antipattern (which is why Crockford left them out).
EDIT:
For everyone talking about a "simpler" JSON...the parser for this is about twice as long as the json2 parser from Crockford, with arguably worse comments.
One could argue "But it parses JSON anyways and lets me write sloppy^H^H^H^H^H^Hfriendly JSON", but that's not the point. People complaining about having to put their keys in quotes and leave off trailing commas are also missing the point.
And it is precisely this rigidity that led to its success. There's a tons of other things that existed before JSON, and JSON won, and it's hard not to read the fact that the very looseness of its competition, which the designers of those formats perceived as strengths, were also weaknesses. Any slight little corner in a spec where there can be a divergence of opinion, there will be divergence of opinion when being implemented dozens of times. So having the spec be rigidly precise was a key advantage for JSON.
Which, incidentally, means HJSON's competition isn't JSON. This is why everyone here is talking about YAML, and the other such languages. And that's a rich, established field with probably no room for a new language to emerge.
HJSON's only hope would be to have a mode where it could be trivially compiled to real JSON, where it could work like a dialect. Unfortunately it's promise to round-trip comments wrecks that ability.
I contend there's no "point" to JSON at all. JSON is simply JavaScript (in fact, you can eval it) that was discovered could be used to send data from servers to browsers. It became a standard out of sheer convenience.
By breaking Javascript's ability to execute the code, you're eliminating an important feature of JSON. (I'll admit that nobody should be eval'ing JSON, but the fact that you can makes its existence better understood.)
> JSON is literally a JS object literal (with the additional requirement that any key be a string).
Which makes it not a JS object literal but a near subset with slightly different rules with unicode strings that make it not even a subset.
So now you're wrong twice.