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.
As they used to say in a show when I was a kid, “grasshopper, you have much to learn.”
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.
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?
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.
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.
Some of the technologies mentioned here may be covered by intellectual property law. You should contact the author if you have further questions.