Ember.js 1.12 and 1.13 Beta (shimmer!) released

We are happy to announce the release of the first beta version of Ember.js 1.12 and 1.13 series.

The 1.13 beta is the first Ember.js version, which includes the new Ember rendering engine Glimmer, and the last batch of Ember 2.0 features. We will discuss these details in detail below.

New features in Ember 1.12

Ember 1.12 is a relatively lightweight version, including features that make Ember closer to ES6-like syntax and the first part of the internal implementation required for a stable version of the FastBoot plugin.

New calculation grammar

each RFC #11, Ember introduces a new syntax for calculating attributes. This change better aligns calculated property syntax with JavaScript getters and setters, and makes it friendly for developers who write settable calculated properties.

It also has the good side effect of improving performance, because the old syntax with two-in-one function signatures is more difficult to optimize for JavaScript engines.

The simplest syntax for calculating properties is to define the getter as a function:

export default Ember.Object.extend({

  height: 100,
  goldenRatioWidth: Ember.computed('height', function(){
    return this.get('height') * 1.618;


In Ember 1.12, this is still the way to write simple getters, which is the most common use case for computing properties.

Create settable calculation properties in Ember 1.11 if The statement is used to distinguish get and set logic. E.g:

export default Ember.Object.extend({

  height: 100,
  goldenRatioWidth: Ember.computed('height', function(key, value){
    if (arguments.length > 1) {
      this.set('height', value / 1.618);
    } else {
      return this.get('height') * 1.618;


This syntax is practical, but error-prone, verbose, and difficult to understand (for humans and JavaScript engines).

In Ember 1.12, you can very well separate getter and setter into two different functions.

export default Ember.Object.extend({

  height: 100,
  goldenRatioWidth: Ember.computed('height', {
    get(key) {
      return this.get('height') * 1.618;
    set(key, value) {
      this.set('height', value / 1.618);
      return value;


This also aligns Ember’s API with JavaScript getters and setters, and simplifies the way to use JavaScript getters in Ember 2.0 after dropping IE8 support.

For more information, see the initial implementation in #9527

thank you very much @stefanpenner with
@米格尔坎巴 Support and release this feature.

One last thing: thanks for the experimental support JavaScript decorator In Babel, we also plan to further improve in the near future:

export default Ember.Object.extend({

  height: 100,

  get goldenRatioWidth(key) {
    return this.get('height') * 1.1618;

  set goldenRatioWidth(key, value) {
    this.set('height', value / 1.618);


Instance initializer

The next feature, the instance initializer, allows the FastBoot application to run many requests simultaneously.

Before FastBoot, you could only run one application at a time. Even in automated testing, the tests run continuously one at a time, so an application is destroyed before the next application is created.

In FastBoot, it is very important for a single-node server to be able to service the second request when the first request gets its data.

Fortunately, Ember has ensured that all state is stored in the container, so in theory, all you need to do is provide your own container instance for each request, and then get concurrent requests in FastBoot.

In practice, we need to make some small API changes to make it work in situations involving initializers. In Ember 1.11, the initializer will run when the application starts (or once for each test). Some initializers are setting up code (and injection rules), which are the same in all FastBoot requests, while other initializers are creating instances, which are different from request to request.

In Ember.js 1.12, application startup is divided into two stages:

When multiple plug-ins may register factories and inject, the two-stage initialization process is safer.

Ember-CLI 0.2.3 supports instance initializers. E.g:

// app/instance-initializers/sleep.js

export function initialize(application) {

export default {
  name: 'sleep',
  initialize: initialize

To define instance initializers in global mode, use Ember.Application.instanceInitializer
method.For more information about instance initializers, see the implementation in

Thank you @tomdale, @wycats with
@dgeb For this function and other refactoring work around application initialization.

Initialize the context

Previously, the this The scope of the initializer is the global scope.
#10179 Change the scope of the initializer to the initializer object itself.

Thank you @gf3 Used to suggest and add this feature.

Man 1.13 Beta

Now, great enchiladas!

With the release of Ember 1.12, we will release the first beta version of Ember 1.13.

Ember 1.13 is:

  • The last minor version of the 1.x series
  • The first version that contains the new version Low light rendering engine

Review; what is shimmer?

  • A new and faster rendering engine with a particularly fast update speed.
  • An implementation of a component “re-rendering” programming model inspired by React, with a one-way data flow by default, and better performing data downward and upward operations.
  • Support angle bracket assembly (<my-component />), ergonomic properties (<my-link href="https://blog.emberjs.com/{{url}}.html">go home</my-link>), it is very close to HTML syntax with some minor improvements.

We will write a blog post in the next few days to extend the programming model of Ember 2.0 and discuss the most important new features. The complete documentation will be released soon.

We would like to thank the entire community for all nights and weekends in the past few months for getting Glimmeralmost) Cross the finish line. This is inspiring.

1.13.x series

In most cases, you should expect Glimmer to be faster during initial rendering and updating. If you find a performance regression in idioms in the app, we definitely want to hear it. Please submit a bug.

The Glimmer rendering engine has changed the part of Ember that has not been affected since SproutCore 2.0. In practice, this means that you may rely on the implementation details of the pre-Glimmer implementation that were not captured by the test and were not discovered during the Canary period.

Due to the magnitude of internal changes, we expect that the stability of the first few Ember 1.13 betas is not as stable as the other betas in the 1.x series. We need your help to find and fix compatibility regressions.

Please report any incompatibilities you find. We will investigate and consider eliminating any regressions affecting a large number of applications, even if the root cause is a change in internal implementation details.

We know that there may be some compatibility regressions, especially in terms of implementation details, which we did not find during the 1.13 beta. We plan to continue to release point versions to the 1.13 series to fix these details after the 2.0 beta version is released, and maybe even within a period of time after the 2.0 final version is released.

Our goal is to ensure that most applications can be upgraded to Ember 1.13.x, remove deprecations, and then upgrade to Ember 2.0 without fussing. If a large number of applications that have been carefully tried to upgrade in this way cannot be upgraded, we will continue to fix the issues that prevent the upgrade.

To learn more about our transition plan for existing Ember 1.x application users, please refer to the recent Detailed transition to Ember 2.0 Blog post.

Change log

Leave a Reply

Your email address will not be published. Required fields are marked *