I think a large portion of what we spent the time on during the 2.0 series - it was a fairly long series… And what we kind of recognized was some of the infrastructure that we have, primarily around the rendering layer, wasn’t going to set us up for success. So around 1.0, or going from 1.13 to 2.0, at EmberConf we talked a little bit about this project called Glimmer. The name has evolved from that point, but what Glimmer was trying to do was modernize the underlying rendering engine. In Ember 1.0 it was primarily doing string concatenation and interpolation with dynamic values… Then towards the tail end of 1.11, or towards the end of the 1.0 series, we released this thing called HTMLBars, which was going from string interpolation into just generating compile templates that were effectively what you would handcraft if you were to write all the DOM methods to construct the DOM, and then there was a system there to keep that DOM up to date.

And then right around that time, that’s when React came out and really made us kind of rethink on like what the programming model should be, and that is like driving all the state through property setting, or in React it’s “set state”, which causes you to basically re-render the entire view. So the first iteration of Glimmer was kind of getting to those similar semantics, and not necessarily using the virtual DOM itself, but the same idea that whenever you need to update the UI, you call this set with a new value, and then you basically have committed that change into the system and then the rendering engine figures out how to most optimally update the view. That was the first version of Glimmer.

Then 2.0 kind of started, and then we realized we wanted to implement what was known as these angle bracket components, which were supposed to be a lighter weight version of what existed in Ember 1.0 and still exists today is these Ember components, these Glimmer components is what we called them, or angle bracket components, were meant to be a lighter weight thing that did have some of the performance issues and APIs that we just don’t really wanna live with anymore, but when we try to implement them on top of this infrastructure, the HTMLBars with these React-like semantics, they weren’t actually faster… So we felt that the underlying architecture made a lot of assumptions on how the old rendering engine worked. That kind of started this big kind of iterative change to figure out what the new rendering engine should look like.

We typically are all about incremental improvements over time, and not do big bang rewrites… So I think Yehuda forked the HTMLBars repo in 2014 or something like that and started working on the next iteration of what we called Glimmer 2.

Glimmer 2 is kind of from the ground-up rearchitecting how we think about the rendering engine from an architectural point of view. Templates themselves are kind of an interesting concept. A template is at its truest form a pure function. You have a template and you have a context, and you mash those two things together and you get some output. Now, if the context and the template are the same, it’s referential transparent, right? If the context doesn’t change, then you’ll get the same output every single time.

So we think about the templating – we’ve changed the focus of how we think about the templating layer from like this thing that creates views and we actually wanted to model the underlying rendering engine as if the template language was an actual programming language. So we think of the templating language now more as a functional language itself, so part of what the Glimmer rendering engine does is that – or it is a virtual machine. So what we do is instead of compiling the template into a bunch of JavaScript code that is then just kind of like called into from JavaScript land and then it produces the DOM, the first iteration of the new Glimmer rendering engine was compiling the templates into a JSON structure, and then we interpreted that at runtime and we compiled into a program that then created the view.

This is a pretty fundamental difference between – where I think a lot of JavaScript frameworks are today is that you have things like JSX, or you have Angular templates, and they’re all compiling into JavaScript and then running it on the client.

One of the founding principles is that we felt that we could make the compiled output much smaller if we compiled to a JSON format, and then interpreted it at runtime. That turned out to be true.

When we did this work and we landed inside of the LinkedIn application, I think we reduced the compiled template size by I think 5x…