If anyone's around the Boston area, we're actually doing the second BackboneConf <i>tomorrow</i> and Thursday in Cambridge, close to MIT. Last year there was a bunch of really lovely discussion about different approaches, different frameworks and libraries, and favorite tips and tricks for doing sophisticated applications in JavaScript. Looking forward to seeing some of y'all there.
I have used both in my startup job and vastly prefer angular to backbone, however I think it's not quite an apples to apples comparison as angular provides a <i>lot</i> more than backbone.<p>That isn't meant as a criticism of backbone per se, rather I think they are actively going for different things - backbone makes it easy to achieve a client-side rendered single page website with MVC separation but <i>lets you control actual rendering and data binding</i>, i.e. maximal control, whereas angular allows you to do the same thing but provides 2-way data binding, code/html reuse via directives [0], local scoping of data on DOM elements [1], dependency injection [2], vastly improved testability [3] and lots more.<p>My experience of actually developing websites with both is that angular is a better experience and involves a hell of a lot less boilerplate than backbone and even though, when it doesn't work, it can be infuriating it is net a simply amazing framework.<p>Obviously I'm very biased and by my own admission my understanding of both is limited and I am certainly not the best developer ever blah, so take this with a pinch of salt. I think if you need maximal fine-grained control over the behaviour of your website while getting help with MVP you're better off with backbone, but in any other situation use angular (or possibly batteries-included alternatives like ember.js or knockout.js - I have no experience with them so can't comment there.)<p>[0]: <a href="http://docs.angularjs.org/guide/directive" rel="nofollow">http://docs.angularjs.org/guide/directive</a><p>[1]: <a href="http://docs.angularjs.org/api/ng.$rootScope.Scope" rel="nofollow">http://docs.angularjs.org/api/ng.$rootScope.Scope</a><p>[2]: <a href="http://docs.angularjs.org/guide/di" rel="nofollow">http://docs.angularjs.org/guide/di</a><p>[3]: <a href="http://docs.angularjs.org/guide/dev_guide.unit-testing" rel="nofollow">http://docs.angularjs.org/guide/dev_guide.unit-testing</a>
Not sure about the methodology here. In addition to having my own startup using Ember.js, I'm constantly meeting with other startups building their business on it:<p>* Discourse<p>* Travis CI<p>* Practice Fusion<p>* Nitrous.io<p>* Embedly<p>* Balanced<p>* Customer.io<p>* Addepar<p>Not sure if you count other places like Square or Zendesk as startups, but they're using it too. We've also seen big companies like McGraw-Hill Education start building out their next generation technology using it.<p>You can find a longer list of users here:<p><a href="http://emberjs.com/ember-users/" rel="nofollow">http://emberjs.com/ember-users/</a>
Am I the only one whose brain was unable to parse the graphs as the article went on? By the time I hit the blue-orange switching diagram (for that's what it most closely resembled), I was fairly sure that I was being put on by the authors.
On a recent project I used pjax, because it was way simpler to figure out what the heck was going on, and it did not have a bunch of extra stuff that was difficult.<p>Angular seemed very nice - until I tried to do something that it did not foresee and... wow... things get complicated really fast when you do that.
We're currently undergoing a complete frontend re-write (after we have proved with prototype we can make money) using Angular and I must say it's been an emotional rollercoaster with plenty of love and hate, but at the end of the day, love wins hands down. I haven't used much Backbone, so you could say I'm biased, but the truth is that Angular really teaches HTML new tricks (directives) which can save you days (or weeks) of development.<p>We're pairing it with Breeze (<a href="http://www.breezejs.com/" rel="nofollow">http://www.breezejs.com/</a>) in order to preload all the entities when user logs in - hopefully achieving 0 waiting time when user clicks around. This part hasn't started yet, but I'm planning a series of blog posts once done.
We are using Ember.js for our upcoming release of billysbilling.com. It's a huge app. We already have 60 different routes and several hundred .js files.<p>The best thing about Ember that I always tell curious newcomers is that Ember is both easy to make small apps with, but it's also trivial to keep expanding into really big apps. You can keep repeating the same pattern infinitely without rewriting old parts of the app, and without feeling like adding bulk to the app. I see our app as a large very flat structure. We can go in and replace every small piece in isolation to everything else.<p>My impression of something like Angular.js is that often when you want to add new features you have to go back and refactor a lot of stuff (just check out the cage match between Tom Dale and Rob Connery <a href="https://vimeo.com/68215606" rel="nofollow">https://vimeo.com/68215606</a>). It feels like a pyramid that will need a lot of maintenance to stay standing.<p>This is not the case with Ember. Ember was written by some very smart people, who have spent _a lot_ of time refining how an app should be developed in the long run. Features are prepared for the future. Both the future of browsers and JavaScript but also the future of developers' apps.<p>I am sure that Ember will prevail over all the other frameworks within the next year and stay on top for many years to come.
I've played with both and I honestly still don't feel comfortable with computing the view on the client side instead of in my code on the server.<p>Most of the form factors we use regularly to access HTML5 type applications are in flux. Today we see the latest quad-core Snapdragon that screams across the silicon leaving empty battery cells in its wake. Tomorrow may be a battery friendly OS that sacrifices resources in your hand for a lower point of entry cost-wise for the non-technical user.<p>If you are using client side JS to build your views, you take a risk not knowing what the end user may be experiencing. Why take the risk at all and let the known variables of your own infrastructure deal with that workload?
I wouldn't draw a strong conclusion about 'larger' startups using Backbone instead of Angular based on this data.<p>There is probably some high correlation between a startup's size and age... Older startups are likely to be larger, and are likely to have started their stack using the popular framework of the time (Backbone). Newer startups will be smaller, and were founded at a time when new frameworks (e.g. Angular) are much more mature.<p>edit: grammar
I think the obvious reason for Backbone and larger teams is that larger teams are more likely to be working on projects that have been around "a while" (being defined as say, more than a year). A year ago, Backbone was clearly a more popular choice. I didn't see anything in the article that corrected for that.
I ran a start-up for several months and we moved from backbone to Ember in December after concluding that Ember was positioning themselves to provide a much more powerful suite of primitives for the type of apps we were targeting.<p>I have now joined another startup and am using Ember to build a somewhat ambitious web application and so far I am on cloud9 wrt the experience. I think the recent additions of the formalized Components api, the new much more flexible Router, and the prevailing ease of preserving URLs makes Ember a pretty obvious win for a certain class of applications.<p>As a quick comparison, I built a small embedded application in both backbone (as idiomatic as possible) and Ember and the BB version was 3x the LOC and much more difficult to reason about.<p>Steve
Of the two choices, I would definitely continue to use Ember.js. Backbone is disqualified due to obvious, reknowned scalability issues; most apps need a plethora of plugins and framework enhancers that jell dubiously and weigh your app down as much as a heavier framework like Angular or Ember, so why bother? Between Angular and Ember, I would take Ember's API over Angular's directive fanaticism any day.
I spent several years building backbone applications, and recently have been doing a lot of work with Ember and Angular. For most of the applications I work on, I find Angular to be a really excellent choice. It fits in very well as part of a larger app with "islands of richness". It's really quick to learn and become productive with. The ecosystem of existing components (directives in angular parlance) is huge. The choice of plain old html for templates means I can take screens of html/css produced with our design team and iteratively turn them into an angular app. And last but NOT LEAST everything is very easy to test thanks to DI.
Whenever someone asks me about learning and using AngularJS I link them to this helpful diagram:<p><a href="http://www.bennadel.com/blog/2439-My-Experience-With-AngularJS-The-Super-heroic-JavaScript-MVW-Framework.htm" rel="nofollow">http://www.bennadel.com/blog/2439-My-Experience-With-Angular...</a><p>I've been using AngularJS for more than three months now and feel like I finally reached a tipping point where the months of agony are starting to pay off. Before switching to AngularJS I used Backbone.js extensively and tried out Ember.js.<p>The biggest thing to realize with AngularJS, I think, is that your entire front-end "stack" needs to be re-evaluated. Having been using CoffeeScript for a long time, I actually ended up taking it out of all my environments so that it would be easier to debug and understand my JS code as it is "interpreted" by AngularJS. I also had to force myself to stop thinking in jQuery and learn to live with jqLite (which naturally pressures you to exercise restraint with by-hand DOM manipulation, angular.element, etc.,.). While it felt unnatural to me at first, writing directives became second nature after I understood how to properly use them and how powerful they really are. When evaluating JS libraries to include in my code, I now find myself asking whether they can be easily integrated in the "AngularJS" way (making D3.js work with AngularJS was great practice).<p>Secondly, we all need to face and accept that the current AngularJS documentation is crap and it doesn't look like it's going to get better anytime soon. In addition to that, I sometimes stumble upon a lot of poorly written (or outdated) AngularJS example code on blogs, videos and SO. I only began to understand what really goes on under the hood when I started stepped into AngularJS's function calls while debugging my code. I also found that much of the functionality is not yet documented or is documented poorly and lot of insights can be found in the code comments left by the Google folks.<p>Was it painful to learn and to use for a long time? Oh yes. Does it still sometimes cause me to tear my hair out? Absolutely. Do I think that it is worth it? Without a doubt.
At <a href="https://starthq.com" rel="nofollow">https://starthq.com</a> we use Angular. Here's a talk I gave that's both an introduction to Angular and a summary of our experiences: <a href="http://video.yandex.by/users/fdconf/view/4/" rel="nofollow">http://video.yandex.by/users/fdconf/view/4/</a> (slides here: <a href="http://www.slideshare.net/olegp/oleg-podsechinfrontendconf" rel="nofollow">http://www.slideshare.net/olegp/oleg-podsechinfrontendconf</a>)
If I want to build a rich js app, with no hash tag URLs (meaning - Google can crawl everything), would you still use Backbone/angular.<p>I'm an amateur when it comes to JavaScript, but we had to jump through a lot of hoops to get a map based application working in Backbone (which was crawlable)-plus the performance was not as good as ... well,let me say competitors not using Backbone.
We're using backbone and marionette, because we re-use a lot of code on the front-end and the backend, including the ability to render the initial page on the server.<p>Angular is interesting, but it's kind of staked out a position on the client side that is rather spectacularly orthogonal to my needs.
Is it even fair to do a straight comparison? Each has their own plusses and minuses I'm assuming - I'm actually quite ignorant on the topic. Can anyone provide a brief breakdown of pros/cons over each.
The sample size ("over 30") is really too small to draw many conclusions. Then again, it's a larger sample size than the typical ranting blogger (sample size of 1) who likes/dislikes a given stack.