Sessions is temporarily moving to YouTube, check out all our new videos here.

Ember.JS in the Year 2020

Ricardo Mendes speaking at EmberFest in October, 2017
Great talks, fired to your inbox 👌
No junk, no spam, just great talks. Unsubscribe any time.

About this talk

Ember has been around for a while. It has survived several JavaScript framework eras by delivering innovation without leaving users behind. In this presentation Ricardo will be looking into the recent work that will unlock the next stage of Ember, and share his vision of what that next stage might look like.


Hi everyone. So. Let's get started. I'm Ricardo, I work at Talkdesk. I am on the core and the learning teams of the EmberJS Project. You may know me as Locks from Twitter, Github or from Slack. I'm a little bit nervous, this is my first keynote and Berlin has been sending me some weird warnings. My flight was delayed and then I missed my connecting flight and then I missed it again. And then I thought I was off the hook, I was on my way to my AirBnB and suddenly I'm five minutes away from the AirBnB. I look at my phone and there'san email, a notification about the AirBnB being cancelled. Sothat was interesting. But I managed to get to the speaker's dinner and then everything was sorted out. The other day I was just browsing Twitter as one does and I saw these really cool sci-fi covers. And was like, "Okay, this is interesting. "The font is really awesome." And I found out that the font was made, it's a new font. It's based on an older font and these covers are actually all fake covers. The person was so inspired by the font that they decided to make the covers. So you'll probably see a lot of Marvin Visions, which is the name of the font. I got so excited about the font that I use it everywhere and I even bought a licence. So before getting to the presentation itself I just want to mention EmberFest and thank the organisers for bringing it back. It's really nice to have more than one conference happening in Europe. A lot of people can not afford to go to United States or somewhere else. And that really opens up the possibilities to more people coming to our community. I want to mention again the code of conduct because this is something that the core team takes very seriously. The Ember Project has had a core code of conduct for awhile. And the guidelines. If you see the keynote from Ember Conf, Tommy who also mentioned this. The conference is made by people for people, so as we say in the, in the learning team newsletter be kind. And if you feel uncomfortable with something reach out to the organisers as mentioned in the announcements. Today I'll be talking a little bit about the past, the present and the future of Ember. I'm not gonna talk that much about the past because if you go check the, the opening keynote from the Ember Conf from this year, Uhuda and Tom did a complete retrospective of the Ember Project. They better than anyone can tell you the history of Ember. So this week has been very eventful. We had a couple of releases, we had 2.16. Which was a hard one for the learning team because of the new Modules API. We had Ember 3.0, the announcements of the plan for it. There was a post mentioned in Glimmer components, some changes for Glimmer components. I'll be talking about this during the presentation, so don't worry. Okay. Let's get started with the past. To understand how Ember is developed you need to understand some core values about Ember. One of the big ones is stability without stagnation. And this informs a lot of Ember, both from the user side and from the development side. From the user's side one thing that happens is that you feel safe upgrading your app usually. Because we provide good upgrade paths we try to communicate the change is coming you have DLTS releases you have the beta channel so you can try out features beforehand. On the other hand, for the users sometimes it gets boring. Because nothing seems to happen and people start focusing on what's to come. Ember is a bit, the framework of tomorrow, like, "Oh tomorrow will be better, or will have this feature "or we'll have that feature." And sometimes we forget that the features we already have are really good, they're really solid and Ember can solve a lot of problems for you. Now, today. I'll mention a couple of things that landed recently. The first is the router service. And this comes from the development side of stability without stagnation. Which is our idea is to provide ways for people to build on top of Ember instead of building everything into Ember. We did that at first because historically the platform wasn't really there. We had to do Ember object, we had to do Ember array. A whole lot of other things, our SVP, Backburner that eventually might go away. That is our idea. So routing is something that, it was very interlinked with Ember and our idea is to provide the router service so you can try to branch out and do experiments, routing your components, do all kinds of things. At the moment we've only released phase one. We will detail the other phases along the way. Hopefully soon. It's kind of complicated because the phase two will start messing with the internals, route info and there are some semantic changes, but it's coming. And you can try it since 2.15. On 2.16, we, I'm gonna say we released the new Modules API and you can now import, instead of always importing the Ember package you can import, for example, import components from @Ember/component. But we didn't actually release it with 2.16. What we did in my opinion more interesting. Instead of rewriting the internals of Ember and possibly taking a whole year. We don't know because rewriting the internals and making sure everything breaks and it's backwards compatible and all of that is a lot of hard work. So we decided to do a different approach. Basically we use Ember-CLI-Babel. which is included in every project. And we take advantage of two things. One, we can include some Babel transforms by default. Sorry, one we can include Babel transforms by default and two, we have separate phases of the build for our add ons and then for apps. So the add ons can be built, with for example Ember-CLI-Babel five. and they get merged into the app and the app can use Ember-CLI-Bable six. So starting with Ember-CLI-Bable 6.6 what we do is if we see the new imports, so import component from @Ember/component, we actually transform that back into the old imports. So this has the disadvantage of being like a magic show, "Oo! "You have new modules!" But it's still, everything is the same under the hood. But you can start now with 2.16 and Robert Jackson mentioned that he, he tested all the way to Ember-CLI 2.2 and he didn't go further back because he gotbored. But what this means is that if you're using Ember-CLI 2 dot something, you can use modules. So this really widens the upgrade periods for modules. You can just pick your app, there's a really good codemod. If you use NPX you can do NPX, Ember- Modules-codmod and it will transform your modules to the new syntax. There are a couple cases where we don't have a mapping to the new modules. And it will write mark down reports with all of the cases that weren't converted. So you can actually check the file and either submit a bug issue or fix it yourself. So the present, like I mentioned Ember users usually have some time on their hands, because instead of spending time minutes, let's say messing with their webpack config, they just Ember instal the add on and use it. So, we start looking forwards. And we sometimes forget that the now is pretty good. So I'm gonna talk about some things that are happening or recently happens. First I wanted to mention the community. Our community sometimes feels like it's small, and it is smaller than others, but it's very vibrant anyway. We have two news letters. The Ember.js Times is from the learning team. Recently Jessica Jordan has been writing it very consistently every week. The idea is to give news about the development of Ember and Ember.js projects themselves. We have Ember Weekly which is more geared towards community content, blog posts, videos, add-ons from the community. We have two regular oh it's a bit cut off. We have two regular podcasts, Ember Weekend and EmberMap. EmberMap is a newer one. We have a couple other podcasts, some are infrequent. Some mention Ember, but aren't specifically about Ember, like the Frontside podcast. And then we have a lot of meet ups. That tweet there is just an example. There's a new Paris meet up that's coming up, so that's exciting. And we have the conferences. We have a bunch more in the United States. There used to be Ember Conf, Wicked Goods Ember, and So Ember, so at least those. I think one of them is not happening this year. But it's more than oneconference. And the attendance is very good. We have a very good system for add-ons. And as you can see the growth is stable. It's not astronomic, but it's not falling down, either. So this is a good indicative of the stability of our community, basically. Another thing that we started to do is improve communication. After the 1.13, 2.0 periods. And basically up to 2.0 we kind of promised some things were gonna happen. Angle bracket components and some other things that I'm gonna mention later. And they didn't. And we failed to communicate why there were some changes and why we had to do some other things to get there. We had to make some groundwork in order to build up the features that we want. So we're trying to do more blog posts. We put up the status board, which I'll go into a little bit more detail. And we have the newsletter that I've already mentioned. Glimmer.js was one of the recent blog posts. I'll talk a bit more about it later. So let's go into the future of Ember.js. We like really ambitious slogans, we're a ambitious framework for ambitious apps. And we like to say we're the SDK for the web. What this mean is basically we want to provide some of the missing tools out there for our users in a way that they don't have to care about the little things. We want to avoid as many paper cuts as possible. This was also mentioned in the keynotes they go a little bit about, about it with more detail. But, one thing that I want to mention is that Ember is five years old, or about, and at the beginning we had to build much, much higher because the platform was really low on the capabilities. But the platform, each passing month gets more capabilities, gets more performance. So in time what we want to happen is that either part of the Ember stack gets integrated into the platform or it dissipates away. And talking about the future, the roads to 3.0. Blog posts. So as I mentioned we have a plan. We have some deadlines. It's boring again because like happens on 2.0, the release change log is gonna be just, oh we removed deprecations. One thing that's happening is we're likely gonna drop support for IE 9 and IE 10, so we're gonna support IE 11, Edge and all the rest of the Evergreen browsers. And what this allows is to start chipping away at the Ember framework. We want to move closer to the platform and removing the support for older browsers enables that. Because at the moment we are not using some features that we could use. Because they're either hard to polyfill or they're not performing when you do. So it's gonna be exciting. The status boards. I'm gonna go through the initiatives mentioned in the status board and try to contextualise them. I've already mentioned the router service, so I'm gonna skip to the Modules API. Like I mentioned you can do, you can instal the latest Ember CLI and generate the new application. And the blueprints have been all updated to use the new syntax and you can import component from the @Ember/component package. This marks the beginning of our internal restructuring of Ember. At the moment you can not use separate parts of Ember, like I mentioned we transformed everything to the old imports. But we started breaking it apart. And the first case is Ember String. And this is a really good example of what I meant by the deficiency of the platform. Ember String did two things, it provided utility functions to handle strings like Dasherize, Camelize. At the moment Low Dash didn't exist, Underscore didn't exist if I remember correctly. So we needed to provide this. And the other thing that we did that at the time was very common, there was even a library named after the concept which was Prototype JS. We extended the native string prototypes. And now a days that's frowned upon so we're marching into the future. And Sedu and I worked on an RFC. It's mostly implemented so we just need to make sure the little details are there so it starts getting merged. So we are gonna remove the @Ember/string package from Ember itself. It's gonna be the first one. And we're deprecating the prototype extensions. This will basically set the precedent for extracting packages. At the moment we're figuring some things out on how to do that and et cetera. So my hope is that in the future we'll be able to do it for more and more packages. More than likely target is Ember Array, but there are some very fine issues there with performance and et cetera. But more RFCs will be upcoming. The next one is another RFC about ES classes. This RFC is about it's not about replacing the Ember object model which a lot of people for one reason or another would like to see. This is about being able to use the class syntax with Ember objects. There is some more details. One thing that is likely holding this back is that to fully support the Ember model we kind of need decorators. And decorators are still stage two in the TC 39 committee. And what the means is that the spec can change in significant ways. It already happens, Angular suffered from that because they used an implementation and then suddenly the spec changed. And now they have to decide if they break everyone's apps or how they're gonna handle that. So this carries on the theme of chipping away from the Ember platform and bringing us closer to the browser platform. Next is the module unification. This has been a long time coming. It's a bit of hard work. Mick Sonic has been leading the effort. So, we're not only trying to remove parts of Ember itself. We're also trying to move more of the work from run time to compile time. Because at the moment, for example when you look up controller or when you use a component, everything is done in the browser. Like you ask, "Oh give me my component." It goes, searches the list of components, tries to find it and then returns an instance of that. What we want to do is move more and more to compile time. Tom Dell has been tweeting about this, some vague references to Ember-CLI being a compiler. If you read the Glimmer, the new Glimmer blog post, you will also see this theme, because the idea is we do very aggressive ahead of time compilation for templates and it's not even Java Script it's not JS anymore. It's just binary, we send that to the browser and the browser doesn't even need to parse and everything is really fast and really small. So that's the idea is by moving more and more things to the compile step, we can optimise we can know more about the app. And we can send fewer and fewer bytes to the clients. Which will address one other complaint about Ember being too big of a framework. So. Okay there's a link at the bottom that you can't see. I was told before coming up here that that command won't really, really actually work. There are some problems with one of the templates. But it's being worked on and it's almost ready. We changed the syntax to capital components. It's basically what React uses. The idea is the first letter of the components needs to be upper case and then the rest is whatever you want as long as it matches the name of the file on disc. The rationale for this is explained very well in the blog post. The idea is to disambiguate between the, the stash components and the web components and plain HTML. So now you can have like input with a capital I and that's Glimmer will know that that's not a native input. There were a couple of syntaxes deliberated, but we thought this was one of the better ones. There are some other new things in Glimmer.js because it updates the internal Glimmer VM to one of the latest ones. And once again the theme of doing more work beforehand so that when the code is actually running in the browser we do as little work as possible with as little Java Script as possible. So there's the bundle compiler which does some very aggressive ahead of time compilation of templates that I mentioned. There's the binary VM which has some changes to how the up codes and the VM itself works. Chad Hyatella wrote a couple blog posts about this. If you search for Chad Hyatella in Glimmer you'll probably see them. And there are some other things that will be mentioned in a change log. So more things about the status board. The Ember.js, Glimmer.js integration and eventual writeable components, is underway. And what I mean by this is that we're trying out our ideas in Glimmer.js. That's what Glimmer.js is for basically. It's a way into Ember. It's a framework or library focused on mobile performance because we want to be as performant as possible. And who benefits more from that is the mobile market. So if you want to target emerging markets, or low powered phones, Glimmer is your best bet. But it's also a way for us to experiment. We wouldn't be possible, it wouldn't be possible for us to do what we're trying to do with Glimmer components in Ember. We tried that with Angle bracket components in 1.10 I think, and it only survived one beta, was 1.10, the first beta. And then we removed that feature and it still haunts usuntil this day. Like people are like, what happened to the components? Okay. So that is our goal is experiments in Glimmer.js, get it stable, get it ready, get it merged into Ember. And don't worry, Ember was and is very community driven, so RFCs will show up, for the integration so you can give your feedback. That's a very valuable feature of our development process. That coupled with the weekly betas and six month releases really enables us to try to stick close to the community and react to feedback. Another thing mentioned is code splitting. There's a talk today about that, so I'm not gonna mention much more about it. I'm just gonna say that once again the idea is to ship less code to the browsers, so we want to do more or less automatically proroute the bundles. So you have your blog routes and in the context of module unification we know which controllers and components are in that context and we bundle that code together. And then we only send that and lazy load the rest. The status board is a work in progress. We still have a testing, and sveltes which are happening. We're gonna get there, testing has a couple of RFCs from Robert Jackson. And there's something called the Ember NPM package, it's a metapackage. It's something that we have discussed internally because we do own the Ember package on NPM and it's just sitting there. I think it's versioned with 1.3 or something and it really confuses people. The idea is we provide a metapackage and when you want to upgrade your Ember, like it will contain Ember-CLI, Ember data and all of that. And you just need to move the version of a single package. So it will be very clean. There are some more things that I could talk about mostly from the learning perspective and easing the development. But I already did a very dense talk about it. It might have scared some people because there were a lot of projects, but I think it was also a good way to show that there's a really, really, really, long list of things happening in Ember, like a lot of projects. We just don't surface them that well. And routable component. So I just ran out of time. So thank you. But you can talk to me about it afterwards. Thank you. Just last kick word, I literally have a bag of stickers. I have a secret Ruby Tomster, that almost no one knows about. So if you want a Ruby Tomster, come talk to me thank you.