AJAX should not mandate HTTP

An interesting and unfortunate by-product of AJAX applications is that these applications rely upon the existence of an application server always being available. Many Web users are used to the idea that they can save a Web page to be read at their convenience. Even when there is Flash on the page, the page still works offline. After all, HTML is simply a document storage format, and HTTP is simply a protocol designed to optimally transmit HTML documents. But, in reality, more and more Web developers are assuming that the user will not want to save the Web page or lose network connectivity. I think that this is a mistake.

A lot of frameworks have come out recently that are designed to tackle the offline problem; the frameworks' approach is usually to run a database on the client. The database can cache data from the "home server," and if the user makes changes while offline, that database can write the changes back to the "home server" when it becomes available again. These frameworks don't do anything about all of the back and forth requests to the app server that AJAX applications generate.

Some developers try to tackle this problem by loading a miniature application server on the client via Java (or similar "applet" style technologies). This approach works. However, after a certain point, I wonder how many hoops someone needs to jump through to compensate for an inherent shortcoming of a particular technique before it becomes clear that a technique might not meet their needs.

Even assuming that you can put a miniature application server and database server on the client that can cache and sync with the master servers whenever possible, you still have not solved the problem of "saving a Web page." The user doesn't think they are using an "application"; if it runs in a Web browser, they treat it like a Web page. Users are always clicking the Back button (which messes up AJAX apps) because they expect it to work like the Undo button. And incidentally, it does work like the Undo button in a more traditional step-by-step forms-based application. Ironically, one of the biggest issues that AJAX addresses in traditional Web development is the stateless nature of the HTTP protocol — and yet it suffers from its own lack of state.

Let's take a "product finder" application as an example. In the application, the user selects various options as "must have" and "nice to have" features. Some of these are Boolean selections, while others might be numeric ranges, and one or two might be "one-of-many" or "many-of-many" options. Now, let's imagine that our user has narrowed her choices down to four products from the original 50. She decided to save the Web page to disk so she can e-mail it to her boss or coworkers for review. Whoops! Her boss and coworkers will likely have a problem if they try to bookmark the page or e-mail the link. In a traditional Web application, if the developer is smart, he or she will use GET rather than POST for these scenarios to ensure that the link accurately represents the application's state, and the page is quite easily saved in its current state.

I am not saying that AJAX applications cannot function like this; however, until users get used to the idea that the traditional model no longer applies, developers will want to find smart and creative ways of addressing this issue. One way of doing this would be to periodically "tag" the state with a hash code and redirect the browser to a URL that calls that hash code (for example, http://www.site.com/application/j7qw132j). This way, if the user hits the Back button, she goes back, say, two minutes in time (or 10 operations) rather than back to the beginning. Also, the user can e-mail (or bookmark) that link. Developers often build in E-mail This Page, Bookmark This Page, or even Save This Page buttons on their site, but it takes effort to build in the buttons, and users often miss those buttons or assume that they do the same thing as the similarly labeled browser functions.

I think that developers who work hard can find some creative, workable, and usable solutions for this issue, and their users will appreciate it.

• Date: May 30th, 2008
• Author: Justin James