AngularJS Vs EmberJS

One of the battles we are seeing the developers fight these days has been for the Throne of JS framework. The interwebs keep fighting these wars and in the end there is never a proper victor. But still we persevere because that is the nature of humans. The contenders in this particular war are Backbone, Ember &  Angular ( there are other smaller colonies but for this discussion and for the sake of brevity we shall leave them out ). . Alteast, these are the 3 most popular MV* javascript client-side frameworks according to github watchers.

We are building Dhi – An Artificial Intelligent Assistant to help you build web apps. You might find it interesting. Go check it out.

This post is not mostly about Backbone because a lot of people have already discussed it at length, come to various conclusions and moved on. Even the inspiration for this blogpost compares Backbone with Ember. I myself have written a longish answer on StackOverflow about the topic.

Disclaimer : I have never worked with EmberJS. So you might deem that I am not the proper person to talk about this. Continue at your own risk. 

This post is really a response to what the inspiration talks about. This is a response based on what I managed to assimilate based on that post. So lets begin…

Backbone and Ember

To set things straight first, after having gone through that post, one thing was clear to me. Ember apparently does , in fact, do more ( much, much more! ) than what Backbone does for any developer. One of the toughest things to do, when starting a project, is making choices. Ember takes care of that for you. It has already made choices and it has already prescribed those choices to you, which means that there is “an  Ember way” of doing things. You stray from this god-chosen path and you are left to yourself.

Backbone on the other hand does not make any choices for you which means that you have freedom to choose. Freedom means that you are in fact wasting quite a lot of time making these choices yourself ( and in the end taking responsibility for those choices ). One thing we have to remember is, the average developer out there is like a sheep. He will never know the boundaries of the grazing field. This means that giving him more freedom will eventually lead to him going astray and never knowing that he actually did. Even in restricted environments, you can do mistakes but lets just say that the chances are less. You would argue that , if there is a lot of freedom, the average developer will be more careful. Yes, he would be when he has infinite time and not when there is a manager behind his back pointing a gun to his head. So, restrictions are good. In fact, they are a blessing. Atleast now you can blame the framework.

Does Backbone have two way data binding? No. Ember does.

Does Backbone have composed views? No. Ember does. In fact backbone has no idea about your DOM. You are left on your own when it comes to DOM.

Does Backbone have a complex model structure ? No. Its model structure is the simplest possible. Its “observe” mechanism arises out of setters and getters that are defined on the base Backbone Model Class. Ember does have a mechanism for declaring complex model structures. It has a totally separate module (Ember Data ) to take care of that.

So far we have established that Ember is in fact a far superior choice to Backbone. Now lets try and take apart Ember, shall we?


Ember is / has been put together with a lot of thought behind it. One of the major things that I noticed when going through trek’s post was that Ember used concepts like Ember.Object.extend(…). If you notice what is being done here, you will understand that we are trying to bring into a language a concept that it refuses to bring in. A class. In fact it explicitly calls it a class ( Note the use of reopenClass ). 

As opposed to this, angular uses a concept that defines javascript. Its prototype chain. It uses a $scope and each scope you create, prototypically inherits from its parent scope all the way upto the RootScope. Most of your activity is done on this object. There is no confusion regarding “this” because you dont really have to use it in most cases.

Data-binding and polluting the views

This is one of the most infamous complaints I have heard of in terms of what Angular / Knockout do to the HTML. In the name of 2 way data binding they pollute the beauty, the sanctity of HTML and add their own shit in between. In terms of templating systems, there are two kinds. DOM templates and String Templates. These string templates take strings , take the data and combine them together and produce a pure html which is then pushed into the DOM.  To those who talk about the pureness and sanctity of HTML / views, I have a few questions. Why the f**k do you really care about it? What you should be caring about is your productivity and how it looks / appears to your user. Lets say you do have some valid reasons. Have you had a look at the code you have to write to produce these templates in handlebars, mustache, underscore or jqtemplates? They are all ugly as shit and even worse. Just to add, computed properties do exist in Angular as well.

Composite Views

How do both the frameworks compare in terms of Composing views and nesting views inside of each other. As far as my understanding goes, Ember has a way of defining these using outlets (with names if you need multiple ). In your handlebars templates you define outlets which can further be installed into the current view as and when required. Swapping and replacing of these outlets is the way to go if you are into Ember. Angular, since it does everything with HTML itself and calls itself Enhanced HTML provides you more attributes that are self explanatory. If you see an attribute called ng-switch or ng-repeat what comes to your mind? Yeah, you are right. They both are responsible for exactly what you thought.

This is how you define a repeated element in handlebars / ember

<code>&lt;script type="text/x-handlebars" data-template-name="contributors"&gt; 
{{#each person in controller}} 

This is how you do the same thing in angular

<code>&lt;span ng-repeat="person in persons"&gt;{{person.login}}&lt;/span&gt;</code>

Which do you think is cleaner? Ofcourse, in the final rendered html the ember way  above is going to look cleaner because all the other stuff is going to get stripped out. In case of angular, all of this (except the thing in double flower brackets ) is going to stay. But, seriously, who is having a look at your final rendered HTML? Just so you know, that who script tag is going to still exist in your final HTML too , but somewhere else.

DOM Manipulation / the ugly part of client side coding

Whether you agree or not, manipulating the DOM is the most ugly part of writing code in JS. By now most of us are so used to it that it has become part of our life, part of the way of our thinking about DOM. Ofcourse, just to encourage you not to do it, IE / M$ had put in all kind of hurdles in front of you and earlier not many tried crossing that barrier. Finally, one day a great leader ( JQuery ) came forward and showed you a way of crossing the sea ( They even parted that sea for you so you can cross) you are now so accustomed to this life across the sea. What if I told you that you can achieve all the things you have been achieving after getting access to these new tools WITHOUT using them? Ofcourse, you still need those new resource. But, use it only when its absolutely necessary. Not everytime.

Component Architechture.

Ember does not provide you a component architecture. It does not provide you a way of defining new components. It helps you define views , even composite ones but that is not one and the same. Angular’s directive mechanism though agreeably raw currently allows you to provide powerful layouts and widgets. This provides a  mechanism for defining terse html code that makes more sense to the reader. It also makes it easier to partition tasks. You can have a component writer and a layout builder – 2 different people doing different tasks they have expertise with. We could even have an open source project which provides you those controls out of the box which anyone can plug -in (just like jquery plugin’s but this one is used declaratively! ).

Dependancy Injection

This is something new in the world of JS. As far as I can tell, not many ( I dont know of one that has DI ) have implemented DI in JS. I will be bold enough to declare that Angular is probably one of the only mainstream framework to implement DI. I am not even going to talk about DI in Ember because it doesnt seem to exist. Those who are new to this system seem to find this to be totally absurd or magic. How can it work? Do we declare everything as global and then input those global variables into these controller functions for the heck of it? Apparently not.

DI makes it extremely easy to manage dependancies. There is a central system (which perhaps is global) that when asked for an object of a particular type gives you that object. What do you do in a typical scenario of OOP. If A has a dependancy on B, you try to figure out what is the best way of getting B into A. Sometimes you do that communication through events, sometimes through an interface etc etc. In DI , A asks the DI system for B and the DI system gives it back. But now the question is ,how does the DI system know what to give back? This is done when A or B is created. They register themselves with the DI system with a Unique Name. Lets say DI has an internal map which has a mapping between the name and the Object / Class to instantiate. So whenever you do a DI.give(“A”) it instantiates this A and gives you back that A.


In Conclusion, it looks like Angular provides  you whatever Ember is providing and more. It also has a smaller footprint ( 25kb vs 37kb), reduces even more boilerplate than what Ember does ( remove all DOM Manipulations!). Just to note : Ember is not done yet because they havent hit 1.0 yet. So we still need to know how they evolve. But it looks like it was created for large applications and helps manage more things than Backbone does, I would even call it an opinionated Backbone on steroids but I dont see it touching the levels of Angular. I dont say this out of malice towards Ember but because angular is showing itself to be a class apart. It dared to think differently and that paid off.

14 comments on “AngularJS Vs EmberJS

  1. I think you missed or are ignoring the central thesis to my preamble: “There’s a lot of writing comparing the three, but once you become familiar with them you’ll see it’s a totally nonsensical comparison. Although their output is the same (i.e. a ‘web app’) they just don’t belong in the same category.”

    Articles like this are built on a faulty premise that, because the output all target the browser, these tools are in any way trying to accomplish the same goals.

    If I may offer an analogy – imperfect as any analogy must be: What you’re essentially comparing is a bathtub and a kitchen sink. Yes, we can “compare” them based on the intersection of their salient features: both contain water, both come with a means of getting water into them, and an apparatus for draining this water away. But to straight-facedly write an article comparing the two is folly. They’re entirely different tools, crafted with entirely different purposes, and that is reflected in their particular form and function.

    When I read “it looks like Angular provides you whatever Ember is providing and more” I can’t help but hear “it looks like a bathtub provides you whatever a sink is providing and more.” After all, you can both bathe *and* wash dishes in a bathtub. Plus, although I’ve never used a kitchen sink, the bathtub has at least 10x the holding capacity of a sink making it an obviously superior dish washing and food preparation tool.

    Philosophically, comparing Angular to jQueryUI or html data attribute jQuery plugins style makes a great deal more sense. In style and goals these projects have way more overlap than Angular and Ember do. And, if this is the comparison, I’d say Angular does a far better job of accomplishing the goal of component-based app app building while simultaneously.

    • I understand what you are trying to say. But, the part where I disagree is :Angular and Ember are built for different things. I dont think they are built for different things. Angular is not a replacement for a component architechture. Enyo for example is.
      Angular and Ember are both in the same market, competing for the same audience. People who build massive web-applications. Do you refute this? If we say that Backbone perhaps is not, I can tend to agree with you to a smaller extent but still not completely because people do build massive applications with Backbone( though I think they shouldnt! ).

      Could you segregate the audience for me – for each of the frameworks?

      • I don’t think this is a discussion that can be had fairly unless both parties have built something substantive in using both tools. And, once that happens, I don’t think it’s a discussion that can be had at all outside of a Lewis Carroll novel.

        • @Trek : I expected more from you mate.
          What I am attempting to do is comparing the two frameworks based on their advantages to an average developer. What you are saying is that such a comparison is pointless unless both of us write substantial applications on both the frameworks.
          This atleast seems to be a scenario which is highly implausible because of the fact that we both have made our choices. What I am giving you is the opportunity to defend your choice.
          Note : I am in no way belittling your choice, nor belittling ember. It is after all your personal choice. But you should still be able to justify that choice. Thats all I ask.

          • “What I am attempting to do is comparing the two frameworks based on their advantages to an average developer.”

            What you’re *actually* doing is comparing a tool you know well to your initial impressions of a tool you don’t. How is that genuinely useful to for someone hoping to make a decision? In your comparison you neglected to mention all the parts Ember has but Angular lacks. You mention component architecture, which Ember lacks, but miss the salient point: Ember doesn’t have components because it solves those problems in different ways. A true, helpful comparison would explore that difference and explain how it affects the structure and maintainability of your application.

            The only real thing present in Angular but missing in Ember is dependency injection. Which *is* extremely expressive once you get the hang of it.

            I could write a similar article highlighting all the “missing” things in Angular and then conclude “Angular has a smaller footprint ( 25kb vs 37kb), but barely gives you half the tools, so your application’s own code will have to bear that burden”, but how would that help anyone make an informed decision?

            That’s why I maintain it’s not a question of “or” but a question of “and”. Nobody will be hurt learning Backbone, Angular, and Ember. They’re each suited to particular styles and sizes of application.

        • Could you actually point out those additional time savers that ember has? I am really interested in knowing them. Like DI in Angular, there might be stuff on Ember which are unique to it, which make development a breeze or more structured or something that can tip the balance to an average developer. I am looking for that feature.

          Atleast you now concede that I know angular well. I am glad :). I noticed your tweet the other day. Just saying.

      • I’ve been using all kinds of “frameworks” for a while. But there comes the time, when the ones you have used, are not good enough anymore. Mainly not because they cannot do the same thing, or provide similar persistence layers, or routing, or whatever, but because they are limiting my architectural plans and do not give me enough freedom in writing the code the way I want. You may say, that Ember is very strict and that I mean that it does not provide the above. But you are wrong. An application always starts from what the user looks at. If it doesn’t have that, it is not a webapp. Starting there, Ember is the only one which lets me plan, write, reuse the code in perfect balance with my UI. Backbone has a layer above jQuery, which is not good enough to me anymore.
        Angular did not even come into consideration because while trying it, it gave me the feeling of writing funny js code about ten years ago. And yes, it is very important for me feel comfortable with the code I write, because I am going to maintain it.
        In the end, I have one more thing to say: the three frameworks, I think, are mainly chosen based on experience. Not all do it like this, but they do choose somehow. I chose based on my needs, on my experience. I did not want to have a layer (or more) above jquery, I can do that, no need for a framework in such a case.

        • If you are comfortable building and working on your own framework then its your choice. No one can push a framework down your throat. But choosing one of the popular open source frameworks is also a contract between you and any future developers who are going to work on the same code base. If you are the only one who is going to write it and maintain it forever then yes, writing your own framework makes sense (kind of)… But, you might miss out on some of the features and if you even know how to implement them, why re-invent the wheel?

  2. Thanks Raj for the article. @Trek, While your point might be somewhat valid, it is almost the same thing for a new developer choosing a framework.

    Take my example,

    Skill level: new developer,

    Goal: Get rid of complicated, messy jquery code,

    Solution: backbone, knockout, ember or angular js.

    What did I choose: Doing both backbone and angular right now and angular is
    definitely faster for me. And since it is opinionated, makes life easier for me.

  3. I’ve explored all of these and the one thing that angular and backbone have in spades is documentation (screencasts, examples, tutorial, great api docs).

    Everyone keeps saying how great Ember is, and maybe it is; but it is worth absolutely nothing and will die a quick death if the team doesn’t get on the ball and write sound documentation that, at least, come close to what the other have.

    There is no excuse for not having documentation, none at all!

    • I was very interested in Ember, despite the trolling their main promoters tend to about other frameworks, sadly the lack of documentation and comprehensive tutorials drove me to another framework.

  4. “Ofcourse, in the final rendered html the ember way above is going to look cleaner because all the other stuff is going to get stripped out.”

    Actually, no. See this and look for the the two instances of “littered”.

Leave a Reply

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