If you do use hashbangs, be prepared to deal with the consequences (and possible backlash from web purists). The hashbang was never intended to be a long-term solution, so don’t rely on it. That’s a lot of broken links, so you’re stuck with that JavaScript forever. As the server does not receive the path following the hashbang, removing that JavaScript drops support for all those URLs.This means that only JavaScript can utilise it, so browsers without JavaScript enabled are out of luck. The fragment identifier is only accessible on the client side.While the Twitter implementation accepts both !/akamike and, it has some disadvantages: This works as a method of creating a bookmarkable, shareable URL for a page’s state in the absense of a standard API. This technique updates the address bar with a fragment identifier that can then be used by JavaScript to determine which page and state should be displayed. You may have already seen articles fussing over the adoption of the “hashbang” (#!) pattern on sites like Twitter. If you’ve already built an accessible website that provide these entry points, you’re laughing! Those f#!king hashbangs… # In this article, I’ll cover the client-side use of the History API, so make sure you set up your server to work with the new URLs. If the user copies or bookmarks a stateful URL and visits it later, your back-end can be configured to interpret such a URL and jump the user right to the correct page and/or state. These are then returned to the script when the user (or script) goes back in the history, thus enabling authors to use the “navigation” metaphor even in one-page applications. Pages can add state objects between their entry in the session history and the next (“forward”) entry. These history items can also hold data that you can later extract to restore the page state. The changes to the History API are intended to give developers ways to push history items to the browser so the native back and forward actions can cycle through those items. Fragment identifiers, like those used on this article’s headings via the id attribute, provide some state information, but they’re entirely dependent on client-side scripts. With dynamic Ajax web applications, where the browser updates the page in parts instead of changing location entirely, it’s difficult to give the user a URL to bookmark or share the current application state. Send the user agent back (negative) or forward (positive) Previously, the JavaScript History API offered some very simple functionality: // Check the length of the history stack They’re the veins of the web, and they need to be looked after. You can copy these URLs and share them with your friends or use them to create links from any HTML document. They’re the method of accessing the vast collections of information and resources on the web, and more recently, they’ve begun representing the intended state of a web application. It goes without saying that URLs are important. Thankfully, HTML5 gives us that control by extending the JavaScript History API. With the rise of more dynamic web pages, we need more control. We could check the number of items in the history and push users forwards and backwards, but this provides little benefit to the user. Until recently, we developers couldn’t to do much with the state and history of the browser.