Web Development optimize

AJAX: The Right Goal, but Often the Wrong Tool


I think I am beginning to come to terms with AJAX. Frequent readers know how much I dislike it. Joel Splosky ("Joel On Software") wrote a good piece recently (FogBugz 4 1/2 and Subjective Well-Being) that has helped turn me around, but only slightly. Joel helped me see where my anti-AJAX crusade is unproductive. AJAX does have the right goal in mind, but I still think that it is a poor technique for accomplishing it.

What Joel (rightly) points out is something that I harp on a lot, which is that the user experience is what it is all about. AJAX holds out the promise of much quicker response to user input, which is a prime factor in user satisfaction. AJAX also allows user interactivity that traditional Web applications do not provide, such as drag and drop and right click functionality.

What Joel misses though is the technical issues with AJAX. As Roger Ramjet (frequent ZDNet commenter) says, "JavaScript is the COBOL of Web development." I would like to add to that, "AJAX is the Yugo of programming techniques." Sure, it can get you where you want to go, but you really will not enjoy the ride. In this case, the destination is a great user experience, and the ride is the development process.

When you mix "the COBOL of Web development" (JavaScript) with "the US national budget of data transfer mechanisms," (XML), you get "the Yugo of programming techniques." AJAX combines a slow language that has many mildly different implementations with a bloated way of transferring data, and tries to display it on the screen with a system that still will not reliably display the way you want it (HTML). This just makes no sense to me.

Many AJAX proponents that AJAX is the only way to achieve these goals. I believe that this is incorrect. Remember, the goal is to provide a great user experience. Does drag and drop or right click add much value to the user? Yes, but only for some users. The majority of users do not use drag and drop or right click unless they have been taught to do so in a particular application. Users are timid. They do not try things outside of the ordinary. So to add this functionality is an incredible amount of work for no gain for most users.

So I am softening my stance a bit. If AJAX can be used in a way that the problems with JavaScript and XML do not hinder it (small chunks of data, basic JavaScript functionality) then it is a perfectly fine technique to use. But to try to replicate full rich client functionality just does not work. Microsoft has discovered this with the Live.com development. They reached very far, and had to drop the XML end of things in favor of JSON; XML parsing was taking far too long on the client side. AJAX can deliver usability benefits, but only when used appropriately and carefully, and the cost of development must be weighed against the expected utility.

J.Ja

About

Justin James is the Lead Architect for Conigent.

1 comments
Hendry_Betts
Hendry_Betts

Justin, you are such a victim here. AJAX was never meant for more than data transactions. Many of these "usability" tools contain a little ajax and a lot of crap (old DHTML dogs wrapped in new, shiny, heavy graphics) Dojo, scriptaculous, MooFx... all of them... have _ONE_ AJAX request. And any component that they have that doesn't interact with a remote data source is not an AJAX component. It is a UI component. Don't get me wrong. They have their place and can make some dog ugly applications seem friendly ... but if you put lipstick on a pig... it's still a pig.