AJAX: Making Web Pages Responsive
By Martin Heller
September 12, 2005

In my July column, I touched briefly on AJAX, in the context of Ruby on Rails and the Microsoft Atlas announcement. I'd like to expand on that a bit.

As I said in July, AJAX (Asynchronous JavaScript and XML) is built on Dynamic HTML and client-side scripting, and gives you lightweight client-side code that lets you update a page without a server round-trip. What's added in AJAX over DHTML is the use of the Microsoft XMLHttpRequest object to interchange and manipulate data asynchronously with the Web server.

I have since learned that the XMLHttpRequest object was introduced by the Microsoft Outlook team to make Outlook Web Access (OWA) more usable. It's more usual for journalists to talk about Gmail and Flickr when they discuss AJAX, but let's give credit where credit is due: it was a Microsoft innovation at its core, and it's several years old.

AJAX has been popularized by, among others, Jesse James Garrett of Adaptive Path, who coined the term in a February 18, 2005 article, which gives a pretty good overview of the technology. I also recommend the Wikipedia article on AJAX programming, which not only explains the model but also has a good list of external links for AJAX articles, portals, scripts, and libraries.  

var xmlHttpReq = new ActiveXObject("MSXML2.XMLHTTP.3.0");
xmlHttpReq.open("GET", "http://localhost/books.xml", false);

So, the XMLHttpRequest object provides a client-side protocol support for communication with HTTP servers. Why is this an advantage? Because the client-side script can update only the information it needs, instead of going through the overhead of refreshing the entire page from the server. The other advantage is that you can make the callback asynchronous.

Think about it. If I'm using OWA or Gmail, my current web page has a list of my e-mails (say, the first 100 of 3,000), plus some preview information, plus a bunch of user interface controls. Refreshing all of that stuff takes a noticeable amount of time: when I first log into OWA or Gmail, I have to wait while the page loads, even if I'm using a fast FiOS, cable, or DSL connection. With broadband, it's only finger-drumming annoying: over dialup, it's try-not-to-throw-things unbearable.

Once the page is up, however, updating one item can take under a second. Why? What's happening under the covers when I mark an item as read?

First, the client script handles my mouse clicks and the local interface. In OWA, that's a right click, a menu popup, and a left click, all handled locally on the client. In Gmail, that's a left click on a checkbox, a change of color for the affected message, a drop-down menu, and a left click, also all handled locally on the client.

Then, the client script sends an XMLHTTP request to the server for an update to just that item, gets back the new item from the server, and updates the item on the screen using Dynamic HTML. This is still subject to some round-trip delay, but the amount of information transmitted and the amount of processing required are reduced both at the server and at the client.


As AJAX libraries of varying quality and pedigree began to proliferate, it was inevitable that a commercial tool vendor would introduce one. At this point Microsoft has only announced the Atlas project, and won't even demonstrate it until this week's PDC conference. I have an appointment with a third-party software vendor to discuss a RAD tool for AJAX at around the same time, but they haven't even announced their product yet.

On the other hand, telerik has not only shipped a set of AJAX-enabled controls, called r.a.d.callback, it has already shipped its first hotfix to that package. (Is a quick hotfix good or bad? I guess it depends on the subtlety of the bug being fixed.)

I first encountered telerik, a Bulgarian software development company with an office in the Boston area, when I was looking for a rich edit web control for a project I was beginning last spring. Microsoft has a rich edit web control built into OWA, and another built into Commerce Server, but doesn't make either available to developers. telerik filled the gap with a product called r.a.d.editor; you can see a demo of that here. I was impressed with the functionality of r.a.d.editor, but concerned about the slow postback times I saw in my own experiments with complicated pages.

When I asked the telerik product manager about his plans for AJAX-enabled controls, he let me know that they were already in the works. I didn't beta-test them, but I got a license and downloaded r.a.d.callback within a few days of its release.

The general idea of r.a.d.callback is that it is a set of AJAX-enabled substitutes for standard WebControls. These make lightweight callbacks using XMLHTTP requests instead of heavyweight postbacks. The biggest trick involved in implementing AJAX well is making it work on all the major browsers. According to telerik, r.a.d.callback works on all browsers that support XMLHttpRequest (Internet Explorer 6.0+, Netscape 6.0+ and Mozilla FireFox 0.6+, Opera 8.0.2+). If the browser does not support XMLHttpRequest, the callback is performed using IFrame (Opera 7.0).

The r.a.d.callback controls interact well with other standard controls. If you have a web form that only needs to do a callback when the user presses a button, the only control on the form that needs to be from the r.a.d.callback kit is the button: instead of a standard button, you'd use a CallbackButton. On the other hand, there are some issues with the way r.a.d.callback controls interact with more complicated controls. To handle this at least within its own product line, telerik will be issuing a service pack for r.a.d.controls Q3 2005 to improve the integration of its heavyweight controls with its callback controls. While the callback controls are supposed to work with other third-party controls, your mileage may vary.

telerik is also promising a new version of r.a.d.controls for the middle of September: a first beta of the controls for Visual Studio 2005. These will have declarative DataSource support, support for Themes and Web Parts, and better design-time integration with the Visual Studio IDE.

The middle of September promises to be an interesting time to be a software developer. Stay tuned.

Continuing Education Department

The education being continued is mine. Last April, I reviewed Parasoft's Jtest 6.0 for Developer Pipeline. On the second page of the article, I said "Other times, you can use Jtest's test-case sniffer to generate realistic tests by monitoring an actual run of the program."

Well, I was speaking theoretically. In the heat of writing the review under deadline pressure, I tried running the test-case sniffer mentioned in the documentation, but couldn't find it in the product. I asked the company about it, but couldn't reach the right people in time, and so left the mention as it was, given the company's fair dealings with me in the past. In hindsight, I should have struck the sentence.

Now I know what happened: the feature was dropped from the product at the last minute. It has since been perfected, and is the major new functionality of Jtest 6.5. While I haven't tried it myself, I have watched it in action in a web demo, and I must say I'm impressed. I may not be happy with Parasoft about the previous confusion concerning the test case sniffer, but now that it has been released, I think it's worth a look from any serious Java shop.


Martin Heller is a Web and Windows programming consultant, an author, and a Senior Contributing Editor at BYTE.com. His most recent publicly viewable project is PC Pitstop. You can reach Martin at MrCLP@mheller.com.

Copyright 2005 CMP Media LLC

Questions or problems regarding this web site should be directed to abeckman@outdoorssite.com.

Copyright 2008 Art Beckman. All rights reserved.

Last Modified: March 9, 2008