Spine.js vs Backbone.js | Hacker News Reader

Spine.js vs Backbone.js

hjortureh.tumblr.com

65 pointslucaspiller31 comments

In summary, one should use spine because it:

    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.

Cherry pick much...?

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.

That's about as rational as being uninterested because the author is a Gemini. CoffeeScript compiles to JavaScript. They are 100% interoperable.

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.

This is the exact problem I ran into.

Is 2.6k really a difference nowadays?

  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.

I'm surprised he did redress this at the summary

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.

I've used Knockout for two applications and it's great; MVVM is definitely more relevant for JS web applications than MVC in many, tho not all, cases.

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.

If you feel that way, you might like knockout-rails. https://github.com/dnagir/knockout-rails

I think I prefer Angular over Knockout. Similar concept but more intuitive and cleaner syntax.

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.

[0]: http://girlfriendnyc.com

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 found backbone to be much simpler, and method names have a clearer intention of what they do and follow common conventions.

Looking at the following Spine methods, Spine.Model.sub, configure, I cannot even make an educated guess what they do.

Used spine for half a year now, and I never had to use those things.

All you need to know are, init, create, save, find.

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.

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.

Backbone is more famous though, I don't know why.

I made a collection of 4 Spine example apps that use a regular PHP backend - click "Examples" http://docs.structal.org/#/pages/87293423

Why has this comment been downvoted?

thanks for the upvote! I'm guessing it's because i'm promoting my own project

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

Backbone.js requires Underscore.js. Total it is 9.6k. that is > 7k

The wording is still wrong! But it doesn't matter much.

It would be better if it was

Backbone is bigger ( 5.6k ) because it depends on the utility library Underscore.js ( 4k ) that makes up for some of Javascript missing features.

Spine's hard-coding of "id" is unacceptable, especially when what they're really referring to is an ID.

For those that don't quite get the difference...

What do you mean "really referring to ID" ? Is that different to id (other than case)?

http://en.wikipedia.org/wiki/Id,_ego_and_super-ego

I hope that isn't a serious response... really?

Reply on news.ycombinator.com