BT

Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ

Topics

Choose your language

InfoQ Homepage News Ember.js 1.13 Brings Glimmer Rendering Engine and 2.0 Beta

Ember.js 1.13 Brings Glimmer Rendering Engine and 2.0 Beta

This item in japanese

Ember.js 1.13 has been announced, the final iteration of the 1.x series, along with the first Ember 2.0 beta.

Co-creator Yehuda Katz and Ember contributor Matthew Beale announced the latest releases on the Ember.js blog, noting that version 1.13 represents "the effort of at least 43 contributors across over 680 commits."

The 1.13 release brings with it the Glimmer rendering engine. Katz and Beale mention that this marks the third overhaul of Ember's 1.x rendering layer, and "dramatically improves re-render performance in many common scenarios," where previous iterations relied "on granular observation for efficiency."

The advantages of this, they say, include:

Glimmer adopts a value-diffing strategy, using a virtual tree of the dynamic areas of the DOM. This means that even if the original data structure (for example, an array) is completely replaced, the DOM is not updated unless the resulting rendered content has changed.

When updating an array with a new array (because you got a new array from the server, or because you produced a new array through .sort()), you will see a large improvement in performance, making this kind of replacement plausible in Ember.

Furthermore, it is reported that Glimmer's hybrid model "can opportunistically take advantage of explicit mutation (via set) when it is used," at the same time supporting efficient re-renders of entire data structures.

Alongside version 1.13 comes the first beta in the 2.0 series. Katz and Beale say that the 2.0 beta does not "introduce the entirety of our improved development model. However it will take significant steps in that direction." Among those "significant steps" are new features, including the introduction of the each-in and get helpers. The former "allows the iteration of object properties", while the get helper "provides a bound way to fetch a single property from an object."

Ember 2.0 removes many features deprecated during the 1.x series, a number of public APIs, and as previously mentioned, support for Internet Explorer 8 will be dropped in Ember 2.0 after the Ember community voted overwhelmingly in favour of the move.

Among the APIs removed are:

  • all Handlebars APIs, including: Ember.Handlebars.helper, Ember.Handlebars.makeBoundHelper, Ember.Handlebars.helper and Ember.Handlebars.compile
  • many controller APIs, including: {{render "some-controller"}}, {{each item itemController="some-controller"}}
  • all view APIs -- including, but not limited, to Ember.CoreView, Ember.View, Ember.ContainerView and Ember.CollectionView

It should be noted that most of the deprecated APIs have already been moved into core-supported addons, and the Ember Deprecation Guide provides a clear migration path.

The reaction from the JavaScript developer community to the Ember release was a positive one. On the Hacker News discussion about the release, user Thomas Chen commented "I am glad Ember is still going strong. And, as a heavy emberjs user, most of these changes feel like a step in the right direction."

Chen followed up with some questions for the core Ember team, that he was clear to point our were not complaints:

1. What happened to the server fast-boot thing? I was under the impression you guys wanted to ship it with 2.0; has that feature been scrapped / moved into a separate project altogether?

2. There was no mention of the deprecating changes to the initializer API (i.e. the splitting into instanceInitializer and vanilla initializer). Have we gone back to the old initializer API in 2.0?

3. With the removal of action bubbling, do we now have to manually bubble up actions that start in some nested controller but gets handled in application route? For example, say you have an AdminUserController and it has an action that generates an ephemeral flash message, but you handle flash rendering in your application route. Do you now have to laboriously put an actions: { handleFlash { ... } } on every route along the way?

Yehuda Katz replied, explaining that the "SEO-only FastBoot" has already shipped in canary, with work on "Rehydration, the big enchilada" due to begin shortly. Regarding the initialiser API, Katz said the Ember team were "sticking with the split-apart API we shipped a few releases ago", and finally in response to Chen's question about the removal of action bubbling, Katz clarified "We're starting with more laborious (with services as an escape valve), but have some ideas for conventional situations where you could get away with less ceremony. Stay tuned! (by which I mean, there will be RFCs in the near future addressing this kind of issue)."

Users should refer to the Ember 1.13 and 2.0 changelogs for full info.

Ember.js is released via an MIT licence. InfoQ readers can contribute to Ember.js via its GitHub project.

Rate this Article

Adoption
Style

BT