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 :)
> Spine does class/inheritance closer to the "JavaScript" way [...]
Nope. See later on in this thread. Backbone uses constructor functions and prototypes, Spine uses Object.create. Both approaches have properties resolved correctly at runtime.
> Spine seems to have given up the separation between Controller & View.
Nope. Spine Controllers == Backbone Views. Spine doesn't have an equivalent notion to Backbone Controllers (although if one were added, I'd imagine it would be called a Router).
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).
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.
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).
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.
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.
You can create new Models independent of the Collection and they will sync to the server asynchronously when you Collection#add() them, but note that all of the Backbone events ('add','success', etc) are triggered in response to the server. It'd be nice if this was more clear, and perhaps Backbone could trigger additional events based solely on clientside actions...
So did I! I thought it was a spoof of backbone although I couldn't really understand what the reason for the parody was, so I kept on reading to see what it was all about.
Even the name suggests it is a backbone "clone".
Edit:
Upon reading more about it, it sounds like a really nice framework.
A shame it is branded so similarly to backbone which is bound to result in people fighting about which is better, spine or backbone, instead of seeing it for its own merits.
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?
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.
Backbone doesn't become any less great because a similar project has appeared. If we are to believe the claims of the creator, Spine is fundamentally different from Backbone, so I dont think a fork would have sufficed.
I disagree - The more people work with something, the more it can be refined. If you read through the Issues page on Github for Backbone, there are 100s of comments, suggestions and bug fixes, all helping to improve the code and make a better framework.
By introducing a too-similar competitor, (in general, not necessarily Spine) you risk fragmenting the above, which leads to many okay projects, not one great projects.
The point I was making was that Spine isn't a refinement. It may look the same on the surface, but it has some very different ideas about what a Controller is, amongst other concepts.
It's unreasonable to suggest that anyone who has an idea for a project simply abandon it because someone's already working on something similar. It's also unreasonable to suggest that if they do end up writing something really cool that touches on a few concepts of an existing project, that they should keep it to themselves.
I found the documentation for Spine much better than Backbone, or else it was just designed in a more intuitive way. Either way I wanted to use Backbone a while back, but kinda gave up on it.
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.
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.
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.
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.
> 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.
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.
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.
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.
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."
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:
> Whoah - your API looks really similar to Backbone. Why should I use this instead?
> Well, it's true that Spine was inspired by Backbone, an excellent library, and its controller API is very similar. However, the similarities end there. Internally the library works very differently. For example, Spine has no need for Collections, which are required for pretty much every model in Backbone. Spine provides a class library, and has very different ideas when it comes to server sync. Lastly, Spine is much simpler and half the size, go and check out the source.
"Well, it's true that Spine was inspired by Backbone, an excellent library, and its controller API is very similar. However, the similarities end there. Internally the library works very differently. For example, Spine has no need for Collections, which are required for pretty much every model in Backbone. Spine provides a class library, and has very different ideas when it comes to server sync. Lastly, Spine is much simpler and half the size, go and check out the source."
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.
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 :)