This is the second of a two-part transcript from a recent interview with Tom Dale of Ember.js. In part one we discussed the history and direction of the Ember.js project. Continuing the discussion of the future for Ember.js, this post includes the rest of the interview, primarily focused on the Glimmer.js project. Some of the questions were omitted from these transcriptions for brevity, so we’re also releasing the nearly hour long audio file of the entire interview. Enjoy!
Jonan: Let’s talk about Glimmer 2. If I understand correctly it's released now and it entirely supplants Ember. So how are you planning to gracefully sunset the project?
Terence: I think locks (Ricardo Mendes) talked about how people already have five years of Ember experience, they can now move on to this Glimmer thing, right?
Tom: That's right, yeah. You can put five years of Glimmer experience on your resume, on your LinkedIn profile. You know, something we really wanted to be mindful of is that it's really easy to think that we're giving up on Ember or that we just, declared bankruptcy and we’re starting over again fresh. Because actually, this is what happens in the JavaScript community all the time, right? New version, backwards incompatible, we decided that it was just too clunky to ever fix.
Terence: Right. Angular 1 and Angular 2 thing?
Tom: Something like that, right?
Jonan: And in some cases, that's the right choice.
Terence: Yeah, I think it is.
Jonan: In the first version, there were mistakes made, let's move on. There is no right choice in those circumstances. Maybe it's the only choice that you have.
Tom: Right. So Glimmer is a little bit different. The first thing to understand is that Glimmer is an extraction, it's not a brand-new library.
One piece of feedback that we get all the time is people say, "You know, I would, theoretically, be interested in using Ember but I don’t need all of that stuff. I don’t need a router, I don’t need a data layer. I just want components. I have a Rails app and I just wanna do some kind of interactive widget." People use JQuery, they use React, things that are really easy to drop in, super simple to learn.
So, we thought about it and said, "Well, you know, we actually have this awesome rendering library in this engine called Glimmer. Why don’t we make it available to people who don’t wanna buy into Ember?"
You know it shouldn’t be an all-or-nothing thing. We should try to think about how we can bring incremental value to people. So that's one. It's not a new project. It's an extraction.
The other thing is that I don’t think about Glimmer as being a different project. I think about Glimmer as being a way for us to experiment with the future of the component API in Ember. So one thing that we're working on right now, and actually there is an RFC written by Godfrey Chan, is an API that lets people write plug-ins that implement different component APIs.
Remember, LinkedIn is an Ember app. It’s an Ember app that has had a lot of money and a lot of work put into it, and I promise you, we're not just gonna throw that away and rewrite it in Glimmer.
So we really need to focus on the experience of taking Glimmer components and bringing them into an Ember app; that's what we're working on right now. Glimmer components, I think of it as the future of the Ember component API.
What I would really love is that people can start working on Glimmer applications, see that it has this beautiful UI, it's fast, it's slick, all these things. Then they realize, "Hey, actually, maybe I need Ember data, maybe I need a router?" And then what they'll do is just take these Glimmer components, drag and drop them into their Ember app and, boom, they just work without having to change a line of code.
Jonan: Ember includes a lot of things. It's prepared to handle problems that you can't foresee yet which is one of the benefits of using a framework. But that means that it's larger than maybe you need in the moment. So I could start with a very small Glimmer app, and Glimmer itself is small, right?
Tom: Yeah, it's really small.
Jonan: So the advantage right now though, because we don’t have that component transferability, we can't just take an Ember component and take it into Glimmer today, is that it’s small. You described it as useful for a mobile application. The example you gave in the keynote was a temperature widget that gave the temperature in various cities.
Give us like a real-world use case of Glimmer.
Tom: Sure. I mean I can give you a very real-world use case, which is that before I joined LinkedIn, I was working at this really awesome little startup in New York called Monograph. One of the things Monograph was doing was building these e-commerce apps that were designed to integrate into social media apps.
So one thing that's really amazing about the web that you can't do on native, is you can actually run inside of other apps. You can run inside of Facebook, you can run inside of Twitter, you can run inside of any social media app and that's something that native apps can't do.
What we wanted to do was build this experience that felt very native but it also had to load really, really fast. Because you didn’t get to load it until a user tapped the link. So we actually tried to build a few prototypes in Ember and they actually worked really great on the iPhone, but then we had some investors in Australia on Android phones, and when they tapped on it, it took like 10 seconds to load. That's just not acceptable when you're trying to target these mobile apps.
I said "We have this great entry engine in Ember and it's really small. I wonder if I can hack together something using this?" And the reality was that if we couldn’t, I was gonna have to use something like React or something.
So I told my boss "Give me a week. Give me a week to see if I can do it in Glimmer. I have this crazy idea, let's see if we can do it.", and we actually pulled it off.
We've run a few campaigns now and things have sold out in like an hour. So the model works.
I think if you're building an app that needs a router and uses a data layer, yeah, you should be absolutely using Ember. This is definitely a pared down experience, but my hope is that we're gonna figure out ways of taking these big apps and kind of slicing them up in a way that will be good for mobile.
Jonan: I just want to make sure I’ve got the technical details right here. Ember rendered JavaScript in the past, and now it is rendering bytecode: a series of opcodes that are interpreted on the client side by a couple of different VMs. You have an update VM and you have a render VM. So the first time that you load up a page, you're gonna send over some bytecode and that's gonna be interpreted by this TypeScript VM, the render VM, and then the updates will come into the update VM in the next round? Okay. And so the actual content of this bytecode, what is that?
Tom: It's a JSON object. The reason for that is, of course, JSON is a much smaller subset of the JavaScript language. So they're more compact and they're much faster to parse.
Modern JavaScript VMs are very fast and very good at doing just-in-time compilation to native code. So if we emit JavaScript, those will get compiled into these really fast operations.
The problem that we didn’t realize at the time was that when you have apps that grow, that is a lot of JavaScript, and all that JavaScript gets parsed eagerly. Now you are in the situation where you're spending all this time parsing JavaScript. For some parts of that page, it doesn’t need to get parsed because it never gets rendered.
Jonan: So in the olden days, again, I need to simplify this for my own thinking here. I have a page with a home and an about page, right?
Tom: Mm-hmm.
Jonan: And I don’t ever click on the about tab. But that JavaScript is still there.
Tom: It's still loaded.
Jonan: And it's still interpreted.
Tom: Still parsed, right.
Jonan: And it's not necessary, right?
Tom: Right.
Jonan: So now, in this new world, the JSON blob that represents that about page, if the user never clicks on that link, it never actually has to get turned into anything.
Tom: Right. We keep it in memory, resident in memory as a string, and we just-in-time JSON parse it. And of course, the JSON parsing is gonna be faster than the JavaScript parsing because of the fact that it's so restricted.
Jonan: I see. And so then, you can take that JSON and turn directly into the page that you need. There's no other step there?
Tom: Right.
Jonan: I see, okay.
Tom: So one of the advantages of Handlebars, you know, there's kind of this raging debate about if you should use templates like Ember, and Glimmer, and View, JSDO or should you use JSX like React and all of the stuff React likes.
One of the really nice things about Handlebars is that it's very statically analyzable. We can very easily analyze your template and say, "Okay, these are the components you're using. These are the helpers that you're using. This is the structure." That lets us do more work when you deploy, when you build and that means less work on each user's browser.
Jonan: Right, but then also, as you talked about in your keynote, maybe it comes at the expense of file size in some cases which is another problem that Glimmer solves. Because what you're sending over the wire is actually much smaller now.
Tom: Right. So that was the other downside of doing the compilation with the JavaScript and that’s just the representation. I mean think about JavaScript as a syntax you have, you have functions, and you have var, and you have all of these different things. By creating our JSON structure, we can get that down.
Jonan: So, we've been talking about progressive web apps a lot this year, and there are a lot of things that have happened recently that enabled progressive web apps to actually be a thing. We can now say reliably that you can present an offline experience that is close to the real experience with the possible exception of mobile Safari. I've heard that that's a popular browser.
Tom: It is.
Jonan: Something like 55% of the U.S. market is using an iPhone.
Tom: That's right.
Jonan: So they don’t have service workers that's the problem here, right? I wanna just explain real quick. A service worker, for my own thinking, is this thread that I can run in the background, and I can schedule tasks on it. So it doesn’t even mean you have to have my page open, right?
Tom: Right.
Jonan: I can go and refresh the data that I'm caching locally.
Tom: The most important thing about the service worker, from my perspective, the thing that it unlocked in terms of taking something that usually only the browser can do, is now giving me, as a JavaScript programmer, access to intercepting network requests.
Not just JavaScript but literally, I can have a service worker and if I put an image tag on my page and my service worker is consulted saying, "Hey, we're about to go fetch this image. Would you like to give me a version from cache?"
That is hugely powerful when you're talking about building an offline experience. Because now you have programmatic access to the browser cache, to the way it looks at resources. So now, you have this very powerful abstraction for building whatever caching you want offline.
Jonan: So whatever possible request could be coming from your application is more or less proxied through this server?
Tom: Exactly. So in addition to their request, you also have access to browser cache. So you can put things in, you can take things out. That's what lets you program very specific rules. Because you don’t always wanna say use from the cache, right? Sometimes, there are things that you actually want like how many items in inventory remain, right? You probably don’t want that cached. You probably wanna have the most updated information possible.
Jonan: We don’t have service workers in Safari and we won't for the foreseeable future.
Tom: Well, we don’t have it in Safari but we have it in Firefox and we have it in Chrome. You know, the P in PWA, it stands for Progressive Web App, so you can progressively add this to your application. You know I think the best way to get features into a browser is to adopt them and say "Hey, if you're using an Android phone, you have this really awesome experience. But if you have an iPhone, you know, maybe it's not as awesome."
Apple, I truly believe, really cares about the user experience. If there's one thing I've got from the Safari team is that they always prioritize making a feature fast and not draining the user's battery over being able to check a check mark.
So I actually have a lot of respect for their position, and I think if they do service workers, they're going to do it right. If they see that people are having a better user experience on an Android phone than an iPhone that is hugely motivating for them.
Terence: Does the service worker impact the batteries on phones?
Tom: It could, it could, yeah. I think what browser vendors are going to have to figure out is what is the right heuristic for making sure that we can run a service worker, but only in service of the user, pardon the pun.
How do we make sure that people aren't using it maliciously? How do I make sure this website is not mining bitcoin on your phone and now your battery life is two hours, you know?
Jonan: Sure, yeah.
Tom: It's a really tricky problem.
Jonan: Even if they're relatively innocuous. They don’t necessarily need to be malicious. If you've got a hundred of them and they're all just trying to fetch the same image online, this will dramatically impact your phone's performance.
Tom: Yeah, absolutely. Or if you think about, you know, you install a native app and all of a sudden, you start getting push notifications, that's not great for your battery life either.
Terence: I guess, you talked about progressive web apps in last year’s keynote, what has the uptake been since then? I know it was kind of a work in progress kind of thing, and we just saw two talks yesterday related to progressive web apps.
Tom: Yup.
Terence: So has the adoption been pretty strong within the community?
Tom: Yeah, absolutely. I think people are really excited about it. I think there are so many aspects to progressive web apps, and I think the definition isn't clear exactly. It's one of these terms that people talk about. Sometimes, it becomes more of a buzzword than a very concrete thing. There are a lot of things that you can do on the path to a progressive web app.
So service worker, as Jonan said, is the one thing that people think about the most, but there are also things like server-side rendering, to make sure that the first few bytes that you sent to the user are in service of getting content in front of them. Not just loading your dependency injection library.
Jonan: Right.
Tom: You really wanna get the content first. There's the ability to run offline, there's the ability to add to the home screen as a first-class icon, the ability to do push notifications.
Jonan: Removing the browser chrome, making it feel like a native app experience.
Tom: Yup, and actually, Android has done some really awesome work here to make a progressive web integrate into the operating system such that as a user you can't really tell. That’s the dream.
Jonan: Yeah, of course.
Tom: The community uptake has been phenomenal, and this is exactly one of those things where it's gonna require experimentation. This is a brand new thing. People don’t know the optimal way to use it yet and that experimentation is happening.
There are a ton of Ember add-ons: there are service worker add-ons, there are add-ons for adding an app manifest so you get the icon. All sorts of cool stuff.
I think what we should start thinking about is, "Okay, well what is the mature part of this that we can start baking into the default experience when we make a new Ember app, such that you get a PWA for free?", and I would guess that we are probably on the way there, sometime this year or early next year. Saying that "You just get this really awesome PWA out of the box when you make a new Ember app."
Jonan: That will be fantastic. I would like that very much.
Tom: Defaults are important. I think if you care about the web, especially the mobile web being fast, the highest impact thing you can do is find out what developers are doing today and make the default the right thing.
Terence: So do you imagine in the next couple years, PWA and FastBoot are just going to be baked into new Ember apps?
Tom: I certainly hope so. I don’t think we want to do it before it's ready. FastBoot, in particular of course, introduces a server-side dependency.
One thing that people really like about client side apps is that I don’t need to run my own server, I can just upload to some kind of CDN. That's nice, I don’t like doing ops. That's why I use Heroku so I don’t have to think about ops. So that's the hard thing about server-side rendering, it does introduce computation requirements when you deploy.
So I don’t know if FastBoot will ever be the default per se, but I do know that I want to make it really easy and at least give people the option.
"Hey, server-side rendering is really important for many kinds of apps. Do you wanna turn it on?" The PWA stuff, I think we can do it within the existing parameters of being able to do static deploys, so yeah, let's do it.
Terence: If you have FastBoot on the app it’s totally optional though right?
Tom: Yes, totally optional.
Terence: You can still deploy the assets and ignore FastBoot completely, even if it was part of the standard app, right?
Tom: That's true. Yeah, that's true, and really that, I think, is the beauty of client-side architecture plus server-side rendering. "Oh, my server is over capacity." Well, you can just have your load balancer fall back to the static site, and maybe the user doesn’t get the first view as fast but they still get the full experience.
So much of what FastBoot is, is this conventional way of having not just the server-side rendering but also having a good user experience around it. So much of that relies on the good bits of Ember, the very conventional structure. So I think Glimmer will rapidly support server-side rendering but massaging that into an easy-to-use thing is, I think, an Ember responsibility.
Jonan: The VMs that we're talking about, with the Glimmer on the frontend, the updated render VMs, are written in TypeScript.
Tom: That's right.
Jonan: You mentioned during your keynote that there were some features you added to TypeScript 2.2, or worked with the TypeScript team to add to TypeScript 2.2. and 2.3, to enable Glimmer? Is that me misunderstanding something?
Tom: It's not enabling Glimmer per se, because Glimmer 2 from the beginning has been written in TypeScript. I think when they started TypeScript was on 1.8, so when you make a new Glimmer app, the default is to get TypeScript. That just works out of the box, because the library is written in TypeScript you get awesome code completion, you get intellisense, you get documentation in line, all these things automatically.
I can't say enough positive things about the TypeScript team. They are so professional, they are so responsive. We even asked Daniel Rosenwasser, who is the PM, last week "Hey do you wanna come to EmberConf next week?" "I will come, because I really want to meet the Ember community." They're really, really wonderful.
So for Glimmer, the internals, because it's written in Typescript, there were really no problems. But the thing that they realized is, "Hey, there's actually this long tail of libraries that come from earlier versions of JavaScript like when ES3 and ES5 were kind of cutting edge, that built their own object model on top of JavaScript."
So if you look at Ember for, example, you have the Ember objects model where you have .get and .set, and you have ember.object.extend and ember.object.create. Before we had ES6 classes, we had no choice but to build our own on top of the language. The problem is we need some way to let TypeScript know, "Hey, when we call ember.object.extend, that's not some random method, that's actually defining a type. That's defining a class."
The TypeScript team has been really awesome saying, "Okay, how do we rationalize that and add the extension points where a system like Ember or…" I mean here's the thing. Every JavaScript library from that era has their own system like this, so they've built these really awesome primitives in TypeScript that let you express key types or mapped types.
"Hey, when you see ember.object.extend, we're gonna pass it to POJO, Plain Old JavaScript Object as an argument. That's not just a bag of data. I want you to actually look at the keys inside of that object and treat those like types."
So that's the thing we're really excited about because, of course, you're going to be writing Glimmer apps, you're going to be writing Glimmer components.
You're going to get these really nice TypeScript features but then we don’t want you to have to go back to Ember code and miss those benefits.
Jonan: That's a fantastic feature to have in a language and it's a difficult thing to bring yourself to add, I would imagine, if you're maintaining something like TypeScript. I think this is a smart way to approach the problem.
Tom: Yes.
Jonan: But you're looking at all of these people with their own legacy object models and I have an object model now, and I want people to use the object model that exists in this language. Right?
Tom: Exactly, yes.
Jonan: How do I let you also just roll your own object model? It's a pretty fundamental part of a programming language.
Tom: It is, yeah, and that' what I mean about professionalism. I really, really appreciate the TypeScript team thinking so carefully about adoption, because I think it really requires maturity to do that. How do we bridge the gap, reach people where they are today? And then we can slowly bring them into the new, modern world as they do new things. I think that's hugely important and I think it's one thing that many people in the JavaScript community undervalue. It is such a breath of fresh air to see it from Typescript.
Jonan: That's great.
Terence: Yeah. It seems to align a lot with all the stuff Ember tries to do with the way it does it features.
Jonan: So at the very end of the keynote… You ran a little long on the keynote which is a rare thing to see.
Tom: Yeah, yeah, very rare.
Jonan: This year, you were overtime a little bit and you flipped through some content very quickly at the end. I was hoping maybe you could give us a peek at some of those things you didn’t get time to talk about in your keynote, that you wish you had time to mention.
Tom: I think if we had had more time, one thing I would have really loved to go into more was the Glimmer API. I see the Glimmer API for components being the future of how you do components in Ember, and we have focused really hard on making these things feel like it's just regular JavaScript.
Like I was saying, when Ember came of age, we didn’t have the ES6 classes. We couldn't even use ES5 because it wasn't adopted enough. So we built our own object model on top.
Then rapidly, all of a sudden, the pace of JavaScript's development picked up, and now we have classes, and we have decorators, and we have getters, and we have all these amazing new things. Because it happened right after we stabilized our API, people look at Ember sometimes and think, you know, that feels like they're doing their own weird thing and already know JavaScript. It's like "I don’t wanna do it the Ember way. I wanna do it the JavaScript way."
So what we tried really, really hard to do with Glimmer is say, "Okay, let's think about what someone who only knows JavaScript or modern JavaScript, what do they know and what are they expecting?" And let's just make the whole thing feel easy and natural for them.
So for example, Glimmer component when you define it is just an ES6 class that extends the Glimmer component base class. The way that you import the Glimmer component is a standard import. Then there's a proposal in JavaScript called "decorators," which I believe is stage two. That lets you add certain annotations to properties, and methods, and classes and so on.
Now in Glimmer we have introduced something called "track properties", but more importantly in Glimmer, you don’t actually need any kind of annotation because your computed properties are just getters, which is built in the language. Of course, if you want to do change tracking like "Hey, this computed property changed, how do I update the DOM?" You have a very simple decorator. So you don’t have to have this weird Ember thing, you just do what's in the language.
Jonan: Which is hopefully going to increase adoption.
Tom: I hope so, yeah.
Jonan: This is a common problem, not just in the JavaScript community. You're coming up with new frameworks and you're moving very quickly. JavaScript, in particular, is moving very quickly. It seems like every week, or month, there's some new tool that I would have to learn, right?
Tom: Yeah.
Jonan: Something new and each one of them has their own distinct syntax, constantly changing. If you keep moving the goal post, eventually people tire of it. I consider the approach you took with Glimmer to be a very mature approach, and I really appreciate the effort you put in to make that.
Tom: I think when people see Glimmer, it's very easy for their reaction to be "Oh, god, here comes another JavaScript library." What I hope is that people can look at our track record, and I hope we have some credibility with people, and see that, "Hey, we're not just talking a big game here. We actually have a community that has gone back at least five years. And we have apps that are five years old that have migrated."
So I just hope people can feel safe when they look at Glimmer. It checks all the checklists that you need to check in 2017, but it also comes with the same community and the same core team that really values stability, that values migration, that values convention.
Jonan: And speed.
Tom: Yeah, and speed.
Jonan: I think speed is the real reward from Glimmer. You build something in Glimmer and you, somehow, have accomplished this impossible tradeoff where you have a fast render speed and a fast update speed.
Tom: I think it's interesting too because, you know, this always happens with benchmarks. There's some suite of benchmarks that comes out, people become over-focused on one particular metric.
Jonan: Right.
Tom: In this case, the community, has really focused on, in the last year, initial render performance. Initial render performance is super, super important, but it's not always worth sacrificing updating performance. I think Glimmer has hit this really nice sweet spot where it’s not as absolutely fast as the fastest rendering library, in terms of initial rendering, but it blows away all the other rendering engines at updates.
Being the absolute fastest at initial render is only so important, so long as the user notices. It's not worth sacrificing everything if your constant time is imperceptible to the human, and I'm really excited with that sweet spot that we've hit.
Jonan: We were talking the other day at lunch about the fact that there are some pages where I really don’t mind a long load time. If I'm going to a dashboard for a product that I've already purchased, I'm gonna sit there and wait. Like, yeah, maybe it takes 10 seconds, right, and I'm gonna be super annoyed and think, "Wow, why am I paying these people money?" Right? But for some definition of fast, all things start to be equal, when we get down towards those lower numbers.
Tom: That’s right and I think people conflate those. You know, it's easy to get in a Twitter flame war because I'm talking about my dashboard that people are gonna sit on all day. You're talking about this ecommerce site. If you don’t have a response in under 200 milliseconds, people are gonna bounce and you're not gonna make your money. So those are different categories.
That being said, I really do believe in my heart that there is a future where you can build your big dashboard app and it doesn’t take forever to load if we make the tools really good.
Jonan: Thank you so much for taking the time to talk to us today. I really appreciate it. Do you have anything else you wanna share? Last minute thoughts?
Tom: Oh, I just cannot wait to take a vacation in Barbados for a week.
Jonan: Tom, thank you so much for being here.
Tom: Thank you, Jonan, and thank you, Terence.
Terence: Thank you.