JSON vs XML

[Beagle]

Hello all,
I thought I'd share something that I don't see talked about much on the forums.
I've been doing a bunch of AJAX development at work. We're really strapped for processing speed on our client (we build the machines our clients use) and therefore we've needed to find ways of speeding everything up.

One of the things we decided on within the first week of our current project was to completely scrap XML in favor of JSON for sending data back and forth. JSON is JavaScript Object notation. Many of you have already seen it, it looks like this:


{'prop1' : 'someValue', 'prop9' : 5};


That defines an object with 2 properties, prop1 and prop9, with the respective values "someValue" and 5. Compare that to XML:


<obj>
<prop1 value="someValue" type="String" />
<prop2 value="5" type="Integer" />
</obj>


That's a bit more bloated, maybe not too noticeable, but the example is a small one. If you take large amounts of data, and multiple objects, XML can get incredibly bloated, and bloat on the wire slows down your app. That's the first reason we switched.

The second reason we switched is that we save time on the processing. We all know what it's like to get at XML data. Import the document, get the node, get the value, get the next node, get the value. And building XML documents can take just as long: Create document, create root node, create node, create attribute node, set value, append child, repeat... All that processing for something so simple.

JSON on the other hand is a subset of javascript, so check this out.


var data = "{'prop1':'someValue', 'prop2':5}";
var obj = eval("(" + data + ")");
alert(obj.prop1); // *** Alerts 'someValue' ***


The string fits right into JavaScript in one function call. Granted, eval can be expensive, but if you test this out yourself, it's far cheaper than building and deconstructing XML in the JavaScript engine.

There are 2 simple JSON parsing libraries that we use in development: JSON.php and json.js; these provide the necessary functions to serialize any PHP object into JSON, and serialize any JavaScript object into JSON. You can get them at the links below. We are also following the specification for JSON-RPC, defined in the last link below.

We found this to be incredibly fast when compared to XML, and we haven't regretted it yet. Granted, we're not doing full blown web services where the the javascript modifies itself based on the service's self-definition, complete with namespaces and function signatures, but we transfer a lot of data quickly and efficiently to provide our users with the best experience possible.

I recommend examining this further if you do AJAX development. Hopefully this helped somebody.

http://json.org/
http://mike.teczno.com/json.html
http://json-rpc.org/

And now for the "VS" part of this post: Anyone with experience in using both XML and JSON that wants to argue the mertis of either technique? I support JSON for almost all AJAX applications currently. I haven't found a good reason to use XML, and the negatives for using XML (bloat and processing speed) have currently knocked it completely from my "viable options" list. Anyone care to discuss?

[jkd]

The one advantage of XML is XSLT processing. Any good so-called AJAX application should run fine without JS-enabled. A slick way of doing this is writing an XSLT document to transform the response data, and use PHP to dump the output if JS is disabled, or return the raw XML data to the Javascript, and utilize XSLTProcessor() to do the transform on the client. The advantage is you have very minimal code duplication on the client, and you can keep your logic in one place (the XSLT document).

Otherwise, I tend to use something similar to JSON, but a little simpler/faster, since I generally I just get name/value pairs back and nothing complicated.

[liorean]

Well, I support both formats, but there are differences in capabilities.

First of all, let's talk about what the formats are good or bad at:
- XML is good for very highly nested constructs where the DOM and XPath provides better manipulation than searching through a JavaScript object tree.
- XML is good for static data, that is, data that will not be manipulated by the script, but maybe parts of it will be displayed at need. An example would be a client side database where XPath and DOM are effective for just inserting pieces from the database into the document tree.
- JSON is very good if you have to send just modest amounts of data to the server but large amounts of data to the client. JavaScript doesn't really come with any good tools for sending data back to the server. Basically, only XMLHttpRequest or HTML forms can send POST data, and neither of those is specifically made for sending JSON data, so JSON is best for smaller amounts of GET data.
- JSON is a very good format for the browser to recieve data that it will be doing processing on. Especially if callbacks are being used.
- JSON is much closer to the JavaScript environment than XML, and thus much more effective for client side manipulations.
- JSON is moderately smaller than XML. If in-flight compression such as gzip is being used, the redundancies of the XML format do very little to increase the size compared to JSON.




There is a number of things that weigh towards one format or the other. For example, my favourite way of including JSON is to have the server write a callback. Thus you create a function, let's call that function fnJSONCallback, and you request the file from server with a callback query string like so: Original, pure JSON is the file "requestedresource.json". You create a script element client side and request something that might look like this "js?res=requestedresource&fn=fnJSONCallback". The server will then return something looking like this:fnJSONCallback(contents_of_requestedresource.json);
If you're in a controlled environment you can even get rid of the variable callback name and use a single standard callback function name. This obviously can't be done if you have other consumers of your JSON than your own client code.

If you on the other hand need to send more data to the server than a resource identifier, then I don't consider JSON at all as good a solution. It may still beat XML, but using XMLHttpRequest is not nearly as good for JSON.





One of the benefits with XML is that if you need to send larger amounts of data back to the server, then you can use POST instead of GET through the XMLHttpRequest object and you get the XML parsing for no extra cost. Doing the same for JSON gives a double costs of having to parse it.

Also, there's a question of generating code. If you have to build XML through the DOM, then that's costly. So, if you need a DOM, then it's a good idea to start from the XML format. On the other hand if you want raw data to manipulate, but don't need to generate a DOM, then XML is obviously introducing a large overhead.





I tend to prefer to send real JavaScript or HTML+JavaScript to any of these alternatives though. When moving work to the client you want to be able to send functionality, and that can not be done with either of XML ot JSON.


As an aside, I find it interesting that YAML have yet to be seen as one of the AJAX contestants. The format is very server friendly, and it's practically made for PERL or Python manipulation. There's some more parsing to do on the client, but purely static data aside, it's probably the cheapest things you can do on the server, which I feel is in line with the AJAX philosophy of moving processing to the client and have the server as a pure data container.

[Skyzyx]

Any good so-called AJAX application should run fine without JS-enabled.

I'm sensing some negativity towards AJAX... :D Yes, an on-the-web website using AJAX should offer non-AJAX alternate functionality. Webapps, where you can dictate basic requirements such as a modern browser without JS turned off, not so much.

Beyond that, yeah I agree that JSON is one of the best ingredients for AJAX since XMLHttpRequest. Generally speaking, I think people will tend to choose one method over the other, and for MOST apps, the requests and responses will be fairly small.

We're using a lot of AJAX in our current corporate intranet because it made more sense to send small bits of information rather than reloading the whole page from the server.

Now sometimes it makes sense to send back HTML, in which case, handle the data on the server as XML and use all your XSLT stuff to convert it between JSON and (X)HTML. But I would never send XML back to the browser for any kind of processing -- ever.

[garyS]

The one advantage of XML is XSLT processing. Any good so-called AJAX application should run fine without JS-enabled. A slick way of doing this is writing an XSLT document to transform the response data, and use PHP to dump the output if JS is disabled, or return the raw XML data to the Javascript, and utilize XSLTProcessor() to do the transform on the client. The advantage is you have very minimal code duplication on the client, and you can keep your logic in one place (the XSLT document).

Otherwise, I tend to use something similar to JSON, but a little simpler/faster, since I generally I just get name/value pairs back and nothing complicated.

There are a number of Javascript templating frameworks/libraries which transform JSON into HTML in a similar way to how XSLTs can transform XML.

I've listed some on my blog at http://on-web.blogspot.com/2009/12/useful-round-up-of-web-development.html

[Kor]

There are a number of Javascript templating frameworks/libraries which transform JSON into HTML in a similar way to how XSLTs can transform XML.

I've listed some on my blog at http://on-web.blogspot.com/2009/12/useful-round-up-of-web-development.html
What for? It is a piece of cake to use DOM methods, you don't need a bunch of libraries for such a simple thing.

[Old Pedant]

I've only been saying the same thing about XML for...ummm...I ran out of fingers...well, maybe 7 years? 8??

XML is a wonderful invention. When it's used for its original purpose. Which was data movement between disparate systems. (But even there it breaks down badly for scientific uses where you can't exactly transfer a double precision floating point value...or, rather, you can, but only by working around XML limitations.)

But if your code controls both ends of the transfer??? So you don't have to worry about possible impedance mismatches? Seems a terrible waste.

I found liorean's comment interesting:
I tend to prefer to send real JavaScript or HTML+JavaScript to any of these alternatives though. When moving work to the client you want to be able to send functionality, and that can not be done with either of XML ot JSON.
YES!! I've been doing that since long before I ever heard of AJAX.

I simply use a 100% hidden <iframe> and open a new page in it. The new page is 100% javascript (or nearly so...see below) and simply consists of (typically) an array or network of objects and a call to a function in the parent, passing along the array/network. The parent is expecting the data and knows exactly what to do with it.

I even did this before <iframe>s came along, using instead <frameset>s with completely hidden <frame>s.

The advantages:
(1) You can also dump out debugging information (plain HTML, not JS). Then, to *see* the debug info, just change the <iframe> from hidden to visible. I typically use something like
<iframe style="display: none; width: 100%; height: 200px;" ...>
and so only need to change the display value while debugging.
(2) You can do a view==>>source of the iframe to see exactly what data and code was dumped in there. Makes it almost trivial to track down bugs that can be really hard to find using other methods.
(3) There's no encoding/decoding of any kind needed. That JavaScript code--esp. the objects--is sitting right there in plain view, ready to use, as is.

Is it a do-everything solution? Of course not. Clearly it's not how you would publish any kind of service intended for consumption by others.

But it works and works wonderfully well. And if you want, you can even use JSON notation, but you will have JS objects directly, not with any need to eval() the stream.

[Kor]

I simply use a 100% hidden <iframe> and open a new page in it.
The disadvantage is that SEOs will index separately the iframes, not along with the parent (or it will not index them at all; at least many spiders will not follow the iframe starting from the parent page). A javascript which might force the iframe to be opened only along with its parent is also bad viewed by the SEOs which might consider it as a malicious redirect.

[Old Pedant]

The SEOs will never see the IFRAME contents.

It's loaded via JavaScript calls.

Just like the SEOs will never see JSON or XML content that is loaded via AJAX.

I quote from one of google's own pages:
http://www.google.com/support/webmasters/bin/answer.py?hl=en&answer=35769

Use a text browser such as Lynx to examine your site, because most search engine spiders see your site much as Lynx would. If fancy features such as JavaScript, cookies, session IDs, frames, DHTML, or Flash keep you from seeing all of your site in a text browser, then search engine spiders may have trouble crawling your site.

So if you want your content indexed, don't use AJAX to display it. And don't use my <iframe> technique, either.

[Kor]

Just like the SEOs will never see JSON or XML content that is loaded via AJAX.
I've recently read about the fact that Google SEO is now instructed to follow the AJAX generated content.

[Old Pedant]

Well, actually, I *can* allow the search engine to follow the links into my <iframe>s if I want to. And if the JS that I generate in those hidden iframes happens to also contain relevant searchable content, then maybe they will index it.

I can do it by using a hidden <form> in the parent page that is used to submit the info to the iframe--and not so incidentally this makes using POST data trivial. So if the search engine sees
<form action="doSomething.php" method="post" target="myIframe">
it might well be great for me that it follows it and indexes the resulting content.

If google can handle AJAX-based content now, then it could surely handle something simple like that.

[Kor]

Well, actually, I *can* allow the search engine to follow the links into my <iframe>s if I want to.
Yes. Google does offer now their Google maps XML instruction file (which it looks like it is read by other spiders as well). .htaccess under Apache might do some tricks of this kind as well. Things go ahead, don't they? :)