AngularJS vs Ember

Tags: #<Tag:0x00007f52bfbdb820> #<Tag:0x00007f52bfbdb550>


You say I'm using Angular wrong, but one of my main points was: what is idiomatic Angular? If Angular apps should be structured the way you suggest, why are the guides and examples not structured that way?

If Angular ever expects me to do something a certain way, I argue that should be built into the framework. I tried to get this across in the post, but if you open up a different developer's Angular app, is it going to be done the way you suggest?

I'm not saying you can't make awesome apps in Angular. I'm just saying the framework doesn't encourage you to do it the way Ember does, and you have to create a lot of the tools yourself. And those tools are not universal between Angular projects.


I'm going to disagree entirely. I don't think you know Angular well enough... and what about Directives, The greatest feature of Angular is the Directive Construct what does Ember provide as an equivalent ?


Regardless of the framework, the quality of the documentation, or the existence/lack of conventions there will be always be developers who do things the way they want to. Ember might propose conventions in the same way that Rails did, but that doesn't mean there won't be egregious missteps by developers using the frameworks.

What I'm trying to say is that you shouldn't fault Angular for not providing a set of common conventions; creating effective documentation is hard regardless of the tech involved.


How long did it take Rails to answer the same question: what is idiomatic Rails? How many times has the answer to this question changed since 2004? (I'd posit quite a few times, especially when given Steve Klabniks excellent post)

Angular hit 1.0 almost a year ago, it doesn't have enough real world use under its belt to answer the question: "what is idiomatic Angular?" and neither does Ember.


"What’s wrong with Javascript primitives as models?"

This entire paragraph is wrong, you always use a "." when databinding otherwise you end up with parent and child ctrl's overlapping. Misko (the original founder of ANgularjs) says this himself on youtube "Angular JS Best Practices"

"Modeling this in AngularJS"

That's not how you'd do it. You'd store width and height in a model off of $scope like "$" and you'd put it in your view with a filter like "{{ room | area }}".

"Reusing object instances"

I've been building an app that does this for the past week and a half. You don't throw it away you store the model in the parent scope so you can easily manipulate it throughout your entire app. route ctrl's included.

For my simple apps I just use something generic like "$scope.main", doesn't need to be more complicated than that.

"Performance issues"

I've encountered this many times, but EVERY SINGLE TIME when I went over my app after completing it the problem wasn't with AngularJS it was my code organization. I'd reorganize and problem solved.

Most of the points you make are just rookie mistakes I made as well when I first started. Ember philosophy does not apply to AngularJS.


When I first took a look on MVC JavaScript frameworks not too long ago, I initially started out with the former SproutCore, from wich Ember originated later on. However, bumping my head against the wall with Ember over and over again, I spent more time in researching *how* to achieve something properly, than actually achieving something. This wasn't Ember's fault entirely - I still think that it is a powerful and probably more elegant framework than Angular. But the lack of helpful resources, tutorials and beginners support was reason enough to push me on Angular's side.

Setting up my first little Angular.js application was ridiculously easy compared to my first steps with Ember. It wasn't even the documentation or the API of Angular. Just the video tutorials, with code example on their homepage, the amount of solved stackoverflow questions, as well as a big community of Angular developers providing good tutorials, kept me kick starting with Angular development. The learning process down the road also seemed to show in productive results much quicker. But that may be a result of me being already familiar with the usage of functions instead of computed properties, wich where something completely new to me.

I can't really tell yet how much the technical aspects of Angular affect the daily usage of complex productivity apps. All I can say is that the guys at Google did their homework in rolling out a framework to developers. I would love to see Ember keeping up in this case, conveying their concepts in a more easy-to-understand way and providing more practice resources. As a matter of fact, I still want to dive into Ember. But I won't spend the time and energy to wrap my head around complex concepts again, as long as there is an alternative that basically does the same thing in a more comprehensible way.


Interesting post, thanks for writing it.

I agree that the reason that Angular is popular is because it is simple, but in a different way, Angular is simple to get started, it has a very high wow factor at the begining and this is the reason why it is popular. I think that overall Angular is a hard to learn as Ember, is just that in Ember you have to learn a lot more upfront.

You highlight some good point, specially the uniformity of accesss, this is definitelly a drawback in Angular.

Angular has ngResource which is sort of the missing model object, but it is there, you just don’t find people using it as much because they don’t need it. Simple objects do most of the time.

I have also found Angular to be a more flexible and all purpose than Ember. Ember is great for building large single page apps, but how often people want to do this? Lots of time you just want to complement a more traditional server side app, Angular works well in that case as it doesn’t impose so much structure that you might not want. This is a big plus for me for choosing Angular over Ember.


The whole JavaScript SPA thing is still in the very early stages; I don't think any meaningful idioms have emerged yet. My personal opinion, from experience, is that strongly-opinionated frameworks such as Rails (and, if I may I infer from your post, Ember) are great for building the kind of applications they're great for building, but as soon as you stray from that ideal you find yourself fighting the constraints that the framework's opinions impose.

Frameworks that encourage (enforce?) certain patterns have their place, certainly, but when those patterns don't apply, frameworks that are agnostic and flexible come into their own.


> What you are suggesting is good practice but something that I suspect very few Angular developers do as it's not encouraged by the framework itself.

Not really, the $rootScope (edit: and of course services) is widely used by all angular devs to share variables. The fact that you don't even mention it on your post shows that either you don't know much about Angular or you're not mentioning it on purpose.

Also, most of your post is about how dirty checking is bad while this is an old argument Ember people seem to obsess over even though it's been debunked ad infinitum by the Angular guys (ie, first the slowness is not noticeable in 99.9% of the cases as you'd need thousands of bindings on the same page and second, Object.observe brings that number to 100%), I also find it hilarious that a rails guys like you criticizes Angular for sacrificing a bit of performance for the sake of simplicity when this is one of the main selling point of Rails.

Last but not least, I guess you've probably noticed by now that writing FUD about Angular is a good way to promote your Discourse app as it gets you tons of hits so I guess we can expect more posts like this in the future. Luckily, devs are not blind though and most have already picked Angular's simplicity and flexibility over Ember's kitchensync. So, keep hating while we enjoy Angular's awesomeness ;-)


I don't see how Ember is more flexible, my experience tells me the opposite. Ember is more opinionated and structured. Sometimes I just don't want that structure. Angular let's me do that.


I have to disagree with your last statement: "If you’re serious about front end development, I advise you to take the time to learn Ember properly." I took the time to learn Ember more than a year ago. It was when 0.9.8 was out and we shipped a project with it. After that, I joined another project and a new router was out. It was totally incompatible with 0.9.8. The worst part is that there was a post in the Ember forum (Discourse) where yet another new router was being discussed. My options were using an outdated technology (0.9.8), using a router that it was going to be useless in two weeks or picking another framework.

If I am serious about web development I need to get the job done. I need to deliver my product. Ember was not ready for a serious development back then. I don't disagree with you. Ember quality relies in its continuous improvement and being brave about backwards incompatibilities. But when you are working in a company and have delivery deadlines, that does not work. The Angular guys still provide support and bugfixes for the 1.0.x releases that have been compatible for more than a year now. They also provide the latest functionalities in the 1.1.x releases and have even announced the 1.2 series.

I think developers need to feel secure about the tools they use daily. I totally agree with you that Angular is in some place between Backbone and Ember, but until RC3-RC5 you needed to spend more time keeping up to date with Ember changes than working on your own project.

I was going to say that now that Ember is closer to 1.0 let's see what happens, but I just saw this
I use Ember in some personal projects and I love it, but I really think people need a LTS version of Ember as soon as possible.


Great article Robin. Having prototyped apps in both ember and angular, I can appreciate your viewpoints. I will say for me Initially (months ago) Ember sang to me in a way the Angular didn't initially. I went through Tom's video and loved the simplicity. What killed it for me was the oh-by the way issue of data persistence. I know that you don't have to use Ember data to get the same thing. (I read your blog post and cloned your very wellbuilt github project and went through the examples) but at the end of the day, it bugged me that Ember data persistence was so seemingly unstable, even by admission of their own blog, and that scared me off.

Enter Angular. Although skeptical at first, once i went through the tutorials I was sold. Behold! Semi-solid data persistence with ng-resource, and (this sold it for me) mature, baked-in e2e and unit testing. I've not seen anything close to the level of async testing ng gives me for free. I love the concept of directives and services, and alot of the modularity and reuse your seeking is truly captured by proper use of those.

I love Angular, and I really really want to love Ember. There are highly clued people that do amazing things with both. I'll probably play around some more with Ember later this year, especially with the emergence of ember testing and as ember data matures. But for now, I'm sticking with ng.


<iframe allowfullscreen="" frameborder="0" height="315" src="" width="420"></iframe>


you can find an extremely relevant video by clicking this link:


> - not true, thats why $rootScope exists

Please don't go there. If you need to access the same data from different place in your app, make heavy use of services. It will provide a much cleaner interface to your data, and ensure that your controllers are doing what they should: binding your data from services into the views.

And that's where I feel like a lot of the things I read, about how people are using AngularJS, go off the rails. They write these bloated monstrosities that might resemble controllers in some other world, while the focus should be to use directives and services to provide clean and reusable interfaces to the data, and have very slim controllers.

Anyway, just my 2¢ after a month of being heavily involved in writing a large AngularJS web app, and I realize opinions on how to use MVC frameworks differ.


These discussions keep getting pseudo-religious. Can't we all just get along?

Both frameworks have their own strengths and weaknesses. I use Angular and yes, I wouldn't mind more structure around the model. I picked Angular because directives are sexy as hell and I like the view bindings.

What I understand about Ember is that it does models better. I totally believe it. When I write an app with tricky models, I'll give Ember a closer look.

We're arguing about these frameworks because they're both comparable. If one of these two outpaces the other enough, we won't have much to talk about.


Same position as yours, totally agreed!


Yes and yes. We've all, at some point in time, dealt with JQuery spaghetti. I've written a fair amount of that misery, and I'm through with it. It's nice to have these frameworks to debate. The future is bright.


Directives are so much more than just rendering templates.... Have you ever looked into what Directives can do? Do you even understand how they work? How can you compare another framework to AngularJS without knowing anything about the most important feature of AngularJS? How bout have a read here on how they work: - If that is too much for you, have a look through all the videos as he breaks it down into 5 minute videos.


"If you know Angular and I’ve written something wrong here, please contact me to let me know! I’d love to revisit or correct any mistakes or omissions."

Are you seriously going to write an article like this and then end it with that sentence? This automatically tells me that you have absolutely no idea what you are doing in AngularJS and then comparing it to a Framework you've been using for a long time (over a year maybe?) on a massive project like Discourse. What have you actually built in AngularJS?

Like someone else already said, this type of article is only to cause a huge amount of people to rage against eachother in the comments ultimately getting more exposure for Discourse. All press is good press, right?

One last thing:
"In fact, what is idiomatic AngularJS? None of the examples or blogs I read through demonstrated how to reuse object instances, for example. Is that just not done in AngularJS applications?"

AngularJS Services -