AJAX One: What it is, and isn't

Let me establish one thing first: Asynchronous Javascript And XML is just a codeword. It's not a technology - In fact, it's the combination implementation of a couple of technologies that have existed for a long time -, and it's not necessarily necessary (or even useful!) on many websites. What it can be is a very useful way to increase the interactivity of web based applications... when used effectively.

First, lets talk about the XMLHttpRequest, the driving force behind AJAX. W3C defines the XMLHttpRequest object (implemented in both JavaScript and JScript) as follows:

The XMLHttpRequest interface can be used by scripts to programmatically connect to their originating server via HTTP.

Basically, the XMLHttpRequest is a way for a script (generally executed on a client machine after the document has been fully loaded) to get information from its server without reloading the page. As far as the end user is concerned, this means the buttons and links are more "interactive". Also, as I'll discuss in "AJAX Two: Building a basic request", Microsoft and Mozilla have come up with different implementations of the XMLHttpRequest.

You'll notice there is nothing in W3C's definition of the XMLHttpRequest mentioning (a)synchronous execution. Frankly, this is because the execution style isn't a integral part of the object. "If that's true," you may find yourself asking, "why is the standard AJAX and not some synchronous brother? There's got to be something to this asynchrosity." You're absolutely right, the ability to make our requests asynchronously, or outside of time, makes everything faster for the end user.

Let me interject myself for a moment to distinguish between the two request styles: Simply put, a synchronous request (or operation of any kind for that matter) is one that must complete before the next operation begins. An asynchronous one is just the opposite: one that does not need to be completed before execution continues on the page. This is made possible via the response handler function (onreadystatechange) assigned to the request object before it is opened. Every time the request changes its ready state (eg progresses in retrieving the data) it calls the assigned function.

That means, though it may seem counter-intuitive, an asynchronous request can actually speed up a web page. Imagine a site that wants to display data about football players on over four thousand pee wee teams nationwide (for early college recruitment of course). Each record takes about two seconds to retrieve, but may take up to fifteen on slower connections. So, on a quick connection (two seconds) there's only a small potential difference between the synchronous and a- versions of this request... but on the slow connection (fifteen seconds!) the entire page halts while the request is processed if it's not asynchronous!

I do not mean to suggest that synchronous requests are useless, in fact, I use them almost as often as a-'s. A synchronous request should be used in any situation where the processing of the request must be completed before the next operation commences. Take for example a dialog box that needs to close after it processes an XMLHttpRequest POST operation. If this is attempted asynchronously, the request will have no way of calling its response function (which is destroyed along with the closed window) and will report a component failure.

One final note on AJAX before I click the magic "PUBLISH" button (!). Adding it to a website because it's "cool" or a "fad" without understanding why, or how, is akin to adding a mortgage calculator to your sports blog for the same reason. Don't do it. There are many amazing applications of AJAX (Google's GMail for instance relies heavily on them in creating their UI), limited only by the ingenuity of the programmer. They do not include retrieving a script file or stylesheet which can just as easily be loaded with the original document.

If your website could be made better through the use of XMLHttpRequest's (AJAX or otherwise), by all means use them... but learn them and understand them first. Doing otherwise is like publishing an ASP/IIS programmer trying to publish an Apache/PHP website with no prior experience (in other words, laughable).