Everything one can expect in Ember Octane
A few days ago, Tom Dale opened the Ember 2018 Roadmap RFC that set the goals for Ember in 2018. The RFC consisted of three major goals like:
- Improve communication and streamline decision-making, and empower new leaders.
- Finish the major initiatives that have already been started.
- Ship a new edition, Ember Octane, focused on performance and productivity.
In this article we will focus on Ember Octane which is primarily targeted to improve performance of Ember applications for low-end devices and the like.
Some of the primary motivations for Ember Octane came from The 2018 Community Survey, #EmberJS2018 blog posts, Ember Discussion Forum and deliberations among the Ember core teams.
The homepage looks a bit outdated and does not a very compelling job at selling Ember to new users, IMHO. This needs to change.
When you generate a project with
Ember’s custom object model isn’t hard to learn, but it’s a big reason people are turned off before learning why Ember is such a great choce. I’d like to see ES classes support finished and adopted in the Guides ASAP, followed by decorators.
ES6 syntax, the new file layout, new templating etc. — the new features will land in 3.x releases as non-breaking changes, but let’s prepare to show off the sum of all those amazing parts. Sell the vision, right now! A ‘relaunch’ of Ember in the minds of those who dismiss it.
Ember releases a new, stable version every six weeks. For existing users, this reverberation of incremental improvement is easier to keep up with than splashy, big-bang releases.
However, for people not following Ember closely, it’s easy to miss the significant improvements that happen over time. As detailed in the forthcoming Ember Editions RFC (being worked on by Dave Wasmer), every year or so the team will release a new edition of the Ember, focused on a particular theme. The set of improvements related to that theme, taken together, mark a meaningful change to how people should think about Ember.
We can also expect the team to review the new application blueprint, to ensure that it is up-to-date with the latest Ember Octane idioms and includes the right set of addons to help new users achieve our goals of productivity and performance.
Ember Octane is about doing more with less. Not only does this make Ember simpler to learn, it makes the framework smaller and faster, too.
These are some of the highlights of Ember Octane as quoted by Tom Dale in the RFC:
1. No jQuery
Currently available as an optional feature, this will be enabled by default. The process of making jQuery optional started with the Make jQuery optional RFC by Robert Jackson in January this year. For the past Ember has been relying and depending on jQuery. This RFC proposes making jQuery optional and having a well defined way for users to opt-out of bundling jQuery.
Mathias Bynens has demonstrated the major drawback of having jQuery, the increased bundle size, which amounts to ~29KB (minified and gzipped).
2. Svelte builds
“svelte” builds of Ember, are where deprecated but unused code paths in the framework are removed during an application build. The team will get more aggressive about deprecating code that is not widely used. With the eventual introduction of Svelte builds, there will be a mechanism to say “strip out any code for deprecated features from 2.0 to 2.8”.
There is an issue in the official github repository regarding svelte builds with the title [Project Svelte] Deprecation Introduction Hitlist opened by Chad Hietala which highlights some of the ways and approaches to find deprecations and the list of deprecation IDs.
Some preliminary explorations on svelte builds have also taken place among Ember developers some of which can be found in this thread in the Ember Discussion Forum.
You can find some references to svelte builds in this official blog post by Matthew Beale on The Road to Ember 3.0.
4. Glimmer Components
Glimmer is one of the fastest DOM rendering engines, delivering exceptional performance for initial renders as well as updates. Architected like a virtual machine (VM), Glimmer compiles your templates into low-level code so it can run as fast as possible—without sacrificing ease of use. With Ember Octane, Glimmer components offer a greatly simplified API and remove common slow paths.
Glimmer differentiates between static and dynamic components, thus reducing the number of elements that need to be checked when looking for changes. This differentiation can be achieved thanks to the expressiveness of Handlerbar’s templates.
Another key difference between Glimmer and other solutions lies in the way nodes are stored and compared. Glimmer stores nodes as simple stream-like objects (that is, simple queues of values) rather than full-fledged DOM-like nodes. To find out whether a real DOM node needs updating, the final value of a Glimmer node is compared to the last known real DOM value. If the value has not changed, no further actions are taken.
5. Incremental rendering and rehydration
Incremental rendering addresses problems like, to get high levels of animation performance you have to synchronize the DOM (tween stack across the entirety of the animation chain in order to minimize layout thrashing) and skipping style updating when updates would be visually imperceptible.
In React, Fiber takes charge of solving problems like it. Bringing a feature named “incremental rendering” which split rendering work into chunks and spread it out over multiple frames. The new rendering logic allows a better approximation of the principles of an animation.
In traditional way React uses Stack, which is synchronous and recursive. But can’t be split in chunks, have a heavyweight context and other issues. The goal of React Fiber is to increase its suitability for areas like animation, layout, and gestures. Other key features include the ability to pause, abort, or reuse work as new updates come in; the ability to assign priority to different types of updates; and new concurrency primitives.
Incremental rendering: the ability to split rendering work into chunks and spread it out over multiple frames.
Rehydration is more common in frameworks like React where SSR is given an important consideration and with the advent of Ember Fastboot, the concept of rehydration is also becoming a buzzword in the framework arena.
7. Eliminating the runloop
Ember Octane will also focus on eliminating the runloop from the programming model, replaced by async and await in tests.
The final timeline and feature set of Ember Octane will be determined by the Core team and are not set in stone.
Ember Octane will mostly incorporate all features that are either finished or being implemented now, keeping with the commitment to finishing what has been started by the Ember Team. It is recommended that the team will not plan for Octane to have any features that are not already close to being done today, so that they have adequate time to make sure they all work well together as part a cohesive programming model.
The process of releasing a new edition also gives the developers and users an opportunity to evaluate what it’s like to use Ember end-to-end. It is highly likely that the team will overhaul the Ember homepage, focusing on Ember Octane and how it helps solve targeted use cases.
The Ember Team will perform a holistic review of the guides, making sure that examples use the latest idioms and set new learners on a good path.