The State of JSON

JSON.stringify({name: "John", location: "Boston"});
// => '{"name":"John","location":"Boston"}'
JSON.parse('{"name":"John","location":"Boston"}');
// => {name: "John", location: "Boston"}

var nativeJSON = Components.classes["@mozilla.org/dom/json;1"]
    .createInstance(Components.interfaces.nsIJSON);
nativeJSON.encode({name: "John", location: "Boston"});
// => '{"name":"John","location":"Boston"}'
nativeJSON.decode('{"name":"John","location":"Boston"}');
// => {name: "John", location: "Boston"}

Posted: January 30th, 2008

21 Comments (Show Comments)

1. Foo (January 30, 2008 at 5:02 am)

   “Some implementors weren’t interested in including it, others were, and yet other couldn’t decide on the final API or method names.”

   That just sucks. Just implement it already and use whatever names….big deal! We have seen something simular in PHP… where they have had lot of discusions on how namespacing is going to work in php… i mean cmon!

2. Richard D. Worth (January 30, 2008 at 5:13 am)

   This is great news. Looking forward to the eventuality. Thanks for the update, John.

3. Ric (January 30, 2008 at 7:39 am)

   What about schema and validation? Kris Zyp has some great suggestions on Json.Com and there is also some work on selectors (JSONPath) and relative references (a json object contains other objects)

4. Kris Zyp (January 30, 2008 at 8:54 am)

   This is good to hear. However, why would Mozilla not follow Crockford’s lead with API (JSON.parse and JSON.stringify)? He wrote it with the ability to defer to a native implementation when available. The most elegant upgrade path is always when existing code can continue to work, but be replaced by or defer to native code when available. Functionality is not affected and users of implementing browsers enjoy faster speed.

5. Chris Dary (January 30, 2008 at 9:10 am)

   Hey John,

   
JSON.stringify({name: "John", location: "Boston"});
// => "{'name':'John','location':'Boston'}"


   That’s actually incorrect JSON. The single quotes must be double quotes to be valid JSON. It’s a common mistake. Should be:

   
JSON.stringify({name: "John", location: "Boston"});
// => '{"name":"John","location":"Boston"}'


   ( You can check it yourself with a little validator I made called JSON Lint – http://www.jsonlint.com – if you’d like )

6. John Resig (January 30, 2008 at 11:11 am)

   @Foo: If only it were that easy – but when something is done by committee/consensus, the end result isn’t always the most desirable. At least in the case of PHP there’s only a single implementor – so they always have the last say.

   @Ric: One step at a time. I imagine that Kris’ stuff would have to see some level of adoption first before being considered for inclusion in a browser.

   @Kris: Mozilla’s implementation was written as more of a port of Google Caja’s JSON implementation (which, as I understand it, has less bugs in it). Caja actually uses JSON.serialize() and JSON.unserialize(). I don’t remember the exact reasoning but the reasoning for using encode/decode was related to the fact that serialize/unserialize already has specific connotations, whereas encoding and decoding don’t. And “stringify”? Would you seriously want to use a “stringify” function? As it stands, it’s probably a good thing that the API method names aren’t identical – as they don’t provide identical functionality (he allows for a filter function, we have a filter array – stuff like that). All that being said, the final web-user-accessible API hasn’t been finalized yet, it may be very different (although, it definitely won’t be something prominent like ‘JSON.stringify’ until some final consensus on the name/API is arrived upon).

   @Chris: My mistake, I was just writing it by hand – it should be fixed now.

7. Tom (January 30, 2008 at 11:40 am)

   My problem is with JSON itself. In an attempt to be compatible with JavaScript and Python, it requires quotes around the keys (as in: {“key”: “value”} being required instead of {key: “value”}) which no one in JS land wants to do. It also makes writing and reading JSON harder (sometimes worse than XML). People also often miss the difference and use things as “JSON” which actually aren’t compliant, in some extreme cases assuming that anything you can eval() is JSON. Also, noting that you can regex validate JSON, most people won’t if they are hacking. (Which I guess leads to the value of native JSON support.) I wonder if any Python code makes similar mistakes. Finally, lack of comment support in JSON is just disastrous for any hand-maintained files.

   Summary: JSON is hard to write, hard to read, easy to misunderstand the spec, and easy to implement in insecure fashions. Only with people who understand it well, or with third-party (preferably native) code, and then only used as simple data interchange (not for hand-maintained files) is it useful. Interesting when the spec seems so simple.

   Also, I used to be a JSON fan when I first heard of it, but I long ago became disillusioned.

8. Tom (January 30, 2008 at 3:02 pm)

   More specifically, here are the changes I would make to JSON:

   1. Allow ‘ for raw strings (no escapes needed).
   2. Make quotes optional for field keys.
   3. Support multi-line strings.
   4. Allow trailing commas.
   5. Allow comments.
   6. Allow multiple objects on a stream without making them in a big array.

   Leaving out some details, I think that would do it. And some details are purposely designed to make sure it wouldn’t be a subset of ECMAScript nor of Python.

9. Robert Sayre (January 30, 2008 at 3:25 pm)

   Kris and John, it’s closer to Crockford’s json2.js now. That didn’t exist when we started, but I’ve moved closer now that it exists.

10. Chris (January 31, 2008 at 7:06 am)

    Wouldn’t it be wonderful if SOMEONE decided to pen a library that parsed JSON without the evil (sorry – eval) function. Then things like AIR would be pleasant for developers.

11. Chris Snyder (January 31, 2008 at 9:12 am)

    @Tom Good points. JSON _should_ be more flexible and dev-friendly than XML is. Several of your points require a parser that is not based on eval(), or at least some filtering prior to the eval() call.

    Nothing is stopping you (or ANYONE else) from re-mixing the JSON spec and writing their own parser.

    @Chris I always thought the eval() hack was sloppy. It hides in the middle of JSON.parse() like a midget hiding inside a Mechanical Turk. But who really wants to use regex to parse?

12. Eric Wahlforss (January 31, 2008 at 9:21 am)

    Agree, great news indeed!

13. Kris Zyp (January 31, 2008 at 10:32 am)

    @Chris – Crockford has written a non-eval based JSON parser. It was just a lot slower, so no one wanted it. Every tool has it’s purpose, including eval. It is naive to believe it should never be used. But of course native parsing is certainly the best.

14. Adam (January 31, 2008 at 12:30 pm)

    There are some things that are seriously missing in JSON.

    First is literal dates, much of what we want to transfer using JSON includes some date information.
    Second is Comments, which Tom has already mentioned.
    Third is relaxation of requirement for text keys.
    Forth is a divorce from ECMAScript. If JSON is to be a lightweight, cross-platform information exchange format, it needs to be developed independent of JavaScript. This will allow more stakeholders (Java, PHP, Ruby people) a say in it.

15. HMK (January 31, 2008 at 5:25 pm)

    When I first heard about JSON I thought it looked very interesting. I was working on something that required the use of French accented characters but I’m buggered if I could find a way to get JSON to accept and display them. Has anything changed recently?

16. Edward (January 31, 2008 at 7:09 pm)

    @HMK – JSON fully supports unicode, so french accented characters are no problem. They don’t even require special encoding, though they can be encoded if desired.

17. Dean Edwards (January 31, 2008 at 7:33 pm)

    > The State of JSON

    Or “JSON is in a state”. It’s annoying that fundamental functionality is being fragmented like this. There is no clear ES4 standard either.

18. Pete Allen (February 4, 2008 at 11:23 pm)

    I sure wish this passes jslint, which we run on our entire js code base. Any ideas how to make those case statements without break pass jslint?

19. Francesco (February 5, 2008 at 3:09 pm)

    Hi John.
    The new JSON API, during stringify, converts Date objects to ISO date strings. But during parsing, ISO dates remain strings. I would suggest the following to parse that ISO dates too:

    <code>
    var str = some_JSON_String_with_ISO_dates;

    function fromISO2Date(k,v) {
    if (typeof v != ‘string’
    || !/^\d{4}-\d{2}-\d{2}T\d{2}:\d{2}:\d{2}Z$/.test(v)
    ) return v;
    eval(“var d = new Date(“+v.replace(/(-|T|:)/g,”,”).replace(/Z/,””)+”)”);
    return d;
    };

    var json = JSON.parse(str,fromISO2Date);
    </code>

    I modified my personal json2.js to automatically convert the ISO dates, but the above is a good compromise.

20. Francesco (February 5, 2008 at 3:12 pm)

    Oops, I followed the instructions but “code” didn’t work :)

21. Francesco (February 12, 2008 at 7:44 am)

    There was a little error in the function above.
    This is the correct line:

    
eval("var d = new Date('"+v.replace(/(-|T|:)/g,"','").replace(/Z/,"")+"')");


Comments are closed.
Comments are automatically turned off two weeks after the original post. If you have a question concerning the content of this post, please feel free to contact me.