XML vs JSON: A Second Sober Look | January 8th, 2007
There has been a recent fleury of discussion about XML vs JSON. What a great topic for the holidays.
Although I have been talking about this topic for some time, some XML bloggers have recently started to discuss the topic (Tim Bray, Don Box, David Megginson, Dare Obsanjo and all the comments). For the most part the discussion is pretty tame and nothing really new.
Tim brings up the good points about extensibility and encoding. He also importantly acknowledges the fact that JSON is applicable in certain cases. To his points I would add the fact that one is able to use XPath with XML making it very powerful for quickly finding data. XPath is one XML technology that many ignore, particularly in the JavaScript sandbox.
The other important points are really in direct response to Dare Obsanjo’s posts from last week: Browser Security Model and Browser Programming Model. First of all, Dare suggests that one reason for JSON being so popular is due to cross-domain JSON (also called JSONP or JSON with Padding). Ignoring the data format, this pattern is applicable to any kind of data, including XML (XML with Padding is equally valid). There is no reason that Yahoo! could not provide a cross-domain XML API along side a cross-domain JSON API. In fact, I urge people to email everyone they know over at Yahoo! to do so for all their properties such as del.icio.us.
There are also a few points I have in response to the second post about the difference between the programming models of JSON and XML. The main thing that I noticed is that the example presents is not a realistic use case. What is most commonly done with data in an Ajax application is that the data is rendered to HTML. The fastest way to render data to HTML is using XML and XSLT. The other thing that he does not look at is cases where the data needs to be sorted or filtered, in which case XML and either XSLT or XPath provide a very nice solution. Of less importance, Dare also states that one should use a JSON parser in case of security concerns, however, the JavaScript based JSON parsers that I have used have had very extremely poor performance - even worse than plain eval().
The other interesting thing was a comment made by Kevin Hackman from TIBCO in the Ajaxian post. Kevin mentioned the fact that TIBCO uses XML to maintain the JavaScript state - i.e. each JavaScript object has a related XML document where the the object properties are stored and accessed using standard JavaScript accessor methods - which helps in terms of application memory usage. This is something that the soon to be released Nitobi Complete UI Framework also does, although for slightly different reasons like the fact that objects can then be easily serialized for use with server frameworks like JSF or ASP.NET.
At any rate, I am happy to see that some others are joining in on the discussion and if nothing else I hope that people start to talk more about using XSLT and XPath in the browser.
January 8th, 2007 at 2:59 pm
Another piece of the pie that people are not really looking at is E4X (ECMAScript for XML).
MDC: E4X
http://developer.mozilla.org/en/docs/E4X
ECMAScript for XML (E4X) is a programming language extension that adds native XML support to JavaScript. It does this by providing access to the XML document in a form that feels natural for ECMAScript programmers. The goal is to provide an alternative, simpler syntax for accessing XML documents than via DOM interfaces.
E4X is standardized by Ecma International in ECMA-357 standard, see http://www.ecma-international.org/publications/standards/Ecma-357.htm
In Gecko 1.8 based browsers such as Firefox 1.5, E4X is already partially enabled for web page authors.
January 8th, 2007 at 3:06 pm
Yes you are absolutely right Michael!
We will have to see what Internet Explorer does with E4X though before it really catches on I guess.
January 9th, 2007 at 3:32 pm
“The fastest way to render data to HTML is using XML and XSLT.”
No, the fastest way to render data to HTML is to render it as HTML on the server side and shove that down the wire; on the client you have no parsing, no queries, no data structures to walk — you just assign to some element’s innerHTML and you’re done.
January 12th, 2007 at 1:57 pm
Sorry, there was some implicit context there. One could also argue differently based on the speed of the client computer, load on the server and network bandwidth. Of course you are right James that rendering the HTML on the server can be a good option - though it will mean more server load and more data to transfer across the network.
February 9th, 2007 at 2:01 am
I will have to disagree James, depending on your AJAX application it may or may not be faster. I have a page that renders a large sortable table via AJAX and it is much faster than previously when I was rendering the HTML on the server first. I will give some numbers: 450K XML file + 20K XSL file generate a 1.1Mo HTML file. It takes between 2-3 seconds in IE or FF on a decent machine (less than 3 years old). So using XML/XSLT to render in the browser cuts my data transfer in half, and in this case renders faster on the client side for most people (with a 150ko/s connection, make the calculation;). Also this is not without saying that with rendering XML on the client side, they can sort with one click and within 2-3 sec get the whole dataset sorted to their taste. There is no way that JSON could do this with this much data, and re-rendering the page with the proper sort criteria on the server side is history IMHO!
Dave - excellent post, can’t agree more!
June 13th, 2007 at 5:57 am
But this will always depend on the kind of application you are building! Sebastien’s example with the client side sorting in XSLT is nice, but what if the dataset is larger than you ever want to retrieve in one query (so you need more than one page for your data!). In that case you NEED to go back to the server and sort it there (another example is ofcourse filtering).
In this case you will need to build a solution that does server side sorting and preferably do as much on the client as possible (making the responses as small as possible).
This is not too hard to code by the way, but almost none of the available frameworks has a good solution for this. I believe backbase has some dataList or dataGrid thingy that solves this pretty well…
Anyway, if you build it yourself and keep the response as small as possible like I said… Than JSON will probably be the fastest way to achieve this. Another argument is that XSLT is a relatively new (thus unknown, thus poorly documentated for beginners thus very hard and complicated) technique. Everybody knows javascript and dom, so JSON is easier.
June 14th, 2007 at 5:20 pm
I certainly agree that JavaScript + JSON are much easier and everyone knows them!
I think that Internet Explorer is the main reason to want to use XSLT though since it is significantly faster in terms of performance.