Asynchronous JavaScript And XML is a strange little beastie. It’s a concept that all modern web browsers can exploit in order to make client-server applications that run in the browser but don’t require a page re-load each time you do something – yet it’s not all that well-known or well-used.

The average browser-based application If you want to produce a browser-based application that uses resources on a server, there have traditionally been two models you could use. First, you can produce a standard web application, which has HTML pages as the GUI and which, whenever you click something, calls the server with a URL and/or some parameters and their values in order to do the requested task and get a new screen of information. Alternatively, you can write your program as some kind of downloadable applet (typically in Java if you want it to run on multiple client platforms).

You can, of course, do some client-side operation in order to avoid the delays of having to make a page request to the server every time you do something. It’s common to use JavaScript to do things like checking the validity of form input, for example, or perhaps to manipulate imagemaps (clickable images where what the system does depends on whereabouts in the image you clicked). You can also do some more advanced client-side stuff (such as making page elements visible or invisible on demand, changing colours or whatnot, using Dynamic HTML concepts).

What not many people know, though, is that you can in fact implement an entire client-server application using JavaScript. Want to check that a customer record exists, or process a credit card payment, or handle a purchase, without having to do a page refresh? No problem.

The XmlHttpRequest object In order to produce a client-server application, you clearly need the ability for the client application to communicate “behind the scenes” with the server – that is, to make an IP connection or similar and have some kind of discussion with the server that the browser (and the user) aren’t really aware of. The way to do this is the XmlHttpRequest object.

The name of this thing pretty well explains what it does. It makes an HTTP connection to the specified server, sends a request, and receives a reply that you can then dig through in order to pull out the data you asked for. The thing to bear in mind, though, that this HTTP request isn’t a page access – that is, you’re not clicking a link on the web page and loading a new page from the server. Instead, it’s simply the JavaScript making a connection to a server somewhere (which isn’t even necessarily the Web server the page came from) which just happens to be on port 80 and just happens to use the HTTP protocol because these are (a) well-understood; (b) ubiquitous; and (c) generally permitted through firewalls.

The good bits and the bad bits AJAX’s main benefit is that you can significantly enhance the look-and-feel of browser-based applications by massively reducing the number of page loads, and without having to make the user download some kind of widget such as a Java applet (which requires a JVM to be installed on the client) or an ActiveX object (which is platform-specific and will be blocked by many people’s browsers). But are there any downsides? Of course there are – there’s no such thing as a perfect concept in computing. We’ll look at the three main ones.

First, no matter how fancy the back-end functionality of your program is, there are limitations to what you can do with a browser in terms of screen output: you’ll always be able to do more with a desktop application using native graphics libraries. Additionally, when you consider how abysmally the majority of browsers deal with graphical concepts such as CSS2 you have some more limitations with what you can do graphically.

Second, there’s JavaScript and there’s JavaScript. In some ways JavaScript is a maligned language, regarded as the slightly sickly little brother of Java – yet it’s actually quite an extensive language (something I first realised when I noticed that the JavaScript book I’d bought was the same thickness as the VB.NET). Trouble is, though, different browsers have subtly different ways of representing data in JavaScript – the classic example being that browser A might represent a year as a physical number (so this year would be 2006) while browser B represents it as a number of years since 1900 (making this year 106). So you have to program your way around the differences. Worse still, this issue applies to other aspects of browsers such as CSS: a colleague I worked on a project recently rarely stopped moaning that half this job was writing the bits of code that said: “If the client browser is X, do this, or if it’s Y do that, …”.

Finally, although it’s true that JavaScript is a surprisingly rich language, it was devised as a way of extending browser functionality, not really as a stand-alone application development language. This means there’ll always be some element of trying to achieve what you want despite JavaScript’s functionality, not because of it.

Conclusion Notwithstanding these downsides, though, AJAX is a bloody brilliant concept. It uses features that have been included in browsers for donkey’s years (Noah used IE5, after all) and the XmlHttpRequest object is straightforward to use, even if you do have to expend a bit of effort bundling and unbundling XML stuff at each end. Not only this, but as it grows in popularity there’s a growing amount of software being produced that makes it simpler to write AJAX applications: even Microsoft has leapt on the bandwagon with its Atlas Project which is rarely a bad sign for developers,

As with any programming language or development system, AJAX isn’t right for every application. But for something that works, UI-wise, as a browser-based system but could benefit from more page interactions with less waiting for page loads, it’s well worth a look.