First app was slow - known backbone symptom of zombie views: a view that doesn't die. Just creating view after view after view. If you have a single page application and you do this it will run out of memory. You need some method of killing views and clearing memory. Added a garbage collection method but this requires explicitly calling - will get forgotten. Ended up writing much more code than necessary. Backbone Marionette does a much better job of this. If you are doing MVC you should be interacting with the models. Common symptom of Backbone is obese views.
Backbone is not meant to be used out of the box - it's the starting point for building upon: not enough abstractions. (Ember has possibily too many abstractions.)
Best way to communicate in Backbone is to raise events - not having views calling views. True client side MVC is models updating views via the observer pattern.
Ember has a true MVC methodology - always deal with the model. Any change to the model is reflected in any view that references. Ember is all-or-nothing, don't use it for parts of an application.
URL router can specify with very little code which model is used to build views. Rendered by handlebars templates. A lot of conventions in Ember which aren't documented - yet. Templates have very little logic capability which removes temptation to go overboard.
The controller is a proxy to the back end data. Adds computed properties that can be referenced in templates and can observe other objects and re-render when they change.
Don't change the view, don't hack around with the DOM - only change the model.