Hashtags（片段标识符）VS Javascript History API

Question

Which one is better? Using fragment identifiers...

http://www.alinkthatdoesnotwork.com/#!/dir1/dir2/file.html

...or the new Javascript History API?

https://github.com/examplethatdoesnotwork/project/src/script.js

Or should I use both? (via fallback)

Aspects:

• Compatibility/Support
• Speed
• Convenience

Answer 1

Hashtags are a means to categorise content on Twitter, you mean fragment identifiers.

Using fragment identifiers to indicate what content to load via Ajax is a terrible idea. They are a hack that is fragile, search engine unfriendly (except with more hacks on both sides) and depends on JavaScript .

The history API is a robust system that is actually designed to do that job. The only problem with it is browser support , but (unlike the fragment identifier approach) it gracefully degrades to real URIs that will be passed directly to your server (which is what Github does ).

Even Twitter appear to be about to switch to the history API .

Answer 2

The history API is vastly preferable, so long as normal links work normally in browsers that do not support it.

You could use a library such as History.js to enable it in these browsers.

More information here: It's About The Hashbangs , Side Effects of Hash-Bang URLs .

In a nutshell, URLs are important. URLs are forever, and cool URLs do not change, and finally: Once you hashbang, you can't go back.

Answer 3

The new history methods are incredibly useful for AJAX navigation. For example, pushState or replaceState allow you to update the browser's address bar so the user sees a clean URL instead of an ugly hashtagged thing.

However, as I'm sure you're aware, support for the new API is still limited. location.hash is much more widely supported at this point, meaning that you'd have to write a hash fallback for browsers that can't take advantage of the newer window.history stuff.

Answer 4

I think the question is what is support. You can't go solely with History API at the moment because it is not supported by IE. You'll need a fallback solution like GitHub does.

Answer 5

You've listed "compatibility" as your first criterion. Since the history API isn't yet supported by all major vendors (I'm looking at you, Microsoft), not even in their most-recent releases (IE9 doesn't have it), that pretty much means you have to use the hash. (Which is too bad, but there we are.) And it's not just Microsoft, lots of mobile devices are using one- or two-versions back of their mobile browser, and so still don't have it.