This is a great article, history support for Ajax applications is an awesome achievement. At the same time I think that the importance of having full history for Ajax application is overrated.
Take GMail. This is a typical CRuD application with item list and editing/viewing of a particular item. When you read a particular email, you don't see the list, so it is easy and convenient to return to the list using Back button. In this case usage of history is justified.
In the O'Reily Mail you can see left navigation menu and content pane. You click Back and scroll to previous menu item. What for??? The menu is always visible. It is more convenient just to click on another menu item. Why would I want to go back and forward through a menu? I hate scrolling back and forth through meaningless pages, the nonsensical dead views of resources I visited a while ago.
Note that this area has a number of ideal requirements.
* Unique URL for each state.
* Should be able to open the URL to load app in that state. This must work even when the app's already open. (Which is tricky since the URL is manipulated using a hash (#) fragment identifier, and browsers don't reload when that changes.)
* Back button takes you back to previous state, and not to previous application. (Which is tricky since IE doesn't consider changes to # as part of the history, hence iframes.)
* After the user leaves your app, Back button from *next* application must take you back to most recent state of your Ajax app.
Why, oh why do you want unique URL for each state? This just pollutes browser history and makes writing of web wizards a complex and tedious task. A
resource, not a
state of the resource must have unique URL. I don't want to navigate to an arbitrary state or view of a resource, I want to navigate to resource itself, and to see the resource in its current state. This is what web is about, the resources, check HTTP spec.
Back button, switching application states, is like tail wagging the dog, it does not make sense. Application state should be changed, based on input command and input data, not on something absolutely artificial to application. Browser history is a part of view at best, and it should not affect the model. Browser history is not a cache, it does not store stale views, it stores locations of visited resources.
No one raises eibrows when they start, say, MS Word, and see a blank page, or a list of recent files at best. Why do you expect from a web application to record all your activities and state changes? Imagine MS Word with "Record Macro" turned on all the time. Yuck.
I truly appreciate the technology described in the article, I just hope that it won't be used
everywhere just because it can be, and because users got used to Back button. The latter just a white lie. No one likes to incorrectly submit a form five times, and then to click Back six times to get out of the page. Again, history and navigation is good, but entities that are being navigated should be meaningful. To create a great application a developer should consider every smallest use case, to decide how it should be handled.
What I personally want to be able to do is to be able to refresh resource freely, and to have a webapp completely retained its state, with data, with selected items, with relative element positions, etc. Considering bookmarking, I would just mix and match traditional navigatable pages and Ajax, where a navagatable page identified a resource. I would be able to bookmark a resource with no problem. If I could use approach described in the article creating a fully ajaxified application, that would be even better, but I would not meticulously resurrect full session history in Ajax application.
Ajax liberated us from session history, don't put yourself
back into chains.
