Making history with the August Dev Derby

It is time to announce another month’s Dev Derby and this August we want you to play with the History API. The History API is a much needed piece of the puzzle of creating modern web applications and here is why:

Links are good, they make the web work

The web is made up from sites linking to each other. You are on some site and read an HTML document, you hit a link or submit a form and the browser redirects you to another page. This is great as it allows for a few things:

  • You always get a unique address you can bookmark and send to your friends to see the page you were on
  • You can use the browser’s back button when you did something wrong and get back to where you were before
  • Search engines love links and following them through your site

Why load a whole page when only a small bit changes?

Of course there are some annoyances with that, mainly that you need to leave the page and download a full new document and its linked resources every time to perform a simple action. As this took too long even in the dark past of the web we found workarounds like frames which only loaded part of the site rather than the whole document. This broke the bookmarking and going back in history bit for the first time. The other big thing of course was to make Flash sites bookmarkable and allow for using the back button in them (you might remember JavaScript confirm boxes popping up saying “do you really want to leave this page?”).

When AJAX came around we totally killed the bookmarking and history of the browser. This was a problem as our visitors have already been conditioned to hit the back button every time something goes wrong (admit it, you also found yourself reloading or hitting back in GMail one time or another). We needed a fix for that. As far as I remember Mike Stenhouse was the first to propose a fix in 2005 using the fragment identifier of the URI to store information and a hidden iframe element to seed the history. This fix got wrapped into several libraries like the YUI history manager and the jQuery History plugin.

Breaking the web with “hashbang URLs”

The problem of broken links and browsing session histories escalated when some sites like Twitter and Gawker media discarded real URLs for hashbang URLs. So instead of reaching me at clicking my profile in Twitter will get you to!/codepo8. As Twitter is an app that uses a lot of JavaScript, it was deemed more efficient to use the latter to navigate – all Twitter does is load the new content of my profile via JavaScript. This saves them a lot of traffic, but also makes the links dependent on JavaScript which means search engines don’t follow them. In Twitter’s case this is not an issue but when Gawker moved all his blogs to a format using hashbangs rather than reloading the page, a simple JavaScript error in a different script caused a major outage on a lot of blogs. But Hashbang URLs became something people really wanted to have to create fast loading apps and pages instead of reloading the page over and over.

Hashbang URLs are brittle to say the least and a lot of people voiced concerns about them. Not all user agents on the web have JavaScript enabled, which means your site can’t even be reached by them. This includes search engine spiders which is why Google set up a proposal how to make Ajax sites crawlable even throwing out a whole spec. As an aside, the Facebook vanity URLs also redirect with JavaScript, which is why mine is “document.location.href”.

The solution: History API and server redirects

So instead of using hashbangs and break the web and very basic browser usage patterns we now have the History API in HTML5. It allows you to dynamically change the URL in the browser toolbar and add to its history without reloading the page. You get the best of both worlds – you do atomic updates in the page and you leave real, working URLs behind for the user to go to, bookmark and send to friends. The History API is in use by quite a few major sites, Facebook allows for back button use and Flickr uses it in their lightbox view. The coolest implementation however is GitHub and their Tree Slider:

Isn’t that slick? You navigate the whole page, it loads in milliseconds rather than seconds and you can hit the back button or copy and paste the URL any time you want.

Now it is your turn, show us what you can do with the History API! Here are some resources to read up on.


Ladies and gentlemen, start your editors and show us how to make History!

About Chris Heilmann

Evangelist for HTML5 and open web. Let's fix this!

More articles by Chris Heilmann…


  1. Ryan Grove

    Keep an eye out for the new YUI Library website (launching this month!).

    The new YUI API docs use HTML5 history extensively (but transparently) to speed up page loads and provide seamless navigation with full server-side fallbacks for older browsers, similar to the GitHub file browser.

    Incidentally, Firefox was a joy to work with on this project. Some other browsers less so, but I won’t name names.

    August 2nd, 2011 at 15:48

    1. Chris Heilmann

      Yeah I remember the previews and was very excited about it. Looking forward to it.

      August 3rd, 2011 at 00:28

  2. Niloy Mondal

    “You always get a unique address you can bookmark and send to your friends to see the page you were on”

    How is the History API solving this?

    August 2nd, 2011 at 22:00

    1. Chris Heilmann

      By allowing you to change the URL of the application without having to reload the page of course.

      August 3rd, 2011 at 00:28

  3. Fawad Hassan

    Excellent post and History API is truly awesome :)

    August 5th, 2011 at 03:37

Comments are closed for this article.