This article is also available as a TechRepublic download.
The AJAX bandwagon is a good place to be. It takes you to faster, more efficient, more dynamic apps. But it also has pitfalls all its own.
At first blush, those pitfalls may seem avoidable through sheer common sense, and to a degree, that's true. But AJAX apps bristle with architectural differences from its DHTML forebears. No matter how much common sense you bring to the application development task, it is still good to learn from the mistakes of those who have preceded you. We'll call these mistakes our Seven Deadly Sins, but they are by no means the whole story.
In fact, before you commit any of the deadly sins, you're much more likely to commit a few lesser sins. So we'll start with those. These are the ones that make everybody's list. These mistakes are so common that you can find most of them in a simple Google search.
The Seven Lesser Sins
of the Back Button -- This is
the one mistake everyone's going to have on their list. The Back Button
has become a user expectation in many kinds of Web apps. Many new AJAX
developers drop a Back Button into their AJAX app and promptly break it,
it; and second, AJAX design requires a new way of thinking.
It's not always readily apparent to a new AJAX developer that "Back" isn't best. "Back" is a feature you'll need at a page-update point or more often, when you want an event-specific "Undo" feature. Think this through before you code, or you'll end up doing it twice.
- Not telling the user what's happening -- Part of how AJAX works is that it doesn't use conventional Web UI page loading. So you need to explicitly design some visual cue to let the user know what's happening.
content control for page control -- Breaking with the traditional client-server interaction is a wonderful
gift, if you're seeking dynamic content control. But it's also a curse: rewriting
highly-specific areas of a page to fine-tune a user's interactive experience
does indeed give you fine control, but this pulls you away from the big picture.
All too often, we focus on processing some sector of the page and forget that the page isn't going to be refreshed by the server. This can lead to a fragmented page, a confusing user experience, wherein the screen they're looking at can be out-of-date with itself! Take care to keep your attention on the entire page; make sure that any dynamic content event evokes changes everywhere the user will need to see them.
- Killing spiders -- The upside of AJAX is the truckloads of text you can feed a page without a reload. And the downside of AJAX is the truckloads of text you can feed a page without a reload. If the app is intended to be search-engine-friendly -- well, you can imagine. Whatever is happening in the guts of the page, be sure to plant plenty of stable text up top, for the spiders to play with.
Truth to tell, most of those are common-sense issues. The real killers are less obvious.
The Seven Deadly AJAX Sins
memory leak -- Anyone who has worked
in development for very long understands cyclic references and the danger they
so that it sniffs out variables no longer accessible by any reference path
and de-allocates the memory they're using.
That's fine as a general principle; but you can't count on it to keep your memory usage optimized, because of those cyclic references, when a Model-layer object is referencing a View element and vice versa. Nulling the object nulls the element, in principle, but if there's a backward reference from element to object, then the garbage collector won't touch the object.
Now, here's where it gets tricky: in the Document Object Model, any DOM node that's part of the document tree may be referenced by virtue of its presence in the tree, whether it's explicitly referenced by another object or not! So any object you tag for garbage collection that is back-referenced by a DOM node must be explicitly nulled in that direction, or its memory remains allocated!
knowing what "asynchronous" means -- Asynchrony can be really unsettling to a user unaccustomed
to it, and this can be ironic, since the Web apps you'll design and build for
those users wouldn't find them at all unsettling if they were desktop apps.
This is a crucial design point! Most Web apps are functionally very similar
to their desktop counterparts. But in a Web app, there's a looming characteristic
that sets it apart: user expectations.
Users carry a very different set of biases and anticipations into a session with a Web browser that they don't tote into a desktop app exchange. So while it may be incredibly cool and efficient to have myriad responses trotting back to the page from the server, and the page revising itself in the meantime, it can be deeply disorienting to the user to see this constant barrage of change. For this reason, you need to apply two rules, and consider them with every change that comes into the user's field-of-vision: If the update is not immediately essential to the user, make the update unobtrusive, so that it does not distract; and if the update is vital to the user's interaction with the app, make its presence on the page clear and prominent.
the server in the dark -- The decoupling
of client and server has a huge downside that seldom occurs to us up-front.
Server-side apps know all and see all: every exception, every reload, every
event can be watched and recorded, and of course the server knows exactly what
the client looks like, because the server basically wrote whatever's on the
In an AJAX app, this isn't the case. Stuff happens, and it happens independently of the server, and this means that there can be problems on the client side that the server won't immediately be privy to. Capture and log events and exceptions on the client side, in a place and manner that enables the server to home in on problems that require its intervention as soon as possible.
- Getting lazy with GET -- GET is for retrieving data; POST is for setting it. Don't use GET when you know you shouldn't, even if you think it will do no harm. GET operations change state, and links that change state are confusing to users; most are accustomed to links as guides to navigation, not function.
- Some apps just don't know when to shut up -- Dynamic generation of content, with no dependency on page-reload, can be disastrous if left open-ended. How many Web pages have you seen that were longer than the Congressional Record? If Web pages that go on forever are a confusing nightmare for users, just imagine how they'll feel about an application that goes on and on and on. Make your Web app pages dynamic, but build in some practical limits.
Scott Robinson is a 20-year IT veteran with extensive experience in business intelligence and systems integration. An enterprise architect with a background in social psychology, he frequently consults and lectures on analytics, business intelligence and social informatics, primarily in the health care and HR industries.