Godfrey Chan @chancancode | GitHub | Tilde Inc.

CHARLES: Hello, everybody and welcome to The Frontside Podcast Episode 53, brought to you by The Frontside where we engineer user experience that is just so. If that's something that you're interested in, please feel free to reach out to us on either Twitter or at contact at the Frontside.io. Today we have a really fun episode. Again, we're second week in a row, we've got a nice fat panel. Jeffrey Cherewaty and Chris Freeman, who are developers here at The Frontside and we're also here with Godfrey Chan. Just a little bit of background on Godfrey, from my perspective, I remember very distinctly back in EmberConf 2014, I went out to dinner and I sat across from this guy who was the organizer of the Vancouver Ember Meetup. Was it Vancouver?

GODFREY: Yeah, that is correct, Vancouver, BC.

CHARLES: Yeah, Vancouver, BC. You know, I was struck at the time and I was like, "Wow, this guy is really smart and insightful and actually making me laugh a lot."

GODFREY: You're very kind.

CHARLES: I don't know if you remember that but that was borne out at the next EmberConf in 2015 where he gave this fantastic talk on the power of Ember Data's adapter and serializer layer, where he repeated the same trick except at scale in front of the audience. I think we were all rolling in our chairs with laughter but also learning a lot about this really, really powerful pattern and you had written serializer and adapter layer to basically build without a back end at all, a completely new UI for Hacker News. It was really a fantastic talk.

Since then, you've just been going on to do a bunch of other great things: you joined the Rails core team, the Ember core team, and most recently, it sounds like the major thrust of what the last year or so has been giving birth to Glimmer 2, which is the next generation of the rendering engine in the Ember.js framework. It’s a really fascinating topic. Thanks, Godfrey for coming on and talking with us about this.

GODFREY: Thank you for having me.

CHARLES: Yeah, it's a huge deep topic so we're just going to scratch the surface. Obviously, can't cover a year of life in just under an hour but we're going to do our best. Why don't we talk just a little bit about what Glimmer 2 is? For our audience members who are deeply involved with Ember community, it probably is not going to come as a surprise but we actually do have other listeners. What is it and why is it important?

GODFREY: Like all good software, Glimmer 2 was basically born out of an accident. Glimmer 2 on a very high level is the new rendering engine for Ember. That's pretty vague but I guess, we'll go back a little bit in terms of the timeline and maybe that would become more clear. The time frame was pretty much when I first joined Tilde, we shipped 1.14 for a while and we just about to ship 2.0. That’s when the original Glimmer planned it.

That year at EmberConf, I believe it summer of 2015, like Tom and Yehuda talk about this new Glimmer thing on stage that has promised to basically renew the Ember programming model to better match the data down, actions up paradigm as opposed to very reliant on to a bindings and stuff like that.

On one hand, it gives you better programming model and on the other hand it's promised to be much faster at rerendering. It’s more or less inspired by React so you can just treat your component as if it's refreshing a page on a server-rendered HTML or something like that. You can just update your data and then rerender a component and that's going to be efficient enough that you can just basically rely on that as the main fully-rendered model.

That ship in 1.14, for most part it was great so we were planning to start working on the next thing and at that time, the plan was to work on rehydration. If you're not very familiar with it, it's basically the next iteration of FastBoot where today when you have a FastBoot render page, when it goes [inaudible] has to then download JavaScript the data and rerender the page basically for the DOM then re-insert the newly rendered content into the page.

There are several problems with that. First of all, it's a lot of wasted work because you already rendered all the HTML on the server side and now you're re-doing the work and you’re framing them away. Also your users will probably see a brief flash because you're deleting the old DOM and you're replacing with a new DOM. You probably lose important things like [inaudible] position and probably not the most performant way to do that also. That’s what we're going to work on next. Basically, allow the rendering engine to instead of rendering a new DOM, just rehydrate the existing markup that was sent by the server and just wire up the thing so it can be updated further on the client side.

CHARLES: What I'm hearing is that the original Glimmer that was introduced in 2015, it had to always assume starting from a zero state. It couldn't take an existing DOM and kind of converge.

GODFREY: Right. That's still true today. I wouldn't say that the rendering engine is not capable. It’s just that the feature was not written yet, at the time we were about to start writing that feature. It took us maybe a week or two spiking on it. We got something working like as we go for that exercise, I was basically new to the code base at the time so Yehuda was explaining a lot of things to me. We were pairing basically full time at that time.

If you know Yehuda, he also travels a lot. He has a lot of other responsibility like [inaudible]. We basically paired for a few days and then he might go on a short trip or I might go on a short trip for a conference or whatever. Then we'll come back and then it was like, "Wait a minute." I basically forgotten most of the things so we have to go through the concepts again. That was a little bit painful.

On the other hand, the code was not really that well-rationalized or well-structured. It's a relatively old code base or at least in terms of JavaScript age, the original Glimmer 1 was basically bolted on top of what we were using at the time, which is HTMLbars engine where we can perhaps go into a little bit more details on that later. But basically, the engine was not really designed for a lot of those so it was getting a little bit difficult.

Separately on another fret, a lot of things is going on at the same time, we’re getting more reports on performance regression on Glimmer 1, which is probably a little bit surprising because the whole point of Glimmer 1 was introduce a new algorithm to make things faster. That’s the big promise of the original Glimmer but it turns out that, indeed we rerender performance a lot faster. However, because it was so slow before, basically a no one used that feature ever so the existing apps are not getting any of the benefits because you would have to do a lot of refactor to take advantage of new programming model.

However, you have existing code that you're using in production. Those code did not used new programming model, did not get any of the benefit. On top of that, it turns out that even though we have this superior algorithm in Glimmer 1, we inadvertently regressed it the initial render performance for components. That’s not a tradeoff that we explicitly made. It's just that we wrote a lot of new code and we were mostly focusing on making the rerender pass as fast as possible.

By the time were done, everything seems fine, we shipped but in the wild, people reported, "It turns out the thing I care about just got slower," and because it's not like a design decision that trade off that would made, we don't actually know what's going on like we have a lot of new codes somehow, that made thing slower when you do investigate.

Basically, at that time, we had to polish our work on rehydration and focus more on performance. As we dug deeper into this rabbit hole, it turns out one of the main thing that happened was how we handle blocks. In the handlebars template, you have a pound or a hash, like let's say, '#if' and then if something and there's a block in there then you do slash if, that's blocked in handlebars.

It turns out we made some significant changes in how that works and blocks got significantly slower for some reason and you can see that by comparing the performance between the block form of the if-helper, like #if, blah-blah-blah, versus the equivalent of the inline form just the curly-curly, if something then show render a string, otherwise render some under string so if you compared to those two versions, they really should be the same thing. They are not functionally any different but if you compare the render and performance between the two versions, it turns out the block version is like in order of magnitude slower, for some reason.

That’s bad because it turns out we also made some changes to how components work and each component has at least two hidden blocks that you can't see. It were like basically, how the tech name and stuff were rendered so these components, some blocks and blocks got a lot slower so the end result is component initial rendering got slower. That’s unfortunate because that's probably one of the most useful feature of Ember or any view [inaudible]. Like on a client side, the way I like to think about it is like if you're writing code and if you've a really long function you probably want to break it down to smaller function for your own sanity.

I think components serve a similar role in your templates, like when your template are really big, you probably want to split them into some more modular or hopefully reusable components. If nothing else, just break it down to smaller chunks so you can reason about it.

Components are really important and the community is really starting to pick up the idea of components around that time. Unfortunately, we made a change that made components slower so we have to do something about it. That’s more or less why Glimmer 2 happened like you're starting out as an investigation into why components got slower, what can we do to make it faster and deeper? We take down on that rabbit hole.

We found more things about the HTMLbars engine that is not very aligned with the way we want things to work, which makes it more inefficient than we will like. Basically, it turns out as an effort to realign how the engine actually works with who we actually do with the engine. It start up very incremental and at some point, several things happen that basically cost it to become a complete rewrite. That’s basically the backstory of Glimmer 2.

CHARLES: Now, here we are, there are these fundamental problems with Glimmer 1 that you can't get to where it is that you want to go, which sounds like these set of optimizations so a rewrite is underway. What were the key things that needed to change in order to make this happen?

GODFREY: The overarching theme is basically the original rendering engine. There’s not much of a rendering engine to speak off. I think at the time, we don't really fully understand what our requirements are. We don't really know what our needs are so we built something very, very flexible. That’s basically HTMLbars and it's kind of self-evident at this because we could take HTMLbars and retrofit the Glimmer 1 [inaudible] from on top.

HTMLbars is literally just handlebars plus HTML. It's capable of rendering static HTML and every time it sees a double curly or a mustache, as we would call in handlebars, like every time you see open double curly braces, it provides a set of hooks for you to hook into that process. Every time you see curly-curly, what happens? It says, "This is a block or this is an inline helper," and it just delegate to Ember to, "Please tell me what to do next." That's basically handlebars.

CHARLES: If I can kind of interject a question because I think this is kind of a source of confusion, certainly for me. What is exactly the relationship between handlebars.js, like if you go to handlebars.js, the GitHub organization, it is a separate code base, is that just a parser and a syntax? What exactly do the individual libraries contribute? Because we have handlebars.js, HTMLbars, Glimmer 1, Glimmer 2. I think it's a source of confusion that's how are these composed to work in tandem or in tridem when I actually use Ember. Because I know there's people who use handlebars.js that have nothing to do with the Ember community so what's the relationship there?

GODFREY: Right. There's handlebars, the language, so to speak and there's handlebars.js, the library. Handlebars is basically just a string templating language. The word 'templating' is probably more confusing than it helps in this context but it's a fancy string interpolation. In JavaScript now, I guess in ES6 you can do it or in Ruby, you have special notations and string to interpolate things. Handlebars is a platform independent language for writing interpolated strings. It has some fancy features like helpers and stuff. But at the very core, it's a way to write really long interpolated strings.

Handlebars.js is the JavaScript bindings for that language. As I said, handlebars itself is platform independent but if you have a helper and handlebars like you need to be able to write code for that helper somehow and handlebars.js is the binding that let you write those helper functions in JavaScript.

Handlebars.js indeed has a parser in there so you can give it a handlebars template and it would parse into NAST for you. It also has a small runtime library that allow you to register helpers and stuff like that. That’s handlebars.js.

CHARLES: And HTMLbars is using handlebars.js?

GODFREY: In some sense, yes. The original Ember up to 1.10 or something like that, actually uses handlebars.js. It used to be that. We actually do everything as string templates. We just interpolate the string and more or less, just set 'element.' in HTML equals '.string' and that's how Ember used to render things on a screen.

Now, HTMLbars does use a part of that pipeline, specifically uses the handlebars parser. How it actually works is there are two possible orders and maybe in the middle of this, I realized I was wrong and it's actually the other order. But I believe how it works, let's say you have an a HTMLbars template or just .hps file in your Ember app, you basically run that through the handlebars parser so you get this some string and then there's some curly mustache here and maybe this is a helper, this is a block, this is whatever.

Then I believe we then take all the text notes in the handlebars-jst and then we parse that as HTML tokens. Basically, if you have user.firstname, let's say, and close curly-curly, closed diff, that will basically end up being parsed into a combine jst of this open element of diff and then there's a mustache of user.firstname and then there is a close element of diff. That's the extent that HTMLbars uses handlebars so basically, it uses the handlebars parser to help with some of the work.

Now, the part I said I always get wrong is either, you parse it through your handlebars first and then you parse the HTML inside the handlebar-jst or you parse the HTML first and then you use handlebars to parse the curlies inside the HTML-jst. I'm pretty sure we do the handlebars thing first but I'm still not 100% sure. One way or the other, if it turns let's say it parses handlebars first, if it turns out that I'm wrong, I'll probably sent a tweet or something after the show. Does that answer your question? Does that make it more clear?

CHARLES: It does because I was always kind of wondering, does Glimmer and Glimmer 2 include its own completely separate implementation of handlebars or not and I think it answer the question of where that boundary lies.

GODFREY: Right. Actually, there's a minor detail. I think we're actually on the older version of handlebars. I think there are some new handlebars feature that we need to reconcile. But for the most part, yes, we use the handlebars parser and that's basically the part of the handlebars.js we actually use.

JEFFREY: That leads to talking about we used the handlebars parser at the bottom layer. How do you maintain that compatibility? Do you want to have a really great upgrade path from using HTMLbars as the renderer to using Glimmer 1 or 2 as the renderer? Would you talk a little bit about how you maintain that [inaudible] and compatibility?

GODFREY: Actually, the handlebars parser part is probably the least interesting part in terms of compatibility. When we did Glimmer 1, I'm kind of speaking as outsider person here because I was not super involved at that time. But from what I hear, after EmberConf 2015, there was a website called IsEmberFastYet.com. It basically count down the number of failing test.

Glimmer 1 was kind of a similar situation in that. It was still using the same HTMLbars library and it was part of 1.14 so it still maintained support for a lot of the legacy features like Ember.View and things like that. It's 'easy' in a sense that most of the test are still applicable so more or less, you just rewrite the code and you keep running to test and see what passes or what fails. Then when everything is green, you ship. That’s the Glimmer 1 story.

However, the devil is in the details. The tricky thing is at the time the test coverage is not very good. As it turns out passing on to test isn't really mean a whole lot so the difficulty in Glimmer 1 is you don't even know who your enemy is really. Not a lot of ways to find out if it actually did the job or not, other than actually just shipping it. As you ship, people start to report a lot of bugs and we're like, "Oh, crap. Actually, this is not tested at all so now we need to fix it." That went on for a long time really.

If you actually look at the release history of 1.14, probably have the most number of point releases and that's probably the biggest divergence we ever had from the six weeks release cycle.

Unfortunately, what the software is supposed to do is it's unspecified at the time, at least in terms of actual tests so it was a long process and somewhat painful process for the community to figure out what we actually need to support. That was the 1.14 transition. Unfortunately, some apps are still stuck on 1.14 today because of that, because some add-ons or some part of the code bases using some of the features that were previously undocumented or unspecified and it doesn't work on Glimmer 1 anymore. That’s Glimmer 1.

After that transition, we have a much better test coverage story to work with when we did Glimmer 2. However on the other hand, we actually rewrote the entire engine and also in leading up to that, we actually drop a lot of the legacy Ember features. The test coverage we previously have is useful to have but they're also pretty outdated. Concrete example of that is most of the tests previously written was written in terms of [inaudible] that's no longer a thing in [inaudible] Ember but all of the tests use views internally to test things.

The first thing we actually need to do when we try to integrate Glimmer 2 is to port all of those tests, update all these tests and make sure they're still meaningful and modernized them. That was actually a huge task. Thankfully, it's also a task that's very paralyzable. The first thing we did, Yehuda and I spend some time porting those tests and Yehuda being Yehuda we actually spend some time making a really nice abstraction, a really nice test harness for doing that so we started porting some of those tests.

But as we start doing that, we realized this is a lot of test to port. Fortunately, it's very paralyzable so what I did was I spent some time writing this really long issue and now are known as The Quest Issue for Glimmer 2, which outline, I for one, this is what we are trying to accomplish. This is going to be a lot of work but fortunately, the work is pretty mechanical or at least the transformation is pretty easy to describe in words. I did that. I described the work that needs to be done and we invited the community to help along.

Let's see, that Issue# 13127 on the Ember report. That’s known as The Quest Issue and basically, it have a checklist of all the test that still needs to be ported. Surprisingly, a lot of people were really into that, like a lot of people turns out were interested in contributing to Ember but didn't know where to start. This Quest Issue end up being a very good place for someone new to Ember to start contributing.

We got a lot of response from that and within a relatively short amount of time, certainly much less than what we would have spent time doing it ourselves. In the relatively short amount of time, all tests were ported. I think that was one of the most successful call-for-help in the history of Ember or even in the history of open source software that I am personally involved with.

As part of that too, by doing the harness, we actually introduced much more rigorous approach to testing things. In that process, the test coverage is probably increased several faults as well. With that, we were able to have a relatively high confidence that once all the tests are passing, that we are certainly in a very, very good shape. There might still be some unspecified behavior like there will always be some of them. But I think given the Glimmer 1 transition and also given the new style of testing, that is a lot more rigorous than before, we certainly did that much, much better compared to a Glimmer 1.

After doing the original Glimmer 1 and even further back, we start with handlebars and then we wrote HTMLbars, then we wrote Glimmer 1, by now we're actually have a pretty good picture of what we actually trying to accomplish here. The requirements is becoming more clear and at the same time, we have a much better or much clearer model to work with on the Ember side because we got rid of a lot of the legacy features in the transition into Ember 2.0.

HTMLbars started off as a very generic library that allow you to add behavior on top of HTML and handlebars. Glimmer 1 was basically loaded on thing using those very generic infrastructure to implement the algorithm we actually want. It turns out that we actually know what we're doing now. We don't need a super generic infrastructure for this so let's make it more tailor-fit thing for the requirements we actually have.

An example of that is in HTMLbars, there is no concept of components. There's only thing called block helpers or either inline helpers or block helpers and what happens is every time you see curly-curly something and then you call into Ember, "I found a curly-curly, please do whatever you wish with this," and then we checked and, "It turned out this thing has a dash in there so probably a component. Let me try to resolve that. It turns out it actually is a component so now please synthesize some things and callback into HTMLbars library. This is the thing I actually want to render. Please do it."

In Glimmer 2, actually component is pretty fundamental feature so let's build it into the rendering engine. Hopefully that would give you a better idea of what I actually mean by relying the engine with what we actually want. We know we have a pretty good specification of the problem now so we will build the thing that solves that specific problem. When I say, let's build components into Glimmer, it's not even a very concrete thing, like I don't mean the current syntax that happens to be Ember or the hypothetical angle bracket component syntax that's coming to Ember. It is just a very generic concept like there's a thing called component. It’s like function calls but in templates. Let’s make sure we have a good support off that. Basically, the more the engine knows, the better we are able to optimize that.

Previously it's like, it turns out there's a helper-ish thing here so I guess the only thing we need to do is to hand it back into Ember and let it do whatever it wants. Now, the engine actually knows that this is a component so let's try to figure out how we can optimize this component invocation based on what else we know about the arguments and things like that. That’s basically the motivation or the design behind Glimmer 2.

CHARLES: Right. It’s amazing that you find this pattern, kind of cropping up again and again in software where less really is more. The more assumptions that you can make, you can often make the underlying system more powerful. It’s kind of counterintuitive because we want to think we want to make everything super flexible and can handle every single case. But it turns out that if you can eliminate a bunch of cases just out of hand, then you're going to have more power.

One of the things that I'm curious about is it sounds like a lot of the motivation has been around performance, making sure that initial render is performant and not just a rerender. I'm kind of curious, what nonperformance related features is this going to unlock? This has been a while coming, Glimmer 2 land in what? 2.10?

GODFREY: That sounds about right.

CHARLES: Looking forward, what are some of the things that we can expect or what are the kind of cool features that this is going to unlock? What's the potential that we're going to see and realized kind of over the next few years based on this work that's been done?

GODFREY: In a very technical sense, there are not necessarily a lot of features that are absolutely blocked in a very narrow sense of the works. However, as I mentioned before, everyone kind of felt the same way about the previous code base. Basically, the complexity is getting a little bit out of control like it's so super generic that the things are so spread out across different libraries that's really hard to work with. It’s really hard to add new features.

All the rendering related features are kind of put on hold as we work on Glimmer 2 because everyone knew that this better code base that's going to come along pretty soon. If we were to do anything significant, we should probably wait for that to finish. The good news is that has finished now and I think most people would agree that code base is in a much, much better shape now.

In that sense, it unblocks a lot of work, both in terms of this lock that has been released but it's also in the sense that as we design Glimmer 2, we have all those things in the back of mind and we basically make sure the engine has good support for building out those features. Some of the things that are in the pipeline is I guess rehydration. We basically paused like Glimmer 2 spun off that but we never got back to finishing that work. I would say that's coming.

There is angle bracket components. This is actually interesting in that. I think the plan for it to land has changed a little bit. I don't know how much I'm supposed to- Well, there are actually not a lot of secrets but just that someone's in the middle of writing out those RFCs. I don't know if I should [inaudible] shout too much of that. But as I mentioned before, Glimmer 2, the engine has pretty good support for components out of the box, like it's a pretty generic concept of component that's not necessarily tied to a particular syntax and even particular feature set. It's not tied to a particular component API, like this is not forcing you to have a specific base class and stuff.

A lot of the features in Ember, like the mount keyword for engines or outlets in Ember or the render helper in Ember, all of those are actually implemented as 'components' under the hood, inside the engine even though they're pretty different things from the curly bracket component that you're used to in Ember today.

I think there's a rough consensus on this, like I said, the RC is still in progress so a lot of these things can change but I believe the plan is we'll try to stabilize the core component primitive in the Glimmer 2 engine, that basically let you implement your own component API however you want as a very low level feature. If you remember how we implement the engine, it's kind of similar. We stabilized the core primitives for making engines work under an Ember and then we have an official Ember engines add-on that uses those primitive to provide the actual user-facing API when you want to support.

I believe angle bracket component would be similar in that. We would try to stabilize the core primitive of implementing components in the Glimmer engine, then we'll iterate on the new Ember component API, probably as an add-on or something like that. We can get more people to try it and improve the API before actually land that as a core feature in Ember.

CHARLES: What I'm hearing is there's actually the potential here to treat the kind of the core component API as an extension point like if I want to define my own different set of semantics and lifecycle hooks and what have you for my special components within my add-on or my Ember application, I could do that and yet have it exist alongside kind of standard components.

GODFREY: Exactly. It’s a pretty low-level API and I don't think most users would want to go for that. But I think it unlocks a lot of potential for add-on and things like that. Because as I previously mentioned, the [inaudible] in Ember is implemented using that API to render helpers, implement using that API so hopefully you can imagine there are probably something that people really wanted to do and add-on step could be made possible with that low-level API.

It might not even look like a component. It could be things like you do in Liquid Fire. I think, [inaudible] has a suite of add-ons that provide some pretty events rendering features that could fall under that umbrella. Basically, it's just opens up a pretty powerful low-level primitive that add-on authors can use to implement the features they want but at the same time, also allow us to iterate on that.

I don't imagine a future where literally everyone is building their own component API. I think we would still, as a community have basically this system main kind of component you use in Ember but for whatever special case you have, you can drop down to the low-level and do whatever you want.

CHARLES: Right, and at least that area for experimentation and innovation is at least there.

GODFREY: Right.

CHARLES: That actually kind of brings to mind a very specific case that I was thinking about so I kind of throw this at you as a very friendly curveball that like this is something that you could conceive of being possible. I recently was working on an Ember application with my dad and there were some visualizations. Originally, I was doing these visualizations in D3 and it was cumbersome as D3 code can actually get.

The part where you actually compute the D3 scales and the SVG attributes in D3 is very concise but the actual D3 rendering code can be very verbose and can kind of degenerate into this jQuery type like soup. What I did as kind of a first pass is I separated the computations and the slicing and the dicing of the data in D3 and presented those to a simple HTMLbars template as computed properties of a component so I had done all the computation around the visualisation in my Ember component. But then for the template, I used just a simple SVG template and it was beautiful. It was this pretty complex SVG visualization fit into, I want to say, less than 20 lines so you could perceive the entire visualization in one standard editor window, which if you've done a lot of D3 code is actually hard to achieve.

When I saw that and I promise I'm going to make a point here, I was like, "Wow, this is like a powerful concept." I feel like this is the way that we ought to be doing SVG visualizations. But the thing that I lost was the thing that kind of this special sauce of D3, which is I wasn't using D3 to actually do the rendering. I was just doing it for the computation so I didn't get those really sweet transitions.

One of the sweetest concepts the D3 has is this join model where when you make a change and you push a new set of elements onto the visualization, it computes for you the SVG, the actual DOM elements that are leaving, the ones that are entering and the ones that are updating.

I was thinking, "Gosh, it would be really great if there was some way to hook into that inside of Ember," and I'm just kind of curious would such a thing be possible to actually get hooks on the low-level elements? Because essentially, that's what a dom-diff is, which elements are leaving, which ones are coming in, and which ones are changing. Would it be possible to have those hooks with Glimmer 2?

GODFREY: I think it's definitely possible. I don't know how much of that you can actually do right away in the current code base but I think conceptually, that makes a lot of sense and that's definitely something that we should have support for, if we can already do that today. What can be adapt was I haven't spent a lot of time doing animations myself, but I would say that makes a lot of sense. I hope most of that is already achievable today. But if not, we should definitely make it happen.

I think a lot of people didn't realize but we actually spend a significant amount of time on our end, making sure that we have good support for SVG. We do have a spec compliant HTML parser and stuff so it's actually rendering SVG with Glimmer or with Ember, which is actually really nice. We have some of those animations or visualization stuff in Skylight and we actually take a similar approach where we actually have SVG templates and we just use Ember to fill in the dynamic data and we have some, I believe, JavaScript code to do the animation but we should definitely talk more about that topic and making sure it's solid.

CHARLES: You know, I can't reiterate how sweet it feels to do as SVG. Really, when I kind of stumbled upon it, I was like, "Wow, man. Someone needs to do this more."

GODFREY: I believe in the latest iteration of D3, they actually broke up the library into pieces that makes some of those things much more easier. I think that's definitely at direction that everyone wants to have to work.

CHRIS: I know that you talked about that there are people writing RFCs and EmberConf is coming up so I'm assuming that there are possibly some things that are going to be talked about there. But one of the things that has really kind of floated around Glimmer 2 ever since last year's EmberConf is that in terms of the next leap forward for Ember, Glimmer 2 was often pointed to as the blocking thing.

You know, angle bracket components, a lot of other features that people would like to see in Ember, a lot of it seemed to be bound up and Glimmer 2 was going to unlock a lot of these things for us. I'm curious for an end user of Ember, what is Glimmer 2 really mean for them in terms of the next six months to a year? Are there a lot of things that are planning to be unlocked by Glimmer 2? Or is it going to be much more of an incremental progress? Or do we actually know everything that's going to be unlocked at this point?

GODFREY: I think it's a combination of all of those. Like I said earlier, there are probably features that along the lines of the angle bracket component or the low-level component primitives rehydration. There is also this concept of chunk rendering in that, basically, do as much rendering as possible without making a significant pause on the UI [inaudible] and then yields expected browser for user interaction and then go back to rendering more stuff and repeat that until you're done.

The net effect is you basically, don't block scrolling and things like that for a significant amount of time. Even though, your initial render might actually take more than the 60 FPS or whatever time frame you have allocated. Also, performance in general, I think we're very much not done here. We're just getting started. We have a much better engine to work with and there are a lot of further optimizations that we want to do so now, that we've shipped with completed compatibility, we climb in, more or less I think everyone is excited to get back on to those things that they were previously working on.

CHRIS: Another one I have seen kind of reference a couple times, especially by Tom is Glimmer components and Ember CLI as kind of like a lightweight Ember without all of Ember. Even if you poke around the Glimmer repos, a lot of benchmarks that you can see a version of [e] components that don't yet exist, you see TypeScript, you see ES6 extends Glimmer component.

A lot of things that I know people would be absolutely thrilled to see in Ember, a standalone Glimmer like planned to be a thing at all and like [inaudible] syntax, like ES6 class components is that as they make Glimmer 2 unlocks it all or are there other things that are blocking that?

GODFREY: Yes, all of those are definitely in the pipeline. Standalone Glimmer is interesting. As you mentioned, Tom and several other people have started experimenting with that today. I think Tom talked about it in his EmberCamp London keynote this year or last year -- 2016. If you haven't seen that, you can definitely go check that out. It's not something I would recommend doing today in production just because there are a lot of [inaudible] in the code base still so we need to stabilize that. Literally, when I went on vacation for the last three weeks, you could basically rewrote the entire VM. It's some work that we have been talking about for a long time and he basically end up having some free time to check on that. Everyday changed after I came back from vacation so if you do that today, that's probably what you would have to deal with in the foreseeable future in the next few months.

But I think we are definitely working towards making that more stable so we can enable the kind of things that Tom is doing. Part of it is definitely we need to make it easier. Currently, Tom has to do a lot of work to make that happen and Ember CLI has to be a core part of the story and etcetera, etcetera. But I think a lot of people were definitely working towards that goal.

In terms of TypeScript ES6, TypeScript is actually pretty interesting. It's kind of another happy accident that came out of the Glimmer 2 rewrite. As I mentioned at the beginning, when I was new to HTMLbars code base, there are so many concepts and Yehuda and I both travelling a lot at the time so every time we reconvene, it was like, "Wait a minute. I forgot to read things so let's actually take the whiteboard and write down all these things here permanently so I won't forget them."

As we start to do that, it was like, "Actually this is very complicated to write on the whiteboard so let's just write out the types somewhere," not in a very rigid sense but just, "Oh, there's this thing called render node and this is basically the responsibility. These are the methods on that thing and these are the fields on that thing."

As you write that you would probably want to remember, "Oh, this is actually a string or this is an object with these sub-properties," and as we actually tried to do that, it was like, "Wow, we should not actually invent." We either have to invent a notation for that or we could just use a notation that people have made for this purpose already so let's just go to the TypeScript playground and type it out there.

Then that turned out to be great but it's not that amazing to write. Many interfaces in the browser so let's just go back to the editor window and type in there and it turns out TypeScript is written in a way that all [inaudible] JavaScript is fellow TypeScript. Basically, a superset of JavaScript.

Eventually what we ended up doing is we just went through an entire code base and renamed all of the JavaScript file to .ts, then we made a commit of that. Incrementally, we end up switching the entire code base to TypeScript and that's actually how it happened. In terms of using TypeScript and ES6 classes and Ember is probably block by few RFCs. There are probably some design work needed there but I would say that’s happening. I don't know how close it is but just because there are a lot of things in the pipeline right in it. But I think it's a relatively high [inaudible].

CHARLES: Before we wrap up, we had some great listener questions that came in over Twitter. I want to put those to you. The first one comes from Elrich R and the question is, "What are the performance gains on mobile for Glimmer 2? How does this better position Ember for mobile development?

GODFREY: I think the short answer is it's faster. As far as how much faster, unfortunately, a really hard question to answer just because it vary so much from app to app. We have some numbers that we have been looking as we develop it but at the end of the day, each app is very, very different and the kind of things that slows your app down might not be very obvious.

There’s a pretty interesting thing that happened when we were [inaudible] Glimmer 2. One day I was checking the Ember communities Slack and someone reported, "I have this list of 1500 items that I'm rendering. I know that's not ideal but it is what it is for now. But I just tried Glimmer 2 and it's really slow. It's taking three seconds to render that list of 1500 rows. Is there something wrong?"

I was like, "That sucks." We tried to make this thing faster but I agree, three seconds is still really slow. I was like, "Can you share your app? Can you check what is the delta? What was the number pre-Glimmer 2?" He's like, "Let me go and check. Actually, it turns out it was 14 seconds pre-Glimmer 2 and it was now three seconds." I was like, "Yeah, okay. I agree that's not great but with 1500 items and we went from 14 seconds down to three seconds, I think I would take that as a win."

Part of it is difference like that, really is how complicated your page is. Also there are a lot of factors that are actually unrelated to rendering, perhaps surprisingly, all of which we're working on but for example, how many routes do you have in your app, actually for some reason, plays a pretty significant role on the initial render timing and also how big your app is and things like that.

I think across the board, it's pretty much faster. As you can see sometimes, it’s 14 seconds, three seconds for small apps. It might be from 500 milliseconds to 400 milliseconds. In Skylight I think, we're seeing anywhere from 7% to 40% overall and we're talking about micro numbers just like everything from download in JavaScript to everything up until the page is interactive. There’s a lot more than rendering going on there but I don't have a good one-size fits-all number for you here. But I think overall it's faster and we'll make it faster still and we'll continue to make it smaller. Hopefully all of that would be meaningful improvement for mobile or even just performance in general, if that's something you care about in your apps.

CHARLES: Yeah, because I understand that the payload size is a lot smaller and that ought to make a huge difference there. The final question is and this one comes from Lauren T, "What is your favorite flavor of Bubble Tea?"

GODFREY: Interesting. I love Bubble Tea but for whatever reason, I'm just not really into milk teas. I know that's what most people go for when they get Bubble Tea and my personal favorite is probably Honey-Lemon Green Tea. That's probably my go to.

CHARLES: That's delicious. I think, I subsisted wholly on those AriZona Iced Tea in 20-ounce cans from about the age of 17 to 18. There might have been a few months where that represented all of my caloric intake.

GODFREY: I think I once bought a one-gallon pack of those from Wal-Mart and unfortunately, the bottle broke in my trunk on my way home so I basically stopped buying those after that.

CHARLES: You get the nice smell of rancid tea. All right-y. We'll thank you so much for coming by Godfrey.

GODFREY: Thank you again for having me.

CHARLES: Yeah, it had been very enlightening. A deep dive into the what the Glimmer 2 is all about, the challenges that you faced of getting there and where we can expect to go now that it's here.

Oh, let me ask one final question before we send it out. Glimmer 2 has been a long process. There's been a lot of hills to climb and I know a lot of people that I've talked to, as part of the community, one of the biggest questions I have is how can I get involved? How can I help? Where can I throw my weight to see this technology blossom and become really, really useful and widely applicable to everybody inside the Ember community? Just in general, where are more of those quests that you just described? Where can people go to find out more to contribute more?

GODFREY: There are several places. First of all, there is the Ember communities Slack and there's [inaudible] Ember channel and there's also a [inaudible] Glimmer channel. I think we might merge them back into a single channel at some point. But currently, those are where people hang out.

In terms of quest issue, actually really counting to it in terms of the time investment versus the payoff. If there's one thing that I wish I did earlier and wish I did more is probably I would have started these quest issues earlier and do more of them. I guess we have to write more of them. But basically, hang on those channels. A lot of times, people asked questions then we try to help them out. A lot of times those end up turning into opportunities for contributions.

It’s kind of like documentation. I don't actually hate writing documentation but it's not the first thing that comes to mind, in terms prioritization. I think writing Quest Issue is kind of like that one. You actually do it, you realized, "Wow, this is actually really helpful and I should do it more," but it's just so counterintuitive that it's often not the first thing in trying to do when I try to prioritize my day. It’s just something I have to keep reminding myself and I appreciate the reminder here that I need to write more on these issues and get more people, empower more people to be able to help.

CHARLES: Alright-y. Well, you heard it folks. Thank you very much and we will see you all next week.