Backbone.js 0.5.0 Released (with pushState)

http://blog.documentcloud.org/blog/2011/07/code-release-backbone-js-0-5-0/

by jashkenas • 15 years ago

170 36 15 years ago

blog.documentcloud.org

jashkenas5• 15 years ago

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

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• 15 years ago

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

masklinn6• 15 years 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.

jashkenas5• 15 years 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.

auzieo• 15 years 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.

jashkenas5• 15 years 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/c39ddd0c16e...

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

bphogan2• 15 years 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.

jashkenas5• 15 years ago

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

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

premchai21• 15 years 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• 15 years 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

MatthewPhillips6• 15 years ago

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.

masklinn6• 15 years ago

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

MatthewPhillips6• 15 years ago

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?

condiment• 15 years ago

> What am I doing wrong?

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.

johnbender• 15 years ago

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

nikcub• 15 years ago

I can now scrap my pushState fork :)

Hipchan• 15 years ago

http://stackoverflow.com/questions/6193858/pushstate-and-seo

pushState's SEO issues.

zmanji• 15 years ago

How can there be SEO issues? I thought the whole point of pushState was to allow AJAX loading of content (without refresh) but not break URLS with #!.

alecperkins• 15 years ago

There aren't if used correctly. The SO questioner has a misunderstanding of how the history API and the hashbang scheme are supposed to work.

odiroot2• 15 years ago

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.

encoderer• 15 years ago

Which really should be trivial using most modern 3-Tier frameworks. They universally have a concept of "layout" vs "template" so in a pseudocode logic, all you need to do is tap into the render method and swap out an empty layout when responding to an XHR request.

DrHankPym• 15 years ago

I read somewhere that Backbone was being dropped for Spine.

http://maccman.github.com/spine/

Anyone else know anything about this?

rryan• 15 years ago

Dropped by who?

jashkenas5• 15 years ago

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.

azrealus• 15 years ago

Hey Jeremy! Thanks for releasing the new version!

Backbone.js 0.5.0 Released (with pushState)

Related Stories