3 ms·

> Backbone.js is the best client side MVC framework I’ve used, but there are certainly others. Sproutcore is much more powerful. If you haven't checked out 2.0

> Backbone.js is the best client side MVC framework I’ve used, but there are certainly others. Sproutcore is much more powerful. If you haven't checked out 2.0, you really should. I've been following it for years and always thought they had the best KVO system but avoided it due to the js-based layout and enormous size. The 2.0 version binds to handlebars--slightly extended mustache--templates instead of relatively opaque widgets and reduces the wire size to right around the size of jQuery. It's larger than backbone and you have to wade through more concepts but you add an object to an array and the dom updates without any further input. Eliminates the majority of dom manipulation code in your app.

msy 15y ago
Seconding this - Sproutcore 2 is such a different beast to 1.0 it's a pity they share a name. There's a number of concepts, particularly around handling cascades of DOM updates in there that are far more advanced that you'd have to write yourself in backbone.
swannodette 15y ago
And I would argue ClojureScript brings even more to the table than SproutCore or CoffeeScript for clientside development. Having done MVC in all shapes and sizes, I'm not convinced that traditional MVC is a good model given the realities of the DOM.
- grayrest 15y ago
  I've been following ClojureScript with mild interest but letting the clojure enthusiasts make the cowpaths. What I haven't seen is how clojurescript significantly improves DOM interaction. I agree that the core problem of client side development is controlling state, which the DOM frustrates. Sproutcore works around this by essentially binding to the DOM and preferably building a nested state machine on top (statecharts) which doesn't solve mutable state but confines it to smaller pieces. Obviously clojurescript deals well with controlling state in memory but the clojurescript sample stuff I've seen has all deferred actual DOM manipulation to Closure. What's the deal?
gaslightchris 15y ago
Sproutcore has come along way since 1.0, I totally agree. However, the code that I've seen in sproutcore apps just didn't seem as clean, simple and intuitive to me as in backbone apps. What really got me going with backbone is that I could so easily refactor my exist jquery code into a backbone view, and that the models talked to my existing server app (rails) with almost no effort.
jashkenas 15y ago
I had the pleasure of discussing all this with Yehuda last week, but the reason why Backbone doesn't try to do full keypath-KVO-with-template-binding-and-ArrayControllers etc. isn't because the end goal is so very different, but rather because there's a difference of approach in how fine grained your Views are with respect to the DOM. In SproutCore 2, you'll have very specific DOM elements and attributes observing very specific properties of JS objects. Here's a flavor of the Handlebars.js that connects a view to models: {{#collection contentBinding="Todos.todosController" tagName="ul" itemClassBinding="content.isDone"}} {{view SC.Checkbox titleBinding="content.title" valueBinding="content.isDone"}} Whereas in Backbone, you'll tend to allow coarser grained views -- logical chunks of UI and DOM -- to update all together, whenever the underlying model changes. Here's a flavor of the view code that connects to models: this.model.bind("change", this.render); this.notes.bind("add", this.addNote); The end result of both is that you'll be able to add an object to an array, and the DOM will update without any further input. But the style in which you get there is different.
- grayrest 15y ago
  I don't mean to disparage backbone. It's simple in both design and implementation. I had my own KVO system I was using on a project when you announced backbone and I wrote a 10 line patch to add computed attrs and dropped my system for yours. The problem I ran into was composition. It could have certainly been my failure in design but when I started trying to nest views inside other views I found myself unable to just do a innerHTML (i.e. dumb/idempotent) .render() call and instead wound up writing a significant amount of DOM manipulation code to get things working. It's been a few months and the details of exactly why this happened escape me but that's the general outline. The obsessive focus in SC on converting EVERYTHING to a model attribute change altered my thinking process for KVO so maybe I could now use backbone the same way. My impression (since I still haven't done SC2 for more than toy projects) is that the more declarative nature of SC's approach yields cleaner composition. In theory, you should be able to do the same thing with both systems but in practice I found myself having trouble.

msy 15y ago

Seconding this - Sproutcore 2 is such a different beast to 1.0 it's a pity they share a name. There's a number of concepts, particularly around handling cascades of DOM updates in there that are far more advanced that you'd have to write yourself in backbone.

swannodette 15y ago

And I would argue ClojureScript brings even more to the table than SproutCore or CoffeeScript for clientside development. Having done MVC in all shapes and sizes, I'm not convinced that traditional MVC is a good model given the realities of the DOM.

grayrest 15y ago
I've been following ClojureScript with mild interest but letting the clojure enthusiasts make the cowpaths. What I haven't seen is how clojurescript significantly improves DOM interaction. I agree that the core problem of client side development is controlling state, which the DOM frustrates. Sproutcore works around this by essentially binding to the DOM and preferably building a nested state machine on top (statecharts) which doesn't solve mutable state but confines it to smaller pieces. Obviously clojurescript deals well with controlling state in memory but the clojurescript sample stuff I've seen has all deferred actual DOM manipulation to Closure. What's the deal?

gaslightchris 15y ago

Sproutcore has come along way since 1.0, I totally agree. However, the code that I've seen in sproutcore apps just didn't seem as clean, simple and intuitive to me as in backbone apps. What really got me going with backbone is that I could so easily refactor my exist jquery code into a backbone view, and that the models talked to my existing server app (rails) with almost no effort.

jashkenas 15y ago

I had the pleasure of discussing all this with Yehuda last week, but the reason why Backbone doesn't try to do full keypath-KVO-with-template-binding-and-ArrayControllers etc. isn't because the end goal is so very different, but rather because there's a difference of approach in how fine grained your Views are with respect to the DOM. In SproutCore 2, you'll have very specific DOM elements and attributes observing very specific properties of JS objects. Here's a flavor of the Handlebars.js that connects a view to models: {{#collection contentBinding="Todos.todosController" tagName="ul" itemClassBinding="content.isDone"}} {{view SC.Checkbox titleBinding="content.title" valueBinding="content.isDone"}} Whereas in Backbone, you'll tend to allow coarser grained views -- logical chunks of UI and DOM -- to update all together, whenever the underlying model changes. Here's a flavor of the view code that connects to models: this.model.bind("change", this.render); this.notes.bind("add", this.addNote); The end result of both is that you'll be able to add an object to an array, and the DOM will update without any further input. But the style in which you get there is different.

grayrest 15y ago
I don't mean to disparage backbone. It's simple in both design and implementation. I had my own KVO system I was using on a project when you announced backbone and I wrote a 10 line patch to add computed attrs and dropped my system for yours. The problem I ran into was composition. It could have certainly been my failure in design but when I started trying to nest views inside other views I found myself unable to just do a innerHTML (i.e. dumb/idempotent) .render() call and instead wound up writing a significant amount of DOM manipulation code to get things working. It's been a few months and the details of exactly why this happened escape me but that's the general outline. The obsessive focus in SC on converting EVERYTHING to a model attribute change altered my thinking process for KVO so maybe I could now use backbone the same way. My impression (since I still haven't done SC2 for more than toy projects) is that the more declarative nature of SC's approach yields cleaner composition. In theory, you should be able to do the same thing with both systems but in practice I found myself having trouble.