Ember 1.8 has been announced. One of the biggest changes is use of metal-views, which improves rendering performance. It also paves the way for more rendering improvements, grouped as "HTMLBars" in the future.
In earlier version of Embers, the HTML of a page was created (via Handlebars) as strings and assembled using string concatenation. Now, the fragments of the page are still created as string (via Handlebars), but then parsed into DOM and assembled as a DOM Tree.
This is advantageous in several ways -
- Ember no longer needs <script> tags to mark regions of data-bound content (to know where to update values in the DOM). It can now track this using the independent DOM objects.
- Adds support for components, data-binding, logic with inline SVG documents
- Recursion removed from the rendering layer. Reduces GC pressure and can reuse objects during render
The new changes seem to introduce some performance regressions, especially in IE and Android browsers, compared to Ember 1.6. This seems to be because of the extra intermediate step (first converting handlebars to string and then to DOM) but is yet to be confirmed. In a future release, this step will be eliminated.
Matthew Beale posted on HackerNews about the current status of rendering changes and further plans -
We've started using the term HTMLBars to mean a collection of changes to the Ember rendering pipeline. In the current release (1.8) we've added metal-views (a renderer refactor), in the next release (1.9) we will be adding Streams (a data-binding refactor), and in 1.10 we hope to land parts of the new syntax and the DOM-based templating engine.
We've worked very hard to make HTLMBars an incremental release, and not a Big Bang rewrite. Partially because of this, it has taken longer to ship than was planned. However I'm personally very happy about how smoothly the transition is going thus far, and if you are a user of Ember.js I think you should feel the same way.
The "Streams" Matthew refers to, are a new Ember.js internal that replaces bindings at the lowest level of the Ember rendering pipeline. They simplify implementation of template helpers. This is available in Ember 1.9 beta, which accompanied the 1.8 release.
The community has been excited about HTMLBars for several reasons. Existing applications will become significantly faster with no change in syntax - purely because of rendering changes (parsing to DOM rather than string manipulation). Also, it will allow a host of new things such as HTML syntax for components. A lot of these planned changes have together been elaborated on in the post "The Road to Ember 2.0 RFC".
However the changes have taken a lot longer than anticipated, especially because of the amount of testing required.
Ember 1.8 also gets several other performance improvements -
- Several caches introduced for various operations (case changes, signularizing/pluralizing) of string normalisation (when looking up class or route).
- MANDATORY_SETTER changed from a runtime to a build-time feature flag. Allows code paths in getters and setters to be slimmer in production builds.
- Ember.Map has been rewritten to be faster and closer to ES6 implementation.
There are also several deprecations. These are published as a deprecations guide on the Ember website. Refer to the changelog for a full list of improvements and bug-fixes.