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).
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 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.
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.