I'm really loving the new Promises/A+ support in Ember—lots of weird corner cases just got a lot cleaner, and it's much easier to bypass Ember-Data when the need arises. See this section of the original post for an example:
The first rule of Ember.js happiness is "Don't fight with Ember Data." When Ember Data does what you want, it's amazing. When you want to do something that it doesn't support, just fall back to jQuery and promises at the model layer, as shown above.
I've always been meaning to take a look at Ember. When I first started seeing discussions about it about 2 years ago, there weren't many guides or quick examples on how it is different than other frameworks out there. What would the use case be for Ember.js vs something like AngularJS?
Angular folk are often quick to point out that "Angular isn't a framework; it's an HTML compiler", or, as their homepage states, "AngularJS is a toolset for building the framework most suited to your application development." Angular doesn't necessarily set out to solve all of the problems and use cases that developers might run into, but rather Angular intends to give you all of the proper data-binding, dependency injection, and testability primitives as a foundation to build your app upon.
Because it doesn't intend to solve all the problems that a framework might, Angular is far fewer conventions about how to organize large-scale applications than a much heavier and opinionated framework like Ember. This doesn't mean Angular doesn't scale, or that it can't be used to build large apps, but it does explain why it's common for different teams to build large Angular apps in totally different ways, using different patterns, etc.
Ember on the other hand sets out to establish way more conventions, built right into the framework, for solving problems common to most web apps. These patterns are rigorously battle-tested since everyone is using them, and as such, it's easy (once you're past the learning curve), to drop into someone else's Ember app and know exactly where to go to diagnose a problem. That being said, when these patterns aren't helpful for an app's specific needs, most of Ember's patterns/abstractions are, like Angular, built upon composable primitives that you can use to assemble your own data structures, custom classes, etc., to tailor to your app's needs.
One thing I might add for others who read this is that many of Ember's design patterns are modeled after Cocoa, which has proven to be one of the world's most robust platforms for building apps. If you're familiar with Cocoa's two-stage object instantiation, MVC, or first responder patterns you should be able to recognize them fairly easily in Ember.
Thanks for this response. I think I may have to do a crash course on each one for a few days to make a more informed decision. I've always used Backbone to quickly prototype, but I like the idea of having a more complete toolkit once prototyping is done.