Hello once again to Readers’ Questions, presented by the Ember.js Times folks with a little help from the core teams 
Today we have a question by Jonathan regarding the future of Glimmer.js:
Will breaking up Ember into components remove the need for the separate Glimmerjs library?
‐ Jonathan
This week’s answer is @ef4. Make sure to read and comment
The short answer is: yes.
Glimmer.js is a small, standalone UI component framework. It’s built on the same underlying rendering system – glimmer-vm – that Ember uses. But since it’s unstable and does less out-of-the-box than Ember, it’s an easier place to experiment with radical improvements to both developer experience and application performance.
Those experiments have been paying off. We’re able to much more confidently propose changes to Ember when those changes are already empirically working well in Glimmer.js. A stream of RFCs are steadily bringing Ember into alignment with Glimmer.js’s components.
- RFC #308 (Deprecate Property Fallback Behavior)
- RFC #298 (Deprecate Component Lifecycle Events)
- RFC #287 (Promote {{-in-element}} to public API)
- RFC #278 (Template-only Components)
- RFC #276 (Named Arguments Syntax (
{{@foo}}))- RFC #240 (ES Classes)
- RFC #213 (Custom Components API)
Ember is already benefiting from performance improvements in glimmer-vm that were made first to support Glimmer.js. And now that we have Glimmer.js as a measurable goal, it’s much easier to show the benefit of deprecating older Ember features that prevent today’s Ember apps from doing everything Glimmer.js apps can do (like statically resolving nearly all components at build time).
As the question alluded to, the next step is making it radically easier to consume Ember piece-by-piece. On the surface, this may seem like just a nice thing for people who want to ship smaller apps, since they can leave out parts they aren’t using. And that is certainly one of the goals. But there is a much more important goal: unlocking a new level of community innovation.
Glimmer.js allowed rapid innovation in a new way to use components. And we are rapidly reintegrating that capability back into Ember proper. We want to do the same thing for many more parts of Ember. For example, I want to make it easy for people to swap out their Router with a new experimental version. That’s the surest way for the community to get empirical experience with new designs, iterate them until they are mature, and then be able to come forward with a rock-solid RFC showing exactly why the new thing should become the Ember default.
We take stability seriously – which means there can be a long lead time between deciding to deprecate some feature and the day when we can drop it from the codebase (at the next major release). This reduces the incentive for people to bother deprecating code in the first place – the payoff is far away. But once we can selectively ship subsets of Ember, it becomes possible to segregate deprecated (or even non-deprecated but rarely-used) code into packages that not everyone needs to use. This lets early adopters benefit immediately, which strengthens in the incentive to do the work in the first place.
This also means that the Glimmer.js use case – apps that only need components and that want to be as small as possible – will be something you can do with Ember, just by taking only the most minimalist set of packages. Once we have an Ember that uses Glimmer components and that can leave out everything but the component system, we have basically reached Glimmer.js and the distinction goes away.
‐ @ef4
This answer was published in Issue #36. Don’t forget to subscribe to the newsletter to get development news right in your inbox. You can also submit your own questions! You will find a link at the bottom of the newsletter.
See you in the next issue!