Mozilla

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 http://twitter.com/codepo8 clicking my profile in Twitter will get you to http://twitter.com/#!/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.

Resources:

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

5 comments

Comments are now closed.

  1. Ryan Grove wrote on August 2nd, 2011 at 15:48:

    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.

    1. Chris Heilmann wrote on August 3rd, 2011 at 00:28:

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

  2. Niloy Mondal wrote on August 2nd, 2011 at 22:00:

    “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?

    1. Chris Heilmann wrote on August 3rd, 2011 at 00:28:

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

  3. Fawad Hassan wrote on August 5th, 2011 at 03:37:

    Excellent post and History API is truly awesome :)

Comments are closed for this article.