AngularJS vs Ember.js vs Backbone.js: JavaScript Framework Battle Royale!

There’s gonna be a JavaScript framework showdown!

I’m a huge fan of JavaScript, and I love frameworks. Trouble is, there are a ton out there with new ones every day. How to decide which one to use? An app-off, that’s how!

I’m pitching the three most popular frameworks/libraries against each other in a single, simple webapp fight to the finish.

The Contenders


Angular is a Google product designed to add dynamism to HTML by extending its vocabulary. Unlike other frameworks (and conventional MVC design) which pull behavior out of the HTML, Angular uses custom DOM elements and data-bindings to express behavior and link display elements to the model. It boasts automatic two-way data-binding, a modular style, and detailed form validation.

Angular is known for being highly “opinionated”, for better or for worse, and experienced Angular devs talk about the “Angular way”, which broadly refers to using Angular’s native components and code style exclusively. Angular actively pushes a Behavior-Driven Development model, and includes a number of unit and end-to-end testing tools to that end.

Interestingly, Java developers seem to love Angular because it looks and feels like Java. Make of that what you will.


Backbone was created by Jeremy Ashkenas, creator of CoffeeScript, as a lightweight alternative to heavier frameworks like Angular. It’s popular, though not as widespread as Angular, and proponents favor its hands-off, laissez-faire approach to application development. Compared to Angular, Backbone doesn’t care how you structure your app or how you do development. Having only one dependency, it has a very small data footprint in its default state.

The main argument against Backbone is that, while it is indeed very small by default, most projects will require additional libraries, with the resulting app having more requirements overall. Backbone’s bareness allows for easy customization, but also means you’ll be writing a lot of boilerplate code for basic UI stuff that the other two frameworks handle in the background.

Backbone is typically considered the closest to plain ol’ JavaScript. They say you have to learn Angular and Ember, but Backbone is just a library, so it’ll play nicely with whatever JS programming style you prefer.


Full disclosure: this is the only one of the two frameworks I’ve never used. I’ve built a working site using Angular and have done a few prototypes using Backbone, but I have no first-hand knowledge of Ember whatsoever.

Based on what I’ve read, Ember is an even more opinionated framework than Angular. Its motto is “Convention over configuration,” which means it forces you to do things one way–convention–rather than allowing you to tell your app how you’ve decided to do things. The downside to this is that it constrains developers in ways that prevent or hinder customization and it forces them to conform to practices they might not like. The upshot is that it enforces standardization, which usually results in better stability, easier bugfixes, and a generally more pleasant workflow when working with larger teams.

Ember is famous for having the best router in the business, and handles nearly all of the MVC wiring automagically. It’s infamous for relying on Mustache for templating and for being the largest of the three in terms of download size.

One of Ember’s authors was an Apple dev, and the other worked closely on Rails and jQuery. Supposedly, it shows in the enforcement of the “convention” philosophy and a stylistic resemblance to Rails. Quite frankly, not being a big fan of Apple’s “why would you want to do things any way but ours?” philosophy makes me think I’ll not enjoy working with Ember, but I’m hoping I’m wrong, as there are a good many developers who love it.

The Setup

I’ll be making a simple webapp: Bottleday. Bottleday is a single-page app that, given a volume and a bottle size, calculates the number of bottles needed for, well, bottling. It will consist of a start page with a button which, when clicked, will transition to a second page with form inputs and a conditionally-displayed result. For shits and grins the result might be displayed in a modal. As these are all client-side frameworks, I won’t be doing anything with user accounts or data persistence.

I will be using front-end frameworks. My preference is for Foundation 5, but I’ll use whatever happens to work best with the JS framework in question. For instance, I’ll use Foundation for Apps with Angular as it is actually built on Angular and includes several helpful modules–ui-router and ngAnimate–along with Foundation-specific directives. Ember, on the other hand, allegedly works best with Bootstrap.

The Criteria

I’ll evaluate the three contenders on several factors. First and foremost will be the quality of the end product compared to the time and effort to produce it. However, I’ll also be looking at things like the learning curve, the amount of setup required to start developing, and the elegance of the code. Was development frustrating? How helpful was the documentation? Did I have to work against the framework to accomplish specific goals? Perhaps most importantly, would I use it again?

I’ll post regularly (I swear, this time I really mean it!) with updates on progress and host the resulting apps on this site.

Let the battle begin!

Leave a Reply

Your email address will not be published. Required fields are marked *

To create code blocks or other preformatted text, indent by four spaces:

    This will be displayed in a monospaced font. The first four 
    spaces will be stripped off, but all other whitespace
    will be preserved.
    Markdown is turned off in code blocks:
     [This is not a link](

To create not a block, but an inline code span, use backticks:

Here is some inline `code`.

For more help see