There is a reason why JSON is becoming very popular as a data exchange format (more important than it being less verbose than XML): programmers are sick of writing parsers! But “wait”, you say – “surely there are XML parsers available for you to use so that you don’t have to roll your own…”. Yes, there are. But while XML parsers handle the low-level syntactic parsing of XML tags, attributes, etc…, you still need to walk the DOM tree or, worse, build one yourself with nothing but a SAX parser (Objective-C iPhone SDK I’m looking at you!). And that code you write will of course depend on whether the XML you need to make sense of looks like this:
1 | <person first-name="John" last-name="Smith"/> |
or this:
1 2 3 4 | <person> <first-name>John</first-name> <last-name>Smith</last-name></person> |
or this:
1 2 3 4 | <object type="Person"> <property name="first-name">John</property> <property name="last-name">Smith</property></object> |
or any of the myriad of other ways one can conceive of expressing the same concept (and there are many). The standard XML parser does not help you in this regard. You still need to do some work with the parse tree.
Working with JSON is a different, and superior, experience. Firstly, the simpler syntax helps you avoid the need to decide between many different ways of representing your data (as we saw above with XML) – much less rope to hang yourself with. Usually there is only one straightforward way to represent something:
1 2 | { "first-name" : "John", "last-name" : "Smith" } |
Even more important, if you are working in Javascript (which is very often the case when working with JSON), all you need to do is call eval on a JSON string to obtain a first-class Javascript object. This is huge. The subtle point here is that the output of an XML parser is a parse tree, not an object native to the programming language being used. With XML you are still dealing with syntax to a large degree. When you work with JSON you can go straight from a string representation to object (and back).
What makes this possible is that Javascript has syntactic constructs for describing composite data types literally. While virtually all languages have syntax for the literal description of objects of primitive types (integers (e.g. 5), strings (e.g. “hello world”)), not all languages have syntax for the literal description of objects of composite types. For instance, if you want to create a map in Java you need to do it procedurally:
1 2 3 4 5 6 7 | Map m = new HashMap();m.put("a", 1);m.put("b", 2);m.put("c", 3);... |
Java does not have literal syntax for maps. But languages such as Python and Javascript (and others) do. In Javascript we can define our map literally:
1 | { "a" : 1, "b" : 2, "c" : 3, ... } |
As it turns out, such sub-languages are a great match for data interchange formats that are both human and machine readable.
As for XML… it’s just not the best for structured data interchange (even with some of the cool Object/XML mapping technologies out there). It works well for markup (i.e. HTML) of text but not as a language for structured data. For that developers want something they don’t have to parse all the time.
