AngularJS vs Ember

Tags: #<Tag:0x00007f52c1719fd8> #<Tag:0x00007f52c1719e98>


Sharing reusable objects is fundamental to AngularJS design in the use of DI singleton services


Great & enjoyable article. But I have to say I can't understand why knockout.js doesn't get more love. It offers a great compromise.


It is quite the contrary. Ember has nice ideas but Angular design is superior. For complex applications, I got success with Angular while burned my hands with Ember. 1) name clashes: - 2) bugs preventing simple tasks like showing the most recent blog post by default:


+1: Angular learning curve is steeper. Enjoyed Ember at first, but was forced into Angular because I'm unable to achieve my goals with Ember (Ember has nice ideas but I have deadlines).


Great article, I've been leaning towards Ember.js because of a lot of the reasons you've presented here. Thanks for writing this, it's a good read.


Knockout is great for what it does - ui bindings. It is an excellent library if that is all you need. But it is not comparable to Angular or Ember in scope. Knockout doesn't address things like routes, server communication.


I'm not sure what the problem is. Your model can be whatever you want. Just attach it to scope where needed to get model to view binding. Pass in a UserFinder service to your controller. Run an init to get your model object. Assign it to scope and use it in your template. What's the specific problem? I'm working out kinks here and there with angular but overall find it rather satisfying. It would be fun to make a comparison chart of 20 or so real world problems and get an "authoritative" answer to each one. Then let others judge for themselves. How about you make a list on SO or quora, with links to each question and the community can answer?


Thanks for sharing your 2c. I'm still mulling the decision of which to use myself, and as you pointed out in the initial paragraphs, the developer momentum (as well as the aesthetics of the view's code (I hate {{/each}} syntax) has pushed me the Angular way...

The missing link to the Model is worth another look, though.


I'm in the middle of rewriting a Backbone-based prototype in Angular (after mostly failing to re-write it in Ember), and one of the problems I have with Angular is that some of the computed properties I want to use are only available after a while. (In this particular case, I'm loading an image, drawing it to a hidden canvas, reading the pixel values, doing some calculations, and coming up with an average colour that I want to set on a border.) As far as I can tell, it would be a terrible idea to have a filter that waits for a setTimeout (or an onload callback) before returning its value. _Perhaps_ I could use promises, but I've ended up having the callback set a different property on the scope, which feels a little hacky.

Having said that, I've gotten the Angular re-write 90% done in a couple of weeks of 2-ish hours on Fridays. With the Ember re-write, I basically got nowhere, since it would take me the two hours to ramp up and figure out what should go where, and I would end up with no time left to implement the feature. I still think I prefer Ember's way of doing things, but it's really hard to justify the lack of productivity to myself, much less my boss.

(If you've got a couple of hours some Friday, Robin, I'ld love to demo the app for you at the Mozilla Toronto offices, and chat about how you'ld implement it in Ember. Just because I'm doing the Angular re-write now doesn't mean that I'm not going to also do an Ember re-write later. ;)


There's a lot to be said for 'ease of use'.

The angular vs ember debate brings back memories of jQuery vs MooTools.
I think we can all agree that jQuery won.

The ability to see results quickly is usually enough to make people explore the framework further, and once a considerable amount of time has been invested, probably less inclined to switch later.


"My example illustrated that you don't have to do anything extra to share objects, it just happens. In Angular, you have to specifically use the $rootScope to do it."

Again, this could not be more incorrect.

if $scope.thing is defined in the parent, $scope.thing is accessible in the child. You do not have to 'specifically use the $rootScope to do it'.

And I agree the Angular docs aren't great, but in this case the docs are perfectly clear about inheritance:

It sounds like you are hell bent on Ember vs Angular, but this kind of attitude just makes you a less well-rounded developer. I would encourage you to stop fighting Angular and give it an unbiased place in your toolkit. This will give you the right opportunity (and authority) to judge its strengths and weaknesses.


I chose Angular for a project last August. I looked at Ember, but at the time, it was extremely slow, with noticeable delays. I couldn't chance that the performance would improve, regardless of promises. I wouldn't be surprised if it has, but at the time, it killed it as a choice for me. I've been very happy with the choice, but it's helpful to see some of the differences between the two frameworks pointed out.


re-read the article. It's well reasoned, and doesn't bash anything. If anything, you're a good example of where the simplicity of AngularJS appeals. Your app is hardly an example of a large scale front end development, and your PHP framework metaphor is over simplified (and arguably totally untrue; zend is an old framework with rapidly declining support). Your 'loving it' means you figured out how to use it, not that it was technically better - the inefficiencies in computationally demanding examples were clearly explained in the post.


What of backbone compared to ember?


Indeed; Shoving everything that need sharing in $rootScope is not better than shoving it on window...


If you are familiar with basic MVC, then Backbone is a bit like not using a framework at all (It's 1500lines and almost do nothing beside giving you a few objects to extend; It's surprisingly full of quirks for that size too; it has a useless router, and underscore methods called on collections return... Arrays? lol). I guess it's ok for newbies who need strong guidance in how they should structure their app, a bit like Cairngorm or PureMVC in the Flex world; If you know what you're doing, you either roll your own solution or use a framework that give you more... Added value.


Well explained and I agree with you. So which framework do you think its at least? If someone now ask for you advice..which one can you recommend?


Top article congratulations!


Hi Robin.

To be honest when I first read your post I got somehow mad because I did not agree
with your "biased" comparison between Angular and Ember. But then I
realized that I am as "biased" towards angular as you are towards

I would like to say that I highly appreciate the effort that you have put into learning
about Angular before even trying to compare it. It is obvious that you are an
Ember expert and from what I have read you seem to be one of good ones out

I know nothing about ember so instead of comparing it with angular IĀ“m just going to tell you
what I think you are missing about angular on your post.

The pitfalls of simplicity

In essence what you I think you are saying is. If you are going to build a complex application
instead of using a framework that is easy to use, with simple concepts you are
better with another that is more complex to use and understand. In the end it
will pay off.

Well angular is build upon some powerful simple concepts like dependency injection,
double binding and directives. That is what makes it so attractive the core
concepts are simple, and easy to use and understand from the beginning. But to
say that this does not scale is just not true. While it is easy to start there
is more to angular than just simple concepts. If you work with Angular you have
increasing set of services that help you deal with all the situations you may
encounter while building a web app, and you also have quite some external
libraries that can really help you with you project (Angular-ui is the perfect

$scopes and models.

While it is true that whatever you put inside of the scope is going to become the model for
a particular view in angular, this does not mean that you have to treat it as a
huge global model where you put everything on the same place. What you do
instead is to "divide" the page into different pieces and create an
small model for each part of the view using controllers. The result are a group
of small and simple models that are easy to create, maintain and to test. There
is no need to add complexity to the model or to make it inherit from a certain
class it is just not necessary

Using getters and setters to apply the Uniform access principle

I agree with you on the "Uniform access principle" you should always try to
access the model the same way no matter if you are accessing computed values or
primitives. But I personally donĀ“t think that this is a problem with Angular.
It just means that you have to do things a little bit different in Angular. You
should always try to make your model a simple POJO; computed values should be
calculated and then added to the model. Personally I donĀ“t think there are many
situations where you need to have computed values and if you do, you probably
are doing something wrong. Especially if you do some computation inside of a getter!
For sure you are always going to need some model values that have to be
calculated and updated periodically. On these cases I try to calculate all the
data of the model when it is created on the controller and if necessary I
update the values following and observer pattern.

Performance issues

While I find it completely reasonable to think that dirty checking may have performance
issues in reality it is not a problem with angular. Since your model are (or
should be) simple POJOĀ“s the comparisons are supper fast and all the heavy
computation happens on different services that can be made asynchronous to
avoid performance problems. AngularĀ“s double binding works as a charm and I
really makes your code simpler (with so much less boilerplate code), readable,
testable and maintainable. By relying on the double binding you just have to
test that the scope is properly filled on your unit tests.

Reusing object instances

Again in angular you do things a little different if you want to reuse the same model
for two different views you simply reuse the controller that initializes it.
And if you want to reuse only parts of it you abstract them into services and
reuse them through all the application if needed.

By the way, you can make angular not to reload the controllers whenever there is a route
change. You only need to check the ā€œreloadOnSearchā€ property to false on the


On this conclusion you picture a junior developer working with angular. Sure he will
make all the possible mistakes. I would like to see the same junior developer
working with ember and following the ā€œconventionsā€ you have talked about.

Regarding your question about what is idiomatic AngularJS?
The answer is crystal clear to me. OBJECT ORIENTED DEVELOPMENT you can use all
your knowledge on it and applied to you application.


i agree with the author, i think what he is implying is, if you want to make angular behave like ember why not use ember in the first place. everyone is shouting about what angular can do adding this and that.