AngularJS vs Ember

Tags: #<Tag:0x00007f52be12e7e8> #<Tag:0x00007f52be12e0e0>


I think this video is very relevant:

Tom Dale, Peter Cooper and Rob Conery; Cage Match - EmberJS vs. Angular

The last part about adding a second row to the table made me lol a bit.


I don't now where to start, but initialy the $scope is not a model, the concept would be similar to viewmodel because the bidirectional binding, similar to an observable in knockout(mvvm), in a context of a controller,which can be attached to a page, partial view, or directive, this and another beauty such as dependecy injection, I would recommned read:


Dude, why do you have such a chip on your shoulder? It's just coding. Go out and booze for a couple of days. Get yer rocks off.


Ember has roots in Rails so of course it is going to be opinionated. Angular is way more open by not forcing you to choose one way.

If you have a basic JS class [not extending anything within Angular], you can use that as a controller and ignore $scope all together. Angular just works with your normal flow so you don't have to learn anything new until you need it. Use as much or as little as you want.

You want frameworks to dictate your style so Ember speaks to you. Others like freedom to do things their way so Angular may speak to them.

Oh and don't judge the framework by the docs. They are not good, Google knows it, and they are working on it. New docs are on their way soon but I can guarantee they won't show you "the" way to do it. If you want to see how to build an app the Angular way, peep the tutorial:


As someone who has used both Ember and Angular, I have to say that when I first started using Angular, it took me a while to stop looking back at Ember and Handlebars thinking "my god what have I done".

Ember is awesome and I'm not a fan or this versus that. Whether to use Ember or Angular really depends on your situation. If I am the only one working on a project, Angular is definitely the framework. If I am working with other developers that don't know Angular, Ember is a safer bet because it is the type of code that typical developers can understand.

AngularJS is a paradigm shift. It took me weeks to "get it". Now I refuse to give up Angular directives because they are a HUGE time saver.


You don't have to replace anything when using AngularJS directives - they can augment existing elements (say, if you add a comment or attribute signalling a directive to be used). That's the beauty of them. Just add an attribute to a tag, and it instantly gets all the functionality of the directive. Heck - add a second attribute, and get another directive working on the same tag. You're simply not limited.


Go home, Batmann, you're drunk.


The only problem with that is that directives almost always require an isolate scope, and ng-model requires an inherited scope, and a single DOM node can only have either and not both.

When I first learned about Angular directives, it was obvious to me that they are one of the best features, and so they definitely should not go without mention in an article comparing Angular, but as I explored and really dived into them it became clear that they are somewhat immature and are not very capable. This is largely to do with the issues of scope but also because you cannot attach a controller to a directive that has an isolated scope.


Your examples are already disproved as they don't reflect the reality of AngularJS development. Your claims of having to re-fetch data from the server are preposterous and speak volumes of your naïveté in this subject, and make the rest of your claims dubious in the least. I honestly applaud you for attempting to compare the two, but not knowing about AngularJS means it's an exercise in futility. The only thing we've learned today is that you don't know as much about AngularJS as someone should in order to compare it with Ember.


I get that you guys want more people to use Ember, but this is a really nitpicky nitpick that causes you to lose a lot of credibility in my book. Ember uses Object.defineProperty behind the scenes to create properties with getters and setters, so there's literally nothing stopping you from doing the same with your models in Angular. Additionally, I think having to use Object.defineProperty explicitly is preferable because it's unshimmable for legacy javascript engines (IE 8 and below). If you don't believe me, check out Ember's source and grep `defineProperty`, where this is all explained. This is a non-issue at best and a con for Ember at worst.


IMHO the biggest disadvantage of Ember.js is that it use Handlebars. I love Angular.js declarative HTML idea and I theirs module concept. It allow me to create app that has various of independent modules and then connect them to show user one consistent view, but each part of page behave independently, which is awesome.


Great article. I have tried both ember js and Angular js but found CanJS to be much simpler,faster and cooler. It brings the best from many world together in one package.


You should read about Providers and $scope inheritance. It negates "Reusing object instances" and "Performance issues". Getters/Setters.. Meh I can write my own base javascript model if I'm really that pedantic.

If dirty checking is so bad, why do video games and GPUs use it? I remember writing a Backbone Application that had Collections / Models and every Model had events. Man did it run slow if I had too many Models because of ALL the event listeners.. For performance I had to put single event listeners on the Collection and some other trickery...


It's obvious that you are biased toward Ember, hence "Discourse", nothing is wrong with that, but the philosophy beyond software dictator ship in the form of "conventions" is the reason so many programmers are spoiled and can't write decent code, I my self is a very fine example of a programmer who doesn't know a lot, i am not embracing the Socratic paradox -"I know one thing: that I know nothing"- i am just saying and i'll wrap this up quickly, following the Rails/Ember/Convention Over Configuration way is like being a very neat person with OCD, yes you are neat you are clean your house is clean, but if a big nasty "bug" gets in, you'll spend the night paranoid, cleaning after it, changing furniture or you might give up and end up changing the whole house :).

ps: don't get me wrong i love Rails, i've developed in Rails since the end of 2010 (~3 years) and i had some amazing experience with it, i've learned a lot from Ruby just like Matz learned from Emacs, I've been inspired, but i don't think the answer is in "conventions based frameworks" at least for me, thank you.


Im a newbie in MVC/MVWhatever/MVVM. I used (try to learn) Knockout, Backbone(Backbone is better than Knockout, its the best). And found Angular Js is way faster and easier to learn. I always keep my models and partials organised.


How does ember compensate for the lack of "directives" or something like it? It's funny they are the number 1 factor why people choose Angular and you don't even mention it in your post.


You got me thinking about the room example. It's a good example because it's simple.

I don't agree with the Uniform Access Principle when it comes to computed values. I prefer area() because it tells me I can't write to it. Worrying about all the cascading changes in source you'd have to make is eliminated by a decent IDE. Most of us don't develop libraries, so no need to worry about customer's downstream code. And as the link you included says "going from method to simple attribute really wasn't a problem, as one can always just keep the function and have it simply return the attribute value." Seriously, dragging the Uniform Access Principle out is just pedantic.

Martin Fowler corrected me as I was making a premature optimization. "Don't optimize performance unless you run a profiler." Dirty checking got me worried, and then I noticed you didn't put any numbers with your accusation, so I used the poorman's profiler of putting console.log("calc") in area(). It runs twice anytime width or length changes. Twice? That's it?!?? Come on. Quit whining, or show the real numbers for why dirty checking is evil.

HOWEVER, you did mention arrays, and angular's dirty checking shows some inefficiency there. Changing a single room's width in rooms[n] results in 2*n calc's. 100 rooms means 200 calc's. WTF? Still livable, but I'm now wary.

I was able to get you your cake and eat it too if I
1. change your prototype function name
Room.prototype.computeArea = function() {...
2. add new controller for room
function roomCtrl($scope) {
$scope.$watch('[room.width, room.height]', function () {$ = $;}, true);

Doing so results in 3 effects you were looking for.
1. one change = one calc
Changing a single room's width in rooms[100] results in 1 calc, not 200
2. Uniform Access Principle
You got back room.area property.
3. one watch is all you need for all your controllers. I put the same room in two different controllers. One of which had the watch. I can change the value through the dom on the controller without the watch. [yes, the watch has to be executed to work. Putting the watch in an unused controller doesn't magically attach itself to the room.]

I really appreciate the blog. I learned a ton. Whether or not we agree on what is best is not as important as the discussion itself. Please keep writing.


Conceptually $rootScope and window are both a global namespace, and both can be abused. However, if you truly need something shared globally, use $rootScope. It is better than window in that you are the only one putting stuff there (and the little that angular puts there), and it doesn't differ by browser and version.


You are far better off creating a singleton service and storing things there. I would not store anything on $rootScope unless it was truly global and needed.


I think we're all agreeing, but worry about someone skipping over the warning "truly global and needed". You see so many abuses that it becomes easier to just say no.

I'm ignorant about services. I'll pick it up. Thanks. I wonder how much better it will be. Seems like it could the new global dumping ground. "A 'good' programmer can write Fortran in any language."

I hate that angular has a steep learning curve later on, considering how easy it is to start. On the other hand, I love how much mileage I've gotten from built-in directives and simple controllers. You don't have to know it all to get value from it. I think it fits Larry Wall's definition of good language design: "Simple things should be simple, and hard things should be possible."