Even without that uncertainty, it's definitely a bit tricky to move to thinking about everything being in the browser.
Emberjs makes building non-trivial easy while backbone makes building non-trivial apps hard but makes building small simple app easy.
People like talking about the size of emberjs but after you finishing stitching together numerous boilerplate code, you might end up with a bigger code base than emberjs and you are worst off as you have to maintain your boilerplate yourself rather than use a community curated codebase.
Two good getting started tutorial: http://trek.github.com/ http://emberjs.com/guides/router_primer/
Please i don't dislike backbonejs but we should use the right tool for the right job, backbone is not the right tool for non trivial app except you like boilerplate code. I also respect Jeremy Ashkenas. So my comments are not hate induced.
"Backbone is the wrong tool for anything non-trivial" is just hyperbole.
Writing a tutorial / informative blog post in coffeescript is like : Giving an English lesson in Chinese while teacher and students are native speakers of English.
It doesn't make much sense for tutorials to be written in coffeescript unless they are specifically coffeescript tutorials
https://github.com/thoughtbot/backbone-support
It has a CompositeView and a SwappingRouter that you should use in place of Backbone.View and Backbone.Router
1. myModel.on('change:title', this.render, this); // inside `myView`
2. myView.dispose(); // when you are done with `myView`
Backbone is a real pitfall here in larger projects and you have to keep memory leaks in mind when using Backbone events. (sadly JavaScript has no WeakMaps yet, which would solve the problem for us) That's why projects like Backbone Marionette or EventBinder exists which are handling the Backbone events leaking problem better than bare bones Backbone alone. See http://lostechies.com/derickbailey/2011/09/15/zombies-run-ma...
In a very large application I'm writing at the moment I've introduced a common View parent class which extends Backbone views with proper subview handling and correct event disposal. So in my views I can write something like this (works very similar to the Backbone view's DOM "event" mapping field, but instead of DOM events we are talking about Backbone events here) [Edit: well, looking at the submission article, that's very similar to the solution described in the article]
objectEvents: {
'model change': 'reload',
'collection reset': 'render'
}
Backbone subview handling can be a real pain and memory management has to be kept in mind. Every time you are using the "on"-method you should ask yourself when this event gets destroyed and if it could lead to a memory leak. Or you should use something like EventBinder. https://github.com/marionettejs/backbone.eventbinder
Which is one of the main reasons why EmberJS was created.
Sometimes I wonder why backbone is still getting so much love when saner alternatives (Ember, Angular etc.) have been around for so long.
Is it only inertia or is there perhaps a need for a framework in the middleground between backbone and ember (in terms of abstraction)?
This is fixed by ensuring there's an off()/unbind() for every on()/bind(). I do this by following a pattern like the one in this article: http://lostechies.com/derickbailey/2011/09/15/zombies-run-ma...
https://github.com/chaplinjs/chaplin
Simplified router, subviews, model binding techniques like described in the OP are all helpfully baked in.
Always worth considering using a framework layer like Marionette to help you with architecture. Otherwise you will end up writing something similar to it yourself. Which sometimes is necessary, but not always.