

Backbone.js: Hacker's Guide Part 3 - jashkenas
http://dailyjs.com/2012/08/02/mvstar-4/

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

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

