Ajax and History Management Alternatives

There are two solutions that are being used to provide some amount of back and forward button support for AJAX based apps. Both these involve someway of changing the URI as seen by the browser. That is because, current browsers manage cached pages against URIs (one per URI per frame). The trick is to change the URI without leaving the current page. I find that both the solutions are lacking the kind of flexibility and behavior one would expect from browser navigation controls (i.e., back, forward, and reload buttons).

The first solution is to encode the state of each user interaction in the fragment identifier part of the browser’s location URI. This approach usually involves the following steps:

• For each request (I have only seen demos using GET, but POST should be
  possible), encode the state of that interaction as a unique string
• Use this string to submit the request, so that the browser would note
  a change in the window.location value
• Register a JavaScript timer to poll for changes in the window.location value.
• When a change in the location is noticed, trigger a JavaScript callback function which will then reconstitute the previous/next view. This callback should now what the previous/next view was, and how to reconstitute it.

This approach was sketched out at dojotoolkit.org and also by Mike Stenhouse, and is supported by Dojo, Blackbase (see Backbase Explorer for a demo), and Google Web Toolkit (see the Kitchen Sink app for a demo). There may be several other toolkits supporting this as well.

As you can see from the demos, the approach works reasonably well, although Blackbase demo seems buggy – sometimes the state in is not fully reconstituted when you navigate using back/forward buttons in the Blackbase demo. However, the trouble with this approach is that the developer, and not the browser, needs to decide what should happen when the back of forward button is pressed. For example, in the Google Web Toolkit, a callback onHistoryChanged() method replaces the current view with a view corresponding to a history token. Dojo has a similar JavaScript callback. This approach becomes somewhat complex if you are making state changes (not just browsing between resources using GET) via POST, and you may not be able to recreate a prior state easily. This is unlike the traditional behavior where the browser renders the previous/forward view from browser cache – no application code gets involved in the history mechanism.

Moreover, this approach also contradicts HTTP 1.1. Section 13.13 of RFC 2616 states that the history mechanism should show what the user saw at the time the resource was first retrieved. Here is the related conformance statement from RFC 2616:

… history mechanisms SHOULD NOT try to show a semantically transparent view of the current state of a resource. Rather, a history mechanism is meant to show exactly what the user saw at the time when the resource was retrieved.

So, recomposing the state when the back/forward button is pressed is not inline with HTTP 1.1.

The alternative is to somehow involve a hidden iframe to dispatch AJAX requests to the server. This way, the browser would be able to use the regular history lists to record every request. Here is an ugly but simple demo of this approach. Keep clicking on the two hyper links and then navigate using forward/back buttons. Each request is funnelled through an iframe, which receives some JavaScript. This JavaScript then submits the actual XMLHttpRequest. Each time the forward or back button is clicked, the same scripts get executed. The executed script merely starts an Ajax request, but in this demo the response for the Ajax request is already cached in the browser – and so the browser passes the cached response to the script.

The second approach is worse than the first one since there is an extra roundtrip involved to funnel the request through an iframe. The only advantage is that it does not force writing code to support back/forward buttons.

It is fair to conclude that both solutions provide an incomplete solution for a complex issue that better be solved at a more fundamental level (e.g. HTML and JavaScript).

That brings us to the solution being proposed in the Web Applications 1.0 working draft. This proposal addresses the fundamental problem – which is to let you programatically push the current state into
the browser history – just like leaving breadcrumbs – without changing the location URI. In this model, you can the push multiple state objects (document objects) into browser history using the
pushShate() method of the History object. This is a great improvement over the current behavior where only one document state object is associated with each URI. In the proposed model, you can associate multiple state objects against the same URI. This makes it possible to support better browser navigation for "one-page applications" like those using Ajax. We just need to wait for a few years to get this support across all major browsers.

Tagged as: Ajax, HTTP