My summary of why I will choose Ember over Angular2

I would love to hear your opinion :slight_smile:

- Experience: My experince with Ember(months) better than Angular (days)
- Terminology: Angular( Routes, Component, Services, DI, Providers, Directives, Pipes, Services). Ember (Routes, Model, Components, Data Store)
- TypeScript(Angular) very Java, Ember is less "java" (OOP)
- Routing (angluar: ember: )
- Data on the client side( angluar: self-managing, Ember: data store)
- Framework flexiblity(anglar > ember) by OO abstractiion and de-coupling while Ember has wrap it up
- Framework easiness( anglar < ember): ember has built in Route/Model/Serializer/Store
- Component (same)
- Service (DI feature, same)
- History( Ember (2 years), Angular1(>2yrs)(Angular2 ~ 1 months)
- Sponsor Ember(Apple ex-staff), Angular(Google)
- Cross platfrom(Native app) support ( both have it. With abstraction leve. A seems > E.)
- Examples(many, stackoverflow, forum)
- Open Source (ember > Angualr)

Feeling in my guts: Even Ember is better. Angular will win. Because: Angular is again driven by Google scheme to take over the market to make it suitable for all platform and Java developer friendly. The more OO/Java you are, the easier it is for you. I am not Java develper so I don’t see much of a benefit at all and it feels not natrual even because I am more functional than OO. Also, they seems trying to solve Asynchonocy events cancelation/exception handling problem by reying on DI/Serice/Provider patterna and reactive styles. I don’t see there is such a problem yet( maybe I am not experienced enough) when it comes to single page app development because ember has very much minimize that problem by Ember Data store (in my opinion) to load data into the client side and cache it into a store, only make remte request when you have to.

1 Like

At some point Google will discontinue Angular :wink:


The meme is that one should use the right tool for the job. Sometimes Angular will make sense (especially in a java or c# shop where typescript allows you to bring the idioms of that language to JS). Ember has plenty of big companies using it and, IMO - more importantly contributing back. Ember in that sense is more classical open source project as opposed to other frameworks that exist as more ‘source out in the open’ and is stronger for it. On the other hand Vue poses some interesting questions for ember that seem to be in the process of being answered.

Here are some things to think about.

Ember is really productive, you dont need to wire up the various components in comparison to Angular 2 you actually have to put in work to put the pieces together. In Ember since it utilizes conventions lots of things are done behind the scenes unless overriden. Being a good Ember developer is knowing what is going on in the framework.

Ember also has a good ecosystem of reusable addons you can add on your appiclcation via ember observers website… This brings great out of box functionality.

Some cool things for Angular 2, coming from a Java background using annotations make your application feel like as a Spring application. This type of coding has clear cut separation. If you were to build up your Angular 2 app and one day choose to abandon Angular 2. All you need to do is take out the decorators and Your left with pretty much logic.

In comparision to Ember, there are a lot vendor specific things like Embers own objects, this.get. this.transitionTo. Its tougher to port out of Ember.

Another thing Angular does great is Typescript and autocompletion. This can make your life so much easier and productive…

Ember is very productive once you get the hang of it, it has a great community, stable and fast moving. Not sure how well you can say this for Angular ,2 just yet. Ember is application and productivity focused.

Angular 2 has a pretty great feel, it took lots influence from Ember and Spring framework and I feel Angular 2 is engineering focused (code longevity).

Thats my little quick reply hoprfully it makes your think!


Don’t get fooled by Angular being backed by Google. It’s a big misconception that this means stability and continuous support. Remember what happened to Google Web Toolkit? Once Google decided to not use it anymore for their own products, they dropped it in the mud for the open source community to pull it out, which eventually never really happened.

Ember’s future in the long run is healthier and way better guaranteed.


You are quite right and it is why I do not trust Google frameworks anymore (Angular/Polymer etc.)

Rob Eisenberg who has worked with Angular 2 team for some time has a very interesting point of view:

You were part of the team at Angular, and you talk about “irreconcilable differences” between yourself and the team, could you talk a bit about that? We disagreed on various technical choices which I felt wouldn’t be tenable in the real world, wouldn’t be flexible enough. But coming back to the business side of things, what I began to see when I worked there was that the entire development process was completely disconnected from the community. There was a lot of speak that went out that was “Thank you, we love our community…” and that was genuine, they really do, but when they went back to build version 2, there were no use cases or case studies coming from anyone, not even from inside Google. There were groups inside of Google using things that they could have done an official case study with, and that didn’t happen there and it didn’t happen publicly. If you do a bit of research you’ll find that Angular is actually a subteam inside of something called GreenTea which is an internal app (specifically Google’s Adwords CRM). Really, that is the driver for Angular, and if Angular does anything at all, it’s going to be this one app. Because of how they’re set up there, Angular isn’t really this independent Google product that exists to do what people think it does. It does some of those things, but that whole business side is missing. It really exists because it’s funded internally by this other thing that has it’s own agenda.

Google exists to make money, not to save the world. Their goals will always prevail over a community’s goals. If they are identical; cool, if they are not: too bad.

The GWT example is indeed a good example on how Google can abandon a product when it does not fit their needs anymore. Another example: Angular 1.3 where support for IE 8 has been brutally dropped despite yellings from the community. For me, this incident has triggered some alarms.

Ember in the other hand is a real community-driven project that allows long-term vision for apps. The transition from Ember 1.x to Ember 2.x that I have personally experienced was a perfect example of what a professional framework should do: it was gradual, smooth and very well done.


@HerveSeger, I’m a huge fan of Ember. But I take issue with the point that transition from Ember v1.x to Ember v2.x was smooth. It wasn’t for my project. Besides that, however, I love just about everything else about Ember and have been suspicious of React and Angular for aforementioned reasons.

Also, the Ember RFC process is probably the best thing about Ember in terms of community participations and openness.

1 Like

@shunchu, I have started to develop with Ember 1.5 year ago and I was working on a brand new project so the transition from 1.x to 2.x was pretty simple to manage. Migrating an existing app with a big code base was probably more rock’n roll.

I’ve been watching thoughtworks’ technology radar for a while. Radar was updated on November 2016, and they put Ember.js at the “adopt”. On the other hand, Angular 1 is on hold. (Throw it away, quickly) But, interestingly, they didn’t mention about Angular2.

Yet in the majority of cases the comments made during the RFC process are simply ignored, since obviously the core team knows best.

What you need to consider is that you are not choosing between Ember and Angular2 as they exist now, but as they will exist in one or two or three years. In other words, instead of (or in addition to) considering current features, you need to consider the roadmap. Unfortunately, AFAIK there is no actual roadmap for Ember. For instance, when we will get typed language support? When will it move to true support of native ES6 modules and classes? When will we finally be able to stop writing this.get('prop')? We don’t know the answers to any of these things.

Bob, if you take a look at the bottom of the core notes here ( you’ll see that your comments on the title bar weren’t being ignored. It’s something that was actively being discussed by the core team although their conclusions weren’t necessarily put on the RFC itself …

Regarding roadmap and better communication of it, it’s been a long-standing desire to better communicate that well. Yehuda did some initial work on this back in March of 2015 and I imagine the core team had been talking about it before that. For the learning team it’s a pain point that we’ve been wanting to address as well.

The main thing we need on the roadmap (we’ve been calling it the feature dashboard) is someone to help champion the work. Would you be willing to help out with it? I’d love to point you in the right direction and make sure we get this moving, I just don’t have time to buckle down on it myself.

If you’re interested, contact me on either Twitter or the Ember Slack (same handle as here), would love to see that finally get built! :smiley:

Regarding the above questions, Yehuda was in Denver a few days ago and talking about all of these items (sadly no video was taken). And yes, all of those things are on the core team’s roadmap (the modules RFC being the necessary precursor to move away from the Ember globals approach that still underlies Ember-CLI).

There is also a talk Yehuda gave on this recently that can be seen here: that lays things out as well

Does that help? Anything else that has been a sore point on the roadmap that I can help address?

Thanks for the link to the talk, finally something that made what’s going on with ember clearer. However, I think some sort of roadmap is sorely needed, this information is next to impossible to come by. How about just a simple table with columns like feature, link to RFC if it exists, state it is in currently and ETA (ember version), copy/pasted and updated with each release blog entry? Requires almost no effort, and would benefit all Ember users.

You mean like the one we’re working on here? Updates dashboard by locks · Pull Request #2726 · emberjs/website · GitHub :wink:

Would love to get help on that if you’ve got the time, volunteer cycles on these things are at a premium. That applies to your comment re: almost no effort to update as well. Turns out the more processes there are that “other people” have to maintain, the harder it is for things to move.

Nice :). I could spare couple of hours, why not, don’t know any rails though. Anyway the table seems straightforward enough to me? Only thing it needs is the data.

I am REALLY brand new to Ember. And I did a boat load of research on which JS framework I wanted to utilize to retool my existing app. I undertook some Angular training and I liked it - albeit, a large learning curve for me, coming from server-based apps with some JQuery. But I LOVE this stuff! After looking at Ember and looking at the logic and reasoning behind those who decided to run with Ember, I knew that was the direction I wanted to go. And I have had VERY helpful feedback and assistance from the community. I just feel more at home with Ember.


@acorncom I’m especially intersted in the TypeScript story. Did Yehuda said something about when TypeScript is comming to Ember-User land? Is this even considered?

At this point we’ve got a Dashboard page up (all data for it is static at the moment): Issues · emberjs/rfc-tracking · GitHub Would :heart: to get help working out how to automate pulling in the data, as it’s going to be a bit bumpy keeping that up to date. Volunteers gladly accepted!

From the discussion we had, it sounded like something that the core team might like to allow at some point (no promises) but doesn’t ever intend to make a requirement (i.e. I wouldn’t expect the guides to ever be in that format). From what I hear, I think different folks on the core team have mixed opinions on TypeScript :grinning: