Web Development

The Seven Deadly Sins of AJAX application development

There are common, obvious mistakes anybody can make when creating an AJAX application; then there are the mistakes that can obliterate function and performance, stripping away all of AJAX's benefits. Scott Robinson shows you how to avoid the Seven Deadly Sins of AJAX application development.

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

  1. Misuse 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, for several reasons. First, JavaScript isn't the friendliest language for 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.
  2. 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.
  3. Neglecting Links -- Here's another AJAX standard blunder: neglecting URLs that can be cut-and-pasted for uses outside the app. How many times have we grabbed a URL and e-mailed it to someone? When you're using AJAX, the only way to provide your user with useful cut-and-pasteable URLs is to manually provide them. Why? Because in an AJAX app, the server is not providing the page: JavaScript is dynamically generating it! Don't neglect your users' potential interest in this all-too-common feature of Web apps. Take pains to provide URLs, since the server won't.
  4. Trading 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.
  5. 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.
  6. Producing unspeakable text -- AJAX doesn't support many character sets. This isn't a life-or-death limitation, but forgetting it can create real problems. Your basic character set is UTF-8. Don't forget to properly encode whatever JavaScript is sending, and remember to set the server-side character set for content.
  7. Not letting the JavaScript-challenged user know what's going on. There are browsers out there that don't have JavaScript enabled, and users out there who don't understand immediately what that means. Be sure to clue them in.

Truth to tell, most of those are common-sense issues. The real killers are less obvious.

The Seven Deadly AJAX Sins

  1. Letting memory leak -- Anyone who has worked in development for very long understands cyclic references and the danger they pose to memory management. JavaScript, the workhorse of AJAX, is a memory-managed language. What that means is that JavaScript has built-in garbage collection, 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!
  2. Not 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.
  3. Keeping 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 screen.
    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.
  4. 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.
  5. Not accounting for data type -- JavaScript, isn't part of the .NET Framework. While this may draw tears of sorrow, it presents us with an example of a problem you'll eventually run into: making certain that JavaScript understands the data types of the platform it's running on, and vice versa, be it .NET or otherwise. There are various converters available to you, and you should seek them out. The Ajax.NET Pro library, for instance, offers converters that can convert objects between .NET and JavaScript Object Notation.
  6. 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.
  7. Keep your JavaScript out of your DOM -- Remember that AJAX is built on the Model-View-Controller structure. Take this seriously. JavaScript belongs in the Model layer, DOM in the View layer, and the Controller is their marriage counselor. Make sure your Web document has the same content independent of JavaScript (this helps with the JavaScript-disabled user) -- except when the content itself is only meaningful or practical if the user can use JavaScript. In that instance, create that content with JavaScript.

About

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

16 comments
JayBofMA
JayBofMA

You forgot the first element in the colleciton deadlySins[0]="Ajax". AJAX is an improper capitalization. Although an acronym, the originators would expect you to use the right case.

Jaqui
Jaqui

number one deadly sin is USING JAVASCRIPT. if the site doesn't function without it, then there is ZERO content worth anyone's time.

Shimon Amit
Shimon Amit

If you have a filter on all incoming requests that forwards you to the login screen when the session has expired, this could pose a problem to Ajax requests. Possible solution: Have a dialog box appear on the user's screen prior to session expiration. If the user does not respond, allow session to expire. Otherwise, refresh the session with an Ajax call.

Mark W. Kaelin
Mark W. Kaelin

What other AJAX deadly sins would you add to this list?

jc williams
jc williams

Now, I may be a bit unusual in this idea ... Shouldn't AJAX applications be a business function and not really a public consumption function? I can control what browser is used and the settings of that browser if it is a business function, I cannot do so if it is a site designed for public use. I feel that most web-apps of this sort (business function) would be a replacement of existing desktop or legacy applications or the introduction of new applications for the associates of the firm. Therefore, the issue with the browser being either java-script compatible or enabled should never arise.

apotheon
apotheon

There's another option: just make sure the site still works, albeit less smoothly and less like a desktop app, without Javascript. Make sure the site degrades gracefully. In other words, the Zeroth Deadly Sin should be: [b]Making Access Depend On Javascript[/b] . . . or: [b]Making Usability Depend On AJAX[/b] . . . or something along those lines.

samueljoeljolly
samueljoeljolly

then no ajax, again disabling javascript itself is a sin! code2dotnet.blogspot.com

navot.peled
navot.peled

I would like to draw your attention to an AJAX paradigm shift. One should be aware that I am not, and do not pretend to be objective. Visual WebGui is an open source rapid application development framework for graphic user interfaces of IT web applications. It replaces the obsolete paradigms of ASP.NET which were designed for developing sites, with WinForms methodologies, which were designed for developing applications. Thus enabling designer that was designed for application.This provides the developer with an extremely efficient way to design interfaces using drag and drop instead of hand coding HTML. VWG doesn?t expose logic, data or open services on client requests and therefore is not as vulnerable as common AJAX solution. Worth a look ? www.visualwebgui.com

Tony Hopkinson
Tony Hopkinson

is reduced installation/deployment issues. Internally I don't see any security problem with using ajax / javascript, if you can lock javascript execution to your domain. However it's no easier (in fact often harder to impossible) to write a rich web based app and a well written executable will out perform them every time. .NET has improved things but it's still stateless and that causes all sorts of design issues and inefficiencies. There are situations where they are useful, coping with cross platform issues , or in widely spread business units as long as the apps are reasonably simple at the front end is an acceptable use of the technology. In my opinion it should be a last resort internally, not the more common oh look there's a bandwagon, lets jump under it, first choice.

Neon Samurai
Neon Samurai

Anyone remember the days when near any page would load in Linx or Lynx (the later supporting tables)? Yeah, I know.. everyone loves the GUI but sometimes you just want to load a freaking page to get a quick bit of info, whithout loading a GUI layer.

Tony Hopkinson
Tony Hopkinson

It's yet another naff bodge for attempting to produce stateful applications using HTTP. Ajax does what it does reasonable well, what it doesn't do is solve the real problem. That would require a paradigm shift.

Neon Samurai
Neon Samurai

Often too cluttered with Ad boxes and such but definately pretty. Browser accessed applications are one thing but a page such as techrepublic and other content pages should be developed to degrade gracefully all the way back to html 3.0.. The fancy stuff and pretty add-ons could be included through metadata and themes with a simple text based default for the near-dead browsers. This could even be done in the same way that a framed page used to direct non-framing browsers to a single page while still presenting Netscape and IE with seporate pages in framed context. Sometimes a cigar is just a cigar (george carlin) and sometimes a webpage is just a page of information rather than a challenge to see how convoluted the formatting can be. Some pages have to contain those rich bells and whistles but there are so many pages where the content itself is simple and all you need to do is pop open a second text terminal and Lynx www.blah.com/page.thml instead of loading a bloated memory hog just to view a news article or technical spec sheet. For efficiency of browsing, I've even tried that fiddly keyboard navigation plugin for Firefox but it simply eats the page formatting while adding a numeric tag to each link.

apotheon
apotheon

I'm not talking about a rich text document with links like that. I'm talking about low-bandwidth plain text source files with rich text formatting, plus links. In other words, a Lynx-style interface that doesn't actually leave out the mass of functionality you'd get from visiting the same page in, say, Firefox.

jc williams
jc williams

Are you talking about a dynamic document or a static one. Could a .pdf document provide you with both the rich text information and links? Just a thought.

apotheon
apotheon

The World Wide Web is meant to support rich document formatting with images, backgrounds, et cetera. I prefer designing with XHTML and CSS over doing so with HTML 3.0, too. I've left the kind of functionality Lynx provides a long time ago. On the other hand, browsers that provide the functionality I need also utterly fail to be reasonably well-designed. Even Firefox, my favorite browser, sucks. It simply sucks less than the alternatives. One of these days, I may get around to creating a new web browser that is highly functional without having to be "feature rich" in the grand tradition of bloatware. In the meantime, however, I have another idea that occurred to me when I was thinking about the reasons Lynx doesn't do it for me any longer. I think we need a second form of browser, in addition to the web browser, for accessing hyperlinked documents on the Internet. Such a thing could be interoperable with webpages, so long as those webpages are designed to make use of a well-formatted text document inserted into the page by server-side scripts. Then, a metadata page for use with this other document browser application could also be placed, which would provide information like related links. That metadata page could then be used to populate links on the webpage. Between the text document and the metadata page, a hyperlinked network of formatted text documents separate from the concerns of the rich content World Wide Web could coexist with it, without any redundant development effort, that would provide content sans gimmicky BS. Maybe I should start working on that some time soon. I even have an idea for how I could make such a thing actually "catch on" with people.