This is a very useful post -- unfortunately, it describes an all too common occurrence: treating a single example as gospel truth. I've gone ahead and added an explicit "There's More Than One Way To Do It" section to the FAQ.
'Collections should keep track of their views' seems badly explained. You're not keeping references to views on a collection, you're keeping a reference to subviews inside a view that uses a collection. The code is correct, and agnostic to whether the collection is local to the view, or a shared collection.
When building apps on Node.js, we use the same Backbone models and collections on both client and server. The difference is the Backbone.sync implementation:
* On client Backbone.sync does AJAX calls
* On server Backbone.sync talks to database
In some cases we also do Backbone.sync via socket.io
Note: Backbone.sync is the method all I/O operations on Backbone.js models and collections call. You can either use the default AJAX-based implementation that Backbone.js ships with, or override it with your own.
AJAX will be the lowest layer. Think of it as the database calls in an ORM like activerecord. You have an object, you do some validations or perform some logic and when you want to persist it on the server, you make an ajax call. In backbone you will call save on the model and it will do a POST or PUT request based on whether this is a new or already existing model.
Except I think it's more like MVVM in client-side JS code.
You don't really have a request dispatcher on the client side (a controller). Instead, you have a View Model, which is basically a representation/manager of the View in JS code (where the View itself is HTML).
One could easily argue that Backbone is the controller. Or even the EventEmitter.