AngularJS vs Ember

Tags: #<Tag:0x00007f52c60a61b0> #<Tag:0x00007f52c60a5cb0>


I was choosing what to use for my next app. Your article took away all doubt! Ember is the way! Thanks


One of the things I like about AngularJS is the tools that it provides. Unit testing was considered early on in the development of AngularJS as was E2E tests (karma now Protractor) I think these two points made it a very competitive framework or toolkit. Also the Google branding and marketing behind it.


**I’m really confused. JavaScript has a built-in uniform access mechanism…accessor properties. **You can easily define this on the $scope object:

Object.defineProperty($scope, 'area', {
  get: function() {
    return $scope.l * $scope.w;

Sure this is a relatively new feature. But so are the frameworks. Well, thanks ember for reinventing the wheel.


What about the caching of values and automatically updating the dependency graph as I talked about? Or the safety of chained properties I demonstrated?


It depends on that one post. One bit of the right information is all it takes to change anyone’s mind about something. This article in particular is very well-reasoned and provides solid examples of the issues it brings up.

For all we know, this is the fourteenth article @fabienallouis read about the subject, but it happened to be the one that was most important in forming his opinion.

Indirectly suggesting that someone isn’t qualified for their job because a well-reasoned argument shifted their opinion seems a bit harsh.


I am not entirely sure how it works, and your exact distinctions between business logic and UI, but I believe that is how Discourse is using EmberJS. Rails back end, Ember front end.


I just wanted to say that although heated at times, the comments and the dialogue in the comments has been very educational. It would be beneficial to really get two sides here of devs that have used both frameworks for larger applications. We can all agree that the ‘ToDo’ app doesn’t really do much good. Couple of notes here:

  1. I would agree that Angular is missing aspects of models and scope can be a confusing term. That said, I also see some flexibility.
  2. Directives are quite powerful in AngularJS. I know as well they are positioned well for future web components. I’m curious what the story of web components will be for Ember, and how does Ember handle wrapping up DOM manipulation ?
  3. Neither Angular nor Ember has done a good job keeping it’s documentation up to date
  4. I’m currently on a project using DurandalJS - which does a good job providing application structure. I like it’s modularity approach with RequireJS - I’m curious how Ember would work with RequireJS ?


Both harsh and I’d say even slightly ignorant. One trend I’ve noticed with Angular developers is that they find themselves too comfortable conforming to what they’re used to and give off an opinionated bias even if they’ve been shown hard facts as to why some ideas are flawed.

I don’t know enough about it Angular, but the little I do know about it is what turned me off, which was that they tried introducing way too many new ideas and there was far too much underlying code that was needed just to even get started with an application.

If the majority of your time is spent writing wrapper code for the framework, then clearly the framework isn’t doing it’s job properly.

But with that said, if people feel more comfortable and productive using Angular, than by all means keep using it, but insulting someone by essentially saying they’re lower than them and that they don’t deserve to be in that role just because they use a different framework or because the opinion of someone they respect changed their mind is the type of elementary crap that open-source projects need to work against.


I don’t think you really understand the $scope variable. You talk about how the watch variable is attached to the scope variable and not the room, the room has its own scope, so do the Rooms collection so theres no need to iterate through a collection if you’re using the right scope. Just use a directive with a watch attached to the scope in that directive and apply the directive to the individual room for each of the Rooms & you’re done. No need of having to iterate through the collection at all.

As for property chaingng and doing non-trivial computations in a getter as others have mentioned:
a) If you’re changing properties you’re breaking encapsulation i.e. follow the law of demeter to ensure loose coupling.
b) You shouldn’t be doing anything non-trivial in your getter, it should just get things i.e follow single responsibility principle.

This is why I like angular better as I believe it leads to code thats more loosely coupled especially with the use of DI & from what I’ve seen from ember code samples feels like it tends to put code in the wrong place.


I think you have got the Angular wrong. You based all your argument that for computed properties you need to define functions and then had a few conclusion based on that and finally decided that Ember would be better. I recommend you to read more on watches.


Please read this before placing Durandal on top of your list


This article seems to have good intentions, but it seems to neglect a major, key philosophy of both Ember and Angular.

They’re not on their final version.

The problem I see isn’t so much that the points raised can’t be true, but that they seem to make the assumption that one project or the other is feature-locked and has no true intentions of growing out of these problems.

I’ve actively used both, at this point, and I really cannot say I’ve seen a situation where one outperformed the other enough to make me want to switch. In a grid with millions of records, I’ve not had any difficulty getting an end product to my users using either angular, ember, knockout, or mithril.

This whole thing goes back to something my father told me when I finished college…

If you buy a house with a lawn, you have to maintain it. It’s a great way to learn more as you go.


Menschenkinder, if trolling and making useless comments makes you happy maybe you should consider it as a full time job.