Asynchronous JavaScript plus XML, or Ajax in marketing lingo, has gotten lots of attention lately. Jesse James Garret coined the term in his essay “Ajax: A New Approach to Web Applications”. Ajax is far from innovative. Developers know Ajax as remote scripting. From a thorough summary of different remote scripting techniques and technologies read my post on how to create a Google Suggest like feature with ASP.NET 2.0. This post speaks of a concept called “Chubby Clients”, this is a term I came up with to describe “Ajax” applications. The difference between “Chubby Clients” and Ajax is that I never tried to give the impression that this was something new that I had invented, it was a term meant to underline that applications relying on server callbacks and excessive DHTML usage where fatter than traditional postback based web applications, yet slimmer than traditional desktop clients.
I wrote my first “Ajax” application in late 1996. This application used a hidden frame to issue GET requests to a CGI script on the server. When I demoed this application to more seasoned developers, whose experience reached back to the days of green screen terminals, they were intrigued by the fact that I did asynchronous communication in the modern world of web development. My frames and JavaScript based protocol was more familiar to these COBOL programmers than the request / response pattern of HTTP. This goes to show that there is nothing new about Ajax, neither conceptually nor technologically. When I do my “Chubby Client” presentation I clearly state that the concept should only be used when the request / response model doesn’t provide a rich enough user experience and building a Smart Client isn’t an option.
As with all software, while a simple “Chubby Client” is easy to build, more advanced enterprise “Chubby Client” applications are not. This is probably the main reason why we’ve seen so few successful web sites using XmlHttpRequest to do out-of-band communications between the browser and the server. I’m not surprised to see Google’s top-notch developers creating working “Chubby Clients”; I would be surprised to see “Joe Developer” do the same. Having years of experience with leftfield web technologies, such as different forms of remote scripting, I can assure you that while these techniques solve lots of challenges, creating applications that apply them is time consuming, debugging such applications is hard and supporting them is a nightmare. There is a discussion on The Server Side on whether “Ajax” will render Smart Clients obsolete. It won’t, but the emergence of Smart Clients will blur the boundaries between web applications and Windows Forms applications. This will raise the bar for what kind of behavior users will except from departmental applications, such as accounting systems, developed as web applications. If such applications are to survive as web applications, the user experienced must be enriched. Fattening the applications and transforming them into “Chubby Clients” is a viable option although the best solution is converting such applications into Smart Clients. Traditional portals et cetera won’t have much to gain by fattening the user interface, so they’re like to stay as they are.