Think of the router as the "main" method of your application. It's passing you the initial arguments. You just parse it and run the correct logic and/or display the view that is required.

That's a pretty handy shift in perspective.

I've hacked my webserver to respond to any request that looks like a Backbone route. For example, if you define a backbone route '/search/:query/:page', the server will return a minimal html page to any request starting with '/search'. The minimal html contains the backbone and app javascript, which then dynamically renders the page.

I've done something similar with a Symfony2 application I'm working on, but with a tweak.

The app is basically one big REST endpoint, but it does some header sniffing to handle requests with a "text/html" Content-Type. If it encounters one, the request to the still goes through and returns JSON, but that response is then injected as a preloaded datastore into the template being rendered. This bypasses the whole double load scenario that Twitter once was. Discourse is a great example of this in action, just have a look at the view-source://

Always load index.html, give up the idea that "I'm already on the server, I should go ahead and render here", you'll never win trying to do that.

this is bad advice imo. in a good system you should render what people requested and then go from there, if the system does not cater for it then the system is not good enough.

You absolutely should render it, in the client.

I honestly just don't agree with this. any templating language you use should work equally well on the client or the server and you should be able to get anywhere. we obviously consider other types of constraints than you do.