People like it because it’s snappy and responsive and lets you do nifty interactive stuff in the browser. But AJAX may be a big enough network-engineering win that the UI sparkle starts to look like a fringe benefit. Herewith some illustrations by example and a snicker at history.
As I wrote recently, I made some updates around the picture rotation here at ongoing, and I’m kind of fanatical about performance. Thus, this little meditation.
Servers are Busy · A really good way to achieve high performance in a web server is to not look at the data you’re sending out; just fetch files off the disk (or if you really must, fields out of a database) and pump ’em down the wire as-is. This allows you to use, almost entirely, the highly-optimized code paths in your filesystem and database and webserver. As soon as the server starts doing dynamic data parsing and mingling at request time, that’s a potential performance bottleneck, which can cause a world of pain when you get that real big traffic surge.
A server’s compute resources are usually at a premium, because it’s, you know, serving lots of different client computers out there. Lots of different computers, you say; and how busy are they? Not very; your average Personal Computer usually enjoys over 90% idle time. So you’ve got a network with a small number of heavily-loaded servers and a huge number of lightly-loaded clients. Where do you think it makes sense to send the computation?
The Thumbnail Tweak ·
To bring this back to the recent ongoing
refactoring:
I really don’t want, on the server at runtime, to parse the outgoing page,
figure out where the picture should go, and stitch the current graphics and
article pointers into the HTML.
Instead, I dump that info into a static XML file, let the browser
XMLHttpRequest it (one more cheap static server fetch), and do
the stitching with DOM calls in the browser.
Maybe the DOM-wrangling isn’t all that efficient... but who cares? The
browser totally doesn’t have anything better to do.
The Take-Away · Pretty well all Web-publishing software does lots of templating and dynamic page generation, and pretty well all of it is piggish, stressing out servers (and, to be fair, representing a pretty good business opportunity for my employer).
I suspect there’s a huge system-wide optimization waiting out there for us to grab, by pushing as much of the templating and page generation work out there onto the clients. In particular, when you’re personalizing a page, assign all the work you can to the personal computer sitting in front of the person in question. Yeah, that cool, responsive AJAXy stuff is nice but maybe it’s the icing on the cake; the real win is making the Web run faster. ongoing doesn’t do any sexy-UI stuff, but you know, the page content could be a lot more dynamic, and there’s no reason for it to run slower; or even to upgrade from the single fairly-basic Athlon that hosts it.
History · You know, I could be excused for being a little bitter here. Everybody’s all gaga these days about AJAX as meme-ified by Jesse James Garrett. Check out Taxi to the Future, a piece I wrote for XML.com in 2001, talking about how to improve user experience and system performance with a Transform-Aggregate-send XML-Interact architecture. Remind you of anything?
But you know, I’m actually not crying in my beer because first, Garrett was in the right place at the right time with the right acronym, and secondly, Scott Isaacs has been talking about this stuff since 1998 and helped invent most of the underlying technology, but dammit Scott, how could you ever expect to hit the memescape big-time with a dorky name like “Dynamic HTML”?
It’s all good.
[A tip of hat to Kevin Marks for asking the question that led to this piece.]
