

Spine -- A lightweight framework for building JavaScript web applications - jashkenas
http://maccman.github.com/spine/

======
napkindrawing
As I'm currently building a Serious Application in Backbone (dozens of Models,
dozens of Views, a dozen Controllers), the differences between Spine &
Backbone to me seem to come down to:

Spine does class/inheritance closer to the "JavaScript" way where properties
are resolved correctly at runtime, Backbone seems a little more hackish in
this area IIRC (+1 Spine).

Spine seems to have given up the separation between Controller & View.
Backbone has a great separation here that has been a great aid to me in
refactoring a large application. (+1 Backbone)

Backbone treats collections of Models (Backbone.Collection) as proper first-
class citizens. Collections can receive & emit their own events, handle their
own serialization/fetching, and make use of all Underscore.js methods (+1
Backbone)

Other than that they seem pretty similar to me. So my verdict: Spine +1,
Backbone +2 :)

~~~
frekw
I actually think that Spine seems to implement more sane controllers than
Backbone (but I never really liked Backbone's way of doing it in the first
place).

Controllers are supposed to coordinate the interactions between views and
models by propagating changes and events between the two.

For example, if you had a todosController responsible for controlling a
collection of views, there isn't really a clean way (in my opinion) to utilize
it from two independent Backbone views without passing the controller through
to the view (which makes the view depend on the controller). By handling
events in the controller instead of in the view, you remove this dependency
(which is also similar to my perception of Cocoa's delegates/SproutCore's
bindings, but I may be wrong).

Both Spine's and Backbone's view layer consists of rendering templates to the
DOM. To me, a "proper" view layer would include things like positioning and
both frameworks seem to utilize CSS to do this, for the most part.

I think of Backbone's controllers as a poor man's State chart, without any
enter or exit callbacks (e.g going from "#/" to "#/todos" should trigger a
callback that states that I will exit the state "#/", so I can do necessary
cleanup).

~~~
manlon
This is true, but because Backbone made a poor naming choice. Backbone Views
are what one normally thinks of as "controllers" (coordinating presentation
and models), and the view/presentation layer is not handled by Backbone per se
but by something like Underscore templating. Backbone Controllers really are
just some helpers to deal with URL hashes.

In my experience Backbone Views become the "top level" of a client-side app,
but that is appropriate because they encapsulate controller logic.

~~~
frekw
Yeah, I'm aware of that, but from my experience the code can end up uglier
than it needs to be, either because you need to pass through proxying views
further down the chain, or need to duplicate functionality.

I guess I just dislike the convention of interacting directly with collections
from places where it shouldn't be done, e.g a todoView removing its own Todo
from the collection (hence the risk of duplicating functionality throughout
your code), instead of asking a proxying controller to do it. I think this is
the reason as to why I've seen a lot of Backbone code where a reference in to
the view is stored in the model itself (e.g
<http://documentcloud.github.com/backbone/docs/todos.html>), which disgusts me
since it completely misses the point of MVC.

Also, events passing feels more complicated than it would need to be (even if
you can always include Backbone.Event).

------
netghost
Seems neat, but it would have been nice to differentiate itself from backbone
a little more upfront. The sites even look similar.

The key architectural difference seems to be that the ui is updated before the
server responds, which is great in a single user situation, but can get pretty
inconsistant once you're in a multi user app.

I do have to say that I like the patterns section at the end, it's always good
to see a prescription for how you would use a library or framework.

~~~
jashkenas
That's actually not an architectural difference. In Backbone, when you call
.save(), the attributes update instantly, and the changes are synced to the
server asynchronously.

~~~
netghost
That was the main difference pointed out in the documentation. I guess I'd
have to try it out to see how it differs in practice.

------
beseku
I'll be honest, it's an MVC JS framework centred around jQuery or Zepto. If
I'm familiar with Backbone, what is going to drag me over to this - the
size/number of lines of code isn't, thats for sure.

Javascript frameworks are making all of the mistakes that PHP frameworks did,
no differentiation and promoting fragmentation. Backbone is up on Github so
would it not have been more constructive to fork it and create one great
product, not two less great products?

~~~
jashkenas
As in the general economy ... competition between similar open-source projects
is good for developers. Spine provides an alternative way of accomplishing the
same goals as Backbone, written in a different style. I'm sure there's lots
that both projects can learn/steal/share with one another.

Open source isn't a zero-sum game, the more you share, the more you have to
give away.

~~~
collypops
That's what we all sign up for. Some share more than most, which I'm sure many
have/will thank you for!

------
seats
The number of js frameworks popping up is kind of crazy. Clearly tons of
overlap between them all. It kind of makes me want to not choose one and wait
for tech natural selection to whittle the options down and hopefully along the
way the best elements of each are demonstrated and incorporated into the few
winners.

~~~
msy
To a large degree that's what Ender.js is trying to do. Whether it'll succeed
or not remains to be seen.

~~~
joshontheweb
I just don't see Ender.js pulling it off. Mostly it is the use of klass that
puts me off. I much prefer the pure prototypal style of backbone.

------
reustle
How funny, I'm working on Vertebrae.js, a JavaScript MVC framework.

~~~
lucisferre
Honestly there are so many JS MVC frameworks. I'm looking at using one in the
next little while, but with so many it's going to take more effort than I'd
like to pick a good one.

------
jsparks
I like the approach of separating the dom events logic into its own
controller.

In backbone the dom events are tied to the view which makes it more difficult
to reuse the logic with other views. I've worked around this by doing pretty
much the same thing as spine; i've created a dom controller from the base
controller, but it's not ideal since the controller was specifically designed
for hash change events.

~~~
jashkenas
I think this just a terminology confusion. Spine Controllers == Backbone
Views.

Both have DOM events, a "this.el" property, a "this.$" selector, and event
delegation. The patterns of use should be the same.

------
marknutter
I've been using JavascriptMVC on a large project for the last couple of months
and have been loving it. I don't think it really matters what framework you go
with, as long as it's not too DSL heavy and does things the JQuery way
(assuming you're using JQuery). Just having something, anything, has made my
life 10 times easier for building big JS apps.

------
tomswift
Out of curiosity why does the Spine site look so similar to Backbone's?

------
munificent
> Since Spine doesn't use constructor functions, due to limitations with
> prototypal inheritance, classes are instantiated with inst().

Can someone explain this to me? I've been using prototypal inheritance through
Closure's goog.inherits() and never had any problem using regular object
constructors.

~~~
firefoxman1
Maybe it's referring specifically to the "new" keyword that can cause issues
if left out when creating instances. If you look at the code, Spine uses
Object.create(this.prototype) for init.

This article is a great explanation on issues with prototypal inheritance
<http://howtonode.org/prototypical-inheritance>

------
pancakeman
Great for making UI. Still a lot of work to do all the crappy "extends" stuff,
but still not bad.

------
Rygu
Typo: the landing page says "Spine is a lightwork framework"

~~~
maccman
That's intentional ;) Seriously though, thanks - all fixed.

------
collypops
I'll have to have a dig around the code to see what's different from Backbone.
Were you involved with this development, Jeremy?

~~~
jashkenas
Nope -- someone just sent me the link this morning, and it was interesting to
poke around the internals.

~~~
heydenberk
It's to your great credit that you promote and engage openly with the
"competition." FWIW, CoffeeScript + Backbone/Underscore/Docco is, in my
opinion, the most exciting thing to happen to JavaScript since the advent of
major DOM libraries, and possibly since before then.

~~~
secoif
+1 to that.

------
bchhun
wasn't this backbone.js ? the TODO example is the same one !!

~~~
jashkenas
This isn't Backbone.js -- it's an alternative. Different codebase, different
function names, partially overlapping API.

At the top of the FAQ, he answers some of the comparison questions:
<http://maccman.github.com/spine/#h-faq>

The bit about it being smaller is pretty misleading (especially when comparing
2k to 3k) -- it may be 500 lines instead of 1100, but the 1100 are heavily
commented, and the 500 are entirely comment-less. It also doesn't include any
of the collection mapping, filtering, and aggregation functions, which contain
a large part of the usefulness of Backbone when used with real models.

~~~
flippyhead
I'm curious how you respond to the differences in the Spine inheritance model
and the argument they make for it:

"Spine's class implementation is one of its features that makes it stand out
from the crowd. Rather than copying properties to emulate inheritance, as most
libraries, Spine uses JavaScript's native prototypal inheritance. This is how
inheritance should be done, and means it's dynamic, properties are resolved at
runtime."

~~~
jashkenas
Backbone uses proper prototypal inheritance ... so I'm not sure which "most
libraries" he's comparing to there.

In fact, Spine doesn't use "JavaScript's native prototypal inheritance",
which, if we're being honest, is the use of constructor functions with
prototype properties. It uses an emulated version of Object.create:

[https://github.com/maccman/spine/blob/master/spine.js#L79-11...](https://github.com/maccman/spine/blob/master/spine.js#L79-119)

... which, even when natively implemented, is quite a bit slower than the real
thing:

<http://jsperf.com/new-vs-object-create>

------
Frozzare
Looks interesting.

------
thomasdavis
The only thing Spine seems to have really tackled is "Collection/Model
synchronization" which in my opinion should have just been built as an
extension to backbone.

Copying the website element for element and 90% of the design paradigm from
backbone.js would have been semi-acceptable to me if the author elaborated
more on the comparison between backbone in his FAQ.

"Lastly, Spine is much simpler and half the size, go and check out the
source."

"Much simpler" seems like a huge call to make and it has been nice to see
Jeremy refute all claims by spine.js thus far.

Edit: Also I don't think Backbone.js should receive any negative points for
naming conventions. MVC has such a diluted definition that it barely matters
how a framework chooses to implement it.

