There are so many companies who believe they absolutely must use AJAX on their website. Many of these companies, it seems, make this decision without actually knowing what AJAX is. I can understand that. It’s really confusing: DHTML, CSS, JavaScript, AJAX, XMLHTTPRequest…

I’m regularly contacted by tech recruiters looking for someone who knows JavaScript AND DHTML. The reason I find this silly is, JavaScript and DHTML are almost one and the same. DHTML isn’t actually a thing. It stands for Dynamic HTML, as in HTML plus JavaScript.

So, being that these companies don’t seem to really know what they’re asking for when they ask for AJAX, how are they to decide when it’s most appropriate? There are lots of things to take into consideration when you move from the classic refresh model to a dynamic, in-page application.

One of the main problems that’s plagued web apps since the dawn of time, and one that’s especially noticable with single page appse, is the browser back button. How do you handle the browser’s back button? With most web applications, the default behavior is unacceptable. If you’re in a web application where everything happens without reloading the page and you click the back button on your browser, guess what. You’ve just lost all your work.

So what can be done about this? Truth is, I don’t really know. I’ve recently begun evaluating some interesting code in the lastest release of the dojo toolkit. Specifially, there is a package called ‘Undo’ that hooks into the browser’s back and forward buttons to use them as a sort of undo stack for the web. So far, I’ve only had a chance to read the documentation; I haven’t actually tested it, but it looks very promising.

Anyway, I was just starting to get into this when I notice this article on digg. It’s an article published by IBM specifially about this technique. If this method is as functional as it sounds, we may finally have a solution to a problem that we web developers have been fighting since the dawn of man.