[manlon]

This is true, but because Backbone made a poor naming choice. Backbone Views are what one normally thinks of as "controllers" (coordinating presentation and models), and the view/presentation layer is not handled by Backbone per se but by something like Underscore templating. Backbone Controllers really are just some helpers to deal with URL hashes.

In my experience Backbone Views become the "top level" of a client-side app, but that is appropriate because they encapsulate controller logic.

[frekw]

Yeah, I'm aware of that, but from my experience the code can end up uglier than it needs to be, either because you need to pass through proxying views further down the chain, or need to duplicate functionality.

I guess I just dislike the convention of interacting directly with collections from places where it shouldn't be done, e.g a todoView removing its own Todo from the collection (hence the risk of duplicating functionality throughout your code), instead of asking a proxying controller to do it. I think this is the reason as to why I've seen a lot of Backbone code where a reference in to the view is stored in the model itself (e.g http://documentcloud.github.com/backbone/docs/todos.html), which disgusts me since it completely misses the point of MVC.

Also, events passing feels more complicated than it would need to be (even if you can always include Backbone.Event).