Chlorine hazard: do not mix cleaning agents

A while ago, pondering the hype surrounding the emperor’s new Ajax clothes, Henning Koch boggled whether the talk about accessibility had been lip service all along. That piece wedged an idea into the back of my mind that I couldn’t quite grasp. It was finally kicked loose by Shelley Powers’ clarification of the reason she was perplexed by the hype.

I do believe Ajax is somewhat exciting. The current hype is way beyond reality, but it’s a very useful technique nonetheless. The place it has is in web applications which, according to precedent in the C language, one might refer to as having “volatile” session state. The distinction is that the server-side state of a session is not dependent solely on the requests sent by the session client, and that it is desirable to keep the user’s screen up to date without interrupting their interaction with it.

Chatrooms are the best example: the chat backlog must be periodically refreshed. In the meantime, the user may have entered an incomplete message. On a frameless page combining both the backlog and some text input, a full refresh would clear that partial message and therefore is unacceptable. Traditionally there was no sane model for implementing webchats other than to use at least one frame. Using XMLHttpRequest however, you can simply render a static backlog on such a frameless page, adding intermittent chat in-place inside the same window without refreshing. This increases usability for scripting-enabled clients. Meanwhile, scripting-challenged clients can manually submit forms and refresh the page, exactly the way they would have in any other web application, except more accessibly so compared to webchats that use frames. Everyone wins.

Webmail fits the defition of a volatile session as well: mail may arrive at any time while the user is looking at a previously rendered listing of his inbox. (Note that GMail does not set a good example of such minimal Javascript use, according to what I know. I have not tried the service myself, though.)

In this way, Ajax compounds the user experience, rather than constituting it.

Following these suggestions makes it very easy to “add Ajax magic” to any web application that can benefit, using David Heinemeier Hansson’s proposed approach for minimal Javascript code when using Ajax. Just expose a version of your page renderer that does not include the full page skeleton so you can request these partial documents from Javascript-land and insert them in the page. The result is an application that generally works exactly like traditional web applications, but can take advantage of optional refresh-free in-place updates where available.

To clarify, I don’t mean that the Ajax support in Rails, whose implementation I have no idea about, degrades gracefully in the way I described. I was focussing on David Hansson’s general suggestion to do most of the work on the server and use only minimal XMLHttpRequest-based logic on the client. My proposition is this can be employed for gracefully degrading Ajax features and for near-zero effort on the server side of the application, while also giving the varying benefits for different kinds of clients that I described. It’s a blindingly clear win-win-win situation.

Referenced in I don’t GET the problem, I say graceful degradation, you say progressive enhancement.