Can't say I agree with all of the stuff in it, but Chaplin is a neat take on a Backbone.js++</blockuote>
To investigate: how they handle composite/nested views.

In my experience writing Backbone apps, views are very primitive and tend to cause issues. There's no support for any sort of view nesting, which is totally critical for large applications with complex UIs. In contrast, Ember provides an easy way of nesting views inside one another.

The other thing you'll notice with Backbone is that there's a lot of micro-management required when building Backbone views. They need to be properly cleaned up by hand, otherwise you end up with zombie views bound to events, or events that don't fire at all.

It's ironic, but this actually allows AMD users to use backbone in an amd environment without hacking the source.

Backbone checks for root._ but underscore didn't export to root when define was detected, and since underscore is a dependency it was all busted.

Now you can write a little shim to get all the libs you need for backbone w/o touching the source of any of them.

define ['vendor/underscore', 'vendor/jquery', 'order!vendor/backbone'] -> Backbone

You might have a finite set of data that you need to fetch once for your application.
You might have a feed of data that is constantly updating and thus your collection periodically check for updates.

Dealing with the first scenario is quite simple. It would require defining a Collection constructor that has a url property. Calling fetch on an instance of that collection would then fetch the data and that would be sufficient.

Dealing with the second scenario is somewhat more complex for several reasons