> People who don't care much about Internet Explorer support often say to just use pushState, and let IE users endure full page refreshes ... but that's not really an acceptable way to build a responsive web app.

Why not? It's responsive for those with a modern browser (and may get the IE team to integrate the history API in IE10), and is less responsive for those with an older browser. That can be an acceptable tradeoff.

Sure -- it depends where you draw the line for "acceptable", and how much you care about the experience of your IE users. In any single-page web app of significant size, I'd argue that it's never acceptable to do a full page refresh. Would you really want to go back to a GMail that refreshed when you clicked around between labels?

Regarding (2): hash-based URLs also work perfectly well for older browsers.

you're right, "acceptable" is subjective. but it doesn't seem unreasonable that if you are using an outdated version of a program, it will not perform optimally. to that end, managing both pushState and hashchange adds overhead and complexity. personally, i don't think enhancing old browsers is worth said overhead.

that said, if it was part of a framework i was using anyway, overhead and complexity are much less of an issue, so the question becomes "why not".

I'd just like to see a little better documentation on this in the Backbone docs. The documentation you currently have says I'll need to alter the backend, but it's not exactly clear what the changes to the backend would need to be. Do I need to implement /new and /edit on my server to make Backbone's pushSate work, or do I need them implemented to provide for a graceful fallback? It's a little confusing as written so I had to just code something up to see what happened.

Thanks for the tip. How does this look to you?

https://github.com/documentcloud/backbone/commit/3a56d366865...

It looks like a good start - I'll follow up on github. Thanks!

I'm suspicious of certain possible scenarios here. Someone without the history state API (e.g., an Internet Explorer 8 user) who wants to send out links winds up publishing fragment-based links (with all the scattered interoperability breakage thereof), but others get and publish full(-flavor) links. Then someone finds that with more restrictive JavaScript settings, some of the links work and some of them don't, or bookmarks two references to the same thing, or…

It seems like it would have potential for confusion, but it strongly depends on the application and its context. It's possible for the author to partially work around this by providing what amounts to an extra URI indicator (similar to “permalink” markers in blogs and other time-dependent views of content stores), but this is awkward. (Is there an add-on library for that, for that matter?)

Those two URLs don't result in the same behaviour. After clicking the first, you have to click back three times to go back to the current page. This would surprise most users.

Thanks for reporting that. Here's a commit that improves the hash-to-pushState upgrade by using replaceState instead:

https://github.com/documentcloud/backbone/commit/c39ddd0c16e...

Now, if you click on the first link, and then go back once, you should end up back here.

I've been waiting for this feature for a long time, congratz.

This is probably the best articulated post on why hash-based URLs suck: http://danwebb.net/2011/5/28/it-is-about-the-hashbangs