There's a good bit of confusion and misinformation in these ten reasons, so perhaps it would be helpful to walk through them and clarify a bit:

1. "A Clear Architecture". The MVC in Spine is structurally identical to the MVC in Backbone (or MV*, or whatever you'd prefer to label it) ... except for:

2. "Models are Models". Following Rails' lead, Spine conflates the class of a Model with the object that represents the Collection of all models of that type. This makes sense on the server-side, where you have ready access to the entire table; but is a misstep on the client side, where most of your lists of models will only represent small filtered collections of the server-side table. It's very useful not to be limited to a singleton, making it easier to have different sets of the same kind of model with different endpoints (/documents/101/notes vs. /documents/202/notes, for example).

3. "Spine.app". Yep -- Backbone doesn't include a file generator. Some folks like putting every class in a separate file ... others prefer to leave their entire (small) app in a single file. It's up to you.

4. "Dynamic Records". The code example shown here works exactly the same way in Backbone. If you find a model by id, you get a reference to the that record. It's not surprising that changing one changes the other because both are the same object.

5. "Elements Hash". It's been proposed for addition to Backbone, and there are plugins for it (https://github.com/chalbert/Backbone-Elements), but we aren't adding it to core, because it's not a great default. With frequent re-renders of Views, cached elements are likely to be either incorrect ... or they all need to be re-queried every time the view re-renders, which would be very inefficient. `this.$(selector)` is a nicer default to have.

6. "The Release Method". Removing Views from the DOM is all well and good ... but the Spine release method doesn't actually unbind model events that the view is listening to. Which makes it completely ineffective at fixing the memory leaks you're referring to. In fact, you can simply stop calling it (just remove the DOM element instead), and see that your app's memory profile remains identical. Unbinding model events you'll still have to do by hand.

7. "Routing Lives in the Controller". In Backbone, routing lives in the Router. Call it whatever you like ;)

8. "Model Adapters". Naturally, this paragraph would read pretty much the same if you replaced Spine with Backbone. Models are in memory, if you call `.save` they'll be persisted with the default REST-style Ajax calls, and there are plugins to make `.save` use LocalStorage, WebSockets, CouchDB, Mongo, etc.

9. "Get a Model from its HTML Element". Yes, by default Backbone doesn't use jQuery.data in order to attach references from the DOM back to models. Most of the entire point of using JS models and views is to stop tying your data concretely to the DOM ... so if you're relying on this feature, it's likely a place that's ripe for refactoring.

10. "Logging". No argument here. Backbone doesn't have any special logging over the built-in JS `console.log`.

Sorry for the exhaustive teardown, but there's enough FUD already. (And full disclosure: I work on Backbone.)

Most of those complains seem to be pretty basic. To me the only interesting one is #4, about syncing models.

As for collections - how would you handle adding/removing objects in Spine? Backbone's collections just let you listen for add/remove events so you don't need to do any manual work there.

Semi-related question for you experts out there: how do these frameworks fit into a multi-page web app (ie: a typical Rails app)? They all seem to target the single-app market and the examples are always so simple that I have yet to figure how to build a larger application with either Backbone, Spine or Ember.

Is the idea to treat each page as a unique application?

Nice overview. Have you ever looked at knockout.js?

This was a great overview, thanks. One off-topic thing though: I'm browsing on my kindle fire, and unless I turn off javascript, your site crashes the browser after a few seconds.

Why lock up the code from the spine tutorial in images?