6 ms·

The point of JSON is to have a standard way for data-interchange. Adding the complexity of "sometimes you might have quotes, sometimes not" and "you can displa

The point of JSON is to have a standard way for data-interchange. Adding the complexity of "sometimes you might have quotes, sometimes not" and "you can display multi-line strings in different ways" gets away from this. 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.

tinco 12y ago
No, the point of XML is to have a standard way for data-interchange. The point of JSON is to have a lighter and simpler way of data interchange, where the data is arrays and maps of strings and numbers. It also works well with Javascript. 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)
- angersock 12y ago
  I'd say that JSON proved that having a standard for data-interchange was important, especially because as a standard it was both straightforward to implement and limited a lot of the crazy feature creep that made/makes XML annoying. It not only was a standard, it was a strictly better standard. 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 Anything else is gravy, and JSON managed to nail that core supporting set of features right on the head, without adding other bogus stuff. 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.
- jerf 12y ago
  I'd say that was exactly backwards. The reason JSON succeeded is precisely that it is a very, very specific standard. You may still be operating under the common misunderstanding that JSON is just "Javascript object notation", but in fact it is a carefully chosen and very rigid subset. It is actually illegal to not use double-quotes to identify a key, even though in Javascript itself often no quotes are required, and apostrophes are accepted as quotes. JSON's human-readability is a bit deceptive... it is also a very rigid format. 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.
- otterley 12y ago
  > The point of JSON is to have a lighter and simpler way of data interchange, where the data is arrays and maps of strings and numbers. It also works well with Javascript. 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.)
  - gnaritas 12y ago
    No you can't, JSON is not JavaScript and eval is not capable of working on all correct JSON documents. JSON requires a JSON specific parser. So this breaks nothing, eval doesn't work now and JSON has never been JavaScript.
    - otterley 12y ago
      When JSON was first used, it was evaluated with eval. Certain issues might cause JSON not to evaluate properly (the only article I could find arguing that it's not Javascript involve Unicode issues that are rarely encountered), but it doesn't invalidate my point.
    - draegtun 12y ago
      And to back up gnaritas comment... JSON: The JavaScript subset that isn't - http://timelessrepo.com/json-isnt-a-javascript-subset http://timelessrepo.com/json-isnt-a-javascript-subset
    - deleted 12y ago
      [deleted]
    - ninjaplease 12y ago
      Look, you're just wrong. The only exception to "eval" is some obscure unicode bug others are mentioning. JSON is literally a JS object literal (with the additional requirement that any key be a string). There's also no reason to use eval when JSON.parse will do it safely.
- deleted 12y ago
  [deleted]
lcfcjs 12y ago
I totally agree with this, JSON was designed as a standard.

tinco 12y ago

No, the point of XML is to have a standard way for data-interchange. The point of JSON is to have a lighter and simpler way of data interchange, where the data is arrays and maps of strings and numbers. It also works well with Javascript. 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)

angersock 12y ago
I'd say that JSON proved that having a standard for data-interchange was important, especially because as a standard it was both straightforward to implement and limited a lot of the crazy feature creep that made/makes XML annoying. It not only was a standard, it was a strictly better standard. 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 Anything else is gravy, and JSON managed to nail that core supporting set of features right on the head, without adding other bogus stuff. 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.
jerf 12y ago
I'd say that was exactly backwards. The reason JSON succeeded is precisely that it is a very, very specific standard. You may still be operating under the common misunderstanding that JSON is just "Javascript object notation", but in fact it is a carefully chosen and very rigid subset. It is actually illegal to not use double-quotes to identify a key, even though in Javascript itself often no quotes are required, and apostrophes are accepted as quotes. JSON's human-readability is a bit deceptive... it is also a very rigid format. 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.
otterley 12y ago
> The point of JSON is to have a lighter and simpler way of data interchange, where the data is arrays and maps of strings and numbers. It also works well with Javascript. 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.)
- gnaritas 12y ago
  No you can't, JSON is not JavaScript and eval is not capable of working on all correct JSON documents. JSON requires a JSON specific parser. So this breaks nothing, eval doesn't work now and JSON has never been JavaScript.
  - otterley 12y ago
    When JSON was first used, it was evaluated with eval. Certain issues might cause JSON not to evaluate properly (the only article I could find arguing that it's not Javascript involve Unicode issues that are rarely encountered), but it doesn't invalidate my point.
  - draegtun 12y ago
    And to back up gnaritas comment... JSON: The JavaScript subset that isn't - http://timelessrepo.com/json-isnt-a-javascript-subset http://timelessrepo.com/json-isnt-a-javascript-subset
  - deleted 12y ago
    [deleted]
  - ninjaplease 12y ago
    Look, you're just wrong. The only exception to "eval" is some obscure unicode bug others are mentioning. JSON is literally a JS object literal (with the additional requirement that any key be a string). There's also no reason to use eval when JSON.parse will do it safely.
deleted 12y ago
[deleted]

lcfcjs 12y ago

I totally agree with this, JSON was designed as a standard.