Backbone.js 0.5.0 Released (with pushState)
blog.documentcloud.org
Backbone.js 0.5.0 Released (with pushState)
1–10 of 38 posts
Re: Backbone.js 0.5.0 Released (with pushState)
#2I'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
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.
Re: Backbone.js 0.5.0 Released (with pushState)
#3Right 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.
Re: Backbone.js 0.5.0 Released (with pushState)
#4I'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 People who don't care much about Internet Explorer support often say to just use pushState, and let IE users endure full page refreshes ...…
I've been waiting for this feature for a long time, congratz.
Re: Backbone.js 0.5.0 Released (with pushState)
#5I'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 People who don't care much about Internet Explorer support often say to just use pushState, and let IE users endure full page refreshes ...…
> 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.
Re: Backbone.js 0.5.0 Released (with pushState)
#6Right 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…
> 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.
Re: Backbone.js 0.5.0 Released (with pushState)
#7I'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 People who don't care much about Internet Explorer support often say to just use pushState, and let IE users endure full page refreshes ...…
> 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 trad…
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.
Re: Backbone.js 0.5.0 Released (with pushState)
#8For those of you looking to use pushState in your apps, its also broken in iOS 4.2.x.
More information here:
http://stackoverflow.com/questions/6161701/is-history-api-br...
Re: Backbone.js 0.5.0 Released (with pushState)
#9Earlier quoted context omitted.
> 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 trad…
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".
Re: Backbone.js 0.5.0 Released (with pushState)
#10Right 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…
> 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…
They are not arbitrary separations, they are very real. When a user navigates from the URL bar or from a link on another site the browser requests a specific location from my server. Since I'm already serving the browse HTML it makes sense to render my templates at the same time. It doesn't make sense to send only a generic template and then have the popstate trigger an XHR request for some JSON which gets rendered by a javascript template library. That's extra and unnecessary.
What are you suggesting? That I request the entire html doc at every popstate event?