
Backbone vs Ember - borismus
http://smus.com/backbone-and-ember
======
knowtheory
I would recommend the JS Jabber from this week over this blog post:
<https://news.ycombinator.com/item?id=3587689>

Jeremy & Yehuda touch on most of the issues in this post and you can hear the
points directly from their POV rather than filtered through someone else.

Additionally it's interesting to hear that Jeremy & Yehuda are at odds
(philosophically) on several other issues which I think help to round out the
ideas behind Backbone, Ember, and other projects both of them are involved in.

------
JackDanger
We're using both Ember and Backbone here at Square. Backbone has proven useful
for small apps (<https://squareup.com/retail>) while Ember is an effective
replacement for Rails when it's backed by a good JSON api.

~~~
marknutter
What do you build your JSON api with? I've been using rails against large
javascript applications. It seems like ember.js is a good match against rails
(especially with <https://github.com/emberjs/data>)

------
jashkenas
Guh. A fun dive into politics, but I'm not such a big fan of Boris'
conclusions, as you might imagine.

    
    
        > Backbone by itself is not sufficient for building complex web apps. 
    

That bit is particularly galling ... It's one thing to opine about stated
philosophy, and another thing to really look at how the rubber hits the road.

SproutCore/Ember (5 years worth of apps, major corporate backing):
<http://sproutcore.com/#application-slider>

Backbone.js (1.5 years worth of apps, just plain 'ol open source):
<http://backbonejs.org/#examples>

'nuff said.

~~~
wycats
Bro come on :(

Ember is a total, ground-up rewrite of some of SproutCore's ideas and you know
it. I don't count any SproutCore examples as Ember examples, and saying that
Ember is anything other than plain 'ol open source is unfair.

I don't count the time you spent on Backbone at DocumentCloud against
Backbone's open source, because it would be ridiculous to do so, and you
shouldn't count time spent at Tilde working on Ember (mostly on our free time)
against Ember being open source.

Our largest contributor (according to
<https://github.com/emberjs/ember.js/contributors>, Peter Wagenet) has done
almost all of his work on his free time, and we have a wide variety of
contributors who were never on the payroll of this so-called "major corporate
backing".

There's a lot that you validly disagree with about our approach, but trying to
attack us for being "not real Open Source" is a low blow.

~~~
jashkenas
Apologies -- since the article was treating SproutCore+Ember as a single
continuous entity, I was blurring the same line -- and thinking of the Apple
and Strobe years... I'll try to keep the blows above the belt ;)

But, I do think that looking at the empirical -- _what's been built with 'em,
and how_ \-- is one of the most useful points of comparison.

~~~
wycats
I absolutely agree that comparing actual apps is a very useful point of
comparison.

Ember itself is actually relatively new. The fact that Ember inherited some of
its runtime semantics from SproutCore might give the mistaken impression that
there is shared code. Everything, including Ember's runtime, was rewritten
from the ground up for Ember, and it's only with the release of Ember 0.9 that
I consider the APIs and codebase stable.

Some companies, like ZenDesk, hopped onboard earlier in 2011, while the
codebase and APIs were still undergoing a lot of churn, and helped flesh
things out. That said, when taking the scope of Ember into consideration,
Ember's adoption curve is behind's Backbone's, so it's not surprising that
there are many more impressive Backbone apps in the wild.

We're proud of many of the apps that people are building with Ember today, and
as the year progresses, hope to compare favorably to Backbone's impressive
list.

~~~
jashkenas

        > ... as the year progresses, hope to compare favorably 
        > to Backbone's impressive list.
    

I'm very much looking forward to seeing them. The more different takes on JS-
heavy apps the better.

I'm about to crash, but would you mind expanding on what you've written here
-- "rewritten from the ground up", and so on -- in relation to earlier posts
like this one:

[http://blog.sproutcore.com/sproutcore-amber-a-report-by-
yehu...](http://blog.sproutcore.com/sproutcore-amber-a-report-by-yehuda/)

... which describe what I've always understood to be the heart of Ember as an
iteration on the core SproutCore internals. Does that blog post no longer
describe what ended up happening to Project Amber?

~~~
dmvaldman
Can't we all just get along...

I've been working with Backbone intensively since V0.1, and though I've very
scarcely looked at ember, I've been following the heated discussions on both
sides. Personally, I think it's damaging to both your publicizing efforts.

Perhaps what would be more beneficial is a more complex hello world app than
the todo list. One that expresses the flexibility of Backbone's minimalism,
along with the larger out-of-the-box functionality of Ember. I'm personally in
the Backbone camp, but it would be easier to let the user decide what is best
for him/her.

~~~
tomdale
On the contrary, I've found the discourse between Jeremy and Yehuda vigorous,
respectful, and edifying. In my opinion, these are the best kinds of technical
discussions; they are like a rock tumbler that wears away at our solutions
until we're left with shiny best practices--and can move on to the next big
problem to solve.

------
gfodor
Just thought I'd throw out SmartClient here:

<http://www.smartclient.com/>

It's an example of what you get when you follow the "framework does everything
but the kitchen sink" philosophy to the end and pile on feature after feature.
(It's open source, too!) It's great if you need to hack together a
"enterprisey" client and don't really care about style or extendability (rare
but these requirements happen.)

The databinding support, controls, and the amount of stuff it does out of the
box is absolutely incredible for a free open source framework. But, it's ugly
as hell, bloated, and if you want to do anything off the beaten path, you're
fucked. But it's a remarkable piece of engineering that goes under the radar
(similar to OpenLaszlo) but also a cautionary tale for the Ember guys to not
take it too far.

~~~
tomdale
Hey, Ember.js maintainer here--

Luckily, providing a widget library is, and will always be, outside the scope
of Ember.js. While we'd be quite pleased to see someone else develop a widget
library on top of Ember, it's not something that we're personally interested
in doing.

The goal of Ember.js is to roll up common patterns web developers are using
into the framework so that they can write less boilerplate. In fact, part of
the reason we renamed SproutCore 2.0 to Ember.js was to emphasize the point
that our value proposition is in the architecture, not the library of
controls.

As a veteran of the SproutCore project, keeping things lean and focused is my
top priority. And, if it helps, we're all extremely allergic to anything that
feels "enterprisey." :P

------
magicofpi
I'm particularly interested – if anyone has experience using Ember – about the
concerns raised about Ember's performance with large amounts of data and
"hairy custom view situations," as borismus puts it. Is Ember actually going
to be slow when dealing with large data sets?

~~~
bcrescimanno
There are some pretty legitimate concerns with Ember and large data sets right
now as the treatment of those datasets tends to be fairly naive and linear.
There are several people, myself included, who are working on ways to address
that problem--but modifying a large collection, at the moment, can trigger the
entire collection to re-render which can be extremely expensive.

FWIW, I'm not an expert on Ember.js or Backbone; just someone trying his hand
at hacking the Ember.js code to work more effectively with collections (since
some of the use cases I have would be impossible using the current methods of
bindings and collections).

~~~
learc83
>modifying a large collection, at the moment, can trigger the entire
collection to re-render which can be extremely expensive.

How large is large enough to cause problems?

~~~
sbarre
I would also like to know this. :-)

~~~
tbatterii
me as well.

------
alanh
> _In my experience writing Backbone apps, views are very primitive and tend
> to cause issues. There's no support for any sort of view nesting, which is
> totally critical for large applications with complex UIs. In contrast, Ember
> provides an easy way of nesting views inside one another._

I have run into this. It’s really frustrating, in Backbone.

------
shawndrost

      In my experience, there's very much a need for a controller when writing even 
      moderately complex apps. You're presented with several options:
    
      1. Write controller code in views
      2. Write controller code in models
      3. Write controller code in a router
      4. Write your own controller infrastructure
    
      If you care about separation of concerns, none of these options are really 
      acceptable.
    

I care about separation of concerns when it's limiting the program complexity,
and I don't have any problem with 3. Routing code is very lightweight, and
it's sometimes beneficial to associate it with controller code -- those
concerns are closely related, and not often referred to separately. In
backbone, it's very easy to split a router into many (controller-style) files.
If others have experiences to the contrary, I'd be interested to hear them.

------
mmahemoff
I see the difference as something like Django/Sinatra vs Rails. Backbone
requires the developer to be more explicit, whereas Ember is more opinionated
and performs magic behind the scenes as long as you follow the conventions.

On a practical note, my experience earlier this week suggests Backbone right
now is far easier to get your hands dirty with. I was excited to use Ember,
but I had a practical time constraint and discovered it's a rough ride right
now, so reverted to Backbone for this task. There's really very few examples,
unless you want to start diving into older Sproutcore docs and trying to
figure out the diffs.

In contrast, Backbone has a wealth of articles and even design patterns and
books. Of course, it's an apples-versus-oranges distinction with Ember being
so much newer, but an important practical issue for developers to be aware of
if they're deciding right now.

------
erichocean
Ember is definitely an alternative to Backbone, but people should stop
conflating Ember with SproutCore: the two frameworks are targeted at
completely different types of apps.

FWIW, the SproutCore community has rejected the Ember approach for the kinds
of apps SproutCore is meant for: large, desktop-style apps that need to run
fast in modern web browsers. The supposed "features" Ember provides, like
auto-updating templates, have proven to have such bad performance in existing
SproutCore apps that developers have almost universally been ripping them out
(this was discovered at the most recent SproutCore User Group last month).

Ember is an alternative to Backbone -- a 600 LOC micro-framework. That should
tell you all you need to know about Ember's scope. (SproutCore is well over
20K LOC.)

------
scelerat
I've been working with Backbone exclusively for the last six months or so, so
don't know what other frameworks are doing with nested views. The OP marks
this as one of Backbone's shortcomings.

I've been writing my backbone app effectively with nested views, where parent
views pass relevant information to child views either through initialization
or functions on the child view, while the child view "communicates" with the
parent view through events that the PV can bind to.

I kind of like the idea of child views not knowing or caring who created them
or why. I do this e.g. with buttons, forms, panels and subpanels, etc.

Is there a good resource for best practices here?

------
Ecio78
Boris, I dont know if it happens only to me, but your blog is badly rendered
on my Chromium (Linux Mint): many many words are overlapped (like all the
paragraph "I like..." under your photo). Everything seems fine in Firefox,
I'll try with Chrome on Windows at work.

Edit: Chrome on Windows is ok, maybe there's something wrong on my Linux
installation

~~~
ch0wn
I have the same problem with Chrome on Ubuntu from time to time. Reloading the
page usually fixes it. It's annoying, though.

~~~
alanh
Huh. That’s been a known issue for quite some time now. I think it’s triggered
by this, maybe?

    
    
         -webkit-text-rendering: optimizeLegibility;

------
skilesare
I'll add my voice to those that would like some much better documentation from
ember.js. I'm starting to finds some stuff on stack overflow but it has taken
a while to find. A few things that would help tremendously when people get
started:

-Examples of the built in controls(tab,select,textfield,textarea). There are only like 6 of them but when you find out they exist and are not documented they feel like 600. The sroutcore history amplifies this assumption.

-The fact that sub views(ie textfield) don't bubble but are really easy to implement by extending TextField. See: [http://stackoverflow.com/questions/8646238/handling-blur-on-...](http://stackoverflow.com/questions/8646238/handling-blur-on-textfield-child-in-ember-view) (PS. Why is this? It seem silly that I can't do {{view Ember.textField change="parentview.change"}} in my views.)

------
Yaggo
Just to remind, there is also batman.js which is very similar to amber.js but
more CoffeeScript oriented.

~~~
skilesare
I've been building and ember app in coffee script. Works well.

------
ww520
Isn't Knockout simpler than either one?

~~~
hartzler
I have written several knockout/coffeescript apps lately and am wondering the
same thing...

------
andyl
Over the past few weeks I've seen a number of Ember evangelists making claims
about BB as 'hard to use' or 'suitable for small apps'.

I don't agree.

The fact is that BB is stable and has loads of documentation and live apps.
Ember not so much.

~~~
scelerat
I love that BB is such a small library. The concise docs at documentcloud plus
the source code was all the reference as I needed, even for my first
framework-oriented browser app.

I ought to connect with the community more, but so far getting up and running
with it (and building a moderately complex app) has been a breeze, as far as
Backbone is concerned.

