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...<p>CanJS github has ~500+ stars. 25 questions on SO.<p>In comparison Github stars:
Backbone - 13k+
Angular - 8.5k+
Ember - 6.5k+<p>StackOverflow questions :<p>Backbone - 8.3k
Angular - 4.4k
Ember - 3.4k<p>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.<p>If you add Google Groups stats to this , then Angular wins out in community.
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.<p>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<p>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.
I expected to see Batman and/or Knockout on this type of comparison.<p>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?
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.<p>> 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.<p>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.<p>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.
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.<p>I think Knockout, Batman and SpineJS which is like Backbone upgraded should be seriously considered.<p>Lately I use Meteor :)
I gave up using Backbone a year ago. Being a server side dev, the 'to much boilerplate' quickly killed the initial enthusiasm.<p>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.<p>If I was to market angular I'd say it really caught the right angle of frontend webdev
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.<p>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 <a href="http://andreypopp.github.io/backbone.viewdsl/" rel="nofollow">http://andreypopp.github.io/backbone.viewdsl/</a> — 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 — <a href="https://github.com/andreypopp/todomvc/blob/gh-pages/labs/architecture-examples/backbone.viewdsl/js/app.coffee" rel="nofollow">https://github.com/andreypopp/todomvc/blob/gh-pages/labs/arc...</a>
I've been using Backbone exclusively for building Tutorialize's (<a href="https://tutorialize.me" rel="nofollow">https://tutorialize.me</a>) 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?
The very first comparison of assigning scores based on number of features doesn't add value.<p>For example, Backbone is designed to be light-weight and this metric doesn't take that into account.<p>It would be like complaining that git is inferior because it doesn't have all the features of IBM's Clearcase.
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.
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?
I do not mean this to sound cynical, but are people actually <i>building</i> full-fledged web apps with these frameworks? Where are they? Any public examples?<p>The thing is that these tools generally solve the <i>easiest</i> 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.<p>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 <i>incredibly ugly</i> (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.<p>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.