Ember 2.0 is not a traditional major release. After thirteen point releases in almost two years, we're taking a turn to focus entirely on sweeping out built-up cruft as a foundation for continued progress.

Ember 2.0 only removes features that were deprecated as of Ember 1.13, so apps that run on Ember 1.13 without any deprecation warnings should run without issues on Ember 2.0.

New applications should begin using Ember 2.0 today. Apps requiring Ember-Data should use Ember-Data 2.0.0-beta.1 (2.0 release coming shortly!).

New Features in Ember.js 2.0

• <This space intentionally left blank!>

Major releases of most libraries try to do two things. They introduce new APIs, and remove deprecated ones. Our release focuses on doing one thing well: Instead of introducing new features, the goal of Ember 2.0 is to remove accumulated cruft.

Since Ember 1.0, adherence to semantic versioning has helped us grow an amazing community. Ember powers extremely ambitious applications, and most of those applications have been able to move forward over 13+ releases as new features arrived.

We are committed to giving every Ember codebase a path into 2.x. To ensure this, we've flagged everything removed in 2.0 with a deprecation in the 1.x series. If your app runs on Ember 1.13 without raising deprecations, it should run on 2.0. There are no new features to adapt to or adopt.

In the first few releases in Ember 2.x, we plan to land a variety of exciting features. We are all the more excited that thousands of existing apps will be ready to use them immediately. More about this below.

Removed APIs

Internally, we've taken to calling Ember 2.0 a "garbage collection" release. Two years is a lot of framework development, and there are many things dropped in today's release.

Developers migrating forward will find these resources helpful:

• The 1.x Deprecation Guide contains a summary and migration path for many deprecations since Ember 1.7. Additionally, this guide is linked to from deprecation messages in your browser's console.
• The Ember Inspector is an essential tool for debugging Ember apps, and provides some tooling for managing deprecations.
• Core team members Robert Jackson and Matthew Beale published the ember-cli-deprecation-workflow addon in July. This tool helps to manage upgrades to your codebase through deprecation messages. Watch Robert present on upgrade workflows in this NYC meetup video.
• The ember-debug-handlers-polyfill addon provides a future-safe API for writing your own upgrade tooling.

Some of the major API removals follow.

Views have been removed in Ember 2.0. Components, which provide better isolation and scoping semantics, fulfill the use-cases views were introduced for.

We recognize that existing apps will not complete their migration away from views for several months, so we have published the ember-legacy-views compatibility addon, that will allow you to spread out the transition over more releases. We are committed to maintain support for this addon until at least Ember 2.6.

If you are building a new application, the use-case for views have completely been subsumed by Components. Existing apps should refactor away from the {{view}} helper and Ember.Views in favor of Components.

However, existing applications that make use of top-level Views do not need to immediately refactor those views to components. The future Routable Components will provide a softer transition path for this use-case and we commit to support the compatibility addon until the community has had a chance to transition to Routable Components.

Similarly, the use-cases for Controllers have largely been eliminated.

As with views, we have published the ember-legacy-controllers compatibility addon that you can use to spread out the transition. This addon will also be maintained until at least Ember 2.6.

If you are building a new application, you should almost never need controllers except to manage query parameters and communicate with the route (ala transitionTo). For these cases, Ember 2.0 retains support for top-level controllers with no addon required. While we plan to completely replace these use-cases during the 2.x series, everything that works without the compatibility addon will continue to work until 3.0.

Existing applications should refactor away from using the {{controller}} property, use of proxying controllers (ArrayController and ObjectController), itemController, etc.

However, existing applications that make use of top-level Controllers do not need to immediately eliminate those controllers. As with top-level views, the future Routable Components will provide a softer transition for this use-case and we commit to support the compatibility addon until the community has had a chance to transition to Routable Components.

ReduceComputed and ArrayComputed have been made obsolete by the Glimmer rendering engine introduced in Ember 1.13. These APIs allowed array operations to be performed without creating new arrays. Glimmer's value diffing makes this unnecessary. Computed property macros that operate on arrays are still present, but they are not backed by ReduceComputed.

Context shifting in templates ({{#each}} and {{#with}} without block params) is removed in Ember 2.0. For any template, there is now only one this and it cannot be changed for part of that template by any helper. This makes templates easier to reason about, and unlocks opportunities for performance improvements.

IE8 support has been dropped for Ember 2.0. For the 2.x series, IE9+ will be supported.

Legacy Handlebars helpers are removed in favor of the Ember.Helper API. This API does not provide a mechanism for helpers to take a block, but does introduce support for nested helpers which can be used in concert with built-in helpers (like {{#if}} and {{#each}}) to achieve the same ends.

Please see the CHANGELOG.md for an authoritative list of cleanups.

The Road Ahead

Over the last few releases of Ember 1.x, we added a large number of new features. These additions, including a whole new rendering engine, were introduced while maintaining backwards compatibility. Unsurprisingly, maintaining support for the semantics of two rendering engines (among other things) introduced a large amount of cruft. Continuing to provide backwards compatible legacy APIs has a non-trivial impact on the performance of Ember applications, and on the project’s momentum.

Ember 2.0 allowed us to purge much of that built-up cruft. That was no small task; removing code, documenting deprecations, and building new workflows for managing these changes would not have happened without lots of hands. It was an incredible effort, and we'd like to thank the community for making it happen.

With the garbage collection sweep out of our way, we can continue to expand on the foundation solidified in Ember’s 1.x series.

Improved Release Cadence

Since Ember 1.0, we have followed Semantic Versioning, working very hard to maintain public API compatibility while adding new features. In the lead-up to breaking changes in Ember 2.0, we made a number of mistakes that caused our users to experience a great deal of churn.

While we successfully followed our existing policies regarding deprecation before removal, and ensured that each deprecated feature had a viable replacement, we did not do a good job of distinguishing between different kinds of deprecations. Additionally, many deprecations landed very late and all at once. These factors combined made the entire process feel overwhelming.

The feeling of "churn" is contrary to all our release process goals. In addition to the continued maintenance of a six-week release cycle, we have a number of tweaks to the process planned for 2.x. These are intended to help us avoid a similar problem late in the 2.x cycle.

Some examples of improvements are:

• LTS (Long-Term Support) Releases (RFC #56), which can give users who want to upgrade less often than every six week a sanctioned way to do so.
• Mandatory docs. No new features will be added to the Ember 2.0 release channel without accompanying documentation.
• More informative deprecations. All deprecations will include which release their behavior will be removed in, as well as a link to transition instructions.
• Improved deprecation tooling. More informative deprecations allow us to make the Ember inspector's deprecation pane smarter, and more useful for incrementally working through deprecations. In particular, we can avoid nagging you (by default) about removals that will not happen until far in the future. For more information see RFC #65 and the included comments.
• Svelte Builds, which allow you to ask Ember CLI not to include deprecated features you are no longer using. This will reduce pressure on future major releases.

Ember 2.x Themes

In addition to a better release process, you can look forward to several high-level areas of improvement throughout the 2.x series.

Alignment with JavaScript. Throughout 2.x, we will continue our efforts to align Ember with ES6 and future versions of JavaScript. As the JavaScript decorator proposal stabilizes, and as transpilers improve their implementations, we plan to adapt computed properties and other APIs to that syntax.

JavaScript Modules. We will also continue to evolve further towards a modules development style and away from a globals style. Among other things, this will allow us to more aggressively automate the removal of dead code paths.

Stabilization and Integration. The Ember ecosystem will continue to stabilize and integrate tightly. Ember-Data and Ember CLI will be versioned in lockstep with Ember itself. Putting these projects on the "release train" with Ember will mean they adhere to the same backwards compatible and incremental change policies as Ember did through 1.x.

Ember Data. With the release of Ember 2.0, Ember Data is now a stable part of Ember's releases. It will adhere to Semantic Versioning policies like Ember itself, and every release of Ember will include a compatible release of Ember Data. Along those lines, Ember Data will not make any breaking changes until 3.0.

New Features in the Pipeline

Many of our other plans have already been proposed via the RFC process and discussions on GitHub, but here's a recap.

We are actively working on the implementation of these features, and expect them to land gradually over several releases.

Angle-Bracket Components and One-Way Data Flow. Ember 2.x will transition to angle-bracket components. For example <my-button> instead of {{my-button}}. These will operate with one-way binding as part of a larger transition to a "data down, actions up", or "DDAU", style of programming that you will read about as features land. We expect these components to land in 2.2 and be refined over the next few releases. See RFC #60 and PR #12011 for more details about our progress.

Pods. We are also actively working on finalizing the pods directory layout for applications, which makes it easier to group related parts of your application together. This change will be completely opt-in, and existing layouts will continue to work.

Routable Components. After angle-bracket components and the pods layout land, we will be able to transition the last few use-cases for controllers to the much-anticipated Routable Components. RFC #38 and PR #11939 track our progress so far.

FastBoot, Ember's alpha release server-side pre-rendering library, will continue to improve and stabilize over the 2.x lifecycle. Find it on GitHub as ember-cli-fastboot.