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:

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

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):

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"}

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.

Posted: January 30th, 2008


Subscribe for email updates

21 Comments (Show Comments)



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.


Secrets of the JavaScript Ninja

Secrets of the JS Ninja

Secret techniques of top JavaScript programmers. Published by Manning.

John Resig Twitter Updates

@jeresig / Mastodon

Infrequent, short, updates and links.