Here's my iconoclast answer (with a further caveat that I'm a systems programmer who follows web development in my spare time, not an expert on any of this):
Backbone (or Spine, which is just like Backbone but a tiny bit smaller and written in CoffeeScript) is Yet Another MVC Framework. So think of it like Rails, except this time it runs in the client browser. So instead of translating between SQL and Ruby, you're translating between JSON and DOM. There's a "Model" abstraction, which is just a data structure but has fancy features like the ability to "save" it to the server and the ability to listen for changes. And there are "views", which are just the same old DOM/CSS/jQuery environment you know, with the single stipulation that they need to be associated with exactly one Model. And, just like rails, there are "Controllers" which all the guru's seem to understand just fine but that look like huge messy piles of logic soup to the rest of us.
And, like all MVC frameworks before and after, it's subject to the framework disease. You don't "use" MVC, you "port to it". It infects everything you do, such that you get indoctrinated into the particular MVC subculture you've chosen and spend your time screaming at other people on the internet instead of writing code (edit: c.f. rimantas below.).
Stay away. Or if you must use it, be sane and safe, and stay away from the culture.
Yep, stay away from the advice of some systems programmer who "follows" web development and feels entitled to comment on thing he knows very little about.
Backbone is not MVC framework, it does not have Controllers. The name is very apt: it is basically a small skeleton for your app which gives you things you'd have to reinvent and provides some organization and structure.
Actually, the description on backbonejs.org describes it very well:
> Backbone.js gives structure to web applications by providing models with
> key-value binding and custom events, collections with a rich API of enumerable
> functions, views with declarative event handling, and connects it all to your
> existing API over a RESTful JSON interface.
It is very small and simple (and even "rich API of enumerable functions" is provided by underscore.js on which backbone.js depends).
Backbone doesn't actually have controllers, only models and views. Even without that technical distinction, I'd still be hard-pressed to actively describe Backbone as MVC (especially compared to other JS frameworks like SproutCore or Ember, which do actively force you into a more traditional MVC structure).
It doesn't actively encourage you to structure your code in any particular way, other than "separate your business logic and DOM logic", which you probably want to be doing anyway if you're building the sort of JS-heavy rich web application that people tend to recommend Backbone for.
* One is just a fancy web page, it uses Backbone in a traditional sort of MVC way. I don't use the router tho, doing my own thing with pushState and gradual enhancement. Lots of views and models keep things separated sanely.
* Another uses it because I wanted an easy mechanism to map between storage and app. I think the only reason I used views in this case was because I had already been using a template, so I just threw it in a view to tie events together.
* The last I don't use any of the "talk to the server" features, but use the event model because it allowed for easier reactive style stuff with events and forms, and tying into canvas frameworks than alternatives. The data model doesn't fit nicely with Backbone, so I did my own thing.
The point is, Backbone keeps it easy to not get sucked into the whole model if you don't want to.
This is complete rubbish. Backbone doesn't care about the DOM, it works nicely with jQuery, but it helps you to remove app logical state from the DOM. A view can bind to as many models as it needs, it simply has a connivence helper for a single model called "model".
Backbone doesn't care about the DOM in precisely the same way that Rails doesn't care about HTML. And Model isn't a "convenience helper", it's a class from which you must inherit if you're going to do anything at all. A "helper" for this stuff would be something like a "save" function that took an arbitrary Javascript object and pushed it automatically to the right CRUD method on a server. Backbone isn't like that at all. Dependencies like that fester.
You said a view can only have one model, I was saying that within a view "model" is just a connivence helper function, you can reference as many models as you like, but give them their own name
You certainly have strong opinions for someone with no idea what they're talking about. Here[1] is the official backbone documentation. Please, point out the "Controller" objects.
While you're looking for that, maybe you should consider leaving the explanation of a technology to people who have taken the time to learn something about it.
You should try Backbone.js. While I do appreciate your general sentiment about the cultures, you should try it first. It's not really as big a deal as you're making it out to be. It's actually pretty small and doesn't do that much. You can make views using lightweight templates or not, your choice.
The main issue in my view is that most of the examples out there are just too simplistic. But it's too light to be considered an indoctrination platform like Rails or something like that.
Backbone (or Spine, which is just like Backbone but a tiny bit smaller and written in CoffeeScript) is Yet Another MVC Framework. So think of it like Rails, except this time it runs in the client browser. So instead of translating between SQL and Ruby, you're translating between JSON and DOM. There's a "Model" abstraction, which is just a data structure but has fancy features like the ability to "save" it to the server and the ability to listen for changes. And there are "views", which are just the same old DOM/CSS/jQuery environment you know, with the single stipulation that they need to be associated with exactly one Model. And, just like rails, there are "Controllers" which all the guru's seem to understand just fine but that look like huge messy piles of logic soup to the rest of us.
And, like all MVC frameworks before and after, it's subject to the framework disease. You don't "use" MVC, you "port to it". It infects everything you do, such that you get indoctrinated into the particular MVC subculture you've chosen and spend your time screaming at other people on the internet instead of writing code (edit: c.f. rimantas below.).
Stay away. Or if you must use it, be sane and safe, and stay away from the culture.