4 ms·

Backbone.js: Hacker's Guide Part 3

56 points by jashkenas 14y ago

sophacles 14y ago
Some additional stuff on Backbone's router and the history api support: Essentially the history is "hashless hash url". This is fine, and a convenient use-case. It makes moving to the history api smooth, and allows some cool stuff on the backend too. However, if you want your app to go with the "progressive enhancement" style, rather than the "graceful degradation" style of development, you will have to essentially write your own router. This is because Backbone will revert to hash urls if pushState is not supported. This is not a bad thing, but it is sort of a gotcha. It would be nice to see an alternate router that does "gradual enhancement" style handling[1]. I understand the argument that Backbone is really really aimed at single page apps, but at the same time, it is so useful as a general app framework that this use-case can't be uncommon. [1] So what I mean is: you have a page that has content that you would like to pull from an api - click a link and the javascript gets the data. It renders the content and pushState()'s the url to the correct place -- bookmarkable etc. But if someone is browsing the site sans javascript or pushState, I don't want the link to be to a hash, I just want it to do a full page request from the server. Links and urls don't change, just some details of how the client handles them. Further, if you want to do this style of development, but have some extra features (e.g. for admins, certain users, whatever) that make sense with hash urls and requiring javascript, you now have a total mess with the router, unless you manually do the gradual enhancement anyway.
- jashkenas 14y ago
  Nope, that's incorrect. You can opt-in to the "graceful degradation" style of routing by using: Backbone.history.start({ pushState: true, hashChange: false }); ... which will route URLs using pushState where available, and will run full-page loads where pushState is not supported. It's a pretty rare use case for a Backbone app that needs a router, but it's definitely supported.
  - manuelflara 14y ago
    You just made my day, thank you.
  - sophacles 14y ago
    I am aware of those settings, but they behaved unpredictably last time I tried to use them. They may have improved since. Further, it just plain doesn't handle the case where you want to have hash urls and push-state urls in the same page. [1] The History object is a singleton, so you can't have different routers for different tasks, without getting into the embedded backbone stuff, which is complicated enough that just writing your own router for pushState and keeping the default hash routes for Backbone routers is simpler. [1] Yes I know someone will come along and tell me how horrible my design must be, but here's the thing: hash urls are great for some things, particularly when you DON'T want the server side to know about WTF is happening with internal page state, while at the same time you want to be able to handle the back button nicely. Different tools, different jobs.

56 points by jashkenas 14y ago

Some additional stuff on Backbone's router and the history api support: Essentially the history is "hashless hash url". This is fine, and a convenient use-case. It makes moving to the history api smooth, and allows some cool stuff on the backend too. However, if you want your app to go with the "progressive enhancement" style, rather than the "graceful degradation" style of development, you will have to essentially write your own router. This is because Backbone will revert to hash urls if pushState is not supported. This is not a bad thing, but it is sort of a gotcha. It would be nice to see an alternate router that does "gradual enhancement" style handling[1]. I understand the argument that Backbone is really really aimed at single page apps, but at the same time, it is so useful as a general app framework that this use-case can't be uncommon. [1] So what I mean is: you have a page that has content that you would like to pull from an api - click a link and the javascript gets the data. It renders the content and pushState()'s the url to the correct place -- bookmarkable etc. But if someone is browsing the site sans javascript or pushState, I don't want the link to be to a hash, I just want it to do a full page request from the server. Links and urls don't change, just some details of how the client handles them. Further, if you want to do this style of development, but have some extra features (e.g. for admins, certain users, whatever) that make sense with hash urls and requiring javascript, you now have a total mess with the router, unless you manually do the gradual enhancement anyway.

jashkenas 14y ago
Nope, that's incorrect. You can opt-in to the "graceful degradation" style of routing by using: Backbone.history.start({ pushState: true, hashChange: false }); ... which will route URLs using pushState where available, and will run full-page loads where pushState is not supported. It's a pretty rare use case for a Backbone app that needs a router, but it's definitely supported.
- manuelflara 14y ago
  You just made my day, thank you.
- sophacles 14y ago
  I am aware of those settings, but they behaved unpredictably last time I tried to use them. They may have improved since. Further, it just plain doesn't handle the case where you want to have hash urls and push-state urls in the same page. [1] The History object is a singleton, so you can't have different routers for different tasks, without getting into the embedded backbone stuff, which is complicated enough that just writing your own router for pushState and keeping the default hash routes for Backbone routers is simpler. [1] Yes I know someone will come along and tell me how horrible my design must be, but here's the thing: hash urls are great for some things, particularly when you DON'T want the server side to know about WTF is happening with internal page state, while at the same time you want to be able to handle the back button nicely. Different tools, different jobs.