( ([o] (o o)) ([o] (o o)) )

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:

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:

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.

Like this:

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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

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.)

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.)

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!