While there's great feedback here, it's interspersed with information that is either outdated or just flat-out inaccurate. Overall, Angular is a much more exte

While there's great feedback here, it's interspersed with information that is either outdated or just flat-out inaccurate. Overall, Angular is a much more extensive framework than Ember. I don't think this is true. For example, AngularJS, as far as I'm aware, does not offer a persistence story at all. Injection and testability. Ember.js does dependency injection too; we just roll it into our conventions so that new developers don't need to learn what dependency injection is. If you have to learn a ton of comp sci terminology to start learning a framework, they blew it. Additionally, Ember is fully unit tested (over 6000 unit tests at the moment) and, because of dependency injection, loading up your app in a clean state and testing individual components (models, views and controllers) is easy. Support for partials and inclusion of templates. This is another thing I really missed with Ember.js, which offers no easy way to break down your HTML templates into smaller, more manageable files. This is just flat-out inaccurate, and has never been true. Ember has supported breaking up templates since day one. Documentation. While the Ember.js documentation is fairly large, I found it very unorganized and I often resorted to searching the page to find what I need. This has been fixed and the response has been overwhelmingly positive. We still have a ton of stuff planned to make it even more friendly for beginners. Cascading updates are being executed right away. This is simply not true. In fact, Ember's run loop is what powers many of the nicest features, like deferred DOM updating and binding synchronization. I'm a little bit surprised that other JS frameworks haven't copied the idea, to be honest. You need to remember to call the setter: object.set('foo', newValue) I agree that this is not ideal, but the flip side is that frameworks like Angular have to iterate over every bound object when something in a scope has changed, and check it against previously known values to determine if a change has happened. This "dirty checking" can quickly lead to pathological performance issues. We're all about ease-of-use, but not when it turns into a footgun. As you might be aware, Yehuda Katz is on TC39 (the committee developing the next version of ECMAScript). ES6 supports object proxies, which provide sufficiently rich semantics that we will be able to drop the get/set requirement if you are targeting ES6 browsers. We are ready to add this to Ember as soon as proxies land in popular browsers. It's actually disappointing how much FUD is in this article. Competition is great, but let's deal with facts.