XMLHttpRequest for The Masses
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?
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.
So what can we use this for?
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.
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.
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.
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?
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.