Why is JSON so popular? Developers want out of the syntax business.


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:

<person first-name="John" last-name="Smith"/>

or this:

<person>    
   <first-name>John</first-name>    
   <last-name>Smith</last-name> 
</person> 

or this:

<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:

{
   "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:

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:

{ "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.

So, it makes sense that JSON is so popular. At the same time, I don’t think JSON is the best or final incarnation of this concept, and I expect that, over time, other languages with similar properties will (re)emerge offering improvements over JSON (more on that in a later post).

As for XML… it just might not be 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), and can be used for more structured data but over time I believe it will be supplanted by better technologies that are more like JSON and don’t require developers to walk parse trees. Developers should be free from the syntax business by now.

  1. This is very true. I wrote an ajax interface a while back and I got an array back from the database of search results I wanted to pass to a javascript client. In PHP this was as simple as one function call and an echo, and then one simple ajax call in javascript. It was completely painless and easy. If I had to do the same in XML is could have taken me a solid day’s work.

    • Grankulus
    • March 19th, 2010

    Ecmascript 5 has JSON support – no longer any need for sketchy evals.

  2. This is why people who know Lisp so often find the fashion for XML so dismaying.

    Jason is a huge step in the right direction, and it is possible to go even further. Lisp has as about as close as one can get to no syntax at all, neither for data objects nor anything else, and you don’t even need to “eval” a Lisp S-expression: the fact that the reader has read the expression (from a stream, socket, file, whatever) means that you already have a valid Lisp object.

    The sad thing is that we’ve had this concept for a long, long time. Lisp programmers were out of the syntax business by 1960. The rest of the industry still hasn’t caught up.

  3. Keith, I could not agree more. Scheme / Lisp is to what I was subtly alluding when I said “(re)emerge” in my post. It is a shame that we have XML when we s-exprs since the 60’s!

  4. This is an argument against DOM, not an argument against XML. XML and JSON are just storage formats, and do not dictate an API to be used for interaction. I would easily argue that JavaScript developers forcing every other language to provide JSON interchange support libraries was a much worse solution than for those developers to have simply learned how to use a good XML API: something that should have been very simple for them, given that one of the simplest and most direct APIs in existence is E4X, a commonly implemented extension of JavaScript. E4X is supported by at least Firefox and Flash, and probably Opera as well, and could be implemented with minimal modifications as a pre-compile step to target any remaining engines.

    • stefan
    • March 19th, 2010

    agreed. DOM is painful, but why would you want to use DOM directly when the only goal is to build an object structure from an XML representation? in this case DOM is for a framework/library/language developer to provide an easy API/language construct for the XML.

    for the use case described in this post, XML and JSON are completely interchangeable. add to this the fact that XML can do more than JSON …

    this post has some valid arguments, especially when you’re developing in javascript, python, … in python projects i also use JSON for the purposes described in this post because of the lack of a quality XML API, but in java for example, there are API’s that allow you to (re)create an object from an XML stream in a single line of code (XStream). it’s a single line of code when the object has the same structure as the XML (yes, this is a constraint on XML, but this is also how JSON works). there are also API’s that let you choose between JSON or XML as output, so there isn’t much difference between XML and JSON when you put the same constraints on the XML as JSON does.

    as an answer to this post title:
    one would start to think that people just hype stuff so they can write their own libraries for this new technology or format. just to become a ‘rockstar’ and have their piece in history.

  5. …and to think, I always thought I was insane for thinking XML was a data bloating, redundant, overcomplicated “structure”. Your words give me hope of its swift demise.

    • sharded
    • March 19th, 2010

    I cannot agree more, Before moving to json i remember writing classes to handle the conversion to xml and back and the large waste of time that surrounded it. I can now literally do the same thing with less bugs with json in one line on either side.

  6. I love JSON and don’t like XML.

    But I believe JSON does not provide the same “services”.

    90% of time, JSON is not only enougth but better format to exchange data. But JSON lacks a DTD equivalent.

    JSON + an equivalent to DTD for JSON would be perfect. But I see now easy way to declare a database-like information for JSON. You have to check the validity of your data yourself. Which is a task as tedious as to make an XML parser in my humble opinion.

    My own conclusion is, when you are sure of the data you retrive, use JSON. If you have to handle third party data, XML is still better choice for the security of your application.

  7. I didn’t know json was this popular, but seems like an excellent idea.

  8. I think JSON Schema is what you’re looking for…

    http://json-schema.org/

  9. There is a “DTD” format for JSON, though it isn’t very popular, for many of the reasons mentioned in this post:

    http://json-schema.org/

    After all, the main thing it does is get you back into the business of parsing once you had thought you were free of those concerns by moving to JSON. 🙂

  10. I use JSON in my web page and Rails on the server. It is trivial for example to convert a ruby hash into JSON and send it to the web page via AJAX. You can then essentially work with the same exact hash in javascript. Works beautifully.

  11. Do you know about JSON Schema?

    http://json-schema.org/

  12. Hah, what happens when we leave a browser window open for a long time before commenting. 😉

  13. I don’t think it’s because developers want out of the syntax business. I (and hopefully ‘they’) want out of the complexity business.

    Good syntax can make things simpler.

    { “a” : 1, “b” : 2, “c” : 3, … } is also syntax.

  14. Yes, thanks, I didn’t knew it existed. I’ll look to it.

    • A. Schietzsch
    • March 19th, 2010

    Y’know, maybe the world is ripe for a “WebLISP” or whatever you might want to name it. Perhaps someone has already had this thought and created something…

  15. I love it… it’s simple, to the point and keeps everything “frameworked”… I still sent barebones arrays out with requests (they can’t be beat), but for sending objects out it’s great stuff.

  16. Don’t get me started on that shitty XMLHttpRequest() though. That is the worst invention to ever hit ajax… I hate it…

  17. Okay, so it gets rid of some annoying clicks… that’s about it… sorry for the triple post…

    • jj
    • March 19th, 2010

    json is so popular because a new breed of retarded wannabe-programmers (read: the idiots that started with html/javascript/php) are too bad to write proper parsers for xml. heck – they even are too stupid to use existing parsers effectively.

    so they created something as primitive as json. json is an ugly blobbish pile of shit – but it’s so simple that every drooling retard (read: web developers) can understand it.

  18. true and agree. but let’s keep in mind w/ JSON convoluted syntax can also be possible… but agree w/ XML more combinations for same thing is possible and this can be a bad (or good) thing.

    ceo

    • CalmQuiet
    • March 19th, 2010

    Right, no love lost on XMLHttpRequest().
    Long live jQuery!

    • Mark
    • March 19th, 2010

    In the first json sample, the equivalence would be better if it included ‘type’ : ‘person’
    element.

    The point of XML is that it’s possible to identify the meaning of elements, if you specify a DTD/schema or use elements with a well-known/published namespace.

    • Matt
    • March 19th, 2010

    Anyone who seriously has this opinion about a data format is much much worse than anyone who only writes HTML and calls themself a programmer.

    • Pubes
    • March 19th, 2010

    @Jj Wow. Insightful. Excellent arguments.

  19. Nice intro for me. Thank you!

    • cowardlydragon
    • March 19th, 2010

    Keep your postfix notation and obfuscating nested ()’s away.

    • cowardlydragon
    • March 19th, 2010

    schemas are not a silver bullet.

    Inevitably, the validation of data formats involves invoking external programs and external datastores once the data format becomes sufficiently complicated.

    But, an 85% solution is better than nothing…

    • Jesse, Minneapolis,MN
    • March 20th, 2010

    It’s handy for encapsulating arrays/objects into a string. In PHP, it’s a 1-liner. As unconventional as it sounds, I’ve used it for storing an array in a single database field.

    • Ryan
    • March 20th, 2010

    If you don’t like the parens, try this: http://rpw3.org/hacks/lisp/opfr.lisp

    Studies have shown that non-lisp programmers are 67% more likely to accept Lisp if you leave off the first and last parentheses in a statement. Just like web URLs make more sense to people without the trailing dot.

    Also, I should probably reiterate that 47% of all statistics are made up.

  20. You are correct, that utterance is syntax, and you are also correct that good syntax can make things simpler when read and written by a human. What I meant by “getting out of the syntax business” is not having to concern oneself with parsing the syntax (i.e. the string you get over the wire), walking the parse tree (DOM tree) and examining tag names and attribute values in order to manually build your desired object. JSON is not the only way to achieve this, but it does have that feature which, I believe, is at the core of its appeal.

  21. I have seen it – very promising. I plan to mention in my next post on this topic. Thank you Luigi.

  22. One importend point: JSON or XML can transport data with explicit encoding information. With XML you have to declare it – in JSON is utf-8 default.

    An advantange with XML are the tools to validite xml-data (with a dtd), this will come with JSON … if needet.

  23. It’s prefix notation 🙂

  24. I would prefer json over ajax anyday!

  25. I believe both formats have their place in web development. XML for readability, JSON for reducing request size and easy integration with JavaScript. I definitely prefer JSON for transmitting data via Ajax requests.
    -Chris @ webjawns.com

  26. I agree there is a place for JSON, but not as a replacement for XML. The reason XML is so open is because it is a basis for major and complicated data exchange. The kind JSON is not good for. JSON is great in context, but not as a general web data exchange format. Don’t believe me? Craig Riecke has a good explanation of why XML and JSON can co-exist in this month’s PragProg magazine. Especially check out the section “Data Integration is Hard”.

    XML is going to succeed, I think, because it doesn’t make decisions for you–just like Unix doesn’t make decisions for you. (In our case, decisions like “attribute or element? camel case or not?”) It provides a solid framework for representing all kinds of data. Which is why it is also so complicated.

    Anyway, just thought I’d throw in my two cents’.

    I have no stake in this fight, as I don’t do heavy web data transfer. It just seems to me like XML is a good sturdy data option, even if we don’t interact with it directly. (And yes, I’d be okay abstracting it away behind friendlier syntax.)

  27. Without wanting to dispute the relative merits of JSON (which I know very little about) and XML, I would say that XML is extremely good for automatic treatment, information exchanges between different applications, and similar—but is simply not constructed for intense user/developer interaction.

    The fact that it is human readable and editable is a clear bonus, but can mislead people to think that it is something they should work directly with. XML, IMO, belongs further down the abstraction hierarchy where it rarely encounters any human. (Obviously, library developers and the like will eventually have to deal directly with it.)

    A very obvious parallel is HTML: When I am allowed to choose (not always the case) webdevelopment directly in HTML is the exception and most HTML is generated through other types of document descriptions, say a basic markup language (as known from e.g. Wikipedia) or through JSP-style tag libraries. (This comment should not in anyway be seen as a recommendation of WYSIWYG HTML-editors—that is a very different topic.)

  28. @David J. – Nicely said!

  29. Hi there to all, how is all, I think every one is getting more from this web page, and your
    views are nice in favor of new visitors.

  30. I’m really enjoying the design and layout of your website.
    It’s a very easy on the eyes which makes itt much more enjoyable foor me to come here and visit more often.
    Diid you hire out a developer to create your theme? Superb
    work!

  31. When some one searches for his vital thing, thus he/she needs to be available that in detail, thus
    that thing is maintained over here.

  1. March 20th, 2010
    Trackback from : Top Posts — WordPress.com
  2. March 27th, 2010

Leave a comment