The Changelog: Software Development, Open Source - Ember four years later (Interview)

Episode Date: April 18, 2018

Chad Hietala joined the show to talk with us about the long history of Ember.js, how he first got involved, his work at LinkedIn and his work as an Ember Core team member, how the Ember team communicates expectations from release to release, their well documented RFC process, ES Classes in Ember, Glimmer, and where Ember is being used today.

Bandwidth for Changelog is provided by Fastly. Learn more at Fastly.com. We move fast and fix things here at Changelog because of Rollbar. Check them out at Rollbar.com and we're hosted on Linode servers. Head to Linode.com slash Changelog. This episode is brought to you by Airbrake. Airbrake is full stack, real-time error monitoring, get real-time error alerts, plus all the info you need to fix any error fast. And in this segment, I'm talking to Joe Godfrey, CEO of Airbrake, about why getting to the root cause of errors

is so important. Look, Adam, to me, root cause is everything. All software has bugs. We all know that. And when you find a bug or when you can't find a bug, the amount of time that typically gets spent trying to chase around and figure out how to reproduce the problem and a bug the amount of time that typically gets spent trying to chase around and figure out how to reproduce the problem and what's the cause of the problem

even like what part of the code kicked it off or what sort of actions drive it i mean that's hours and hours of time wasted spent chasing your tail instead of actually fixing the problem improving the customer experience and getting back to building more features which is really what your company is all about so to me being able understand, like, what is the root cause of this problem is the key factor to being able to solve that problem and get back to doing what's most important, which is building new features and improving your product. And quite frankly, fixing the customer experience is broken as long as that bug is out there. All right. Check out Airbrake at airbrake.io slash changelog. Our list is controlled Airbrake for free for 30 days. Plus, you get 50% off your first three months.

Try it free today. Once again, airbrake.io slash changelog. All right, welcome back. This is the changelog, a podcast featuring the hackers, leaders, and innovators of open source. I'm Adam Stachowiak, editor-in-chief of ChangeLog. On today's show, we talk with Chad Hatel about Ember.js, the long history of Ember, how Chad first got involved, his work at LinkedIn, and his work as an Ember core team member, how the Ember team communicates expectations from release to release very well,

their well-documented RFC process, ES classes in Ember, Glimmer, Glimmer's VM, and also where Ember is being used today. So Chad, it's been a very, very long time since we've talked about Ember on the changelog. In fact, our last episode with members of the Ember team was called The Road to Ember 2.0 with Tom and Yehuda Katz back in November of 2014. 2014? What? Coming up on four years, Ember's still here and kicking, so we have a lot of catching up to do.

But first, let's get to know you a little bit and maybe even look at Ember through your eyes. Tell us how you came to be an Ember core team member. The path for me to getting to the Ember core team was I joined LinkedIn in 2013. And at that time, we were building a lot of applications that were interactive heavy. And so we were using Backbone for this, but a lot of the meetings that we had internally at LinkedIn at the time were many hours like figuring out how to do some of like these very basic patterns, like how to do routing,

how to do child views, how to, you know, efficiently tear down parts of the UI as like the user interacts with it and navigates away from page to page. And what I kind of recognized was that this is a huge cost. This is like we're talking to like 20 people sitting in a room trying to figure out all of these ideas of how to build these applications and kind of these fundamentals. And so I started at LinkedIn looking at, you know, potential solutions to this problem. How can we build these rich applications and kind of up-level people in terms of

what they're actually concerned about. We have a lot of engineers at LinkedIn that are product engineers. And what we want them to be able to do is like build these really great product experiences for people and not spend a whole lot of time of figuring out problems that frankly, I felt were already solved by a variety of frameworks and technologies in the space at the time. So in, let me think, 2014, we did a big internal project Ember was kind of the audience for. And that's kind of like how I got involved in Ember in general is that like we had like a need,

we were building very rich applications. I thought Ember did a very good job at, you know, doing like the routing and like the components and like views and all that type of stuff for the client side application. So, I mean, we're one of the larger consumers of Ember. And because of that, we were like working on the framework and everything like that. So I, we, I got into contact with Tav and Yehuda at the time and they did, i think uh they did a little bit of consulting work with us at the beginning um and we as linkedin we have like specific needs so linkedin pays me and like several other people at linkedin to work on ember and other open source technologies and so you know just by virtue of you know working on larger and larger portions of the open source project, they asked me to join the core team about a year and a half ago.

So that's kind of like how I got involved with the Ember project. And I also was doing a lot of things with like Ember CLI, which I think is what Tom and Yehuda were really excited about when you talked to them in 2014 was Ember CLI. So I worked with Steph Penner on a lot of things early on with Ember CLI. And that was kind of like my kind of getting my feet wet working on somewhat large open source projects. Well, I think we should maybe give credit where credit is due and give props to LinkedIn. What do you think, Adam? We talk about companies putting their money where their source code is, and this is a shining example of LinkedIn really coming alongside a framework that didn't start there.

We see companies like Facebook having React coming out of Facebook, but here's Ember, which pre-exists and exists out in the open source world, has its own ecosystem, and then LinkedIn really buying into it and supporting it for a very long time. Yeah. I mean, from the consulting side on through to now, you know, I think Tom, does Tom still work there? Yeah. Tom is on my team at LinkedIn. Yeah. And it sounds like your employment at LinkedIn predates Tom joining. So you may even be a part of that whole process.

Yeah. Yeah. So I was there basically from the beginning and I'm still there today. I just like celebrated my fifth year at LinkedIn. So I've been there for quite some time. Is it safe to say that the reason that Ember or LinkedIn has gotten involved and supports Ember is because of you? I don't think I would say that. or LinkedIn has gotten involved and supports Ember is because of you?

I don't think I would say that. I think that the business has specific needs and we think that from a core team's perspective is that we want Ember as a framework to cater different size companies, different use cases and everything like that. And this is kind of, I think, one of the luxuries of having everything be open source is that you see all of these different use cases and everything like that. And I think what I brought to the table from an open source perspective is like, you know, rather large company with like hundreds of engineers. How do we, you know, build a company with like hundreds of engineers. How do we, you know, build a better system to suit those types of use cases? Well, one thing that we can say about Ember, I mean, even back when we had Tom and Judah back on in 2014, they were talking about playing the long game. Do you remember that, Adam? I do. And how they were investing for the

long, yeah, for the long term. And one thing that we can say about Ember is it's just continued to iterate, continued to improve. There's been many innovations that have come out of Ember. The focus on the CLI, I think, was huge. There's another one I had on top of my head that I just lost. Glimmer. Glimmer. Yeah, absolutely. The mind share of developers ebbs and flows.

And we've seen other things come along. Angular became big, and now React is very big. And Ember has just continued to be kind of the slow and steady wins the race attitude of just like continuing to push and push and push. And it's kind of a picture of sustainability in that sense. Yeah, I would agree. It's kind of funny sitting here in 2018 and a lot of like these ideas that I think Ember kind of championed early on, things like having a conventional CLI tool were pretty radical, I think, at that point in time. And now like you have Angular CLI, there's a Vue CLI, there's a React CLI tool for kind of like scaffolding out these projects. The other kind of interesting thing is the way that I think Yehuda and others got involved with the standardization process. There's like this manifesto, it's called the Extensible Web Manifesto. I think like multiple people that are pretty prominent in the industry kind of wrote and said that they're going to become part of the actual standardization process. So you had people that weren't like academics or like language designers, but actual practitioners

going and working on the standardization body. And so you kind of see some of those things in how Ember APIs have been created. In the past, they were, I think, very forward looking. And this is one of the things that I'm probably most excited about the Ember 3.0 roadmap. It is like finally having a lot of these things about, or having a lot of the now specced out things to be the mainline APIs inside of Ember. So for example, I think Yehuda has been working on like decorators, ES6 decorators, or if you're familiar with Java, like annotations for like two years now. That looks like it's going to finally land.

And that's kind of the last feature that we need to represent all of Ember's object model in native JavaScript syntax. So the first thing was like, we need like class system that came out in ES6 and Yehuda was very involved with that in the beginning. And now we kind of, we have like this notion of like computer properties which we need like decorators for. So I think within Ember 3.0, we'll definitely see like how this class system that, you know, that when was released was targeting browsers

like IE7, IE8, IE9 that had like no shot of like ever having these JavaScript features and how we have evolved from a class system in those days to the framework that I think everybody would expect you to have in 2018. So using not using basically a, uh, non-user space defined class system, uh, and other APIs like that. So, um, there's other things, other APIs, I think in, in Ember itself, there is like, there's in a whole

enumerability, uh, class and and mixins and everything like that. And those APIs have now been standardized. They're, I think, in IE 10 and forward. So I think it goes to show that not only was Ember early on some of these concepts, the APIs themselves, I think we're ahead of their time and we have just been we're slowly but surely uh going to land everything that these apis were kind of designed for um or at least for forward uh seeking and or forward looking uh in terms of like landing the actual native thing yeah and then you know it the web itself is better off for it, for sure. The other thing that I had top of head and couldn't remember

as I got mid-sentence is the release cycle, which was, I think the Chrome dev team really was the trailblazers of this continuous release pattern every six weeks with the multiple channels. But Ember was very early, if not the first framework, right? Not Chrome as an end user program, but like a first dependency framework to really say this can work for us as well

and just continue down that road for all these years. We've seen that mirrored elsewhere, so that's another place where y'all have innovated. On the builds page, it's actually laid where y'all have innovated. in between now and then beta one, beta two, beta three. And, you know, it sets an expectation to one, developers contributing and also community stepping in and say, you know, what is the release cycle path for the next release? You know, that kind of thing.

It's a very good to set that expectation because that's half the battle of diminishing confusion. Yeah, I think one of the other things that we were really trying to push forward is we actually have a status board. So the Rust project, I believe, has a similar thing. So I think if you go to like emberjs.com slash status board or slash status, you can see all of the efforts that we're currently working on. And what's the state of those things, the RFCs associated with them, relevant PRs and all that type of stuff.

So some of the things that I mentioned, like, you know, updating the object model is one of the things on there. Glimmer components is another thing that's on that list. So we're still, you know, playing with it. But yeah, we want to let the community know, like, how we're actually evolving the framework over time. And just in case you're listening to this and you went to slash status, it's actually slash status board. So check the show notes for the true link. That is very cool. And I definitely would advocate for other projects to have similar.

I mean, just very explicit and clear on where things are, you know, where they're heading. And that's super valuable. So just thinking about Ember in this, you know, kind of the Energizer bunny of JavaScript frameworks and really as a model for sustainability, it makes me wonder at a macro level, can you describe to us how the, not Ember.js, the source code works, but can you describe to us how Ember, the open source project runs? Governance, we talked about the release cycle a little bit, you know, sponsorship. Give us a picture of like how this machine moves down the road. The way that the core team kind of works is that there's individuals from, that are kind of stakeholders. I would say they are, you know, they own their own business. They work at a company that uses Ember, um, their consultants. Um, and those people have

been kind of like hand selected by, uh, other people on the core team. So obviously this started off as a core team of two is like Yehuda and Tom. And as the project ratcheted up and people put more eyeballs on it, they identify people within the community that were, I guess, contributing a lot to the system that had a fairly good understanding of the system. And we're moving it forward. So I think every year at EmberConf, they kind of announce new people that they recognize to become part of what's known as the Ember core team. But there's also other core teams. There's a core team that is responsible for the actual Ember CLI.

We have a learning team, which is all the docs and the learning resources. They also do like infrastructure for the website, for like the emberjs.com website. And then there's Ember Data Team, which is kind of responsible for everything related to the data layer. And so we think of all of these teams as being, I guess, peers to one another. There isn't like this overarching group that is like the core team or whatever. We really would like to think as we have people that are just very focused on very important parts of the overall ecosystem. Now, the Ember core team historically has met, I think, once a quarter face to face. And we have like two days.

We go somewhere and we talk about like through, we have different types of meetings. There's like, okay, what are like the things we want to do in the next quarter? We kind of come up with a plan. We write RFCs during that time. face-to-face meetings where we kind of ask the question of like, what is, where, where do we want to take Ember and what are the logical steps of getting there? Uh, so they're both like long and short term, uh, meetings that we typically, typically have. Um, and some, so I guess the funding for, uh, from like the meetings and everything like that is a lot of people's employers. LinkedIn sends me to go to those meetings to talk about the future of the framework and everything like that.

Other people are funded or they're sponsored in some way uh through uh if they're consulting at a time and they are they're working on something uh kind of like specific to uh that's kind of blocking what they're doing the consulting work for then they can kind of get their uh you know trip paid for or whatever but i think a lot of a lot of it is people do actually spend their own like personal money to you know drive the the framework forward because they care about it and they have a kind of a vested interest in terms of where where the the the technology should go and they they a lot of people have different um points of views in terms of where it should go because of you know like I mentioned before,

Ember is trying to suit the needs of many different things, like from consultancies to like small applications that really large applications. So having people with their own kind of like viewpoint is like super helpful. Is there a trump card? Is there like a, let's say there's a disagreement about a direction. And I mean, can Tom just say, yeah, no, because Tom's one of the two. How does that work? So we're largely a consensus driven team. Like all of the teams, you have to get consensus of all the members on the team. There's no like BDFL, I'm going to come in and like, tell people this is the way that it's going to be. So as one can imagine, consensus based things are can be typically grueling at times when there's people

aren't convinced that a specific direction is the way to go so a lot of it is um think thinking about all of these use cases and all of these concerns that people have and trying to come up with the the best solution forward typically when people do have concerns it's not like flipping you know tables and telling people, uh, you know, you're just wrong. You can't like give concrete examples of like why a specific direction is wrong. It's more or less, um, there are very true things that just need to be incorporated into the larger design that a person is kind of pitching and so then eventually like some sort of vote uh i we don't really vote it's just like more or less like we ask like does everybody kind

of agree and then we move forward right speak now or hold your peace right like yeah it's not an official boat not not not a boat gosh not an official ballot that's all i was thinking about ballot i said b for anyways if there was an official ember boat that would be neat yeah another thing that is kind of interesting is the rfc process so um a vast majority of the ideas that we talk about like uh in these face-to-face meetings and we also have weekly meeting like we can weekly meetings on friday um are talking about the design. If we're writing an RFC or there's RFCs that the community have talked about,

like everything is out in the open. And that's kind of the point of the RFC process. There isn't like some smoky room where we're like concocting up all these plans or whatever. No, it's like everything that we do that we talk about becomes an RFC. Um, and then the community can comment on it and think it's a good idea or not. Like for instance, I have like a couple of RFCs out right now where they're somewhat controversial, I guess. So, uh, we're hearing from the community in terms of like what, uh, they think, uh, about some of these ideas.

How do you go about starting an RFC? I'm trying to find docs on the process to get there and just poking around the Ember.js website. Where would somebody go that may not be aware of the process, learn this, and then at the same time know how to actually fulfill an RFC that may not be familiar with the process? I believe that the process is outlined in a GitHub repo. It's like github.com slash ember or.com slash ember.js slash RFCs.

And basically anybody can write an RFC. There are required parts of this document. So this document has to give a quick TLDR of, you know, what are you trying to solve with RFC and then give a very kind of like detailed breakdown of like, you know, why? And then if the new a detailed design and then after that, you have to explain how this thing is going to be taught. So if you're introducing a new API, one of the kind of issues with that is, one, you have to be solving a problem that is real. And then two, if the API is so convoluted, then nobody's actually going to use it to or know how to use it, right? So that's probably one of the more important sections that

we've added recently is like, how do we teach this concept or this API? And then you also have to include like drawbacks or alternatives. And then there's like an open questions thing. And then basically anybody that you can, you can basically open up a pr against the repo and then uh it typically will you know we will look at it the core team will look at it um and kind of take a glance at it give feedback in it and then ask the person if we think the idea is good but it requires like some rework in a couple areas we provide that feedback and it's a very like iterative process i like this how we teach part of. We provide that feedback and it's a very like iterative process. I like this how we teach part of this RFC process because it's like maybe help me on this Jared if you like this too.

But it feels like it's like teachable driven development, which is like, you know, not only here's the problem and here's the design for how to solve it and maybe even some open ended questions that may be out there. But how do we actually teach the community how to use this? That seems so I mean, is that does that may be out there, but how do we actually teach the community how to use this? That seems so, I mean, is that, does that happen often out there? I haven't really noticed that this process is part of like the RFC baked in process anywhere else. I'm looking at the, the repo, actually the RFC repo actually is pretty informative and there's a template in the repo that kind of goes through all this, the summary, the motivation, the detailed design, how we teach this. And you've got block quotes for, you know, bullet plate for saying this is how this process works.

This is what we expect to see here. This is some example of what you might put in here. Drawbacks, alternatives, unresolved questions. This is pretty thorough. Maybe this is a huge credit to the stability of this project is like you've got a process for how changes go in and how changes get proposed. And it becomes a much more successful project because you've got good guardrails up. I think that having that section actually changes a little bit on how you introduce concepts because you have to think about the teaching aspect and to some level of like the documentation and like the guides aspect very before you've

actually written any code. Right. So it puts that, I guess, in front of you to answer that question very, very early on and like how it fits into the bigger picture. The only thing I'm kind of bummed about, and maybe this is just me not Googling well enough yet, is just not seeing this kind of template further along early in the process, like a blog about it or something like this is such core information, I think that would be, that's really useful to to would-be contributors that they may have to dig a little too far to get my intuition on that is and and chad correct me if i'm wrong now but my intuition is when by the time you get to the

point where you're going to write an rfc you've kind of been initiated into the ember community a long enough that you've stumbled upon or you've seen other RFCs and you've talked, you know, so it's kind of like for the uninitiated, maybe it's overkill or maybe it's overwhelming. And so maybe that's why it's not up front. Yeah. I think that's kind of the way that we think about it is the people that are really passionate about things in the community and have, um, you know, somewhat detailed, um, about things in the community and have um you know somewhat detailed understanding of how the community works and everything like that are the people that typically write rfcs um so uh we we definitely talk about it in i think different blog articles we haven't

maybe it's been it's probably been several years since we introduced the RFC process. I think it might have happened right around 1.0. So once we hit 1.0, we locked down the API. We said, okay, this is the operating model going forward in terms of introducing new API stuff. So it may have been just a long time since we introduced it. And we're kind of continuing, like I i mentioned we added the learning section recently so it is something that we're still iterating on everything like that as we learn new things from um other people that are doing rfcs now like i believe like react is now doing rfcs uh russ does a lot of rfcs

so yeah we're learning from other communities as well. The amount of detail and the template, the fact that you had this all written down, I was even thinking as I read through the RFCs, read me here, well, you talk about substantial changes, you know, like you don't need an RFC if it's not a substantial change. Like that's a typical pull request. And then I was like, well, what is a substantial? Cause you kept, there's, there's quotes around the word substantial a couple of times. And I'm like, well, what is a substantial change? And then it goes on to describe, this is what we would consider us.

And so it just speaks to how that's funny, you know, how much thought time and like really iteration has gone into this just over the years, just constantly churning, right. Making improving, getting better and fleshing it out. This is the, this repo, the RFC repo, is a sign of a very mature project and community that's been through stuff and learned along the way. So it's just very impressive. Yeah, I don't know how many JavaScript half-lives Ember has been through,

but it'll probably go through several more. This episode is brought to you by DigitalOcean. DigitalOcean is a cloud computing platform built with simplicity at the forefront. So managing infrastructure is easy. Whether you're a business running one single virtual machine or 10,000, DigitalOcean gets out of your way so teams can build, deploy, and scale cloud apps faster and more efficiently. Join the ranks of Docker, GitLab, Slack, HashiCorp, WeWork, Fastly, and more. Enjoy simple, predictable pricing. Sign up to pull your app in seconds.

Head to do.co slash changelog and our listeners get a free $100 credit to spend in your first 60 days. Try it free. Once again, head to do.co slash changelog. all right chad so do your best to catch us up you don't have to give us the full four years um between ember 2.0 and ember 3.0 or 3.1, which is the latest release. We'll talk a little bit more. I know you got into a little bit of the innovations and also where you see things going with the status board. But tell us what's new for those people who have maybe used Ember a couple years ago or checked it out then and moved on, didn't dive deep into it

and have it on a production application. If they revisited the project, what would they find now that they wouldn't have found last time around? So I think a large portion of what we spent the time on during the 2.0 series is 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 in around 1.0, from going from 1.13 to 2.0, at EmberConf, we talked a little bit about this project called Glimmer. The name has evolved into something else from that point. But what Glimmer was trying to do was modernize the underlying rendering engine. So in Ember 1.0, it was primarily doing string concatenation

and interpolation with dynamic values. Then towards the tail end of like 1.11 or towards the end of the 1.0 series, we released this thing called HTML bars, which was going from string interpolation into just generating compiled templates that were effectively what you would handcraft if you were to write like 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 the time, that's when React started, like came out and, you know, really made us kind of rethink on like what the programming model should be. And that is like driving all the state through like property setting or like in React, it's like set state or whatever, 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 a 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 know, you basically have committed that change into the system, and then the rendering engine figures out how to most optimally update the view. So that was kind of 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. So 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 want to live with anymore. But when we tried to implement them on top of this infrastructure, the HTML bars with this React-like semantics, they weren't actually faster. And so we felt that the underlying architecture made

a lot of assumptions on how the old rendering engine worked. And so that kind of started this big kind of iterative change to figure out what the new rendering engine should look like. So it, you know, we typically are all about like incremental improvements over time and not like do big bang rewrite. So I think Yehuda forked the HTML bars repo like in 2014 or something like that and started working on the next iteration of what we call glimmer 2 and glimmer 2 has been it is kind of from the ground up re-architecting how we think about the rendering engine from an architectural point of view so templates themselves are kind of interesting, like an interesting concept. So a template is at its truest form, a pure function. You have a template and you have a context and you match those two things together and you get the same, you get some output.

Now, if the context and the template are the same, you will, it's referential transparent, right? If the context doesn't change, then you'll get the same output every single time. And so we think about the templating. We've changed the focus of how we think about the templating layer from 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. And so part of what the Glimmer rendering engine does is that it is a virtual machine. And so what we do is instead of compiling the template

into a bunch of like 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, the 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. So this is a pretty fundamental difference in between where I think a lot of JavaScript application or JavaScript frameworks are today is that you have things like JSX or you have like Angular templates

and they're all compiling into JavaScript and then running it on the client. One of the kind of like founding principles is that we felt that we could make the the compiled output much smaller if we compiled to a json format and then interpreted it uh at runtime and that turned out to be true uh when we did this work and we landed inside of the linkedin application i think we reduced the compiled uh template size, I think, 5x. So we went from almost 10 megabytes of compiled JavaScript templates down to whatever that is. It was a pretty massive reduction because we can see the templates kind of at one

time and we can do different types of optimizations that you wouldn't otherwise be able to do if you're compiling, compiling to a JavaScript program. So like, this is like hoisting code and every hoisting interesting parts about the templates that may be shared and everything like that. So they're stored as JSON then, is that what you said? I'm just making sure I tracked you. Yeah. So the first pass of it was let's take the templates, compile them to JSON. So there's kind of some interesting articles out there around like the performance of, you know, JSON parsing versus if you were to like have that same string in JavaScript land. A lot of engines, because if you use like JSON parse or whatever like that, the parsing of the JSON string

has to do less checks and everything like that because the grammar of JSON is much more constrained than like JavaScript, right? You can have a string and all of a sudden, like it's calling a function and now you have to like go into that function and then get the return value out and then interpolate the string.

So parsing the JSON and then putting it through basically an interpreter, we got some runtime wins from that as well. If you've looked at like other functional programming languages that are built on other languages, if you look at something like Clojure that's built on top of the JVM, you kind of have a similar story as to the next evolution. So instead of doing this JSON format, we would go from the JSON format into an actual, like a bytecode set. So we wrote

our own bytecode set that we compile the JSON into, and then we have the actual virtual machine loop through that, and it's encoding all the instructions to build the UI. And then, so that was somewhere in 2.0 towards the tail end. And then I worked on a project at LinkedIn last year, which was if we're compiling at runtime, this JSON to this binary format and then running it, can we actually do all of this stuff ahead of time. We felt like it was 100% possible, but part of the challenges of this is with a templating system is that you have a very declarative, a template's very declarative, but it's talking about things that are in JavaScript land. So you need a way of kind of bridging this gap between I'm talking about this declarative template and then calling into JavaScript land to like create components and everything like that.

So one of the challenges is like if we are going to pre-compute the binary that we're creating at runtime, we have to have some way of resolving components at build time. So we built almost like a bridging technology that when we discover an invocation to a component, what we do is replace the call site with a number, which we call a handle. And at runtime, what you're responsible for is basically replacing that handle with a live JavaScript object. So this is similar to how things like, I think in scripting work this way when you're the first versions of like Asm where we're going to like create this, you know, which became WebAssembly,

but you have to have some way of talking about invoking things that are actual JavaScript objects versus binary, yeah, reference inside of the binary code. So we did that and we're able to reduce the template size further because now your programs don't get compiled into JavaScript. They don't get piled in JSON. They actually get compiled into an array buffer. And the reason why we felt like this was where we wanted to go is one of the things that a lot of the folks at Google have been talking about over the past couple of years in terms of like JavaScript performance or getting up and running.

Like I think Addy Osmani has written an article about JavaScript startup performance. And one of the big costs of these client-side applications, especially on mobile devices, is parsing, compiling JavaScript. So you're going from this very high-level code, and it has to compile it all the way to machine code. And there's definitely costs to that. And so we felt that if we can compile templates, which represent a rather large portion of a client-side application into something like binary data that doesn't have to go through the JavaScript parse and compile pipeline, then we can get some decently sized wins from that. Especially as your application grows and grows and grows, the more templates that you'll have inside of your application. And if you're compiling into JavaScript,

you have to occur the JavaScript parsing compile costs. And so this is kind of like the state of where we're at with Ember is we haven't landed the compiling to binary code inside of Ember yet. Last year's EmberConf, we announced this thing called GlimmerJS, which is a lightweight component library that you kind of like equate it to kind of like React. It's just the view layer. It isn't like a router or anything like that. It's like a class object and a template and allows you to like put components onto a page. So we use that project kind of as a proving ground for a lot of like

these crazy ideas. Like, can we take this, you know, templating layer and compile it to binary code. Ember has strong guarantees around stability and SemVer and everything like that. So we can't just like go off and into the desert and come up with like some crazy idea and try to kind of shoehorn it back into Ember, we have to design a system that allows us to make large leaps, but then also bring everybody in the community along for the ride in terms of the performance. So with Glimmer.js, it's the same rendering engine that Ember uses. They have the same dependency on it. So what you can express, the VM, you can think of it as just like a virtual machine runtime. The templating language between these two things are equal. So it ends up working out. So you're able to basically do this experimentation, but have the guarantee

that it is going to eventually land in Ember in some form. You're answering a few of my questions as we go along there, I think, because the first one I started having was, you know, these are major rewritings of the underpinnings. And so do the ergonomics change from the Ember.js user perspective? And it sounds like you're saying no, because you've taken, you've gone through great pains to take the volatile bits and move them over to Glimmer and then like slowly introduce this back into Ember. Is that what you're saying? Am I not following you? The way that we have designed the VM is that we put a hard constraint on this has to be able to work in Ember.

And so while we do a bunch of we've done a bunch of experimentation with the underpinnings, the semantics of the system have to basically remain the same. And we think that React got this bit right in terms of how to think about the programming model. So as long as we have the same semantics of like, when I need to update the state, I call some method or I set some property and it updates the view, that all remains as constant. It's more or less that because the templating language gives us an abstraction, it isn't JavaScript. We're not tied to the JavaScript runtime or whatever like that. We can fundamentally change the underpinnings of this system. And then my other question I was having was, and I believe you answered this,

but I'll reiterate it so we're all on the same page. Glimmer then, Glimmer.js, which actually has its own website, Glimmer.js.com, this could be used to completely stand alone. And perhaps you would maybe even advocate for people who just need a component, a UI library, and don't need all of the other things that Ember offers. You could just use this by itself. Yeah, so that was kind of the idea with Glimmer is that we kind of recognize that there is a spectrum of applications that one may want to build. There is the highly interactive single page application experience that Ember, I think, is well suited for.

And then there is like, hey, I need to put this dynamic widget on this page. And I just need a little bit of state management, but I don't need a full framework. And so that was kind of the idea around Glimmer.js. But we're actually thinking about with Ember is how can we make that experience, how can we make an actual experience like that inside of Ember? So this is thinking about can we serve a kind of like bare backbone of Ember that can do the same things that Glimmer.js has, so that's the way we don't bifurcate. While the Glimmer VMs are

the same between these two things, and you'll be able to take a component from a GlimmerJS app and put it in an Ember app and it just works, that's one of the things that we're actively working on right now. But we're also coming from the other end and saying, can we make it so that you can build very lightweight applications with Ember itself? This episode is brought to you by our friends at GoCD. GoCD is an open source continuous delivery server built by ThoughtWorks. Check them out at GoCD.org or on GitHub at github.com slash GoCD. GoCD provides continuous delivery out of the box with its built-in pipelines, advanced traceability, and value stream visualization. With GoCD, you can easily model, orchestrate,

and visualize complex workflows from end to end with no problem. They support Kubernetes and modern infrastructure with elastic on-demand agents and cloud deployments. To learn more about GoCD, visit gocd.org slash changelog. It's free to use, and they have professional support and enterprise add-ons available from ThoughtWorks. Once again, gocd.org slash changelog. It sounds like Glimmer is similar to the way Vue is heading in terms of drop-in, ease of use, that kind of lightweight thing that I can just drop it into an application, do a little bit of interactive components and then be done with it. So at LinkedIn, we have like a couple of different use cases where we're like embedded widgets in like CRMs, like Salesforce or something like that.

And we want to have like just a little bit of functionality. It's not a whole app. It's a component that needs to go somewhere in another person's like website. But I mean, you could use it for any type of website, but that's kind of the use cases. It's like a small component library that can be used inside of a server rendered application, or it can be the idea is that you can also use these components inside of Ember application. So you have like this cross stack use. So another use case we have at LinkedIn is we have a bunch of internal shared components, and we want to be able to have like high leverage. so no matter what stack you're on you're kind of writing these components for you know if you're on like an old old application

that is still server-side render you can still write using the glimmer component api or if you're working on ember app you can use these uh components and drag and drop them uh into your application so that's kind of the idea is both um to basically um span the spectrum of like use cases for this template driven um approach to uh ui well y'all might need to change your tagline because it's a framework for creating ambitious web applications. But it sounds like it's like, and any other thing that you might be creating. Yeah. So a follow up to that might be, will this be able to be dropped in with just a script tag into HTML? And, you know, if I want to pop it into a page or drop the script into a head, is that how it might be used or is there a different process to make it that lightweight glimmer js uses ember cli uh to actually produce

the assets so at the end of it you have some script tags but it isn't like go to you know like javascript cdn or whatever and just drag grab a script tag and drop it onto the page now you could probably do it if you wanted to, it's not gonna be fast cause you need like a compiler basically to compile the templates into something. So it's not, I don't think it's like how jQuery was where you can just drop it on the page and start using it.

There's still a little bit of a build step to, you know, do get the app running. One kind of interesting thing that we've thought about is we can totally vend the Glimmered components inside of a custom element. And we have, I think there's a repo on the Glimmer.js repository that basically did this. So the way that you would introduce these components onto a page wasn't necessarily through a script type, but it was a custom element that could fetch all of its resources and then render that component to the page. Tell us a little bit more about tree shaking. The way I understand it is you have Ember, the library, and it exposes, you know, n numbers of functions. Maybe there's 500 functions. But in my application code, I'm only actually calling into three of those. And maybe

those three call into 17 others. And so of Ember's 500, I'm just making these numbers up of course of ember's 500 functions my system calls 20 and so tree shaking is the process by which we can actually just shake those 20 out and leave the rest of ember on the cutting room floor hence reducing the dependency weight is that is that what it is yeah i mean i don't know why in the javascript community we come up with like new words for like explaining like things. Like it's dead code elimination is basically what it is. Yeah. It's not tree shaking.

I know. It always, it's mystical. You're like, you're going to shake a tree. Yeah. Before, Chad, you go forward, then what's a good way you say it then? What was the terminology used for this? It's like static linking you're just going to link all of the so you're going to follow the imports back until you basically to depth and you retain only the code that you have statically set inside of your javascript that you're using

so like there's projects like webpack do tree shaking roll up does tree shaking um and yeah it's just another way of saying that we're gonna remove all the code that you're not calling into but you just use the the phrase we're trying to get rid of based on what you just said in your description the industry phrase though he's just using like the jargon all the lines of tree shaking maybe you guys know this maybe you don't i've learned this recently do you know that there are performance junkies, like web performance junkies, who will effectively tree shake their web fonts? So I think they call it sub-fonting or sub-setting. but you're only using of maybe the, let's just say the English alphabet, 26 letters. I'm only using, I'm only using 17 of the letters. And so I'm going to actually tree shake out the other, the other letters out of my web font and reduce my web fonts, you know, set like subset it to just the letters I'm using.

Isn't that crazy? Is this at render for the individual user or using not crazy is this that render for the individual user or just like add a new compile time for the app i don't know man i never looked into it because i mean if it's if it's on demand that's pretty crazy it makes sense though because like if you have 26 or even you know many many more characters than 26 and you're using only 10 and the font weighs two megs and you can cut it down to less than one why not that's true but why not is because that's a lot of work but you do it for your javascript why not do it for your web font why don't you just use times new roman and it's already there

talk to your designer talk to your designer anyways i've derailed us but i just i found that amazing just the length that people will go to to achieve you know to squeeze out a little bit more performance it's kind of cool so we were talking about tree shaking in javascript and i probably completely derailed us uh we were talking about the term itself but maybe you you mentioned that like ember isn't there yet like we can't do it like we want ember to be this you know, framework for both ambitious and, you know, non-ambitious websites. We would love to be versatile and have like a slim version of Ember that we could do via tree shaking, but you didn't sound like you were there yet. And so I guess the next question is, and maybe you've, maybe this is asked and answered, but just bear with us, like what has to change

and when is it going to change so that Ember can be used in that fashion? I think as of like the past couple of days, it's basically done. One of the challenges we had with Ember itself is that internally, like there's circular references to things and you have to be able to like sort all that type of stuff out. But I believe Robert Jackson, who's on the core team, has a branch working where we not only have the as a default to transpile the ES6 or the newest syntax of JavaScript into something that can run in a variety of browsers. So one of the things we've done there is introduce the notion of targets. So what a target is, is if a browser supports all of these new language features, then don't compile it into code that could run in like IE10.

So he has a branch where we're not only doing the modules API so you can tree shake out the app. We're also only transpiling the features that aren't implemented in any browser. of been one of the issues of trying to get Ember to a place where you can target different types of different browsers and different types of, or not, sorry, not targeting different browsers, but targeting different use cases is that Ember comes along with a decent amount of polyfills that are polyfilling things for APIs that aren't there in older browsers. So even though Ember is on 3.0,

we still support IE11 and then everything else is evergreen. So because everything else is evergreen, we kind of have to have an answer of like, I shouldn't have to down compile this code. I should be able to maybe create multiple builds and I can serve assets for IE11 that will run in IE11 versus I can just use the native JavaScript inside of like Chrome, say. So I think very soon, this is going to become a reality.

I looked it up while you were talking there just to confirm I knew what an evergreen browser was. I mean, I kind of understood that it was future proofed, but I didn't know how. Can you break that down real quick? Yeah. So an evergreen browser is basically a browser that automatically updates. It's keeping everybody at the leading edge so that people do not get stuck on like specific versions. So like Internet Explorer was notorious for like, you had like IE6, IE7, IE8, IE9,

and everybody's just waiting for like these browsers to kind of phase out in terms of their usage, where an evergreen browser, if you have like Chrome or something like that, it'll tell you like, oh, a new version of Chrome is available. And then you basically opt in and you have the new version of the browser. So it's very difficult for somebody to get stuck on a specific version. It's kind of pushing everybody forward. So like every, I think, major browser vendor now does this. Edge does this. Chrome does this. Firefox does it. I believe Opera because it's, you know, effectively like blink under the hood. They're doing this as well. So, yeah, it's just a way to make sure that, you know just took my about page for Chrome and I'm on version 65 and plenty dots after that, obviously.

But like could you imagine marketing Chrome 65? Like, hey, what Chrome are you on? I'm on 60. You know, you probably still say that behind the scenes in Devland. But like, yeah, but not general users aren't saying they just know they use chrome and i guess to going back to the question of like being more nimble like view has being able to drop a script tag and obviously you got the vm so it makes makes it harder you're compiling down to machine code or byte code or something like that to make things faster um you know one of the issues

with jquery was just the fact that it would ship so much and didn't do all this tree shaking like we just kind of talked through. You kind of had to ship all of jQuery and support all browsers regardless. But you wanted to use jQuery features. That's what made it sort of go out of style was this lack of modularity. Well, smaller is definitely always better. And especially, you know, now that we've found, we've found the internet very much exists on mobile devices. And those mobile devices are very much on slow internet connections with low latency out in the boondocks. And to stay competitive in the front end space, I think you have to be able to scale up and scale back down.

And Ember was always in the space of ambitious web apps. And so if you know that you need that interactivity and you need routing and you need all this stuff, it was a great choice. But if you don't need all of that and you still need, if you're thinking about doing font subsetting because you need to squeeze out that extra bit of performance, it really takes Ember off the table for you. And then hopefully this will move it back into a

place where you're okay. Maybe I can still, I can still just use the parts that I need, which is great. Tell us what else, I mean, we're wrapping up here soon, but what else is coming down the road, uh, for Ember things that you're excited about or something maybe you're working on personally? Uh, yeah. So one of the, of the i think the biggest uh boons for the community is actually adopting like es6 classes in ember itself it's one of the things that me as a or as an ember developer that you use every single day you're you know writing classes or updating classes and everything like that. And at this point, it feels very old. So we're doing this big refresh of the class system just to use ES6 classes. And I think that's what people would kind of expect of a JavaScript

framework in 2018. Like I mentioned earlier, the reasons why is that we want to support the entire class model, the entire class system inside of native ES6 syntax, and we should be able to do that here pretty shortly. Certain things work today, but not the entire scope in which the Ember object model kind of like falls in today. But I agree with the sentiment that I think the Web has a pretty big advantage when it comes to the mobile market. And so I am personally kind of excited about this idea of like, how small can we get the framework so that we can, you know, address like different concerns for like different markets and everything like that. So the web in general, I think has an opportunity in emerging markets. And Google talks a lot about, you know, the next billion users that come online. They have like they have poor connectivity.

The phones aren't great. You also have data plans are rather restricted inside of these markets. And so like downloading native applications inside of those markets is like pretty like a big non-starter. So I think the web can be extremely useful in these use cases. You just have to think, I think, pretty diligently about things that you're sending down to this seriously and we're doing a bunch of interesting things to kind of like bend the curve in terms of what we think about web applications from the kind of like static HTML applications to like the highly dynamic Ember applications that we have today or like React applications. I think that there is like a good middle ground, which is taking the best

from both worlds of having server-side rendering for like the first route and then client-side rendering all the subsequent routes, I think is like a huge, it's a very good pattern that I think a lot of applications should follow. And I think it's as we get, as we land some of these things in Ember, that'll become kind of like the, hopefully the default way that we think about building these client-side applications is with a very performance-focused point of view from the start, but at the same time, acknowledging that as your requirements of your project change, you have to have, you have to have something, right? You can't just like say like, no, we're not going to build that feature. We have to have like some shared architecture for us to build these ambitious things. That's kind of been the MO for Ember going back to 2014, Jared. Like that's what we heard from Yehuda and Tom was like borrowing the best ideas from the community.

Not so much not coming up with our own, of course, but just like paying attention to what's happening out there and doing their best to adopt best practices that are happening elsewhere. And not just like turning a blinder on because it's competition or a different framework or different ideas. You know, it's like, is it working over there? Okay, let's, you know, how does it fit into the ecosystem of Ember? And how does it make sense for the mission of Ember?

Since we've kind of covered a lot of ground here in terms of, you know, where Ember's been, where it's going, your involvement in it, you know, maybe share with us, I think Jared even asked this question or like, you know, what makes someone come back to Ember if they haven't seen it in a while? I'm thinking more along the lines of they've never seen it at all, or if this is fresh and new for them, or maybe they've only ever seen React. What makes someone choose, you know, Ember? What were good use cases for Ember? And maybe what are some good examples of applications in the wild? Maybe even at LinkedIn, how are you using it?

The value prop has kind of always been with Ember is we do look at what is going on inside of the community and we try to roll those best practices into the application. So this is like the whole stability without stagnation kind of MO, which means that we're going to create really stable APIs, but you're not going to be left behind by what is happening in the larger JavaScript community. So that's kind of the way that we think about it. And if you're building applications that are going to live for,

you know, several years that have many developers working on them, or they don't even have to have many developers working on it. It's more or less like I'm building a business. I don't want to, I want to think about the business. I want the technology to allow me to continue to make my business successful, but I want to not have to think about, you know, which libraries are going to, should I use for routing or what's a good way of like doing change tracking or how do I efficiently update the view? It comes along with, I think it encodes a lot of the best practices. And I think that it still resonates with me. You know, I've been doing this since like working with Ember since, you know, 2013,

2012. And it still resonates with me that we have shared solutions to problems and recognizing that not all applications are special snowflakes. There's like common things that we can build up from. So like this removes like inside of an organization, this removes like hour long meetings on like how you're going to do like, like build this very, this thing that isn't, it's critical to the technology, but it isn't mission critical for the business. And so I think that's one of the areas where Ember strives is the

stability without stagnation aspect of it. I think for people that have used Ember and have come, you know, have left and then are taking another look at it, I think what they will find is I think some of the things that may have been difficult for people to pick up at the beginning was like API docs around like 1.0 and still kind of like through the 1.x series where they were good, but they weren't great at like explaining like how the entire system works together and everything like that. And so I think we've, we've done the, we've invested a lot in documentation, actually having a docs team so that the concepts are easier to

learn. And so those, that's like one category of people is like this thing is it's like I don't get it like it's hard to learn I took like one look at it but the documentation didn't really tell me why I should do this and then there's the performance aspects to it I think we we are doing a lot of interesting things and we have written about like the wins uh from doing those performance things so like if you got into situations where like ember was falling down because of like performance or whatever i think we've addressed a lot of those cases and in some cases uh leapfrogged others in the space um and so those are i think some of the things that I would kind of like re-examine the other thing I guess is the things about like the javascript community are it is definitely like every so

many years like a new thing comes along and you know makes you have to go rewrite your entire application and maybe like people have you know been through this at this point because you know, makes you have to go rewrite your entire application. And maybe like people have, you know, been through this at this point because, you know, like I said, Ember has been around for a decent amount of time and some people get burnt out by that, right? Like always chasing the hype train or whatever is another thing that I think brings people back is like they like went off and like tried a bunch of things, then they're like oh well this this thing actually works and like I don't have to worry about you know worry about like what you're basically having FOMO yeah that's that's certainly the truth is is there's definitely a hype cycle in javascript and you know I think the interesting thing with

embers that you've like Jared said at the beginning of the show, is that you've been like this energizer bunny. You say it's stability. What was the phrase you used? Stability without stagnation. There you go. I mean, you've been that for years, like six plus, seven plus years. You personally even, not just Ember. That's pretty cool to see that so you

certainly give a lot of confidence into the future of ember we'll leave it there then thank you so much for your time today and uh thanks for coming on changelog appreciate it thanks for having me all right thank you for tuning into this episode of the changelog if you enjoyed it do us a favor share it with a friend go on twitter tweet a link if you're using overcast go in there and favorite We'll see you next time. And we're hosted on Linode servers. Head to linode.com slash changelog. Check them out. Support this show. This show is hosted by myself, Adam Stachowiak, and Jared Santo. Editing for this show is by Tim Smith. Music is by Breakmaster Cylinder. And you can find more shows just like this at changelog.com.

Thanks for tuning in, and we'll see you next week. Thank you.