For relational data, would a Model represent a row and a Collection represent a result set? I usually think of an MVC app as having a single model representing a schema. It sounds like Backbone is different.
Yep -- the key bit here is that on the server you have access to the entire table of rows, so it makes some sense to conflate the, say, Book class with the entire set of all possible books.
On the client side, you very rarely have access to the entire table -- often you have different slices of it based on different search queries, or associations -- every Book has its own collection of Notes, for example. So just mimicking the Rails-style 1:1 mapping can be a bit of a fallacy.
Exactly. Your server could query the DB for a bunch of rows from a User table and send the data to your client. On your client you'd have a User model, and a UserCollection that contains many Users.
Can the JavaScript elite please get together and make a decision on Backbone.Events vs. EventEmitter vs. EventTarget?
Also, I recommend everyone read TJ Holowaychuck's latest blog post[1] and lets start distributing these types of things as components instead of "frameworks".
These are 3 implementations of the same thing. I can imagine there are people using Backbone, YUI, and EventEmitter. Oh, and they might be using some other library which shims the EventTarget interface and uses CustomEvent objects.
Read the Holowaychuk article. We need to stop working with frameworks and start working with components. How great would it be of I could use Backbone without Events (not picking on Backbone.Events here, just an example), or use a JQuery function that one of my libraries requires without including all 32k of it.
