Dave Johnson

JSON and the Golden Fleece

September 22nd, 2005

JavaScript Object Notation (JSON) is a clever, AJaXian way of representing data for use in a web browser that supports the JavaScript programming language. However, like the golden fleece (and the fair Medea) retrieved by Jason in Greek mythology, I believe that in time it will be forgotten. Gotta love all the AJaX Greek cliches!

People have before argued that JSON is a good alternative to XML for many reasons. Here are my reasons for why I prefer XML.

Processing
First and foremost, something really irks me about using

eval()

in JavaScript to create objects. This can be a both a security problem and, despite what many people seem to think (I am not sure who started it), it is relatively slow, particularly as you start having nested objects. Meanwhile XML can be deserialized into objects in most OO languages and / or formatted using XSL-T (using JavaScript for example) to create any XML dialect one wishes (such as XHTML for AJaX purposes). Furthermore, in the realm of AJaX you are using XMLHTTP requests to get the data anyway, which returns the data as XML using the

responseXML

property.

Simplicity
Ok both XML and JSON are pretty simple. I find XML easier to write and read myself.

Extensibility
They don’t put the X in XML for nothing.

Interoperability and Data Exchange
On the server JSON requires platform / language specific converters. XML has the lovely XSL-T which is not only widely supported but it is really fast on the client AND server. This is a big plus for AJaX to have the ability to process the same data on either the client or server with one XSL-T file so there is no re-writing or converting code.

Structure and Data Types
Sure JSON has something that you could consider structure but XML has a little something called a schema which is widely supported and a necessity that allows definition of data structure as well as data types.

Data Size
In the extreme both formats could be encoded to be essentially the same. We use an encoded format for our AJaX applications which is about as small as you can get without zipping or ignoring the data.

Emerging Technologies

E4X anyone? (thanks for the link Dan)

Acronyms
Yes, you would need to change AJaX to AJaJ if you wanted to use JSON and it doesn’t really roll off the tongue.

One can really see the benefit of XML when you consider dealing with large datasets for something like an AJaX grid control. For example, a common operation in a data grid is sorting - not only is it faster to sort using XSL-T rather than an array of JavaScript objects but the exact same XSL-T can by used to sort the data on either the server or client in different situations. To investigate this further I wrote some JavaScript to test the performance of

eval()

ing JSON data and compared it to the performance of the same data in XML being processed using XSL-T. The script essentially generated data sets in both XML and JSON formats with varying numbers of records and then procesed them accordingly into HTML fragments to be inserted into the DOM using

innerHTML

. Both tests were done in IE6 on Win2K (didn’t get around to Firefox or Opera:(). The results are illustrated below.

As is plain to see the XML data is processed much faster - especially as we move to larger data sets. This makes sense since once the data is ready it is transformed using a fast XSL-T stylesheet which outputs XHTML. On the other hand for JSON one needs to apply the slow

eval()

function to the data after which the JavaScript objects have to be looped through and concatenated into a string. Admittedly, if for some reason you actually want to deal with a singular JavaScript object (ie not having many records that are being put straight into XHTML) then JSON may be the way to go.

A second interesting thing I noticed here was that using a data-driven XSL-T stylesheet rather than a declaritive one resulted in noticeably slower transformations (though still much faster than JSON). I expected this result but did not expect it to be so evident. The reason for this is because a data-driven stylesheet uses many

<xsl:apply-templates select="*" />

and

<xsl:template match="nodeName" />

whereas a declaritive one uses only one

<xsl:template match="/" />

for the root node and many nested

<xsl:for-each select="nodeName" />

Del.icio.us

This entry was posted on Thursday, September 22nd, 2005 at 11:34 am and is filed under Web2.0, AJAX, XML, XSLT. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.

11 Responses to “JSON and the Golden Fleece”

Michael Mahemoff Says:
September 22nd, 2005 at 5:36 am
Dave, agree on many of the XML benefits here, but I do think JSON has merits too, e.g. bandwidth and the fact that it�s a direct object representation vs XML being a metaformat where you still need to agree on a specific dialect to represent objects.

Nice to see empirical data like this, but why use eval(). json.js also provides a direct parser. Its main purpose is security, so honestly don�t know if it would be faster, but it would be interesting to feed into your benchmarker. (I also suspect a faster JSON parser could be written if the motivation was there.)
Dean Edwards Says:
September 23rd, 2005 at 1:39 am
This is not a presidential election. You don�t have to vote for one or the other, winner take all. XML is good for some types of data and JSON good for other types. End of story.
Dave Johnson Says:
September 23rd, 2005 at 2:06 am
Thanks for your very valuable comments Michael.

Michael said:
�JSON has merits too�
It certainly does and I am mostly playing devil�s advocate to those merits listed here which to tell you the truth I think are a little biased - aren�t we all though.

�JSON has merits too e.g. bandwidth�
I think that both can be essentially the same in terms of bandwidth by using (or using letters for the attribute names even) rather than verbose element based XML formatting.

�JSON has merits too � the fact that it�s a direct object representation�
This is very true � I suppose for us (internally at least) it is simply a matter of defining our schema for objects which consists of an encoded format to keep down the size. We also have a particular way of XML serialization in C# / Java to keep things all in sync so we can go to/from serialized and encoded XML to object instances. JSON also lacks typing at the moment which can make object representation moot.

I will take a look at the Json.js - most implementations I have seen use the eval() which is why I looked at it. From what I saw using two levels of nesting, the eval() function actually takes about 1.5 to 2 times longer than creating the object directly - which would still leave it considerably slower than XML I suppose.

�Nice to see empirical data like this�
I am trying to bring a bit of reality to the AJaX hype Does anyone really care about 2.5ms against 7.5ms for rendering some data? I�m not sure they do. But this hopefully gives a good idea of where things are headed if you are planning on doing data heavy lifting on the client. In reality the innerHTML takes a hell of a lot longer than most XML / JavaScript processing anyway! (this will be examined very shortly)
Dave Johnson Says:
September 23rd, 2005 at 2:15 am
No Dean this is not a an all or nothing situation, that is my point, however, it is not the end of the story as you suggest.

This has been a discussion of why I think that XML *generally* proves to be a better solution than JSON. That being said, I would like to draw your attention to the fact that JSON and XML processing times on the client are actually quite similar when working with small datasets (see figure above) which prompted me to say the following at the end of the second last paragraph:

�Admittedly, if for some reason you actually want to deal with a singular JavaScript object (ie not having many records that are being put straight into XHTML) then JSON may be the way to go.�

So you will see that I am mainly raising some issues with using JSON when dealing with converting large numbers of records to HTML. If you want to return a few records from a database, let�s say, and you want to use those in JavaScript for performing some sort of processing or setting values in a couple of input boxes then by all means use JSON since it is the best tool for the job.

Anyone can just say that �XML is good for some types of data and JSON good for other types�! I am trying to shed some light on what these ambiguous types of data are - ie JSON for small datasets that are not going into HTML and XML for large datasets that are going into HTML.
Rein Peterson Says:
September 29th, 2005 at 1:03 am
Hi Dave,

Thanks for the benchmarking - it�s good to know that large data sets will probably fare better (performance-wise) left in xml format.

Still, I think JSON is worthy as a serialization format when you are performing javascript magic in the browser because it is easy to prototype the objects and/or add functions to them.

If the data being deserialized in the client is intended largely for display, then I would have to concur with your sentiments - it�s easier to just transform to (x)html.

But if you�re calling data to be used in javascript (like the google maps api), and there isn�t a vast whack o� data, deserializing JSON >> javascript objects simplifies your code and avoids instancing the xml dom (a veritable beast).

So, XSLT is a quick/easy/efficient way to generate (x)html from server data (XML), and JSON is the quick/easy/efficient way to generate javascript objects from server data (JSON).

By the way, I�m working on a javascript prototyping notation that will also be a subset of ECMA javascript and will act similarly to an xml schema. I�m planning to use regular expressions to allow you to further constrict value types where javascript is too loosely typed to reflect an xml schema.

I also have xslt forthcoming that will transform existing xml schemas to another xslt that will generate transforms for xml >>> (stronger)proto-typed javascript. The intention is too allow web services to continue handling xml and do it well, while providing a way to offer a JSON data serialization alternative, either transformed on the client or at the server.
Wade Smith Says:
March 24th, 2006 at 1:00 am
While looking for a library to sort some JSON {smirk} i found this article. As I am currently implementing a site mostly in JSON+JSAN and have done a couple client-side XSLT sites before and I find your conclusions a bit skewed.

JSON is great for smaller things, which is quite a bit of active updating needed by most functionality. Where the XSLT is better for robust data and larger page changes.

Example:
Location or Ontology drilldown = JSON
Multipart tabbed musician biographies = XSLT

Saying that JSON will fade away is i think a bit shortsighted, having a native javascript array vs. parsing a DOM has it�s advantages
Dave Johnson Says:
March 24th, 2006 at 3:23 am
I agree Wade - JSON has it�s uses!

I didn�t say that JSON will fade away did I? Though I do think it might once we have E4X
Dave Johnson » Blog Archive » JavaScript Benchmarking IV: JSON Revisited Says:
April 9th, 2006 at 11:55 am
[…] My last post [1] about JSON had a helpful comment from Michael Mahemoff, the driving force behind the great AJaX Patterns site (I recommend taking a quick gander at the comments/responses from/to Michael and Dean who are both very knowledgeable in the AJaX realm). […]
JavaScript Object Notation: The Definite Guide | Scriptorama Says:
May 5th, 2006 at 2:10 am
[…] De output van JSON aanzienlijk kleiner. Betekent dit dan automatisch dat JSON parsen sneller is dan XML? Daar zijn de meningen nog uiteenlopend. Volgens deze benchmark scoort XML beter dan JSON als het gaat om grote hoeveelheden data. Dat komt vooral door XSL, wat erg snel werkt. Een ander groot verschil tussen JSON en XML is dat een JSON string altijd volledig in het geheugen geladen moet worden, terwijl je met XSL of XPATH juist kleine dingen kunt opzoeken. Aan de andere kant veronderstel ik dat JSON sneller is als het gaat om kleine hoeveelheden data, XML is wellicht dan overkill. Het ligt dus aan de situatie welke data exchange formaat je moet gebruiken. […]
J-Lo's Butt Says:
June 15th, 2006 at 11:05 am
Nobody’s mentioned the main advantage JSON has over XML, and that’s of course the cross-domain ability. I see not being able to use XMLHTTPRequest across domains as the major blocker for Ajax for my purposes.
Dave Johnson Says:
June 19th, 2006 at 11:07 am
Take a look at my idea for cross-domain XML here: http://blogs.ebusiness-apps.com/dave/?p=92

JSON and the Golden Fleece

11 Responses to “JSON and the Golden Fleece”

Leave a Reply