Take the 2-minute tour ×

I'm looking for a polyfill for HTML5 History API. I don't understand why https://github.com/browserstate/History.js/ is widely popular since there are so many issues (as of June 27, 2012, there are 109 open issues reported on Github). What really annoys me is "statechage is triggered everytime pushState is called". I'd like to know, if there is a History API implementation for IEs (since all other browsers have implemented it already…).

share|improve this question
You could just not support IE (I'm kidding). –  Rocket Hazmat Jun 27 '12 at 16:36
I wish there were... Here are more comments on the same issue: stackoverflow.com/questions/8744487/… –  jgivoni Jul 13 '12 at 20:18
Just want to second beatak's opinion. I started trying out history a few days and made good progress until I discovered the problems with the statechange event etc. –  DavidHyogo Feb 16 '13 at 12:31
I have the same problem with History.js and just came across this alternative which looks like a promising solution : github.com/devote/HTML5-History-API –  atomless Feb 26 '13 at 19:42
Yes, that project looks way better. History.js is a joke; It has tons of basic bugs. –  AlexG Jun 1 '13 at 17:58

3 Answers 3

For what it's worth. As of earlier this year, balupton moved over maintenance of History.js to the community and migrated the repository to https://github.com/browserstate/history.js

The issue with the huge list of issues has a few complex and self feeding reasons:

  • It started off as a side project by balupton
  • It became incredibly popular almost instantly as it was the first of its kind
  • It is the most comprehensive in terms of its support and normalization of cross-browser quirks
  • The intense popularity of the project raises more general support issues and edge cases
  • Answering support issues and solving edge cases (especially as they require manual testing on all the different devices and versions) is a full time job, one that balupton could not keep up with as a side project that drew no income for him
  • Balupton abandoned the project for a while due to stress, so pull requests went unmerged
  • As of earlier this year, a few maintainers reached out to balupton, and the project is now community managed
  • Pull requests are now being accepted, and the maintainers are working on it as part of their day job

In regards to the pushState call instantly triggering the statechange event. That was an opinionated best-practice by balupton from his years developing single-page-applications. There is an issue somewhere on the repo, and from memory this will likely change in an upcoming release, as there is a few edge cases where this is not desirable.

For more background about all of this, watch this talk by balupton

share|improve this answer
Why is this written in third person? :-) –  Kiran Jonnalagadda Jul 1 '13 at 5:58
I could always redo it in first ;) Just been editing a lot of stuff to remove the implication of my ownership of the project, so got caught in the habit I guess ;) Plus it kinda sounds more story like ;-) –  balupton Jul 1 '13 at 6:39
I would argue that your implementation re: triggering the statechange event after pushState is different from the W3 specs where it is set out that the statechange event is for user triggered state changes. The W3 spec makes sense, and is far more intuitive. I personally don't want to shoehorn all my transition code into the statechange event as in history.js (that's a code smell), but rather I think the W3 history API is designed to allow you to bolt on the functionality within whatever existing framework you are using to transition between states in your app/single page app. –  theringostarrs Nov 6 '13 at 5:38
If the implementation was done to make it easy to load 'pages' from either user input or the statechange event (by funneling both through the statechange event), I would suggest an event driven loading pipeline (eg. page.bind('pageinit', ...)) which can triggered within the code that handles your page transitions, using data from the history state or UI from either UI events, or history state changes. –  theringostarrs Nov 6 '13 at 5:46

It seems like there are no other polyfills than History.js. Modernizr lists a bunch of HTML 5 Polyfills here and they show PJAX as the only another alternative.

share|improve this answer
it seems pjax handles your ajax and also dom replacement/update. since i'm using odata feeds and integrated with knockout this really doesn't work for me. just a heads up to other readers. –  Shaun Wilson Jan 27 '13 at 21:32

You may want to try the jQuery mobile AJAX Navigation api.

The $.mobile.navigate method and the navigate event form the foundation of jQuery Mobile's navigation infrastructure. As such, they can function outside the confines of jQuery Mobile as a clean and intuitive navigation/history API.

share|improve this answer
interesting. thx for your comment. I'll give a try. –  beatak Jun 24 '13 at 19:31
I don't want to use jQuery mobile to get access to this. Is there a jQuery library which does the same thing? By the way, I found something similar but it requires backbone.js: gist.github.com/maxw/3014727 –  Gavin Feb 8 at 22:36

Your Answer


