Interesting. Thanks for the list. My biggest issue with Ember, other than the management of release schedule and API early on, is the concept of tying routes to models explicitly. It seems to assume that given a route context, you'll be dealing with a particular model - and only one particular model. If you want to have an additional data context, you need to establish route and then tie the routes together within one template.

This seems to confuse the relationship between a URL and the data displayed on the page.

I've really enjoyed React+Backbone, on the other hand. Very small footprint and gives me flexibility to design and build an application. After spending years with Rails, I've come around to "convention over configuration" is a nice thought, but breaks down at certain sizes. And it seems to break down much more quickly on the client side.

To me, personally, well-written Backbone+Underscore+React runs circles around the newer JavaScript frameworks. It's not to say the debate is over and settled - I just haven't found the complexity and size of frameworks like Ember to pay back more than they cost.