AngularJS vs Ember

Tags: #<Tag:0x00007f52c23b55d0> #<Tag:0x00007f52c23b5328>


Again it depends... EvilTrout mentions of UI components which are known in angular's world as directives - yup, reusable UI parts of your app or UI parts that require their own logic should be defined as directives (in my opinion)... so You can share your data between directives using current controller $scope, without additional code, without service and without $rootScope, just by passing your variable name into directive as a parameter, like <div my-widget="" ng-model="someVarFromController"></div> ;-)


I believe you missed an important point: most web applications already exist. Ember somewhat will require a rewrite of those applications while frameworks like Knockout and Angular are more suitable to change the application in parts without having to rewrite everything from scratch...

Having said that, I really prefer the Unix philosophy for this. Use many specialized tools in a combined way to achieve your goals, so I still prefer Knockout for a fresh app than something full-stack like Ember.

Also, when developing a Rails app I opt out for AR and choose Sequel instead. Among several advantages of Sequel over AR, one that I like a lot is that I can separate the ORM concern from the web framework and I'm not forced to upgrade my ORM API when a new web framework version is released.


Thanks for writing the article, but I think it is unconvincing. I actually believe AngularJS is really awesome and it's becoming popular for very good reasons.

I chose Angular instead of Ember exactly for the characteristics you mentioned in this article. I actually appreciate that I can use any kind of JavaScript object as a model and that I don't have to pollute my objects with Ember.js stuff. I also very much dislike the resulting setter&getter-based code. AngularJS can be used with any kind of view model layer, so it is more flexible and easier to integrate with other libraries.

The dirty checking technical solution is required by the current and temporary limitations of JavaScript. One way of looking at it is that it's inefficient since it has to do repetitive checks over the same data. Another way of looking at it is that it's a technical solution adopted after a well thought design and not the other way around. Ember.js uses getters and setters as a work around for lack of property observing support in JavaScript. So they actually adopted an inferior design because of some temporary JavaScript limitations (these are going to be addressed in future versions of JavaScript anyway and Ember's setters and getters will become obsolote). The AngularJS designer simply favored a cleaner design instead of maximizing theoretical performance. I like that.


Great post. You've nailed some of the a major problems I've noticed with Angular. I think Angular would be find for small apps but will fail miserably for large single page applications. It is sooo inefficient for model binding or model reuse without hacking it - if you have to hack it to be performant for anything beyond toy single-page-apps what's the point??


You're incorrect on the $watches part. You can easily create a $watch based on a single scope you create. It will travel w/ the model without a problem.

Also, on one hand you mention future proofing as a positive for Ember but fail to future proof your width/height w/ getters/setters in the Angular prototype. If they are getters/setters you can easily update area without a problem. Sure Ember gives you the syntactic sure to handle that for you but essentially they're watching under the hood anyway.

Thirdly,"In AngularJS, every time you visit a route, it passes an idand has to resolve it in your controllers." is incorrect. The $routeParams object is available to your controller but is *not* resolve *in* your controller. It is done before hand.

Angular does execute {{fun()}} each time but that's why you simply don't use them. You should pre-compute your values in Ember, Angular, or whatever [see future proofing above].

In all fairness, I have massive Angular experience and 0 Ember but my points aren't to down Ember or puff up Angular. I work on a large scale JS web app [doubles as a Phonegap app] which uses Angular and the issues you bring up are of no concern to us. If you practice good code, any solid framework will work so many of your points seem reallllly off and wrong. You should do a comparison post from someone with high experience in Angular so a true, non-biased code example/explanation can be provided with Angular best practices.

Good post though.


It's definitely true that the Angular documentation does not really cover good practices, as someone learning angular I hope to find the links and comments on this post useful in that respect. I am sure I will develop my own 'good practices' over time...then there will be a new better framework out, also without "super-excellent" guidelines on best practices. Such is a developers life!

(I got 'sold' on Angular as my choice for a personal project with directives being somewhat similar to future web components, the built in DI and use of POJOs).


I loved the part about the Pitfalls of Simplicity, and I believe it merits a separate discussion. Also there are so many new frameworks today, and the web development community is doing something terribly wrong. I know it is nice to have so many choices, and we are always learning from each other, but there are just too many "great Javascript web frameworks" today with Facebook's React being the upcoming one.

It would be a lot better if sometime in the future, there is one clear winner or the developer's of Angular, Ember, React, Flight and others think about one framework to rule them all. At the end of the day, everything is Javascript.


A good data-grid component is very hard to do well. But as it happens, there is an extremely high quality one for ember -


Angular is gaining a lot of popularity because the single page web app is currently not what a lot of people are building. A lot of the sites are out there are still static by nature but contain sections / pages that require the flexibility and complexity simple query + ajax just don't provide. These people turn to js-frameworks like angular and ember but for this use-case angular just seems the better fit.

We did just this with ember and it works fine when staying in your ember-app but including dynamic parts in the other parts of the site is kind of a pain. We built some mini ember-apps that reuse parts of their bigger brothers to include small dynamic sections.

So all in all I feel like Ember is the better fit for big, complex single page apps but Angular fits better if you have a predominant static site angular seems the better and easier to use solution to integrate.


I started to use Angular about a year ago simply because I was looking for a JavaScript MVC framework and had tried Backbone and Ember and struggled with the learning curve. What made Angular so appealing for me is that in one evening I was up and developing my app because you don't program in Angular in the same way you have to code "in Ember".

Your example showing Ember's model watching is a good example of something I'd not want to use because I have my own View Models and I think that's where a lot of people see the advantage in Angular's stripped down object model which you are not force into developing inside.

That said, I'm glad we have all the frameworks because it would be a very boring world if all our requirements were the same, right?


I'm not really too familiar with Ember, and I'm by no means an Angular expert. I've learned a lot just from the comments here about both Angular and Ember alike even.

The point has been made that they are both different from each other. Not better or worse. There's always going to be a more ideal tool for every job, that may even be neither of these. They can both co-exist and be a choice of one person but not another. This is something that has gone on for years now with programming languages in general, as well as libraries and frameworks. It's a matter of preference not which is better for building an app.

I personally have been building a complex app using Angular and I find that using it's inheritance quite to be great. I like that it's pretty much the same as regular use of prototypes. I also like the way the $scopes work.

I think what might be worth trying out is if you were to build a complex app with Angular. Then came back and posted your thoughts of it after having done so. I'd like to see what you think then.


AnguarJS without all the boilerplate


Let me first agree that Angular docs and examples are not good enough. They really do not use the best practices described around.

I'm a JavaScript professional relatively new to Angular. For my current project SPA, I use a custom-written set of tools to manage modules, views and models, i18n, routing etc. and I reached the point where I lack data-binding - the magic of not manipulating the DOM directly to update every occurrence of some model property. So I'm scanning the Web for the newer frameworks and while learning Angular I'm still in doubt switching to it for my current project.

I started learning Angular with the Developer Guides and screencasts which I find very useful to get known with the base concepts. Then I googled for some more videos. Then I read the API reference including the users' comments. Now I'm reading the source code of Angular to deeply understand what is happening under the hood.

The issue that pops out in the Angular Docs' comments and the StackOverflow answers is that many novice Angular developers do not understand the core concepts of the JavaScript language itself and the virtual machine it operates on (e.g. what's the difference between a reference type and a value type, how the closures work, how the property resolving through prototypes works etc.). They think of having a data-bound view as a sort of magic and they quickly get confused when something does not work as they expect (or sometimes as the documentation says because of typos that may not be understood correctly). That's why it is so necessary to provide Best Practices for such developers (especially "always use a dot in your binding paths").

Of course, It would be better to have a set of answers from the core team on how the features they developed are meant to be used. Plus a more "clean" set of examples that use those principles to be able to do the easiest - learn by example.


Well, the Angular website states that the framework is built to extend HTML for web applications with dynamic views, not static content.


I wanted to say that dynamic content / views are much easier to integrate into a (mostly) static site with Angular than with Ember. Of course you shouldn't use ember or angular to generate static content ;)


The epic battle of low quality language.. ActionScript 3 is about 25 years ahead.
A texts about such "epic" battles very amusing the ActionScript 3 programmers.
It is funny kids .. go ahead .. amuse us more ...


Good writeup, but unfortunately a highly one sided argument. The title 'AngularJS vs Ember' is quite misleading IMO. There are various aspects of Angular such as use of declarative programming that you have not talked about. Yes Angular JS is simple, and with simplicity comes great responsibility to be disciplined. But if the discipline is imposed by the language, then IMO the language/framework starts getting quite restrictive. Only when a language/framework is simple, it evolves into being opinionated (Think Ruby). And we don't hate that. Do we?

I am also not so sure why is it important to know what is idiomatic Angular JS? Is the use of declarative programming to create application itself not idiomatic?

The argument between Ember and AngularJS is not about the principles of MVC. That would be a very bad start. The argument should fundamentally be about how Ember and AngularJS approach a single page web app.


Does Ember have a concept similar to Angular's directives? I think that's a very powerful nG feature that wasn't mentioned in the article.


Doesn't Ember still use "static" html templates? (re-rendered each time?) that's a pretty huge limitation IMO, live DOM is the way to go. I could see router magic being useful for some but that's another one that would completely screw us over, sometimes simple IS the way to go, unless you enjoy fighting frameworks.


The way you strive and strain to construe certain opinions Angular has into objective disadvantages makes it clear that this nothing remotely close to a thoughtful, objective, or dispassionate critique. The fanboyism is transparent and very tedious.

Anyway, I'm sorry you feel so threatened by Angular's success. I guess this is a sign that we should just keep up the good work.