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.
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.
> 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.
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.
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.
Right now I'm doing pushState manually and I have a bug that I can't figure out. popstate happens whenever history changes, including when the user types my URL in and hits enter. There doesn't appear to be a way to differentiate between hitting the back button and going to my URL directly. Which is a problem because if they type it in directly I want to render on the server, if they hit the back button I want to do xhr. What am I doing wrong?
As for Backbone, I really need to switch to this rather than manually handling click events and feeding jquery tmpl. Backbone seems to be a much better way to do it but there also appears to be a learning curve that I'm fighting against going through.
> Which is a problem because if they type it in directly I want to render on the server
Why? What difference does the precise way they navigated to the URL make?
> if they hit the back button I want to do xhr.
Most back buttons have a popup menu which let users go to a completely arbitrary url they've already seen, they're not limited to the very last page. They can also hit the button several times to go back to the same page.
> What am I doing wrong?
You're adding arbitrary separations between two instances of the same event: your users going from your site to your site.
Hah, that might be what Spine would like you to think ;)
In all seriousness, Spine is Alex MacCaw's rewrite/re-imagining of Backbone for his O'Reilly book: http://jswebapps.heroku.com/
The broad strokes are roughly the same, but the internals work differently. I'd suggest you look at what both libraries have to offer, and pick whichever suits your fancy. The benefits accrued by your application should be similar in both cases.
Spine doesn't depend on Underscore.js, but also doesn't benefit from Underscore's rich collection functions. If you'd like to each, map, filter, find, reject, every, some, invoke, include, sortBy, without, or pluck over your models, try Backbone.
If Backbone looks too bewildering at first glance, Spine may be easier to start with: the documentation is certainly better geared for beginners.
Or you could use progressive JavaScript, AFAIK. Make your every link a first class citizen (with it's own view) and for supported browsers replace links' default action with content switching (without reloading) using JS requests.
Of course that's a bit harder since your views need to respond in a different manner to casual GETs and AJAX requests.
[+] [-] jashkenas|14 years ago|reply
* 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.
[+] [-] masklinn|14 years ago|reply
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.
[+] [-] bphogan|14 years ago|reply
[+] [-] premchai21|14 years ago|reply
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?)
[+] [-] auzieo|14 years ago|reply
[+] [-] shinuza|14 years ago|reply
[+] [-] Jase|14 years ago|reply
[+] [-] johnbender|14 years ago|reply
More information here:
http://stackoverflow.com/questions/6161701/is-history-api-br...
[+] [-] MatthewPhillips|14 years ago|reply
As for Backbone, I really need to switch to this rather than manually handling click events and feeding jquery tmpl. Backbone seems to be a much better way to do it but there also appears to be a learning curve that I'm fighting against going through.
[+] [-] masklinn|14 years ago|reply
Why? What difference does the precise way they navigated to the URL make?
> if they hit the back button I want to do xhr.
Most back buttons have a popup menu which let users go to a completely arbitrary url they've already seen, they're not limited to the very last page. They can also hit the button several times to go back to the same page.
> What am I doing wrong?
You're adding arbitrary separations between two instances of the same event: your users going from your site to your site.
[+] [-] condiment|14 years ago|reply
pushState is called with three arguments, {state, pagetitle, url}
If the user navigates directly to a URL, state will be null or undefined, in which case your onpopstate handler should not execute the XHR transition.
I'd recommend testing in both Firefox and Chrome, as each browser handles onpopstate events differently.
[+] [-] DrHankPym|14 years ago|reply
http://maccman.github.com/spine/
Anyone else know anything about this?
[+] [-] jashkenas|14 years ago|reply
In all seriousness, Spine is Alex MacCaw's rewrite/re-imagining of Backbone for his O'Reilly book: http://jswebapps.heroku.com/
The broad strokes are roughly the same, but the internals work differently. I'd suggest you look at what both libraries have to offer, and pick whichever suits your fancy. The benefits accrued by your application should be similar in both cases.
Spine doesn't depend on Underscore.js, but also doesn't benefit from Underscore's rich collection functions. If you'd like to each, map, filter, find, reject, every, some, invoke, include, sortBy, without, or pluck over your models, try Backbone.
If Backbone looks too bewildering at first glance, Spine may be easier to start with: the documentation is certainly better geared for beginners.
[+] [-] rryan|14 years ago|reply
[+] [-] nikcub|14 years ago|reply
[+] [-] azrealus|14 years ago|reply
[+] [-] unknown|14 years ago|reply
[deleted]
[+] [-] Hipchan|14 years ago|reply
pushState's SEO issues.
[+] [-] odiroot|14 years ago|reply
Of course that's a bit harder since your views need to respond in a different manner to casual GETs and AJAX requests.
[+] [-] zmanji|14 years ago|reply