This post was written by Jeff.

Dear Diary,

With the onset of HTML5 becoming increasingly supported among the many browsers out there, there are going to be a number of important changes coming to the way things work. Things such as… the MathML and SVG support, a large number of new elements and deprecation of some older obsolete ones, and most importantly (for the purposes of this article) an important change to the history API functionality!

Unfortunately, HTML5 isn’t supported in every browser… largely because older versions of browser either can’t support it or just aren’t being updated to support it. People should update their browser anyway… so many unnecessary headaches caused by having to go back and debug some random old version of IE or Firefox because someone is reluctant to update. I will say, props to Chrome for silently updating itself to the latest version and indicating that a core app restart is required with those little coloured arrows!

Due to this lack of support in all browser, *glares at IE*, another solution is required to properly combat this looming headache menace! One of the best tools at our disposal as web developers is the History.js HTML5/HTML4 wrapper.

You can find it here: https://github.com/balupton/history.js
…and a demo here: http://balupton.github.com/history.js/demo/

Straight from the description on github: “History.js gracefully supports the HTML5 History/State APIs (pushState, replaceState, onPopState) in all browsers. Including continued support for data, titles, replaceState.”

The key thing that the History.js adds is complete cross browser support for history behaviour on all websites. Of course, browsers that support HTML5 have a much nicer experience, but it still works very neatly in general. Thankfully, it also includes plugins for major javascript frameworks, including jQuery, Mootools and Prototype.

An implementation using History.js

One of the tasks I was working on at work was to transition an aging web application which was still using a frameset for it’s layout into a single-page application. The catch was that part of the page load was an EXTREMELY heavy client side javascript menu. As a result, simply loading the entire page each time while navigating around the application was a bit of a performance issue, resulting in page load times nearly doubled.

My solution was to implement a chromeless loading system based around caching pages in the DOM and utilizing HTML5 history API calls wherever possible to allow for fast page transitions going back and forward in the browser.

I quickly found that HTML5 wasn’t fully supported (as expected), and also that it there was still inconsistent behaviour between different browsers. After a bit of searching around online, I came across History.js, realized its potential, and began implementing it into the application.

The basic idea behind what I wanted to do was keep enough meta information about each page the user navigated to such that I could determine if it was either cached already and could be swapped in, or if it needed to be requested and cached again. This was particularly important, because closing the browser would typically cause you to lose your history for that session, but it is possible to keep track of your history even between browser loads with History.js.

As a result, the general behaviour was to to either push a new page on to the history when performing new navigation, replace an existing cached page when a forced load was required (stale data or no longer cached due to browser reload), and wrap normal browser back and forward with a history state change event.

I actually found a funny little bug while working on this solution (which may be fixed now, I haven’t bothered to confirm), where if you are using the amplify.store.js storage solution for page caching via History.js, after 1000 page loads it would simply go into an infinite loop because it couldn’t find the next “unique” page identifier to use. Page identifiers were generated by selecting a number at random between 1 and 1000… and of course testing this on development, I would constantly be reloading pages and changing states… which lead to some fun times debugging the infinite loop.

Ultimately I had to skip using the storage system, and I implemented a version of it myself in the DOM itself. I like this solution better anyway, because it gave me direct control over what was cached and how it was manipulated more so than the storage system would.

At any rate, here are a few simple code snippets of how I was using History.js:

// set up history change event
var History = window.History;
History && History.Adapter.bind(window, 'statechange', function(){ … });

// pushing new state data (History.pushState and History.replaceState have identical syntax)
History.pushState({
	state: customState,
	timestamp: pageLoadTimestamp,
	page: pageKey,
	extraData: dataObject
}, pageTitle, pageUrl, false);

// state change event
var onHistoryStateChange = function(e){
	var HistoryState = History.getState();

	// access the custom data you've assigned to the history state
	// HistoryState .data.state;
	// HistoryState .data.timestamp;
	// HistoryState .data.page;
	//
	// handle state change by either loading new page or loading cached page etc ...
}

And lastly for more reading about manipulating the browser history, Mozilla Dev has a nice article that I found useful on it here:

https://developer.mozilla.org/en/DOM/Manipulating_the_browser_history

Your friend,
Jeff