Mashup Data Formats: JSON versus XML/XMLHttpRequest

It’s not the latest sequel to the “Jason versus Freddie” movie, it’s one of the decisions you need to make if you’re rolling out a Web 2.0 product. Make the wrong choice, and your project and reputation can suffer. Make the right choice, and you can be a hero. There aren’t any easy answers, but I can take you on a tour of the technology and the decisions involved so you can make a better-informed choice. During our tour I promise you won’t be attacked by a man in a hockey mask, so sit back and enjoy the ride.

On one side, we have the XML/XMLHttpRequest camp. It uses the world-wide XML standard for data. It also involves using the XMLHttpRequest capabilities of most all browsers to retrieve information from a server. We use the XMLHttpRequest object to get XML from our server. So when we say XML in this article we really are talking about both the data format and the data transportation pattern: the two are tightly linked in this area. Due to security concerns, the server has to be in the same domain as the web page. We gotta own it. So if you’re viewing a page from www.bugscratch.com, you can get data from the server at bugscratch.com, but not at weasels.bugscratch.com or at weasels.com. To get around this limitation, you have to use a proxy server: clients hit your bugscratch.com server and then the server goes to the rest of the web and finds information to return to the client. Processing happens asynchronously – your users can continue browsing the page while your code goes off and fetches information. Nearly everybody is a big player in this arena, including Microsoft, IBM. If you can name a big software company, they’ve got an AJAX XML toolkit.

On the other side, we have the JSON camp. JSON stands for JavaScript Object Notation. JSON is a way of formatting information so that it is native JavaScript. It’s not associated with any kind of data transportation pattern. When your data comes back from the server, it’s already in a JavaScript object format. Many developers consider JSON easier to read than XML, although personally I find them both equally readable once you get used to them.

So how can you compare a data format with a data transportation system? Aren’t they two different things? Can’t you just send JSON inside your XML? And isn’t this all called AJAX anyway? AJAX stands for Asynchronous JavaScript and XML. Where’s JSON in that?

As they used to say in a show when I was a kid, “grasshopper, you have much to learn.”

First, you can just embed JSON in your XML and badda-bing, badda-boom, you got both technologies. But you can also send JSON directly from the server to your browser, without any XMLHttpRequest object. You ask the server for information, and it sends you pre-formed Javascript Objects ready for you to use. JavaScript is not just data – you can also put methods and all sorts of goodies in JSON format. Would you rather have XML or pre-formed JavaScript objects? It probably depends on what you want to do with them. At the lowest level, if you are taking the XML and applying XSLT to make XHTML, then XML is better. On the other hand, if you are making procedural decisions in your JavaScript based on objects and their values (or methods), then JSON has the edge.

The plot, however, thickens. Because JSON is transportation-independent, you can just bypass the XMLHttpRequest object for getting your data. Bypassing the XMLHttpRequest system is an interesting option that you may have not considered, and in my opinion it is the primary benefit of using JSON. The acronym AJAX doesn’t really work that well for this pattern, however. I suggest we call such systems XJAX systems, as I explain below.

Meanwhile back in the XML camp, one of the great benefits is that it seems like everybody is working over here. If you want to buy a package that does it all, you can find a lot to peruse. For most of us, we want something to take out of the box and start using, and the XML/XMLHttpRequest guys have it. And they have a lot of it. You can get big, full-featured, big functionality systems. Plus you’ve got a company to back you up in case of trouble. For the Microsoft fans, Atlas is rolling out. Infragistics is AJAX-enabling their suite. Even smaller companies like RicherComponents are stepping up to the AJAX plate in a big way. For you Linux folks, just name the big player and they’re there: IBM, Sun, Opera. And let’s face it: if you still want JSON, just stick it in the XML on the way back to the client. These are some powerful benefits for most consumers.

In addition, we’re not just talking toolkits operating at the lowest level. Some of these suites have fully formed tool groups that do all sorts of neat things for the client. It’s truly turn-key development: complete packages that snap right into your development environment.

XJAX, however, has a secret weapon in its toolkit which is as just as powerful. Since JSON is legal JavaScript, you can get it from anywhere. After all, you can’t very well have a world-wide web only running programs from one server, can you? Everything has to interoperate. When you put a Technorati link on your site, you’re running a bit of code from the Technorati site every time a user visits your site. Same goes for Google Analytics, or any of a zillion other examples.

So that means when you use JSON, you can get data from anywhere, not just your own domain. There’s no more proxy server nonsense. [Insert long argument about security here, which I will not cover for the sake of brevity] There is also a subtle change to the business model which might have a big impact. It means the old concept of server-based development is changing. Why’s that?

Most of these companies offering solutions are offering server-based solutions. That is, you install something on your server which then delivers JavaScript code to the client to make all the good stuff happen. (Yes, there are companies offering AJAX products on the web, but this is a development discussion, not a product discussion) The assumption is that companies sell toolkits to developers which then install it in their development/test/production system. Sales are made to folks who write stuff on the server. The products, for as much functionality as they provide on the client, are really just server products. All the instructions will be how to configure your server to use the tools, how to write programs on your server to make the client act in such-and-such a way, etc.

The world has changed. When I wrote my latest Web 2.0 application, it was a toolkit for bloggers. (shameless plug: visit batBack and check us out! It’s the coolest blogging toolbox on the web today!) If you were writing a blogging toolkit, the traditional way would be to write some server tools for a blogging engine, say MovableType and PHP, and then sell the toolkit to people who used the server tool MovableType.

But think about it – do I want to provide a product to folks who own a certain server, OS, and blogging system? Or am I providing a product for all bloggers to run on whatever blog they have? My customer is any blogger or reader – the world of blogging -- not people with a certain server system or browser. I am making solutions for a certain problem domain, not a certain technology domain. I want folks to add just one line of Javascript to their blogging template and have a complete blogging toolkit no matter which blogging engine or browser they are using. This is a major change and you should be aware that it is happening.

XJAX and JSON lets me do that. You can call it “serverless” programming. Users drop small pieces of JavaScript into their HTML to get big functionality. XJAX stands for X-domain JavaScript And XML (Yes, you can still send XML inside your JSON.) Sure, there is a server, but the server isn’t the key element in the food chain anymore. In fact, from the web developer’s standpoint, it’s just a minor player. You can take a server system that does one thing well – say deliver blog content to browsers, and add dozens of gadgets and whizbangs without having to be a server developer or being concerned about server tools or environment. Outsource the trivial commodities, grab the functionality for free, and concentrate on your goal and not the development details.The world has changed. If you’re a developer, Average Joe is taking your place, and the reign of the server is ending as we know it.

I don’t want to make this sound like a knock-out for JSON, because it’s not. I’m not aware of very many XJAX toolkits out there except for mine. Dave Johnson has some of these same ideas over at eBusiness Applications. Yahoo is also working in this area, and you should check out their JSON API.  It’s good to be in the lead, and this is one of those situations where the problems and technology come together in exactly the right way to catch on fire.

You should also consider that there is a lot of corporate development in which you own the browsers and you own the servers. You need to get up to speed and working right away. Having one vendor control all the processing on the browser is not a bad thing.  Who wants to go through brutal low-level Javascript coding if they don’t have to? (Trust me, you don’t.) For those shops (who are the majority) I would say find a good AJAX company and product and enjoy.

JSON has benefits too, as we’ve shown. If you’re doing something a little more free-form, if you’re looking to push the envelope of what’s possible, then I would go the JSON route. Whatever your choice, be aware that having preformed JavaScript delivered to your browser, as Martha Stewart would say, is a good thing. In the duke-out between JSON and XML there may be no knockouts, but there are a lot of points scored by both sides.

Some of the technologies mentioned here may be covered by intellectual property law. You should contact the author if you have further questions.