

Why I switched to Spine.js - ericclemmons
http://destroytoday.com/blog/reasons-for-spinejs

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

~~~
theone
The flexibility which backbone provides is a big thing for me. Secondly,
Choosing "CoffeeScript" is a turnoff me, as it require additional learning
curve.

~~~
lucasjans
Turn off for me, too. Not to mention, I can imagine debugging being more
difficult.

~~~
pooriaazimi
There's indeed a learning curve, but because 'it's just JavaScript (c)' is
CoffeeScript's motto, it doesn't take much. On the other hand,
IcedCoffeeScript [1] introduces a fe extremely handy keywords that run afoul
of CoffeeScript's motto.

And the debugging is just getting better, and with SourceMap, hopefully will
be a non-issue in the very near future.[2]

In the long term, I think it's better to use CoffeeScript as it is a lot more
readable and maintainable.

[1]: <http://maxtaco.github.com/coffee-script/>

[2]: <https://wiki.mozilla.org/DevTools/Features/SourceMap>

~~~
lucasjans
SourceMaps look very promising. I see that Chrome has support for them today.
I'll take a closer look when support for CoffeeScript is simple.
[http://www.html5rocks.com/en/tutorials/developertools/source...](http://www.html5rocks.com/en/tutorials/developertools/sourcemaps/)

------
piranha
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
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>

~~~
piranha
Sure, pretty straightforward, thanks for the code. So, in the end, no strong
points and no collections.

------
cmer
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
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
Thanks! I'll give that a try.

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

~~~
ericclemmons
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)

~~~
smagch
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.

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

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

