The Transition to Ember 2.0 in Detail

Yep, kudos to the backwards compatibility. Our original stack was Ember and ember-model and we have made the transition to ember-cli and have been tracking ember-cli and are slowly moving the legacy features to ember-data while implementing the new bits in ember-data. While it has not been entirely pain free, we haven't run into any show stoppers and I really like the way the ember ecosystem is shaping up. Big thanks to all the contributors for the attention to minimal breakage.

The changes were the only change we needed to make in 1.x to be compatible with FastBoot.

It sucks that new Ember CLI apps trigger the deprecation. We should get that fixed :)

React is a library, Ember is a framework.

I don't know if they implemented it like React. There are a bunch of virtual DOM implementations out there who are faster.

Also, for the most part, it's a drop in replacement for the old rendering.

That's a completely fair question since large parts of this blog post are focused on major Ember 2.0 features, many of which were strongly inspired by React.

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.

Well... for a start, there are many existing apps written in Ember. These will get a immediate, backwards compatible boost in performance. Quite often "why not rebuild" isn't exactly going to be a trivial exercise.

For new apps, the "why Ember over React" exercise is left to the reader. They're both excellent at what they do.

Doubt anything will change in ember to accommodate any specific transpiler , or (transcompiler) if you would. Do have a look at https://code.visualstudio.com/, ember is used in that first example, so using specific tools for better integration will be a better option at this stage.

Any particular reason why you chose to roll your own workflow instead of using ember-cli? (in most use cases I read about, people already had this before ember-cli matured).

That's pretty much what ember is now. Which is not a bad thing per se, but can be frustrating and was one of the reasons we chose React/Flummox over Ember; plugging in non-Ember specific tools into the build system becomes more difficult vs having a pipeline you have control over!

yeah, it's ES6 shorthand for `keyUp: function (event) {`; the new syntax is valid both in objects and class definitions.

Having been rewriting a large system that was a disgusting jquery mishmash of terrible code in React/Flummox, all in ES6/ES7 classes and compiled down with Browserify, I'd never want to write JavaScript any other way. ES6 syntax like what you've pointed out is simply brilliant in everyday usage :)