Live data from Hacker News

Spine -- A lightweight framework for building JavaScript web applications

maccman.github.com

31–40 of 50 posts

Re: Spine -- A lightweight framework for building JavaScript web applications

#31

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 Co…

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

Re: Spine -- A lightweight framework for building JavaScript web applications

#32

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 Co…

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

Re: Spine -- A lightweight framework for building JavaScript web applications

#34

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

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

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.

Re: Spine -- A lightweight framework for building JavaScript web applications

#35
post #31

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 Co…

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…

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.

Re: Spine -- A lightweight framework for building JavaScript web applications

#36
post #35
post #31

Earlier quoted context omitted.

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…

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-s…

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

Re: Spine -- A lightweight framework for building JavaScript web applications

#37
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.

Re: Spine -- A lightweight framework for building JavaScript web applications

#39
post #12

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…

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.

Re: Spine -- A lightweight framework for building JavaScript web applications

#40
post #8

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…

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...
Post reply on HN