If Ember is going to borrow so heavily from React, why not just use React and Flux instead?
As you know, React describes itself as the V in MVC; in contrast, Ember is a complete front-end stack, including not only a model and service layer, but also a built-in router, integrated command-line tools, and an add-on ecosystem that takes advantage of that common set of assumptions.
It's also safe to say that the React community is still exploring the space of the application layer: multiple flavors of the original Flux architecture, Facebook's recent announcement of a successor (Relay), and different routing libraries that work well with React.
We believe that there are productivity benefits to having the community coalesce around a single stack, but we also believe that it's important to avoid stagnation. That's why Ember 2.0 is both focused on bringing in some of the great ideas that React has pioneered in the view layer, but maintains many other aspects of the 1.0 stack.
We make the changes compatibly on the 1.x branch with a clear transition plan so that we can bring along as many existing users as possible.
For new apps, the "why Ember over React" exercise is left to the reader. They're both excellent at what they do.
The TLDR is:
* We like templates, and were able to implement a more efficient algorithm using them (even more than the recent improvements in Babel).
* Compatibility is important to us, so HTMLBars was going to be a much better transition story for Ember 1.x than JSX.
* We prefer an HTML-centric templating story (copy/paste valid HTML and it works) over an XML strategy that requires camelCasing, className/htmlFor, etc.
* We optimized Glimmer for a hybrid (rerender + subscriptions to the model or service layer) model that can opportunistically avoid work based on knowledge we have from the whole stack.
That is an explicit non-goal of JSX, and it shows.
Also, for the most part, it's a drop in replacement for the old rendering.