

 Sproutcore vs jQuery +backbone.js - thomasdavis
http://ryth.posterous.com/sproutcore-vs-jquery-backbonejs?a

======
jashkenas
To throw my hat in the ring (full disclosure, I work on Backbone.js):

Unless you're a really fastidious coder, _some_ sort of library to help
structure large-scale JavaScript applications is important -- it's far too
easy to degenerate into nested piles of jQuery callbacks, all tied to concrete
DOM elements. To that end, choosing any of these options can be a positive
step, and I have massive respect for Charles and the Strobe team.

If you want to build a desktop-like application, with Apple-esque UI elements,
I'd recommend you go with SproutCore: it's got built-in widgets for all that
sort of thing.

For almost any other application, I'd recommend giving Backbone.js a try.

Backbone doesn't assume anything about your UI. You can use the templating
engine of your choice, and design your interface yourself. It doesn't tie you
down (too much) to a particular data store. We use it with Postgres-backed
models, but folks have built apps on MongoDB, CouchDB, and LocalStorage as
well.

If you're worried about client-side performance, Backbone is much, much
lighter -- both in terms of the amount of JS you have to include on the page,
as well as how fast you can make your UI. Following SproutCore's suggested KVO
patterns is great for most cases, but can bog down performance terribly on
pages with many thousands of items. With Backbone it's a bit easier to choose
your optimizations: how granular your templates are, and how much of the page
you want to re-render at a time.

Claims are nothing without examples, and fortunately both SproutCore and
Backbone have a "Todo List" for an example application. Loading both apps, and
peeking in the Webkit inspector:

SproutCore Todos: 2.675 MB Uncompressed, onLoad in 1470 milliseconds (loading
from localhost). <http://cl.ly/45gI>

Backbone Todos: 265k Uncompressed (160 of which is jQuery), onLoad in 202
milliseconds (loading from github). <http://cl.ly/4626>

... I think that, along with the difference in design, speaks enough for
itself.

~~~
d0m
I've been using backbone exclusively for my project and I'm not sure anymore
if I made the right choice.

The "best" thing about backbone is that it forces you to smartly separate your
code logic. However, I don't agree with everyone about how lightweight it is.
I find myself more and more simply writing the logic/view in different files
without using backbone at all. (I do use a lot of underscore thought).

The problem is that, for really simple models/view, backbone is way too
verbose. And for complicated use, you need to hack backbone hard to make it do
what you want. So, in my opinion (and experience with backbone), it really
shines for medium use.

I wish there was a little library built on top of backbone that make it easier
for small/complicated use.

I'll give you an example of what I mean: If you have a models that contains
other models. At first, I thought that would be builtin, but it is not. So, if
you want to do that the backbone way, you really need to hack it so change in
inner models propagate to outside models. This behaviour is the kind of thing
that a little library could do "for free" on top of backbone.

On a last note, I need to say that I don't like that much the backbone
documentation. Don't get me wrong, each function is well explained and after
reading all of it you get a good grasp of what backbone can do for you. The
problem is that you need to read all of it. I much prefere a small tutorial to
get you started and help you understand the philosophy of backbone with a high
level of models, collections and controllers. And only then, after I started
using it, I would read in depth the function I need.

It's a little bit like if you wanted to learn python by reading all function
in the standard. It takes a lot of time and you might not totally get what
python is. It's better to follow a simple tutorial which explain the big lines
of python, and then, dig deeper in the function you really want.

So, I'm not saying backbone is bad.. in fact, it's probably the best library
out there for simple MVC use. I have huge respect for jashkenas and the job is
has done.

~~~
raganwald
_If you have a models that contains other models. At first, I thought that
would be builtin, but it is not. So, if you want to do that the backbone way,
you really need to hack it so change in inner models propagate to outside
models._

Can you expound on this requirement, perhaps give an example? I'm very
interested in what you want to accomplish.

~~~
d0m
A post that contains comments. Say you have:

    
    
      { id: 3, text: 'test', comments: [{ cid:4, bleh:5}, {c id:6, bleh:4}] } 
    

You give that to a model. It won't automatically create a collection with
comments.

The idea behind backbone is that I could insert a new comment in the page by
simply .add() something to the comments collection. Automatically, that would
trigger a add/change event so that my view could update itself. However, it
was really quite complicated to obtain that behavior.

I know it's a simple example but the more I used backbone, the more "simple"
things like that happened where I had to dig into things I shouldn't have to.

I feel that simple cases should be simple while I would understand that
complicated case might be more complicated. However, with backbone.js, I
really feel that simple cases aren't _that_ simple.

~~~
raganwald
So given:

    
    
        window.Post = Backbone.Model.extend({...});
        window.Comments = Backbone.Collection.extend({...});
        var p = new Post(
          id: 3, 
          text: 'test', 
          comments: [
            { cid:4, bleh:5}, 
            {c id:6, bleh:4}
          ] 
        });
    

You want some way to declare that comments are Comments, so that it is always
the case that:

    
    
        (p.attributes.comments instanceof Comments) === true 
    

And you also want:

    
    
        p.attributes.comments.add({...});
    

To trigger a 'change:comments' event on p, even though you aren't changing the
reference to the comments collection, just changing its comments.

Do I understand you correctly?

~~~
d0m
Yes, perfectly.

~~~
raganwald
<https://github.com/unspace/faux/issues#issue/33>

------
malandrew
I'm currently using Backbone.js + JQuery in my startup and my decision came
down to the following conclusions:

Use Sproutcore or Cappucino if you are trying to emulate a native desktop app
and where long load times are acceptable (i.e. the user sacrifices time to
load everything to not have to wait much if at all after the initial loading).
Also use these two environments when your users are Apple Users.

Use Backbone.js + JQuery in a small startup environment with a lean team where
the front-end devs are multitalented (i.e. they can easily move between
html/css and javascript)

Use a MVVM framework with bigger teams () and with teams where your front-end
guys may be good with html/css and graphic design but have limited or non-
existent stills when it comes to programming intermediate to advanced
javascript and handling mildly to very complex programming concepts.

MVVM has value and I believe it was invented to solve a common
communication/coordination problem in corporate-style environments and
especially with "silo"-ed teams and matrix management. However, the way I see
it will slow down a good front-end developer. MVC is much more powerful and
flexible in the hands of a good dev. MVVM just adds another layer of
abstraction so the pure HTML/CSS and graphic design guys don't have to get
their hands dirty with real programming.

If you are going the Sproutcore/Cappucino route, you really are commiting
yourself to a platform and certain ways of doing things from a user
interaction perspective. You will gain a lot in not having to build some
basic, common interfaces, but you will lose when you need to invent and create
your own custom interfaces.

Summary:

Backbone.js + JQuery = Flexible, powerful, lean - Good for experienced devs

Knockout.js = Less powerful, simple = Overcomes coordination and cooperation
issues in teams where "the left hand doesn't know what the right hand is
doing"

Cappucino/Sproutcore = Complex apps built fast, inflexibility in interface
design patterns. Good for "native-style" apps.

Anyways, those are my opinions. I encourage you to challenge me on anything
you don't agree with as my experience with Sproutcore/Cappucino is limited to
just research and I only built one small app with Knockout.js.

~~~
aaronblohowiak
I think your analysis of Knockout.js is incomplete. You can customize any of
the interactions and bindings, and it supports an entire reactive programming
model (automatic re-execution of functions) that Backbone does not. Especially
with the newer Knockout extensions that turn fromJSON into a full-fledged
updateable model, Knockout competes well feature-wise with Backbone, it just
has a very different flow-of-control paradigm.

~~~
malandrew
I'm sure that my analysis of Knockout.js is incomplete. I checked out
knockout.js when it was first announced on Hacker News several months ago.
Backbone.js was announced on HN at roughly the same time. I gave both a test
drive and came to the conclusion that Backbone.js was more appropriate for my
use as a single developer entirely responsible for the front end, from graphic
design to interactions and events. I hand off responsibility to my co-founder
at the model later. My co-founder is responsible for the MongoDB and Rails
backend.

I'm sure Knockout.js has matured a lot since I first looked at it and that I
need to find time to revisit it one day.

From your comment and the comment of Alisson on the blog post associated with
this thread, I'm pretty sure that my information about knockout.js is out of
date.

However, frameworks aside, I still believe that an MVC approach makes more
sense for small teams where developers handle multiple roles and that the MVVM
approach works better for larger teams and teams with less experienced front-
end developers.

I decided on MVC for my current project working with one other technical co-
founder. However at my previous two employers I would have opted for the MVVM
approach because because I believe it's more "sociologically" appropriate for
corporate environments and for projects where different parts are handled by
different teams (i.e. matrix managed companies),

------
esmooov
Backbone.js is easily one of the finest products I have had the pleasure of
using. There is a small learning curve but after that, it's butter. The best
part, imo, is that more than teaching you to use some foreign dsl, using
backbone.js makes you just better as pojs because it teaches modularity, sane
callbacks, and a whole mess of other stuff. jashkenas and the other guys
behind backbone did a really good job at making a tool that felt like native
javascript.

~~~
jashkenas
A lot of the credit for the ideas behind backbone should properly go to Robert
Kieffer (<https://github.com/broofa>), an old hand at building JS apps.

------
raganwald
I obviously* like Backbone.js+jQuery, although colleagues are using Sproutcore
on a "Rich Internet Application." I'm a big fan of applications that use the
web model, so now that Backbone.js has added Controllers and History for route
support, I give it five out of five stars.

* <http://github.com/unspace/faux>

------
badmash69
Sproutcore is like a full UI widget toolkit -- analogous to extJS or GWT or
java swing in the java desktop world. I am sure you could accomplish a lot
very fast with Sproutcore.

However, I chose jQuery +backbone.js because I am comfortable with the MVC
paradigm and I have a lot of experience with Struts.

For my current project, I am using java Wicket framework for pages crawlable
by search engine while using jQuery +backbone.js for pages that require
authentication and have a rich user interface.Even though GWT or SprountCore
come with a lot of ready made widgets , the JQuery ecosystem is simply
unmatched in terms of widgets available -- with the caveat that you would need
to spend some time to get to learn them.

What I miss most in Jquery + backbone.js combo is unit tests and test runners
integrated into my build system. If anyone knows how to integrate unit testing
of backbone.js based mvc code into ant or maven or any other build system,
please post here.

~~~
clyfe
javascriptmvc has a command-line-able testing:

[http://www.javascriptmvc.com/docs.html#&who=FuncUnit](http://www.javascriptmvc.com/docs.html#&who=FuncUnit)

This video explains it in the second half:

<http://cdn.javascriptmvc.com/videos/2_0/2_0_demo.htm>

~~~
badmash69
JavascriptMVC's unit testing is definitely a big advantage over backbone.

But backbone.js integrates well with my project structure ; I am under the
impression ( and I could be very well wrong about this) is that JavascriptMVC
requires its own project structure and it has its own code generator of some
sort.

It seems that javascriptmvc is geared for huge applications whereas
backbone.js is suited for single page apps.

If I am wrong, do please let me know.

------
Me1000
The question is are you trying to build a desktop class application or not. If
not jquery/backbone is the obvious solution.

If a tablview is particularly interesting to you Cappuccino
(<http://cappuccino.org>) has simply the best tableview out there.

This is what it was like several months ago, and it has only gotten better.
<http://timetableapp.com/TestingEnviro/imdbdemo/>

It's fully customizable too, supporting any kind view you want to put in it,
and will remain very snappy.

<http://githubissues.heroku.com> for example shows of some of this flexibility
and performance in a real world app.

~~~
clyfe
In terms of tableview, I find slickgrid a powertool.

<https://github.com/mleibman/SlickGrid>

~~~
Me1000
This best thing about cappuccino's tableview is that it can be use
everywhere... For example reimplementing tweetie's tweet list (more on that in
a week or so). It doesn't traditionally look like a table, but it is.

It's incredibly flexibly and is used ALL OVER apps in Cocoa. Cappuccino has an
amazing tableview, I don't think that can be said for other desktop class
browser app frameworks.

------
johnbender
The main issue I have with sproutcore is that you build the UI in javascript,
completely ignoring markup, which feels like a huge regression in layout
managment. While this does have performance advantages and Yehuda Katz has
promised that they are working on a way for developers to manipulate markup
directly thats not how its built to be used currently.

~~~
amadiver
Could you expand on why you feel like building a UI in JS is a regression? Is
this a popular sentiment? I really prefer working on layouts without
manipulating markup, so I'm curious to why others feel different. Thanks!

~~~
johnbender
HTML was designed with presentation semantics in mind (eg layout) and using
Javascript to do the job HTML was designed seems like a waste.

Hope that answers your question.

~~~
malandrew
I completely agree with this sentiment, however I think that templating
systems such as JResign's microtemplates or Mustache.js go a long way to
helping us avoid the problems associated with using JS to construct views.

All my views are saved as HTML templates with ERB-like syntax for populating
the views with dynamic data received via JSON.

------
ak1394
Wouldn't you think that <http://dojotoolkit.org/> might be a good alternative?

