is 2.6k smaller
is 7k and still split into multiple files
doesn't have collections
by default doesn't verify that changes were preserved
must use 'id' for object identifiers
includes a tiny subset of underscore
is written in a functionally equivalent but syntactically
different variant of JS that requires additional tooling
... I'm unconvinced. Do yourself a favor and use backbone.
I found the article to be a little more balanced than that. But, basically once I saw that spine.js is written in coffeescript I wasn't really interested.
It's not just the source. A lot of the documentation is only available with CS examples (even though they provide a switcher at the top of the page), which also means the ecosystem (in terms of people writing blogposts about Spine) is divided in Javascript and Coffeescript examples.
Strangely enough Spine models generate a client identifier that is set on the id before saving to the server and is overwritten as the model is synced for the first time. This is in my opinion very confusing and only increases the likelihood of introducing bugs.
Speaking of neither, but trying to be helpful: check out KnockoutJS. Just used it for a fairly complicated project for a client. Goddamned delightful. Perfect (read: not dogmatic) separation between markup and code. CoffeeScript + Jade templating + KnockoutJS = web app delight.
EDIT: Backbone/Spine target different use cases than KnockoutJS, but KnockoutJS seems to target the more relevant ones.
MVC - MVVM : grudgingly, I agree. I did a bunch of Rails coding, so my MVC is the Rails MVC (not the real MVC). KnockoutJS basically ignores Models, so sets off my Spidey-sense, but...
I haven't done much GUI programming, so I'm not familiar with the classic definition of MVC. KnockoutJS's MVVM (really V-VM) is very clear and I love it.
KnockoutJS would benefit from the addition of Models (in order to make it a 'framework'), but I'm 90% more productive right now and am certain that KnockoutJS will evolve to include Models.
The author lists file size as a reason for choosing Spine - but even with the Underscore.js dependency the difference is only ~3k and even less if gzip'd. Some people have ascii logos in their source[0] that are larger than that.
Not a bad article, but the frameworks are incredibly similar, which meant every section boiled down to "Spine does it like this and so does Backbone". And the eventual conclusion didn't really highlight any meaningful difference between the two.
From the conclusion: "...when the key thing is simplicity, file size or CoffeeScript integration choose Spine. In most other cases [use] Backbone." Simplicity, however, is highly subjective, and certainly from reading the article I saw no clear differences. As for Coffeescript integration, as anyone who's tried will attest, Backbone integrates perfectly with Coffeescript. And finally, the articles treatment of file size was deeply confusing as to which was actually smaller but at worst the difference is only a couple of kb.
In short, there's really not a lot of difference here, which makes it all a bit pointless, I fear.
I think much of this is due to Spine being designed for CoffeeScript, and the article only uses the Javascript notation.
Be sure to look at the documentation http://spinejs.com/docs/models and toggle between the Javascript and CoffeeScript versions of the code samples.
spine clones models and sends that to callbacks, I've had strange problems with clones not updating properly, This is has to be user error, because I'm sure it would be a huge dealbreaker if this happened to everyone, but for me it was confusing enough and hard enough to diagnose that i gave up and went back to backbone.
"Spine aims to simplify MVC, it is lightweight ( 7k ) and integrates well with CoffeeScript. Backbone is bigger ( 5.6k ) and depends on the utility library Underscore.js ( 4k ) that makes up for some of Javascript missing features."
Someone failed at math or failed at making that sentence understandable...
Having tried to use both, Spine is far more intuitive since it doesn't split a model into collections and model. This is more similar to server based mvc framework like rails and django.
