9 ms·

Why I switched to Spine.js

98 points by ericclemmons 14y ago

ckluis 14y ago
Nice overview. Have you ever looked at knockout.js?
- ericclemmons 14y ago
  My team & I originally tried out a non-trivial app using KnockoutJS, AngularJS and EmberJS. Knockout was comfortable for me, as I had a Dojo templating background where you'd often specify "dojo-attach-point"s for direct references to specific DOM nodes within your view/template. Knockout seems to be half-angular (DOM attribute bindings) and BackboneJS (Javascript views, logic). AngularJS seems to be all DOM-specific logic, binding, etc. You're able to extend it for your custom logic, but as things got more complicated we had difficulty grepping the large markup. EmberJS polluted the DOM too much for us, particularly when creating dynamic forms, although it seemed to be a much more opinionated BackboneJS. Currently, we're back to using BackboneJS + RequireJS, specifically where our Views have no idea what markup is under them, and the template only defines which "attach points" are needed for events. Really, BackboneJS, SpineJS, AngularJS, EmberJS & KnockoutJS are all extremely fine frameworks, each with their own methodologies (or lack thereof). We've found that each one is best when applied to a specific use-case, while none are ideal for the majority of cases. (Some would argue Backbone is great in every case, but that's because it's practically a blank slate. That's like saying Javascript is great in every case! :D)
  - ckluis 14y ago
    Thanks for the quick review. I'll be curious to see how the javascript MVC & MVVM patterns come of age when Windows 8 and Metro apps allow for native javascript applications.
  - smagch 14y ago
    That review is helpful. I'm going to keep BackboneJS + RequireJS for my project. Technically BackboneJS + almond.js since I build require for production. It seems BackboneJS is the most abstract implemented framework. I always prefer unobtrusive framework.
cmer 14y ago
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?
- dclaysmith 14y ago
  In backbone, I will create a new Router for each page (though sometimes you might reuse the same router for groups of pages that contain the same views).
  - cmer 14y ago
    Thanks! I'll give that a try.
- hehejubee 14y ago
  Where a typical Rails app has a controller per model with all the crud actions for that model, we have used one Backbone router per model. It worked out so that there was one Backbone router per top level nav item.
- apsurd 14y ago
  For multi-page applications the problem becomes how to load and manage dependencies on the client-side. I use http://requirejs.org/ http://requirejs.org/ for this.
piranha 14y ago
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.
- jpallen 14y ago
  No. 4 is something which I've solved in Backbone.js with about 50 lines of (commented) code. It's a pretty simple setup inspired by Rails and it has solved this problem in all use cases I've had. I've put it in a Gist here: https://gist.github.com/2762417 https://gist.github.com/2762417
  - piranha 14y ago
    Sure, pretty straightforward, thanks for the code. So, in the end, no strong points and no collections.
dgabriel 14y ago
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.
jashkenas 14y ago
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 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.)
drivebyacct2 14y ago
Why lock up the code from the spine tutorial in images?

98 points by ericclemmons 14y ago

ckluis 14y ago

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

ericclemmons 14y ago
My team & I originally tried out a non-trivial app using KnockoutJS, AngularJS and EmberJS. Knockout was comfortable for me, as I had a Dojo templating background where you'd often specify "dojo-attach-point"s for direct references to specific DOM nodes within your view/template. Knockout seems to be half-angular (DOM attribute bindings) and BackboneJS (Javascript views, logic). AngularJS seems to be all DOM-specific logic, binding, etc. You're able to extend it for your custom logic, but as things got more complicated we had difficulty grepping the large markup. EmberJS polluted the DOM too much for us, particularly when creating dynamic forms, although it seemed to be a much more opinionated BackboneJS. Currently, we're back to using BackboneJS + RequireJS, specifically where our Views have no idea what markup is under them, and the template only defines which "attach points" are needed for events. Really, BackboneJS, SpineJS, AngularJS, EmberJS & KnockoutJS are all extremely fine frameworks, each with their own methodologies (or lack thereof). We've found that each one is best when applied to a specific use-case, while none are ideal for the majority of cases. (Some would argue Backbone is great in every case, but that's because it's practically a blank slate. That's like saying Javascript is great in every case! :D)
- ckluis 14y ago
  Thanks for the quick review. I'll be curious to see how the javascript MVC & MVVM patterns come of age when Windows 8 and Metro apps allow for native javascript applications.
- smagch 14y ago
  That review is helpful. I'm going to keep BackboneJS + RequireJS for my project. Technically BackboneJS + almond.js since I build require for production. It seems BackboneJS is the most abstract implemented framework. I always prefer unobtrusive framework.

cmer 14y ago

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?

dclaysmith 14y ago
In backbone, I will create a new Router for each page (though sometimes you might reuse the same router for groups of pages that contain the same views).
- cmer 14y ago
  Thanks! I'll give that a try.
hehejubee 14y ago
Where a typical Rails app has a controller per model with all the crud actions for that model, we have used one Backbone router per model. It worked out so that there was one Backbone router per top level nav item.
apsurd 14y ago
For multi-page applications the problem becomes how to load and manage dependencies on the client-side. I use http://requirejs.org/ http://requirejs.org/ for this.

piranha 14y ago

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.

jpallen 14y ago
No. 4 is something which I've solved in Backbone.js with about 50 lines of (commented) code. It's a pretty simple setup inspired by Rails and it has solved this problem in all use cases I've had. I've put it in a Gist here: https://gist.github.com/2762417 https://gist.github.com/2762417
- piranha 14y ago
  Sure, pretty straightforward, thanks for the code. So, in the end, no strong points and no collections.

dgabriel 14y ago

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.

jashkenas 14y ago

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 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.)

drivebyacct2 14y ago

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