4 ms·

I'd be curious to hear from anyone who thinks that this sort of parallel hashchange/pushState support is a bad idea. It should prove to be controversial at the

I'd be curious to hear from anyone who thinks that this sort of parallel hashchange/pushState support is a bad idea. It should prove to be controversial at the least. * http://www.documentcloud.org/public/#search/guantanamo http://www.documentcloud.org/public/#search/guantanamo * http://www.documentcloud.org/public/search/guantanamo http://www.documentcloud.org/public/search/guantanamo 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. Hopefully, having the same structure for pushState and hash-based URLs, with transparent upgrades in both directions, is a sane way to bridge these sort of applications to the future.

shinuza 15y ago
I've been waiting for this feature for a long time, congratz.
masklinn 15y ago
> 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.
- jashkenas 15y ago
  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.
  - catshirt 15y ago
    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".
auzieo 15y ago
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.
- jashkenas 15y ago
  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/c39ddd0c16ef1c7b372dc37cdc7d283d686e01aa 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.
bphogan 15y ago
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.
- jashkenas 15y ago
  Thanks for the tip. How does this look to you? https://github.com/documentcloud/backbone/commit/3a56d366865b1b6fdbf1e6cca566cc2855131a1c https://github.com/documentcloud/backbone/commit/3a56d366865...
  - bphogan 15y ago
    It looks like a good start - I'll follow up on github. Thanks!
premchai21 15y ago
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?)
Jase 15y ago
This is probably the best articulated post on why hash-based URLs suck: http://danwebb.net/2011/5/28/it-is-about-the-hashbangs http://danwebb.net/2011/5/28/it-is-about-the-hashbangs

shinuza 15y ago

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

masklinn 15y ago

> 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.

jashkenas 15y ago
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.
- catshirt 15y ago
  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".

auzieo 15y ago

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.

jashkenas 15y ago
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/c39ddd0c16ef1c7b372dc37cdc7d283d686e01aa 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.

bphogan 15y ago

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.

jashkenas 15y ago
Thanks for the tip. How does this look to you? https://github.com/documentcloud/backbone/commit/3a56d366865b1b6fdbf1e6cca566cc2855131a1c https://github.com/documentcloud/backbone/commit/3a56d366865...
- bphogan 15y ago
  It looks like a good start - I'll follow up on github. Thanks!

premchai21 15y ago

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?)

Jase 15y ago

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