Glimmer is in Canary, test your application!

After months of work, Glimmer landed in Canary today.

What does it mean:

  • The test suite passed.
  • We have tested Glimmer on our own app, and in most cases, the app can start and run correctly.
  • There are still known issues (see below), including test assistants.
  • At this point, we need community help to determine compatibility issues not covered by the test suite.
  • With the exposure of new issues, we hope to continue to improve compatibility with the pre-Glimmer engine in a period of time.

Glimmer is a new rendering engine that the Ember community has been working on in the past few months. This is the first complete change to the template engine since SproutCore 2.0, and uses the foundation laid by HTMLBars to significantly improve re-rendering performance. It also laid the foundation for more performance improvements during the 2.x series and provided React-inspired improvements to the Ember programming model. Most importantly, we will log in to Glimmer in Ember 1.13, which is compatible with the full public API of Ember 1.x.

It’s also worth noting that although our application feels faster, not every performance benchmark will necessarily show a significant improvement. There will be more related content below, but the Glimmer refactoring mainly focuses on significant improvements in re-rendering performance and programming model improvements.

In most of our tests, the initial rendering of component-intensive pages showed some improvement, but you should expect to see the biggest improvement when you re-render the list, especially when you are not using deprecated features.

Once we log in to Glimmer, you may see a variety of different benchmarks testing various aspects of Ember. We want to see benchmarks show that there are still pathologically slow scenarios in Ember, especially in areas where we have no focus on improvement. We hope to continue to improve Ember’s performance throughout the 2.x series and discuss in detail below.

Please also note that although we worked very hard to support the features that existed in Ember 1.12 (including many long-deprecated features), this compatibility usually brings significant performance costs.In some cases, seemingly similar structures (e.g. {{#each posts as |post|]} Compared {{#each posts
itemController="post" as |post|}}
) There are significantly different internal implementations, and Ember 2.0 version has better performance.

Finally, there will be an upcoming guide next week or so describing the new features of the Glimmer engine (attrs, New life cycle hook, type #each), but currently we focus on compatibility with 1.x and use existing applications to test the 1.x API.

Follow the instructions below to use Canary to test the Ember-CLI application:

Known issues

When evaluating Glimmer, you should consider several known issues:

  • We have discovered and are quickly resolving some memory leaks.
  • the concept of controller The templates and actions in Ember 1.x are quite subtle. Glimmer started with a simpler model and layered compatibility at the top. We are still resolving known gaps in the compatibility layer.
  • There are still many problems in test assistants (especially fake unit tests that use “isolated containers”), which cause the application to work and fail the test. We are working hard to fix the test assistant, and this should be done before we release the 1.13 beta.
  • There may be many unknown compatibility issues in Glimmer. You should assume that most of the issues encountered when testing Glimmer in the next few weeks will be resolved before the final version is released.
  • The compatibility layer is slow in some ways, making the entire Glimmer engine slower than we want. We plan to pass the Canary and Beta cycles, and then improve the overall performance during the 2.0 release cycle.
  • In general, Glimmer’s efforts are to improve re-rendering performance, especially in large lists. It also laid the foundation for the initial rendering and important performance work in the entire framework, but this work has not yet been completed. Due to this change, Ember’s performance is expected to continue to improve throughout the 2.x cycle.

Before we release the 1.13 beta, the most critical issues in these warnings should be resolved, and we hope to continue to resolve the remaining issues throughout the 1.13 beta cycle.

Due to the magnitude of this change and the approaching Ember 2.0 “remnants removal” phase, we plan to actively fix the reported errors during the 1.13 beta period. In the next few weeks, there will be another article describing our 1.13 and 2.0 release plans more accurately.

Performance improvement

Glimmer’s biggest performance improvement comes from moving to a simpler rendering model, built on top of HTMLBars.

First, this allows us to delete All Internal view of the structure, such as {{foo}}, {{#if bar}} Even in {{#each posts as |post|}}This kind of view removal will have an impact on the initial rendering, because these constructions are very common in real-world templates.

Secondly, as we have discussed extensively, this allows us to significantly improve the performance of re-rendering, which makes it feasible to re-render the list with a brand new array with very good performance. In the past, it was very difficult to achieve reasonable performance, and even if possible, it would bring a lot of bookkeeping overhead.

Interestingly, we found that when testing real applications, the performance improvement was much more extensive than we expected. This is largely due to the simplification of the overall model.

The performance of Glimmer in practical applications surprised us and surpassed the improvements we saw in the benchmark tests used for stress testing pathology cases.

When upgrading to Glimmer, please pay attention to the actual performance of your application In production mode And after clearing any deprecations with performance warnings.

Deprecated features

Throughout the 1.x series, Ember has deprecated features that we plan to remove in 2.0. This process continues in Ember 1.13, which will include Glimmer.

However, it is worth noting that Glimmer is the first major change to many parts of the view layer since SproutCore 2! Therefore, perfect compatibility, especially in private APIs, is more challenging.

In the process of building Glimmer, we found that the various semantics of “controller” are the most challenging. In most cases, this is because the concept of controllers is based on context (routing, {{render}}, {{#each posts
, {{#each posts itemController="post" as
, {{#with someController}}, and many more. ).

Both the controller and the component manage the “context” of the template (called “self” in Glimmer) and serve as the target of the action. It has always been a challenge to mirror the semantics of these implementation details that are effectively derived from the Ember 1.x rendering engine. We believe they are very close, but if they change, we encourage you to open an issue.

Glimmer, through HTMLBars, has a clearer concept of “scope”, as well as {{yield}} Use the scope object directly.We were able to pass the Ember test suite by implementing the old semantics on top of the new scope concept, but We are aware that we have gaps in implementation.

If you find controller semantics that we have not implemented correctly, please let us know. Bug reports will help, JSBins will help, and pull requests with failed tests will help.

Finally, for the best experience of Glimmer, you should try to change your app from itemController, {{render}} And other structures from the template operation controller. We know this is not always possible (our application still uses these features in some cases), which is why we work so hard on compatibility.

In other words, if you eliminate the use of these functions as soon as possible, you will get better performance and a faster way to upgrade to 2.0. Implementing them correctly adds enough complexity, and we hope to move slightly aggressively in 2.x so that we can further improve performance.

Leave a Reply

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