When to prefer JSON over XML?

Question

My requirement is just to display a set of values retrieved from database on a spread. I am using jquery.

Answer 1

I have a blog post on the subject detailing the history of web protocols (i.e. SOAP, XML, JSON, REST, POX, etc) providing a summary as well as some advantages and disadvantages of each: http://www.servicestack.net/mythz_blog/?p=154

I actually think you can draw many similarities between XML and JSON by comparing the differences between dynamic (JSON) and static (XML) languages.

Basically XML is a stricter, more rigid serialization format that can be optionally be verified with an accompanying schema (which is either an XSD or DTD). XSD's are quite elaborate and allows you to describe many different types e.g. Dates, Times, Enumerations, User Defined Types and even Type inheritance, etc. SOAP effectively builds on top of the XML feature-set providing a standardized way to describe your web services (e.g. types and operations) through a WSDL. The verbosity and complexity of the WSDL spec means that it can be more tedious to develop with but at the same time there is a lot more tooling available to you and most modern languages provide automated tools to generate your client proxies taking some some of the burden off when trying to interoperate with external services. (Although at the same time I find generated proxies a burden themselves when dealing with frequently changing web services).

I would still recommend using XML for your web services if you have a well defined 'enterprise service' that is not subject to frequent change or your web service needs to be accessed from many different languages.

For all its benefits XML comes with downsides as well. It relies on namespaces in order to provide a typed extensible format and enables you to specify attributes and elements within the same document. Having different namespaces within the one document means a lot of the time when using a Xml Parser to extract data, you will also need to provide the namespace of each element you want to retrieve/traverse. It also extrapolates the payload making it more verbose than it needs to be. Having the option to output attributes as well as elements means your classes do not map nicely to an XML document. These features alone make it a poor programmatic fit for most languages making it more tedious and cumbersome to work with. Microsoft has recognized and simplified this somewhat with in their DataContract serializer by doing away with XML attributes and just having the properties of your class map to Xml elements only.

JSON on the other hand is the complete opposite to XML in many ways as it is very loosely-typed and only has simple support for basic types: Number, Bool, string, Objects and Arrays. Everything else essentially has to fit in a string. This is not great when trying to communicate across language boundaries as you will need to adhere to some out-of-band non-standard specification if you want to support more specific types. On the upside its limited feature-set makes a good programmatic fit to most languages - and is perfectly suited for JavaScript as a JSON string can be eval'ed directly into JavaScript object.

Size and Performance

I have some northwind database benchmarks available comparing the size and speed between Microsofts XML and JSON implementations. Basically XML is more than 2x the size of JSON but at the same time it looks as if Microsoft put in a lot of effort in optimizing their XML DataContractSerializer as it is more than 30% faster than their JSON one. It seems that you have to make trade-off between size and peformance. Not happy with this fact, I decided to write my own fast JsonSerializer which is now 2.6x faster then MS's XML one - so best of both worlds :).