What are the differences between history.pushState & location.hash?

Question

I\'m trying to update the URL using window.location.hash or history.pushState.

What are the differences and advantages of each method?

Answer 1

Currently, pushState is supported by all modern browsers. Therefore pushState is better than location.hash, but it is a HTML5 feature.

So, location.hash is not dead, in fact it will be around for a long, long time.

A good way to use this is with a lib that supports pushState, but also gracefully degrades to using location.hash.
Example - https://github.com/browserstate/history.js

Moreover location.hash will still be useful for jumping to named anchors. pushState will be a tremendous help in building web apps. I look forward to using it.

Answer 2

location.hash has a better support than the history.pushState method.

The advantage of the pushState method is that you can bind a state to the history entry.

If you don't need this state object, I recommend to use the location.hash property, to have better compatibility with older browsers.

location.hash = 'new-hash';
console.log(history.state); // null or undefined

history.pushState({extraData: "some state info"}, '', 'new-hash'); //<---
console.log(history.state); // [object Object] = {"extraData": "some state info"}

Answer 3

I personally prefer pushState because it makes nicer looking URLs and I think that is important for user experience.

You can use history.pushState with a hash fallback using the history.js polyfill if you want to use pushState, but don't want to have issues with older browser support.

Answer 4

history.pushState is better than location.hash. but it is a HTML5 feature. so always better to have a fallback method like below.

if (typeof(window.history.pushState) == 'function') {
    window.history.pushState(null, path, path);
} else {
    window.location.hash = '#!' + path;
}

Answer 5

I agree with the other answers, but here are a few arguments in favor of location.hash:

• it works in every browser, including Internet Exploder^TM
• history.pushState is a developing standard, and the API may change in the future
• if the users opens a link in a new window/tab, a hash-URL makes sure there is no server request needed to load the page (if the correct caching headers are set)
• The server configuration is easy, since all the server ever sees is the URL without hash-part

edit: I forgot one

• with hashtags, you can use real links (a href). So you don't have to set up click listeners, which improves performance and reduces code size.

Answer 6

The advantages/disadvantages of window.location.hash vs HTML5 history.pushstate are largely determined by how exactly you want your page to degrade.

Here, you might be interested in graceful degradation in two different scenarios :

The first one being a client which does not have javascript enabled, or an automated bot/crawler visiting your site. This is particularly important from an SEO perspective. If your web-page/web-application uses hash-urls then content that is available through these links is not available to these end-users. This is definitively a problem if you are making sections of content available only via hash-urls with no fallbacks. However it is definitely not a problem if you are using hash-tag links to modify application state which simply don't retain meaning if the page degrades.

As an example consider a scenario where you have a page with three sections of text available in three tabs in a tabbed-layout widget. Now there are two possible scenarios : In the first, you would be loading all the content during the page load - and the tabbed widget will simply serve to hide other sections and show a particular section. So if you use hash-urls in the links you use to construct the tab thumbs, you are using them only to change the client-side application state. When javascript is turned off/is not available, simply the javascript used to construct the tabbed layout does not run, and all the content is immediately available - a reasonable graceful fallback. The different application states simply don't exist in this case and so the hash-urls degrade back to just pointing to anchors in html - the intended purpose. Instead of hash-urls if you were to use html5 pushstate in this case, it would be a bad idea. The reason if that a user might bookmark the link to a particular tab. Because your server would have to take that url and present the user with the client side state which he is expecting. This is not good for a thin server architecture where the client-side should take care of its own state management. You can ofcourse ignore that aspect on server side and let the client check the url right at the beginning upon page load and then switch to appropriate application state. But still it is not a good idea because your server side routing system is concerned with the overhead of additional url fragments which it should ignore, where as it should not be bothered about that fragment at all from an aesthetic perspective. This maps exactly to the requirement for which hash-urls were designed and using them is strongly recommended. If instead in the three sections, the text gets loaded dynamically when a particular tab thumb is clicked, then using hash-urls is not a good idea. The reason being the user will simply have no way to access the linked content if javascript is not available. This is particularly bad for SEO. In this scenario if you handle urls (which would in normal scenario be "hijacked" and "ajaxified") on the server side to make content available in general it is excellent both from point of view of end-user experience as well as SEO.

The second scenario is a client who has an antiquated browser which does not support html5 pushstates. While the above points still hold, in addition I would also argue that forcing users with no pushstate with the same level of degradation as no-javascript is not justifiable. A lot of end-users will simply have no idea why they are receiving a degraded version.

I would recommend you not to tag along with dogmatic motivation of using the latest technology always, and decide the best option for your usage scenario.