

A Comparison of Angular, Backbone, CanJS and Ember - potomak
http://sporto.github.io/blog/2013/04/12/comparison-angular-backbone-can-ember/

======
ganarajpr
Community wise, if you give a 5 to Backbone and 4 each to Angular and Ember -
I would be somewhat ok with that.. But still a 3 to CanJS is a bit far-
fetched...

CanJS github has ~500+ stars. 25 questions on SO.

In comparison Github stars: Backbone - 13k+ Angular - 8.5k+ Ember - 6.5k+

StackOverflow questions :

Backbone - 8.3k Angular - 4.4k Ember - 3.4k

Based on this atleast I would give a rating of 5 - BB , 4 - NG , 3 - Ember and
1 or 0 to Canjs under community section.

If you add Google Groups stats to this , then Angular wins out in community.

------
andrew_wc_brown
I built a web-app for my previous startup in Backbone, after a year and half
working with it, (1) I got frustrated with the amount of files I had to
create, (2) its performance, and (3) the difficulty to write pure tests, (3)
no concreate convention.

EmberJs doesn't relieve me of any of these problems other than convention, but
I'm currently working on contract work that has me using EmberJS

I didn't like Angular for many reasons, but they promised to solve my big 4
problems. What I didn't like at first about Angular. Cocumentation is written
from what I'd expect from a computer science major, I had to litter my dom
with tons of tags and I had to overcome the idea of their syntax as ugly. But
it did everything I needed. I reduce my javascript by 70%. I got ride of most
of my other 3rd part libraries. Performance was awesome. I didn't need to
figure out how to compile all my templates into one js file. It made testing
dead easy since all I was left was logical javascript.

------
knite
I expected to see Batman and/or Knockout on this type of comparison.

Also, I may be biased because I haven't heard of CanJS, but this article seems
suspiciously favorable toward it. Was the article written with a bit of
promotion in mind?

~~~
bsaul
I had the exact same impression. Judging by its github account, he seems like
a contributor to the CanJS project, so maybe he's a little biaised. In
particular, the "maturity" part where he puts CanJS to the same level as
AngularJS, (because CanJS is using some javascriptMVC code) seems a little far
fetched.

~~~
retro212
Why? CanJS' codebase is extracted from JavaScriptMVC which is ~5 years old and
used on a lot of big codebases. It did go through a lot of changes but every
change was made because of the real-world-need.

source: Bitovi employee / core contributor

------
dustingetz
i use backbone for a in-development app that is larger and has a more complex
UI than the examples on the backbone site. (it's in early stages, but we think
we've prototyped enough to know it's going to work nicely.) Most definitely
"serious"; we're talking 10 engineers for a year type of size.

> Backbone requires you to write a lot of boilerplate code, which I think is
> totally unnecessary. This is in my opinion a direct threat against developer
> productivity.

a lot of people parrot this but i think they're missing the point. Backbone
doesn't require you write boilerplate; it requires you to handle dom
manipulation yourself. if you do dom manipulation wrong there's a lot of
boilerplate; or you can use one of many libraries that make this very easy.
backbone isn't meant to be the only dependency, it's meant to play well with
other dependencies. So some of our Backbone.Views use knockoutjs (with
knockback.js) for HTML rendering, and other Backbone.Views use KendoUI widgets
instead of raw HTML. Nowhere are we doing raw dom manipulation and our view
hierarchies are logical, not too deep, and rendering is quite clean. Notably
we are not using Marionette; the "boilerplate" Marionette tries to reduce, for
us, is actual decision points that are essential complexity.

Flexibility in rendering implementation is very important as we're working
with a very talented external graphic design firm to provide a clickable HTML
prototype. We really don't want to be in the business of rewriting their
delivery to suit our framework's rendering choices.

------
Lazare
Once again, nobody ever looks at Knockout. :)

~~~
jimsteinhart
Does anyone have any idea why it is that Knockout is often neglected in these
comparisons?

~~~
radicalbyte
Anti-Microsoft bias is my guess.

~~~
tlrobinson
I've been using Knockout for months and I had no idea it was built by a
Microsoft employee. And why should anyone care?

------
Kiro
Of all the JS frameworks the only one that felt "natural" was Angular. I
instantly saw the benefits compared to doing it the jQuery way.

------
desireco42
I agree it's been a long time to move away from backbone, it is awesome, made
by awesome person(s), but things have moved along in the meantime.

I think Knockout, Batman and SpineJS which is like Backbone upgraded should be
seriously considered.

Lately I use Meteor :)

------
charlysisto
I gave up using Backbone a year ago. Being a server side dev, the 'to much
boilerplate' quickly killed the initial enthusiasm.

But while waiting for Ember to mature, I stumbled on Angular and completely
bought it's original & refreshing approach that is, being ahead of what the
modern browser should be : embracing html components (aka directives),
observables & the beauty of dependency injection. That for me was the initial
'wow factor' beyond the nice feeling you get when binding your first
view/model.

If I was to market angular I'd say it really caught the right angle of
frontend webdev

------
andreypopp
I think that comparing Backbone to such feature rich frameworks like Angular
or Ember doesn't make much sense — you certainly would want to choose some
view technology (maybe even with data bindings) on top of Backbone.View and so
on.

Actually I like how Angular.js extends HTML further with high-level
declarative constructs so I built something like this but for Backbone —
Backbone.ViewDSL <http://andreypopp.github.io/backbone.viewdsl/> — it also
allows you to add directives as new HTML elements and attributes but otherwise
plays well with other libraries, that means it is not yet another "closed"
ecosystem but just a simple plugin for Backbone. You can also take a look to
an implementation of TodoMVC with Backbone.ViewDSL in just 113 lines of code —
[https://github.com/andreypopp/todomvc/blob/gh-
pages/labs/arc...](https://github.com/andreypopp/todomvc/blob/gh-
pages/labs/architecture-examples/backbone.viewdsl/js/app.coffee)

------
lshemesh
I've been using Backbone exclusively for building Tutorialize's
(<https://tutorialize.me>) chrome extension. One year ago backbone seemed like
a very obvious choice, nowadays it's not the clear winner. I'm thinking about
moving away from Backbone and trying out Angular or Ember. I've even thought
about playing around with Dart. The most difficult thing for me has been
dealing with all the things that Backbone doesn't handle out of the box.
Things like zombie views, data binding, and namespacing just to name a few.
The worst thing however has been the constant need to deal with strange quirks
and bugs that I've found almost impossible to track down. I've posed a
question to the #documentcloud irc channel three times and did not receive a
single reply. I believe in the long run that the strength of a framework is
about the conventions put in place. After all, isn't it about making
development easier?

------
corresation
I do not mean this to sound cynical, but are people actually _building_ full-
fledged web apps with these frameworks? Where are they? Any public examples?

The thing is that these tools generally solve the _easiest_ part of problem
space, yet paradoxically they make the novel and interesting parts much more
difficult. They may pay off if your job is an assembly line banging out
trivial CRUD apps, but I just don't see the real value for any reasonable
scale project.

I looked at Angular a while back and while it got rid of a few lines of code,
it made the necessary edges of a modern web app _incredibly ugly_ (and truly
the biggest waste of time is fighting with your framework). That's one of the
reasons I like Backbone's minimalism -- it is more a simple toolbag and less
an all encompassing solution that relieves you of any reason to make
decisions. Backbone also works very well in a non-pure client-side web app,
which are much more common.

Seeing these comparisons I am increasingly getting the impression the
discussion is dominated by people procrastinating from their projects, argue
over the number of lines of "boilerplate" necessary to create an iterator,
which is something that will have negligible significance later on.

~~~
davecap1
I built <http://www.5by.com> on AngularJS in about 3 months, and just a few
thousand lines of code. The same thing in Backbone would have likely taken a
lot more time and a lot more code.

It was my first AngularJS app, and I was learning it on the job, which is why
it took that long. Overall, Angular is a joy to work with and its conventions
force you to write clean, readable, decoupled code.

~~~
romaniv
I find it highly annoying that people who promote client-side MVC and one-page
apps always _claim_ that it's trivial to make pages linkable and make browser
navigation work, yet _the wast majority_ of real-life single-page apps are
missing those features.

~~~
marknutter
That's because it's not generally a requirement for single-page applications.
The idea of a single-page app is to make it feel like a desktop application,
not to make it highly linkable (which is why it was stupid for Twitter and
Gawker to go the single-app route). But yes, it _is_ incredibly trivial to
support it using these frameworks.

~~~
romaniv
_That's because it's not generally a requirement_

Is that a new way of saying "I just don't care about it"?

 _The idea of a single-page app is to make it feel like a desktop application,
not to make it highly linkable_

I've heard that before... from ASP.NET WebForms developers. Incidentally, I've
seen quite a few ASP.NET WebForms applications that were literally a single
page with changing panels and hidden controls. Needless to say, they were a
bloody mess. Thing that normally could be achieved by linking required code
changes. Integrations that could be performed via a simple HTTP post were done
using complicated web services.

Links are the essence of the web platform. Calling something an "app" doesn't
change that.

~~~
marknutter
> Is that a new way of saying "I just don't care about it"?

It's one way of saying it, I suppose, yes. We don't worry about linking to
states in desktop apps so why would we care about linking to states in
desktop-like javascript apps?

> Links are the essence of the web platform. Calling something an "app"
> doesn't change that.

I agree. But when you make a desktop-like app that lives on the web, then
linking isn't as important. I take it your issue is with desktop-like apps on
the web?

~~~
romaniv
My overall problem is that a lot of modern web development trends undermine
the reasons web became so popular in the first place.

Linking is an easy example. Something that didn't require any "extra" effort
now requires "correct" usage of some framework and extra effort. But there are
many other things as well.

~~~
marknutter
Yeah, but seriously, why would you want to link to a particular state in a
desktop-style application? Especially if the intent of the app is to be used
by a single user working with private data.

Take google docs. During any given session there could be thousands of
different states the app is in at any one time, such as certain formatting
options being selected, different popover or dropdown menus shown, or the
content in the document itself changing. There'd be no point in providing a
different URL for each one of those states.

~~~
romaniv
_Yeah, but seriously, why would you want to link to a particular state in a
desktop-style application? Especially if the intent of the app is to be used
by a single user working with private data._

For example, to save some kind of setup you often use as a bookmark. This is
especially valuable in case there are multiple setups you often alternate
between.

To make it more concrete, imagine a table with multiple columns you can sort
by and a bunch of search filters at the top. Your users from accounting always
sort by date. Your users from HR always filter by a particular status and last
name. Your CEO wants to be able to see both views.

If the application supports proper URLs, all of this can be done via bookmarks
with no extra coding. Moreover, if someone suddenly develops the need for a
new weird workflow, they can service themselves simply by bookmarking the URL.

~~~
marknutter
Yeah, definitely a good use case for URLs. Good thing it's so very easy to
support with these newer frameworks.

------
rplnt
I don't really care about the comparison itself (sorry), but the adjustable
results are an awesome idea. I've never seen it before.

~~~
tiedemann
+1 for adjustable bias

------
xsace
Some comparison points are missing. Like testability.

~~~
ubersoldat2k7
Or i18n and form validation, which I find none of this frameworks solve in a
meaning full way.

~~~
virtualwhys
That's what has me on the fence between existing Scala/Play framework server-
side and some-js-framework client-side.

Would be thrilled with my stack if it weren't for the slow-ish build times, so
the thought of offloading the view to the client has some appeal.

For now coffeescript does the trick for client-side functionality -- may
entertain a client-side MVC framework with a less complex/involved project to
test the waters.

------
lee
The very first comparison of assigning scores based on number of features
doesn't add value.

For example, Backbone is designed to be light-weight and this metric doesn't
take that into account.

It would be like complaining that git is inferior because it doesn't have all
the features of IBM's Clearcase.

~~~
ramayac
Exactly! I would give anything if I could use git every day at work instead of
CC.

------
vovafeldman
After comparing the frameworks and talking with client-side expert, my company
decided to go for Ember. Please share what you think about our decision before
it's too late.

~~~
redeemedfadi
I'm making the same decision now. I've used Ember before and it has been a
little painful. I'm going to give Angular a try now. It seems most people on
Hacker News prefer Angular to Ember.

~~~
Lazare
Angular is "hot", but it's not without it's drawbacks. For example:
<https://koglerjs.com/verbiage/angular>

The author's point is that there's a fine line between "writing an MVC
framework" and "writing a compiler", and the AngularJS authors blew past it
without even noticing. And as a result, they now have a pretty crappy
compiler. :)

------
st3redstripe
this is a plug for can.js right?

------
erdogan
Very nice comparison. Is it really time to move on from Backbone? I'm about to
migrate a project to it because I believe in its potential to force me to
write better js code in the long run. Should I not?

~~~
GnarlinBrando
The question you should ask yourself is; "Is it right for you and your
project?" It doesn't matter as far as your project if the community should be
moving on as a whole or not. What matter's is if you, and/or your team, can
effectively use the technology to reach your goals.

------
joshontheweb
If you like Rails, you will probably like ember.js, if you like bottle.py or
flask, you will probably prefer backbone.js. I prefer backbone.js.

------
tlrobinson
How about Knockout?

