I'm the co-author of Composer.js, a Backbone/Spine-flavored framework built specifically for Mootools. I feel like because we borrowed many concepts from these two excellent frameworks, I have a very good understanding of their internals. I almost cringed reading down the list of reasons the author provided. I came on here to start clearing some stuff up, but Jeremy beat me to it. Anyway, some more responses:
4. Since models are just javascript objects, and variables in JS hold references to objects, you can pass an "object" all over the place updating it every which way, and all references to that object will stay up to date since they're pointing at the same place. Backbone/spine work the same in this regard. There's no magic object system separate from javascript where object instances are stored in variables. They are just plain old javascript objects.
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.
Please let me be clear: I love both Backbone AND Spine. I love them enough to have copied the hell out of them when building Composer.js. They are both excellent frameworks and do great things to advance the world of javascript apps. I just don't think the author quite understands their internals enough to be posting about them.
4. Since models are just javascript objects, and variables in JS hold references to objects, you can pass an "object" all over the place updating it every which way, and all references to that object will stay up to date since they're pointing at the same place. Backbone/spine work the same in this regard. There's no magic object system separate from javascript where object instances are stored in variables. They are just plain old javascript objects.
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.
Please let me be clear: I love both Backbone AND Spine. I love them enough to have copied the hell out of them when building Composer.js. They are both excellent frameworks and do great things to advance the world of javascript apps. I just don't think the author quite understands their internals enough to be posting about them.