Float Like a Butterfly: Why AngularJS beat out Ember.js in our stack

August 21, 2013 by @toddpersen

A few months ago, I wrote about our experiences with Ember.js and why we chose to stop using it at Errplane. At the time, we hadn't yet selected a replacement and instead opted to launch our new design with as little JavaScript as possible, knowing that it would get successively more complicated as we iterated on it. Why decide today what you can put off until tomorrow, right?

Well, tomorrow finally came and we settled on AngularJS as our replacement. It's light on its feet.With Angular, we found it simpler to use and clearer to understand when looking at each other's code. If AngularJS is Muhammad Ali, Ember.js is George Foreman. Enough said.

Before I get ahead of myself, it's important to know that our use case is fairly specific, though probably becoming more common. The vast majority of the data that we represent in our UI comes from other APIs that we maintain. To put it more succinctly, the servers rendering our views have no access to the data that will be inserted into the DOM on the client side. We needed something that would let us keep our DOM relatively uncluttered, load data from external sources with ease, and handle a wide range of view states almost automatically.

Enter AngularJS

I've come to expect that getting ramped up on a new framework is a rite of passage, and that indoctrinating oneself to its paradigms should necessarily be hard. After putting off my foray into AngularJS for far too long, I was pleasantly surprised to find that getting started was painless. There's a great community, extensive documentation, and tons of fantastic tutorials.To be honest, this was one of the things I found most lacking when working with Ember.js, and for better or worse, I think it may be because AngularJS is just simpler.

A Word About Simplicity

Is simplicity something you want when choosing a JavaScript framework? Call it a double-edged sword, or whatever cliché you choose, but I feel that simplicity is simultaneously underrated and overrated in the software world. Go too far in either direction and and you'll eventually end up cursing at your computer. Maybe Ember.js is the right choice for a really complicated JavaScript application, but that's not what we were trying to build. Inevitably, someone will point out what Ember can do that Angular cannot. Quite simply, I don't care. Angular's simplicity makes me more effective.

Specificity, Or Something Like It

Since the introduction of the asset pipeline, an oft-asked question in Rails-land is "How do I load specific JavaScript on specific pages?" This question doesn't have a perfect solution, but Angular provides you with an interesting concept that is an excellent substitute. Through the use of the ng-app directive, Angular lets you automatically bootstrap a given application on a specific page. If you're crazy enough, you can even load multiple Angular applications on a single page with manual bootstrapping.

Sting Like a Bee

The real power of AngularJS comes from the ability to implement things quickly. Below are examples of taking an array of items and filtering them based on the contents of a text field, displaying the matching items in a list. Very simple, but it gives you a good sense of what makes these two frameworks so different.

Update: My original Ember.js example gave an unfair representation of the amount of code required to generate a relevant comparison. I've updated the code below with a better example, but for those interested, you can check out the original, longer embercasts version here.

First, the example in Ember.js (lovingly provided by Trek Glowacki):

Next, the same example in AngularJS (written by yours truly):

This difference widens even further when you want to populate that list with data from an AJAX call, something Angular does with ease. Ember.js, on the other hand, relies on it's own data persistence library called ember-data, which forces your underlying data sources to conform to a very rigid REST interface. It's not something you always have control over.

Update: It is apparently relatively easy to sprinkle AJAX calls into your Ember apps without relying on Ember Data. I hereby rescind my thrashing of Ember Data, as it's no longer relevant.

Some might argue that Angular's design causes a massive retreat from the principles of Unobtrusive JavaScript. This is completely true, but it's actually a selling point for me. I've grown tired of having hidden code, and keeping the behavior clearly coupled with the DOM makes working with our designer much easier, and keeps us from having to slice up lots of miniature templates. It also makes it easier for others reading my code to track down where view behavior is coming from, unlike unobtrusive hooks to (sometimes arbitrary and brittle) CSS selectors.


AngularJS was designed with testing in mind. This isn't to say that Ember.js wasn't, but Angular uses an incredibly handy method of dependency injection, which makes testing your code in isolation a breeze.

On top of that, it plays nicely with Jasmine, which pleases me to no end. In fact, most of the tests in the AngularJS docs are written in Jasmine, so you get a good jumping off point for a BDD-infused lifestyle. In comparison, Ember.js has some support for integration testing, but its unit testing is not always easy, though an ember-testing library is underway at the time of writing.

Down For The Count

Since we started using AngularJS about 6 weeks ago, we keep finding new uses for it. I think that's the best sign of a good tool. Sure, some people say it's faster than Ember.js, but it doesn't matter much to me. Users would never notice the difference. There are also a ton of great reasons to use Ember, but users would never notice most of those either.

What they do notice, however, is getting new features out the door while building a codebase that will keep us moving fast in the future. In that fight, Angular wins. Hands down.

We're writing a book on monitoring!

This blog is our place to explore ideas and topics in metrics, insrumentation, and monitoring. We'll be talking to customers, testing out tools and compiling our experiences into a free e-book. Fill out the form below to get updates on new monitoring related posts and receive a free copy of the book when it's released.

comments powered by Disqus