Hashbang versus URI parse

I am looking to move my site into full async document loading, but I don't want to use the #! method of request processing because 1) I don't want to break links, and 2) I want a more flexible way of processing the URIs the site gets.

I've been able to build a light MVC for my site that allows a common-style url ( ex: http://ddrewdesign.com/blog/jquery-is-or-is-child-of-function ) to make the correct requests.

My question is: this was trivially e开发者_Go百科asy to do. What am I missing? Why did Gawker and Google opt for #! when this method seems to make more sense from a user experience perspective?

EDIT

For clarification, originally, my site was solely using the querystring method (no mod_rewrite) of retrieving for requests. These links are all over the web, and I can't have them break. It's my understanding that they will if I move to use the hashbang method. Again: this might be part of my confusion, so I'm not saying I've accounted for everything. I'm asking what it is I'm missing, because nothing I've read thus far has made it seem like I can accommodate that querystring.

I think you're looking for history.pushState urls, which allow you to do partial page loads, and have the same urls with and without javascript.

For example, say your base url is http://site.com/ With history.pushState, you can use javascript to modify the page to be javascript.htm, so that the url changes to http://site.com/javascript.htm.

#! urls only work with javascript, because the #fragment can't be accessed server-side. With hashbangs, your url would be something like http://site.com/#javascript.htm Note that the ! is unnecessary. Since you can set anything after the hash, you could also have the url http://site.com/#!/javascript.htm.

Unfortunately, since IE doesn't support history.pushState, you have to have #! urls as a fallback.

Neither method breaks the back button, but urls have to be set up different ways for each method.

Hashbangs work something like this:

function change(){
   //page update logic
}

//hashchange event binding
(typeof window.addeventListener === "function")
    ? window.addEventListener("hashchange", change, false)
    : window.attachEvent("onhashchange", change);

 //This is how the hash is set
 location.hash = "hashstring";

 //Accessing it returns the hashstring, with a #
 location.hash; //returns #hashstring

History.pushState is a bit more complex, as you store the "state" of the page in an object.

Here are some good references on this method:

• Javascript: The Definitive Guide 6th Edition
• https://developer.mozilla.org/en/DOM/Manipulating_the_browser_history
• http://diveintohtml5.ep.io/history.html

Both methods require javascript page manipulation. I have an example of these kinds of urls. http://timshomepage.net/comic/ has links to a bunch of different webcomics, and embeds them in an iframe in the page. With javascript disabled, the link will be something like http://timshomepage.net/comic/dilbert. With history.pushState, I can have that same url. With hashbang fallback, I get a url like this: http://timshomepage.net/comic/#!/dilbert