Co-authors: Chad Hietala and Sarah Clatterbuck

Editor’s note: This is a continuation of a two-part series about the Glimmer Virtual Machine used in Ember.js for rendering. The previous post looked at how the AoT compiler stack allowed us to drastically reduce the payload size of all Ember applications by moving to a JSON-based wire format instead of an executable JavaScript program. This post will look at how we use the wire format at runtime within the Ember application.

Additionally, since our first blog post, we're happy to announce that Glimmer is now available as a standalone project that serves as a gateway into the Ember ecosystem.

In the previous blog post, we talked extensively about the advantages of the wire format in terms of template size and load time, but we did not talk about how we convert the wire format into a running application. Unlike DOM reconciliation solutions like React, Glimmer VM is designed like a programming language that uses two subsystems, References and Revision Tags, to make fine-grained updates to dynamic values rendered in the UI. While these subsystems differentiate Glimmer from other solutions, they also are more efficient when compared to previous rendering engines in Ember and other JavaScript frameworks.

Runtime stack

The runtime is a virtual machine (VM) architecture, which is responsible taking the wire format and producing a program that can be run to do the initial render and any subsequent renders. At a high level, the runtime looks like the following: