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.)
6. Release methods cannot be automatic. You can remove an element out of the DOM easily, but as far as unbinding any associated events, this has to be manual. Why? Because models can exist under different controllers ("views" in backbone). If one controller releases all the events for that model, the other controller now won't update automatically when the model changes. Unbinding logic has to be very specific and precise and there's no magic way around it...and spine and backbone both handle it the same way: they don't.
7. Routing does not belong in the controller (once again, "view" in backbone). Maybe it does in Rails, but controllers are very specific objects meant to deal with one part of a page. Sure, you can make a controller that deals with an entire page and give it sub-controllers, but unless it's actually binding to elements on that overall page, it can make more sense just to route to a simple function that does the loading. It doesn't always make sense to cram everything into controllers.
8. IIRC this is what the "sync" function in backbone is for. Nothing special here, you can overwrite the function to do whatever you want with model data when it saves.
9. From what I know, this creates JS -> DOM -> JS dependencies, which is a recipe for memory leaks. Not to mention, it's probably best to be accessing models directly, since that's the point of these frameworks.
And the debugging is just getting better, and with SourceMap, hopefully will be a non-issue in the very near future.
In the long term, I think it's better to use CoffeeScript as it is a lot more readable and maintainable.
Spine's "features", to a novice, are indistinguishable to Backbone's, which is probably what prompted the author's post.
1. Naming convention (Mootools' getStyle()+setStyle() vs. jQuery's css(), Router vs. Controller, etc.), which is admittedly personal preference.
2. Lowest barrier-to-entry (Spine.app, TodoMVC example)
3. Debugging (see: compiled Coffeescript lineno debate, compiled SCSS/LESS debate)
4. Framework / Library size. I'm turned off by many JS MV* Libraries due to their larger size. Backbone is very small and lightweight - perfect for mobile web apps.
4. Just create a object store that acts as a factory that will return the same object. In plastronJS there is already an mvc.Store that does this for you.
6. I built on top of goog.ui.Component that has a dispose() method that gets called automagically. I added in methods on the control that will dispose the event handlers when the control is disposed (plus it only has on handler for each type and will react based on an element test).
7. I like the router separate as it decouples the routing string. Instead I use a route and then have a mediator broadcast the new route which controls can listen to.
9. Why would you do this? if you are then you're doing it wrong.
Could you (or anyone else) elaborate on how would you refactor storing references to model id's in DOM?
How do I get the proper model instance in my event handler without using attributes? If I have collection view that renders a list, for example. What are the other options I even have then?
EDIT: This way if you update that one model, you're only calling one view's render method. Each view sets up it's own bindings, and when the view is removed, it can remove just the bindings on itself.