With the advent of Google Suggest it seems that the industry has deemed that client-side XML HTTP is ready for the prime time. The technology is nothing new, of course, and has been part of every server-side developer’s standard toolkit for years, but whilst some browsers have maintained support for XML HTTP for a few years, it’s only recently that support has been widespread enough to utilise.

Interestingly enough, the XMLHttpRequest is not part of any public standard. The W3C DOM Level 3 ‘Load and Save’ spec covers similar ground, but you know how long these things take to get implemented. At the time of writing, if you need to use XML HTTP from a user agent, then the XMLHttpRequest object is the only way you can do it.

So what is XML HTTP?

The idea itself is very simple. By using JavaScript, a web page can make requests to a web server and get responses in the background. The user stays on the same page, and generally has no idea that script running on the page might be requesting pages (using GET) or sending data (using POST) off to a server behind the scenes.

This is useful because it enables a web developer to change a page with data from the server after the page has already been sent to the browser. In a nutshell, this means that the page can change based on user input, without having to have pre-empted and pre-loaded that data when the page was generated.

Example: Google Suggest. There’s no way Google can have any idea what you might be about to search for, so when you start typing, JavaScript in the page sends the letters off to the server and gets back a list of suggestions. If the JavaScript wasn’t able to talk to the server, the page would have to have been created by the server initially to hold every single search term you might type – which would obviously be impractical!

So what can we use this for?

Obviously, the technology has a place in creating a better use experience in terms of user interface. That is not its primary use, however. Its primary use is reducing load on the server.

That may sound mad considering that, in the example of Google Suggest, an additional request is being made to the server with every letter you type. Surely that increases the load by a magnitude, no? Well, no. Each ‘suggestion’ list served by Google is a very inexpensive list to produce. It’s not particularly time sensitive, and it’s not computing anything to get you there – it’s simply giving you a snapshot of a search phrase list sorted alphabetically and then by PageRank (or something similar, but it’s just a list).

Consider what happens if you don’t make a selection from the list and you keep typing. You perform your search and get back 6 million results – no problems there. But if you made a typo, Google’s just had to retrieve 6 million results that you have no need for. You retype and get the 6 million results you’d originally hoped for.

Now consider what happens when you do pick a selection from the list. Well, first thing is that the list doesn’t contain typos, so that problem has been eliminated straight off. Presuming that you clicked on the item you intended to select, you get a perfect set of results straight off. More importantly, however, is that you get a set of results that Google’s already got. Because you pick from the list, there’s no need to reperform the search.

An example

Take the example of searching for information on Britney Spears’ undergarments. I might think of searching on “Britney Spears knickers”, but if I see “Britney Spears panties” in the list, then I’m going to go ahead and select that instead. If Google already have a search for “Britney Spears panties” cached (and believe me, they do) then the reduction on load on the server for retrieving that search vs performing a new search on the uncached “Britney Spears knickers” is significant.

Side note: I checked both of the above search terms, and yes, they both appear in the list. I’d like to say I’m shocked, but amused will have to suffice. Interestingly, this proves the suggestions aren’t more than a simple list lookup (i.e. they’re not intelligent), as a search for “Margaret Thatcher panties” yields no such suggestions.

So, another example on how this technique reduces load. Say that you have a couple of select lists on your page, and in a drill-down style the user’s selection in the first list determines the options available in the second. There are two traditional ways to do this. The simple method, if the number of permutations for the second list isn’t too great, is to pre-load all the options as arrays when the page is built. Of course, for many applications this simply isn’t practical, as either the permutations are too great or are too lengthy to preload into the page at build time. In this case the second option is to have JavaScript post the entire page back to the server after the first selection is made, so that on the reload the server can build the second list with the appropriate options.

Now, this practise, especially the second option, doesn’t sound too heavy on the server. Consider the case, however, where the page containing the two select lists holds a much larger form with all sorts of data that has to be retrieved from a database and processed for display. Some of the other data might contain complex calculations or enormous queries that are very expensive to run. Consider also the amount of work involved in a simple post-back of a large form. All the data has to be re-read from the post and written back into the form in case the user is part-way through completing.

By utilising XML HTTP to fetch the options for the second list behind the scenes, you not only make the experience a little more slick for the user (no page reloads), but you also reduce the load on the server as it doesn’t have to rebuild that page.

Unifying front- and back-end processing

Another neat trick you can perform using this technology is using the server to perform any tricky processes that have until now been left to the client.

Take the example of input validation. In modern web apps, all validation of user input is typically performed twice – once on the client with JavaScript, and once at the server in case the client-side process failed. What this means is that the validation routines have to be written twice and maintained in two places. That’s ok if it’s just a case of checking the user has entered their surname, but if the process is any more complex than that (consider evil numbers with checksums etc), you’re into writing two bits of code to do the same thing.

If you use XML HTTP to tackle this problem, any complex validations with their checksums and wotnot can be posted off to the server during the validation routine, and the server can check it using its own process (the same processes it will re-check it with in a fraction of a second’s time) and spit back a result. And that, as they say, is magic.

So what does it all mean?

Well, now that Google are at it, every bugger’s gunna want it. We should prepare ourselves for an onslaught of badly implemented assisted searches with filthy client-side code the likes of which have not been seen since some utter twit figured it’d be a nice idea to create drop-down navigation using JavaScript. If it’s not on DynamicDrive already, give it a few days.

For us, it means that we should be reading up, trying it out and adding the technique to our ever-expanding toolbox o’tricks. XML HTTP is a useful device and certainly one that it pays to be aware of, especially when it comes to reducing the amount of work your servers have to do. What it’s not is some big revolution that’s going to change the way we build web apps. It will help us build better ones, but you may never notice.