While I have yet to finish a project with Ember (I've been trying!), the amount of attention to backwards compatibility in this upcoming release is astounding.

Great work by all those involved.

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.

Looks great, I can't wait for 2.0...

In case anyone from the core team is looking through these comments, why did you guys change up Ember's initializer API? I mean even new addon projects freshly generated by ember-cli are now hit with a deprecation warning regarding initializers. Considering all the things affected by the initializer change, it makes it extremely challenging to ride canary when literally even canon boilerplate code by the tomster (to say nothing of the 1k addons out there) is deprecated.

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 :)

If Ember is going to borrow so heavily from React, why not just use React and Flux instead?

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.

React is a library, Ember is a framework.

I think maybe the parent comment is wondering "Why Glimmer and not React for the rendering library?"

We talk about this a bunch in https://www.youtube.com/watch?v=qwIyenCaSXk

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.

Fair enough, but I would argue JSX is just as "HTML-centric" as anything Ember has implemented, so long as we agree "HTML-centric" means, practically speaking, "not HTML."

What I mean specifically is that if you copy and paste some valid HTML from inside a body tag, it will work.

That is an explicit non-goal of JSX, and it shows.

The Youtube video just says "Please stand by.".

Whoops: https://youtu.be/msS-3zqKKUI?t=51m5s

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.

I hope it adds easier and better integration with Typescript, in fact I would love that for Ember 1 as well.

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.

Actually typescript already works fine in Atom, which this light weight Visual Studio is based on.

I already got Atom-TypeScript working fine, but I am having issues with ember-cli-typescript not working, I was hoping for an official way of working with it.

What are the plans with Ember-CLI?

I use my own build-chain with Gulp/LiveScript, but I found that some Plugin-Devs mentioned that supporting non-CLI-users was getting harder[0]

Now I have the fear that Ember will become a huge Rails like code generator blob in the future :\

    [0] http://ef4.github.io/liquid-fire/#/installation

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!

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).

It seems like it prescribed too much.

I want to use LiveScript, Emblem and Stylus with the build modules of my choosing. Also I don't need any of these code generators. Broccoli feels also like they are running their own stuff just because they can.

I'm confused by this example:

    export default Component.extend({
      keyUp(event) {
        if (event.which === 13) {
          this.attrs['on-enter'](this.$().val());
        }
      }
   });

This is invalid ES5. I assume this is new ES6 module syntax, specifically the `keyUp(event) {`?

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 :)

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