By Kevin Yank

Bookmarks and back button history for AJAX apps

By Kevin Yank

Aside from the accessibility concerns, which are indeed serious, the biggest problem with single-page AJAX applications (Web apps that work largely or entirely within a single page, like GMail) is that the standard navigation tools provided by Web browsers — bookmarks/favourites and the Back/Forward buttons — become totally useless.

Now, from the same clever monkey developing the AMASS client-side data storage system I mentioned previously, comes a very promising partial solution to these issues.

Really Simple History is a script that lets you associate page anchor names with application states (e.g. page.html#state). The script works by linking the user to a new anchor whenever the application enters a new state (e.g. editing a blog entry). The script then watches the current URL for changes to the current anchor (due to back/forward navigation), and triggers a function you specify so that you can update the application state accordingly.


Obviously it’s not quite as simple as I make out, but with the library in place, the code you need to write to support this is actually surprisingly simple. For now, Safari isn’t supported, but looking at how it works, I wouldn’t be surprised to see that browser supported before long.

The script’s site shows all the sample code you’ll need to get started if you’re a JavaScript gun. Less seasoned developers will want to check out the script author’s article on the O’Reilly Network.

Hopefully the large AJAX Web applications like GMail will lead the way by adding this to their offerings quick-smart. Now that proper bookmarking and navigation is now possible within single-page AJAX apps, I wouldn’t object quite as strongly to the notion of developing my next Web application ths way.

  • Jaffa The Cake

    I wouldn’t object quite as strongly to the notion of developing my next Web application ths way.

    That line probably came across wrong, but it’s true of far too many developers, and I’m going to rant regardless.

    When a new technology becomes popular, it stops being a case of “What technology can I use to solve this problem?” and more like “What can I build that uses AJAX??!!1”.

    It’s this mentality that gained Javascript and Flash a bad name. “Arghh! Must use Flash on the page somewhere! I know! I’ll make some text… that ROTATES! The web is MINE! Ladies will want me!”

    My warning is this: If using AJAX (really hate that word) for a particular function has no benefit other than being cooler because the page doesn’t refresh… don’t use it. If the effect you’re trying to achieve can be done without AJAX, it’s probably best without AJAX.

    Here’s a real world example: I was developing an intranet system for a large company. There was a tree of items to be displayed on a page. This tree was built from a constantly changing database. The query that built the tree would have killed the server due to the amount of times it would be called during general usage (constantly changing so wouldn’t cache). I used DOM Scripting to run only part of the query when the user opened part of the tree. Since the tree wasn’t likely to be used on every page it appered on, problem solved.

    Oh, and can we stop using the term AJAX when we’re talking to developers? It’s fine when talking to clients because it’s a dirty buzzword and they’re into that kind of thing. But, it’s almost patronising when said to developers. I mean, we all know what it really is right? It’s a bit like talking to a technician and calling a CPU “The computer brain”.

  • Somebody woke up on the wrong side of their monitor this morning ;)

    I think the main point that Kevin is trying to make is that there is a big drawback to a browser’s nav bar and the use of AJAX. Flash is a great example of this in the effect that if you develop a very deep flash project that is all included in one file on one page – and a user shops for 10 minutes or so and gets a huge shopping cart, then hits the back button: poof, gone. So I appreciate the tip Kevin.

    AJAX is a pretty industry standard term these days. I know its several technologies combined, but as long is whatever is trying to be communicated is – I think its fine.

    Jaffa, don’t get too angry on a Friday ;)

  • Jaffa The Cake

    Oh it’s a good article, it’s only the quoted statement I took issue with, and as I stated it may have been misunderstood. However, related or not, I stand by my rant.

    AJAX is industry standard, yes, but in the same way that DHTML is. A client asks “Can you do DHTML?”, you reply “Yes! I can! I love DHTML”. However, if you’re talking to another true professional you call it Javascript and CSS, because that’s what it is and faux-trendyness isn’t necessary. In a short amount of time, the term AJAX will be as laughable as DHTML; it’s not a technology, it’s a buzzword. The discussions at the @media conference (the main players in web technology) prove this to be true.

    I’m happy to talk AJAX with clients, because they love it. But I refuse to patronise peers in such a way.

  • smith288

    Ajax ajax ajax ajax…


  • Gosh Kevin. You make it sound so simple.

    It’s crazy how it has taken till now for someone to figure out “let’s use the page anchor as a hook”

  • If you’re not that strong on javascript and the DOM, just create plain vanilla old sites, and add the jazz later.

    Unless you’re using, where frequent postbacks and really strange scripting is just something you must learn to live with.

  • So you would rather say “we are going to use Javascript and CSS to build the menu, javascript and CSS to build the floating advertising, etc” instead of just replacing that with the terms AJAX or DHTML?

    Could I have some ground beans, water, and steamed milk please?

  • Jaffa The Cake

    Urm, yes, if we’re going to write a techinical article then the technical terms are prefered.

    If we were talking about making coffee better in a technical way, I’m sure we’d refer to ground beans, water, and steamed milk as individuals. If you want to stand by your analogy, tell me how to make a good coffee without mentioning ground beans, water, and steamed milk.

  • I had to do something similar for a heavily-javascripted page I was working on. Weird :)

  • I can’t find anything patronising in the use of specific words, particulary when those words are, as you admit, industry standard. I would much rather talk to a colleague using the term AJAX than Javascript and XMLHTTPRequest. I would also hope that the person I speak to is more interested in what I have to say rather than whether or not I use industry standard terminology.


    if you’re talking to another true professional you call it Javascript and CSS

    it’s the person’s work that defines a “true professional” not the words s/he uses to describe their work.

    Now instead of debating what words we should use why don’t we focus on the real problems with AJAX such as the issue Kevin highlights in this blog entry.

  • M.Mahgoub

    yea thats right

    Ajax ajax ajax ajax…

  • Lol. Ok, here is a litmus test:

    “Javascript and CSS”


    “JavaScript and XML” (or CSS, HTML, XHTML)

    Which are more effective for a developer wanting to learn / use these technologies, or groupings of technologies?

  • Brad Neuberg

    I think I’m a professional, and I use both the terms AJAX and DHTML (I’m the guy that wrote the article and the frameworks mentioned above) ;)

  • Etnu

    If the effect you’re trying to achieve can be done without AJAX, it’s probably best without AJAX

    There’s *nothing* that can’t be done without AJAX that can be done with it.

    AJAX functionality is usually beneficial, but it should NEVER require breaking the back button or general web usage. I should still be able to right click and open a link in a new tab. I should be able to bookmark the current display and go back later. My back button should always work.

    Implementing it isn’t hard at all. Use the hash, Luke!

    As far as the term “AJAX” goes — it’s perfectly acceptable. I used to be against it, because it’s such a misnomber, but you know what? It works. It works for the same reason why DHTML worked years ago — because everyone knew what you were talking about. Plus, it’s far fewer words to say.

  • Jaffa The Cake

    Which are more effective for a developer wanting to learn / use these technologies, or groupings of technologies?

    (Refering to JavaScript and XML vs AJAX)

    I’m not sure if you’re arguing for or against me there… I’ll assume ‘against’ because you were earlier.

    If I’m familiar with Javascript and I hear the term “AJAX”, I know nothing about it. It’s a cleaning product where I’m from. If I hear “JavaScript & XML”, I know I’m working with XML and Javascript, so to a developer that term is more useful to me if I’m wanting to learn about it.

    *sigh* I was trying to help, I really was. As a recruiter, it my experience (and others that I’ve spoken to) that people who use the term AJAX without its components have less technical ability than those who do. When I ask for work examples they send something they copy & pasted from a tutorial that they assume I haven’t already seen. Candidates who refer to Javascript & XML (sometimes known as AJAX) generally have a better grasp of the technology and can use it in a real world situation.

    For example, one candidate during a telephone interview mention he could program AJAX. After a few looks around the table we threw him a lifeline and asked him to describe the ‘technology’. 30 seconds into his speech we’d found the site he was reading off and were miming along with it.

    The main use I’ve seen for the term AJAX is for 2 IT people who like to make up for a lack of technical ability by winning games of “I know more buzzwords than thou”.

    AJAX is not the only offender in this. The amount of candidates I’ve seen that say they know XHTML is large, because it’s become a buzzword (but an acceptable one). However, the majority have simply made a badly formed HTML page and slapped an XHTML doctype at the top.

    I’m not just arguing for the sake of it. I’m speaking from real experience. If you’re going to go into an interview situation and mention AJAX without refering to its components, do yourself a favour and just leave it at “I know web stuff and that”, you’ll achieve the same result.

  • That last post Jaffa was far more constructive than the original “rant”.

    If indeed that was your original intention behind the post, then I hope you can see how it was completely lost “in translation”.

    This industry seems to suffer more from the “cowboys” than any other and I have to agree with your point. I went for a job interview once and the IT manager asked me a bunch of networking questions. I held my hands up and said I don’t know much of anything about networking, I can’t answer your questions. From my perspective it was a disastorous interview but I got the job. Later I found out it was because I was the only one that answered honestly.

  • Jaffa The Cake

    Exactly, I’ve conducted interviews where someone else looked through the initial batch of CVs and I helped with the telephone & face to face interviews. Hardly any of them knew as much as they claimed on their CVs. I found out that no work examples had been asked for at the application point. So basically, whoever put the most buzzwords on the CV got the phone interview, needless to say I was quite angry about this. For instance, Octal, you may not have got through to that interview because of your honesty.

    I can see why my initial rant was misunderstood, because it was a rant and therefore more of a release for me than anything else :) sorry about that.

    AJAX is a cowboy term, and is quickly being associated with the misuse of the technologies it represents. See for yourself, do a search for DHTML scripts on google, add a year and AJAX will be the same.

    The cowboys read ‘AJAX’ in a forum and add it to their CVs because it’s the new buzzword. However, in this instance it’s a buzzword you can do without. By all means refer to AJAX in CVs and such, because you may have a cowboy interviewer. But you’ll do a lot better saying something like “Javascript & XML (sometimes refered to as AJAX)”, both situations are covered.

  • Brad Neuberg

    I created the Really Simple History and AMASS libraries, and I use the term AJAX. No, the term AJAX is not perfect, and if you dig too deeply into it you find that you don’t always need to use XML for remote communicaton or even use the XmlHttpRequest object (you can use a hidden iframe). However, the term AJAX has become a pretty good place-holder for referring to advanced web pages that are using a variety of technologies to advance web sites beyond simple, static pages, and that’s good enough for me.

    Brad Neuberg

  • Brad Neuberg

    By the way, Kevin, thanks for pointing out the RSH library to your readers! If you have any ideas on how to make it easier to use or more powerful please shoot me an email at


  • Brad Neuberg

    Oops, you posted this awhile ago; Technorati just pickd it up so I thought it was new.


  • i believe that “really simple history” has been in use by the backbase team for a long time now.

    That explains how to tackle the back button woes … how about bookmarking ? Does Amass take care of that ?

  • Kieran


    Has anyone noticed that using the rshf in IE you see a loading bar in the status bar when navigating the o’reilly mail example ( ). This seems to go against the ajax concept of not seeing any page refresh/loading?

    Any thoughts appreciated.


  • To busy for this crap!

    You know… it’s guys like all of you here that make my day crap! Here I am doing a search for a solution on fixing the back button issue caused by using AJAX enabled pages (AJAX! AJAX! AJAX! AJAX!… oh… and AJAX!) and what do I get? One page of posts that’s 3 freakin’ miles long of people bitching about a word and not about the actual topic.

    See what you made me do? You made me join you and now I’m bitchin’ about the bitchers!

    I hate humans!

  • Matt Foster


    Through best practices of a pure “Ajax service” I have
    developed a manner for implementing history style behavior in Ajax
    applications. It involves a new HTML Microformat and doesn’t require
    polling, two features I thought were particularly appealing. If
    you’re interested in a method for handling the infamous back/forward
    buttons in Ajax applications the full article can be read here.


  • Bill Brown

    If you want to stand by your analogy, tell me how to make a good coffee without mentioning ground beans, water, and steamed milk.

    Well, this is like a year after the fact, but I saw something that caught my eye and thought I’d toss my two cents in: Jaffa’s point is valid, but only to a degree. Working off the analogy posted before, Jaffa responded with a statement which included the quote above. Flip that around and you see the two sides of this debate. Try this: Tell me how to make a good coffee without mentioning coffee.

    For me, the simple use of a buzzword doesn’t immediately mean you’re an idiot. Not knowing the definition of the buzzword means you’re an idiot. Programmers are inherently lazy, at least the good ones I think. A programmer knows how and when to re-use code and why, where the best shortcuts are and how to use them. AJAX as a term is a shortcut describing combined technologies. Referring to those technologies through the use of the shortcut is done for ease. Using the term without knowing what it is or how to use it is dumb. Everything gains a name. It’s easier than saying loops, functions and processes using the hypertext preprocessor (or whatever technology you’re working with at the time).

    Just my two cents. Nicely written article, too.

  • blacklight

    One of the problems with AJAX is the back button being ‘broken’ because when navigating with ajax, you aren’t refreshing a whole page just partial pages. There is a fix though… a way to map partial pages to whole pages and store it in the page history. I found it on, the
    AJAX Back button fix.

Get the latest in JavaScript, once a week, for free.