The Real AJAX Upside

Search

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