Joel Spolsky has an seminal article entitled Don't Let Architecture Astronauts Scare You where he wrote

A recent example illustrates this. Your typical architecture astronaut will take a fact like "Napster is a peer-to-peer service for downloading music" and ignore everything but the architecture, thinking it's interesting because it's peer to peer, completely missing the point that it's interesting because you can type the name of a song and listen to it right away.

All they'll talk about is peer-to-peer this, that, and the other thing. Suddenly you have peer-to-peer conferences, peer-to-peer venture capital funds, and even peer-to-peer backlash with the imbecile business journalists dripping with glee as they copy each other's stories: "Peer To Peer: Dead!"

 The Architecture Astronauts will say things like: "Can you imagine a program like Napster where you can download anything, not just songs?" Then they'll build applications like Groove that they think are more general than Napster, but which seem to have neglected that wee little feature that lets you type the name of a song and then listen to it -- the feature we wanted in the first place. Talk about missing the point. If Napster wasn't peer-to-peer but it did let you type the name of a song and then listen to it, it would have been just as popular.

This article is relevant because I recently wrote a series of posts explaining why Web developers have begun to favor JSON over XML in Web Services. My motivation for writing this article were conversations I'd had with former co-workers who seemed intent on "abstracting" the discussion and comparing whether JSON was a better data format than XML in all the cases that XML is used today instead of understanding the context in which JSON has become popular.

In the past two weeks, I've seen three different posts from various XML heavy hitters committing this very sin

  1. JSON and XML by Tim Bray - This kicked it off and starts off by firing some easily refutable allegations about the extensibility and unicode capabilities of JSON as a general data transfer format.
  2. Tim Bray on JSON and XML by Don Box - Refutes the allegations by Tim Bray above but still misses the point.
  3. All markup ends up looking like XML by David Megginson - argues that XML is just like JSON except with the former we use angle brackets and in the latter we use curly braces + square brackets. Thus they are "Turing" equivalent. Academically interesting but not terribly useful information if you are a Web developer trying to get things done.

This is my plea to you, if you are an XML guru and you aren't sure why JSON seems to have come out of nowhere to threaten your precious XML, go read JSON vs. XML: Browser Security Model and JSON vs. XML: Browser Programming Models then let's have the discussion.

If you're too busy to read them, here's the executive summary. JSON is a better fit for Web services that power Web mashups and AJAX widgets due to the fact it gets around the cross domain limitations put in place by browsers that hamper XMLHttpRequest and that it is essentially serialized Javascript objects which makes it fit better client side scripting which is primarily done in Javascript. That's it. XML will never fit the bill as well for these scenarios without changes to the existing browser ecosystem which I doubt are forthcoming anytime soon.

Update: See comments by David Megginson and Steve Marx below.


Categories: XML
Tracked by: [Pingback] [Pingback] [Pingback] [Pingback] [Pingback] [Pingback] [Pingback] [Pingback]
http://www.JSON.Com/2007/01/22/xml-is-better-because/ [Pingback] [Pingback] [Pingback] [Pingback] [Pingback] [Pingback] [Pingback] [Pingback] [Pingback] [Pingback] [Pingback] [Pingback] [Pingback] [Pingback] [Pingback] [Pingback] [Pingback] [Pingback]

Thursday, January 04, 2007 12:08:31 AM (GMT Standard Time, UTC+00:00)
Wait, your summary appears to have committed the same crime. Isn't a major reason JSON is getting popular is that it gets around the cross-domain limits of XMLHttpRequest?
Thursday, January 04, 2007 12:21:23 AM (GMT Standard Time, UTC+00:00)
I wrote a whole blog post about that, see the post entitled "JSON vs. XML: Browser Security Model". Since this was the executive summary, I glossed over with the phrase 'makes it a better fit for client side scripting'.

Since you pointed it out, I'll be more explicit and have updated my post with the text in red.

Thursday, January 04, 2007 1:59:29 AM (GMT Standard Time, UTC+00:00)
From up here in my space capsule, at least, it looks like you're still slightly off target:

- JSON is popular for browser-side work because you can pass it directly to the JavaScript eval() function

- the on-demand pattern is popular for browser-side work because it gets around the cross-domain limits of XMLHttpRequest

It happens that JSON and the on-demand pattern are normally used together, but JSON doesn't enable the on-demand pattern (it's actually mainly a DOM/JavaScript hack) and the on-demand pattern works with formats other than JSON (just as XMLHttpRequest doesn't actually require you to pass information in XML format).
Thursday, January 04, 2007 2:04:31 AM (GMT Standard Time, UTC+00:00)
I'll take a totally different tack: XML based protocols have fallen prey to the same committee design, academic input, design-and-decree process that killed the OSI protocols back in the 90's. I'm not talking about the "7-layer model" that many associate with ISO/OSI, I'm talking about the network protocols that were supposed to replace TCP/IP, SMTP, etc. Much VC disappeared down the drain. European academics and PTTs lost much stature and money (respectively).

JSON (and it's lesser cousin, JSEN, JavaScript Eval() Notation) is grass roots, evolutionary, and sweet! Simple is better.
Bob Denny
Thursday, January 04, 2007 2:11:20 AM (GMT Standard Time, UTC+00:00)

First off, it isn't "my precious XML" - I'm just a poor slob who has to use this stuff.

More importantly, I do agree that the ironically-named XmlHttpRequest was the killer app that made JSON happen and why people are talking about it.

That doesn't mean the technical meat isn't interesting though, and I would loathe to see someone neglect to do that part of the due diligence before making a commitment.

That stated, I doubt that the encoding or data model differences are why people are flocking to JSON, despite the fact that those differences are (IMO) favoring JSON more often than not.

Thursday, January 04, 2007 3:55:12 AM (GMT Standard Time, UTC+00:00)
It may be too late for json. There is already JSP(ersistence)ON. Next it will be JSON-Schema, JSONDL, JSON-ReliableMessaging and it'll all be done in Rhino. In the mean time, I'm having fun with it. Just don't tell anyone that with XUL being mostly javascript and markup, JSON works with Firefox extensions and xulrunner apps. Even though these don't have the cross-site limitation and they do have e4x, I'm finding JSON very useful (and fun) in the mozilla world. Maybe it's just the fun. XML was fun. Not so much anymore. And with python coming as a native Moailla/XUL language (chrome:// only, not http://), there will be even less incentive to use XML.
Thursday, January 04, 2007 9:06:56 AM (GMT Standard Time, UTC+00:00)
Dare, you're still confusing JSON with the "on-demand" pattern, as David points out in his comment. I want to elaborate a little just to make it clear to everyone reading.

To get around the browsers' same origin policy, some web services return (from a GET request) text of the form "foo(...)", where the data from the web service call goes inside the parentheses. The idea is that then a consumer of the web service can define a function called foo() in JavaScript and then use a script tag to fetch the data. The data will then get passed to the foo() callback and processed.

Now, the format of the data passed back is often JSON, because JSON is a convenient format if the client is JavaScript, but it could be foo({"people": ["Dare", "Steve", "David"]}) or foo("Dare", "Steve", "David") or foo("people!Dare|Steve|David") or foo("[people][person name="Dare"][person name="Steve"][person name="David"][/people]"). (That last example is meant to be XML, but I switched the angle brackets to square brackets to get around the form validation.)

Put simply, choice of wire format is orthogonal to getting around cross-domain limitations.
Thursday, January 04, 2007 1:25:37 PM (GMT Standard Time, UTC+00:00)
David and Steve,
I've updated my post (again) and referenced your comments. Thanks for your patience with me. :)

I hope that answers your original question. JSON isn't needed to get around cross-domain constraints, however it is VERY CONVENIENT to return JSON instead of XML. For example, see what Jason Levitt has to do in to return XML in his article on the On-Demand Hack.
Thursday, January 04, 2007 4:00:11 PM (GMT Standard Time, UTC+00:00)
It is the convenience in JavaScript world that makes JSON a popular choice. IMHO, comparing JSON and XML as "general purpose" encoding formats would be premature. If we just take out JavaScript from the picture, how would one justify JSON over XML today?

Thursday, January 04, 2007 4:37:10 PM (GMT Standard Time, UTC+00:00)
Sounds like we're going full circle back to Smalltalk's original strengths: dynamic in both code and data, and communication/storage at the object level.

The Croquet Project seems to be working very hard at peer-to-peer everything. You can listen to music just by walking by in the peer's world that hosts it. All Smalltalk developed. All reprogrammable in real time while experiencing/running it. All duplicated/synchronized code execution and not just duplicated/synchronized data, on any OS. It also has a built in IDE with every client.
Thursday, January 04, 2007 5:23:49 PM (GMT Standard Time, UTC+00:00)
Part of what makes JSON appealing is that you don't have to deal with the differences in XML support between the browsers. I'm very happy to see that the basic XmlHttpRequest (beyond the way to create the object) are pretty consistent, but once you get into the DOM itself the level of support between IE, Firefox and Safari varies quite a bit. Back in '99 and 2000 when we were doing the first AJAX stuff in OWA we only had to support IE5 which made that part much easier.

Ironically at the time we explored using lots of non-XML stuff, although it was mostly HTML that you could then interpret as having special characteristics (IE lets you put arbitrary attributes in the HTML DOM and treat them as data). This was mostly for performance reasons since the cost of parsing the XML, transforming it into HTML and then re-parsing that was pretty slow, at least on the machines of the time.

Hopefully everyone knows by now that XmlHttpRequest is only called _Xml_ because that was the easiest way to ship it at the last minute in IE5. Chris Lovett and Jean Paoli saw the potential in this and helped make it happen.

Thursday, January 04, 2007 9:11:40 PM (GMT Standard Time, UTC+00:00)
Sure, JSON is nice up to the point when you want to plug something different than a browser to your web-service ... Or up to the point someone start to ship a better language than JavaScript in the browser (python, ruby ?)
Friday, January 05, 2007 2:00:26 AM (GMT Standard Time, UTC+00:00)
Thanks it helps me a lot…

I think these blog is really useful for new comers and Excellent resource list.
Friday, January 05, 2007 11:58:16 AM (GMT Standard Time, UTC+00:00)
How can i find owner of this blog?
Friday, January 05, 2007 10:40:53 PM (GMT Standard Time, UTC+00:00)
LOL. All this reminded me of all the crap the 'Simpletons' received when SML-DEV was in full swing. What I learned from that experience was that technical discussion without similarity in value system is pointless because, even if we all agree on what's in the shopping cart, total sum will be different for everyone.
Saturday, January 06, 2007 4:34:58 AM (GMT Standard Time, UTC+00:00)
Too many buzzwords and phrases for my liking. I guess being a sheep will lead to a promotion.
Jim s
Monday, January 08, 2007 4:11:13 AM (GMT Standard Time, UTC+00:00)
Is it just developers who favor JSON?

If I am a content provider and I give you XML over the wire, you are free to do what you please with the data.

If I make you use a script tag to fetch data, I have the option of not just passing data, but data and behavior (code). This gives me (the content provider) more control over what happens with my content and how it appears in your mashup.
Comments are closed.