Does Glimmer mean the death of Ember? 😱

Glimmer was recently announced by Tom Dale and Yehuda Katz during EmberConf 2017's Keynote. You can get an excellent overview on the main Ember blog which reviewed the EmberConf 2017 State of the Union (which you should absolutely read if you haven't!?), that explains a bit of the history and provides a roadmap of the future.

After the announcement, there was much excitement both in the Ember community and the general JavaScript community, but there was also a hint of worry in the minds of long time users. People have asked me a number of questions since the conference about the Ember / Glimmer relationship, and I think it would be useful to go through them together:

What is "Glimmer"? ✨

The easiest way to explain it is that "Glimmer" (conceptually, not any specific project) is the foundational primitive layer that we use to build Ember. The process is essentially extracting primitives from Ember, into standalone projects with a focus on solid APIs so that we can migrate Ember to use the new project once completed. This has worked incredibly well for Ember users already.

We have been taking advantage of this extract -> iterate -> reintegrate into Ember process since way back in Ember 1.13 where we updated to use the first version of the Glimmer VM (originally codenamed "HTMLBars") as the rendering engine. There were a few bumps along the way, but overall that migration has unlocked many improvements for us with little change to public APIs. For example, in Ember 2.10 we were able to reduce template size by a massive amount. Some applications saw reduced total asset size of 50% while also dramatically increasing the speed of initial rendering.

What was actually announced at EmberConf?

GlimmerJS.com has this to say:

"Fast and light-weight UI components for the web. With the attention to detail you've come to expect from Ember."

The project that was unveiled at EmberConf was the ability to use this new rendering engine independently of Ember. This is a solidification of the APIs that we had already created and support for Ember itself, and now the Glimmer VM has two consumers: Ember and Glimmer. This solidification allows us to continue experimenting and iterating in the render layer in Glimmer all the while bringing those improvements and APIs back to Ember.

Does creating a new framework cause "brain drain" on Ember?

The new standalone Glimmer framework may seem like a diffusion of focus, but in reality it is a proving ground for Ember itself. For example, we have revamped the DI system and resolver so that it support Ember's new project layout and better interops with normal ES2015 classes. We are actively working to migrate Ember to utilize this new system, but while we work on the needed refactors we are also gaining valuable feedback and testing in the wild. The process of focusing on the base primitives will continue to make Ember better.

Why release a standalone rendering framework?

Glimmer appeals to more people than Ember 🎪. It is a good solution for folks trying to add interactive "sprinkles" to their server rendered app 🍩, it helps devs trying to slowly refactor their app to be a SPA 👼, it allows those looking to migrate to an ecosystem focused on both performance 🏃 and developer ergonomics 😻, and it is great for targeting mobile platforms 📱. I could go on, but you get the point 😉.

Being able to use Glimmer on its own provides folks a nice easy on-ramp into Ember. With Glimmer, developers can drop new components into their existing application very easily. While they learn to use Glimmer, they also learn to:

• love our awesome community 💖
• love our community developed solutions ❤️
• love the development ergonomics of the Ember ecosystem (e.g. easy deployment) 💝

Are we going to have two component APIs forever?

This situation probably won't last forever, but the core team hasn't made plans to deprecate or remove current component APIs. Right now the Ember team is focusing on being able to add the new Glimmer component APIs and integrate well with them. The new component API is what we have been dreaming of (cough angle bracket components cough) for quite some time.

Why are you designing an entirely new API that’s different from Ember?

We aren't! 😝 We are designing the APIs that we want in Ember, but developing them outside of Ember so that when we introduce them to Ember they have already been vetted and battle tested.

What does this mean for Ember users?

Quite a lot! The newly released Glimmer component APIs will be available in Ember apps to be used interchangeably with existing Ember components. We will reap the benefits of solidifying APIs, speeding things up, and gaining traction with more audiences. Ember will continue to be a well thought out composition of all the things we (the Ember Core Team) think you need to build applications. Ember users will continue to have a full-featured framework without resorting to manually cobbling all the individual Glimmer libraries together. However, they will gain a new capability: to be able to drop down to a more primitive layer when a given Ember API doesn't meet their needs.

Does the introduction of Glimmer mean the death of Ember?

The answer is very simple: NO‼️

The introduction of Glimmer means that we can build higher, make better abstraction layers, offer bite sized primitives as an escape hatch, and build conventions with a much wider audience.

In short, I believe that the introduction of Glimmer will bring with it a golden age for Ember. Yes, that's right, I said it: a Golden Age... 👑