Wednesday, April 30, 2014

Embular Part 1 - Comparing Ember and Angular

Wee! I can draw things! Yay!
Really I'm probably just high from
marker fumes.
 (photo courtesy: @ebryn)

Stuck In The Middle...

I'm in a sort of unique position to discuss this subject. I have a lot of experience with Angular, and I'm now working at Netflix with an Ember core team member, Erik Bryn.

I have spent the past two years or so developing large single page applications in Angular. I've contributed more than a thousand lines of code to Angular 1.3. I'm a "gold badge" holder for Angular on Stack Overflow. I've spoken at a few events about Angular; Nothing "big time", but apparently I've fooled enough people into thinking I know what I'm doing to be considered an "expert". A lot of that is just the luck of when I got into Angular, and my willingness to share my experience in Angular with others.

My Ember credentials are much lighter (for now). As I stated above, I'm currently working on a team at Netflix alongside Erik Bryn, an Ember core team member. The project I'm working on at Netflix is extremely ambitious, it's a ton of fun to work on, and it's the sort of thing where I'm tossed into the deep end, solving pretty interesting problems in Ember, that are actually a lot more complicated than problems I solved in previous Angular projects.

This was originally going to be just one post, but the size of it was out of control. I'm going to try to bust it into several posts that, hopefully will make it more consumable. As time goes on, I plan to post more in-depth comparisons of individual features in each library as well, which I will also link in this series.

What this series is 

  • It's meant to to be an honest comparison between two frameworks. 
  • A love affair with both frameworks. 
  • A plea to those with bias to toss that bias aside and examine the frameworks more carefully and appreciate them for what they are. Brilliant. 

What this series is NOT

  • This series will not make everyone happy. 
  • This is not a "which should you choose?" examination. 
  • This is not a contest or an attempt to convert anyone from one framework to another. 
  • This is not meant to be an indictment of either one of these frameworks as being flawed. 
  • This is not an attempt to proclaim one of these frameworks to be perfect. 

NEXT: Embular Part 2 - What's Great About Angular


  1. I like that you're helping move the conversation beyond the "which is better" discussion of these frameworks. At this point in history, it's pretty clear that they have different base intentions.

    As advertised, "AngularJS is a toolset for building the framework most suited to your application development." It's a framework-building-toolset... It's not pretending to be the same thing as Ember, and in fact goes the extra distance to separate itself from Ember, which as advertised is "A framework for creating ambitious web applications." The intentions behind both projects are actually pretty different.

    To riff on the upsides, one really good thing about Ember I've found is that it provides guardrails that give the developer the sense when he/she's doing anti-pattern things... e.g. rarely would a dev actually create a controller, but would delegate that activity to the router to perform (and inject other dependencies into it) during the run loop... I went through a whole period when learning Ember trying to create controllers manually and stick them into the global space (coming from SproutCore, where this is actually the way things are expected to work), and of course nothing worked right (or for very long, anyway). Once I learned to accept the conventions around routing and dependency injection, I was able to rip out hundreds of lines of code. Plus, the application worked :)

    With Angular, the idea of guardrails doesn't apply. Convention is expressed in the styleguide, but that's far less than enforceable. Of course, since Angular has a different base intention (to serve as the framework for building a framework), teams should be free to implement their own conventions.

    The more projects I work on, the more I'm actually a fan of the golden-handcuffs approach to framework convention. On any Ember project I look at, I know right where to go in the code to work on any part of the application I'm concerned with. I can't say the same thing about Angular. But I can say that if I was interested in building a web application framework, I'd look to Angular as a toolkit for doing so.


This form allows some basic HTML. It will only create links if you wrap the URL in an anchor tag (Sorry, it's the Blogger default)