The State of JSON

I wanted to pull together some of the recent events that have occurred, related to native JSON support within a web browser, that should be of importance to many web developers. This should serve as a sort-of follow-up to my previous post: Native JSON Support is Required.

Early API Standardization Attempts – Last year, a number of attempts were made by the ECMAScript language committee to standardize an API for JSON encoding and decoding, within the language. A few API proposals were examined and discussed, most based upon Crockford’s proposal, but no general consensus was reached. Some general issues with the proposed API were brought forward (similar to those mentioned in my previous post).

JSON2.js – Late last year Crockford quietly released a new version of his JSON API that replaced his existing API. The important difference was that it used a single base object (JSON) instead of extending all native object prototypes (booo!). Its revised API worked as such:

This version of JSON.js is highly recommended. If you’re still using the old version, please please upgrade (this one, undoubtedly, cause less issues than the previous one).

Dispersion – Even with a newly-proposed API, criticism concerning the inclusion of JSON in the ECMAScript language came to a questionable conclusion. Some implementors weren’t interested in including it, others were, and yet other couldn’t decide on the final API or method names. It was then decided that implementing JSON support in an ECMAScript implementation would be left up to the implementors themselves (unless, of course, some other conclusion is arrived upon in the future).

Mozilla Implements Native JSON – Mozilla was the first to implement native JSON support within it’s browser. Note, however, that this is not a web-page-accessible API but an API that’s usable from within the browser (and by extensions) itself. This was the first step needed to implement the API for further use.

Here is an example of it in use (works within an extension, for example):

Web-accessible Native JSON – The final, and most important, step is being worked on right now – a way to access native JSON encoding and decoding from web pages. How it’ll be accessible is up to some debate (as having its naming conflict with an existing object would be a really bad thing). Regardless, there should be something within the browser by the time the Firefox 3 betas wrap-up.

What’s important about this is that it’s really not a case of “Oh well, guess we’ll have to wait for other browsers to implement this.” Since this is a native implementation (and, thus, very-very fast) existing JSON encoding/decoding libraries can just check for the existence of this particular set of functions and use them directly – gaining a direct, and immediate, performance boost for Firefox users. The same principle applies to features like getElementsByClassName, since they’re available in normal JavaScript code, but are insanely fast when implemented directly by a browser.

“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!

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.

@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.

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.

@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.

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.

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?