Octane moves Ember to an HTML-first approach

Alright, hello, JS Party people. It’s your and my favorite time of the week, time for a JS Party! I am your MC this week, I’m Kball, and I am joined by two very special guests today, plus one of our panelists, who we’ll get to in a sec… But I’m joined today by Jen Weber and Chris Manson from the Ember core team. Thank you so much. Jen, how are you doing?

I’m doing great, thank you. Thanks for having us!

Yeah, you bet. And Chris, everything okay over there?

Oh yeah, great. It’s definitely one of these long-time listener/first-time caller situations.

Yeah, Chris has been in our channel forever, so I’m super-excited to have him in. He helped to make this happen, synced us up with Jen to get her on board, so this should be good. We are also joined by the one and only Nick Nisi…

Hoy, hoy!

So here we go, we’re gonna talk – the context for this episode is there was recently a very big release of Ember.js, the Ember Octane release… But we’re gonna start off by putting Ember into place in the landscape, because while it’s been around for a long time and was actually the answer to one of our JS Jeopardy trivia questions maybe two episodes ago, it isn’t that huge… So a lot of newer folks in the ecosystem may not be as familiar with Ember as those of us who have been around for a long time.

Jen and Chris, whichever one of you feels like it, can you put Ember into the landscape for us? What is it, how does it fit in, and what makes it unique?

Yeah, sure. So whenever people talk about Ember, they’re often talking about it amongst the other front-end JavaScript frameworks - React, Angular, Vue etc. There’s a whole bunch more than we tend to talk about on a daily basis when we start talking about frameworks… But there’s lots of them. And one of the things that most of them have in common is that you write HTML, CSS and JavaScript in order to build apps for the web, as well as some tools have extra capabilities for native.

What kind of separates them I think is largely about the philosophy of what they aim to provide. The philosophy of Ember is that from day one you as the developer should have available to you the essentials for building a production app. Those tools should all work together well out of the box, and as you have people with different abilities on your team - maybe some people are CSS specialists, JavaScript, HTML, accessibility - all of those team members can find the places in the app that they need to do their work, and really embrace those specializations, as well as generalists who bounce between all of those different areas.

Another thing is that it started quite some time ago. It is led by a team of people from many different companies across the industry, and anyone in the community can participate in proposing, designing and implementing new features.

[04:16] Yeah, the community management approach is a place where I think Ember has been a leader along the way. I remember a couple years out I was at VueConf US, and they were talking about “How do we move Vue from being a single benevolent dictator for life to being a community-run organization?” and almost all of the steps that they took were things that had been modeled and pulled from the Ember community.

Yeah, I did a review recently to see how the RFC (request for comments) process is being used across the open source community, and it really seems to have taken off. I think we originally took some inspiration from Rust (…is the history there), and we’ve found it to be a very successful way for engaging and developing, and really making sure that what we are building doesn’t just serve my needs as an app developer, but we’re actually hearing from the broader community.

Chris, from your perspective, what makes Ember different and unique?

Yeah, it’s a really good question. The thing that really kind of drew me to Ember back in the good ol’ days of web development - I’m talking eight years ago now, which is a very long time in JavaScript years - the thing that really caught my attention was the fact that it was all-inclusive. Ember not only had a lot of the things that you needed to get started and actually build a full app in the box, it also kind of nudged you in the right direction.

When I started using Ember, I wasn’t a very good front-end developer, and I would pretty much give all of the experience that I’ve gained - most of that is because I’ve been an Ember developer for eight years, because a) I’ve been able to learn from the really smart people who were making the framework, and b) we’ve been able to focus on building actual web apps, instead of having to reinvent various pieces over and over again if we’re restarting an app every few years, or whatever. And that’s one of the main things for me, is the longevity as well. I am actually maintaining some Ember add-ons and Ember apps that are five years old. That’s frightening. And they’ve been updated various times between when they were started and when they’ve been updated recently.

One word that I think is commonly associated with Ember is that it’s opinionated. Would you say that that is what helped you level up as a developer early on with Ember, being kind of guided by those rails? Pardon the terrible pun there…

Well, you know, pardoned the pun there, but a lot of the inspiration early on in Ember actually came from Ruby on Rails. I don’t know a lot of the history, because I actually skipped the whole Rails thing. I never was a Ruby developer. I was JavaScript front and back for most of that time. But Yehuda Katz, who is one of the two founders of Ember - I know he was very involved in the Rails community for a long time. And again, I don’t know the exact history, but there has been a lot of inspiration from there. And yeah, that is something that really helped me.

It’s one of those things where you can kind of think of it as junior developers. You’ve got these rails for people who are starting in your organization or starting as Ember developers, and that’s great… But it’s also a really useful tool to be able to build higher, for more intermediate and expert developers, where using some of the concepts in Ember you can kind of automate whole chunks of your application, so that you don’t have to, again, as I say, reinvent the wheel so many times.

[08:01] One interesting pattern I’ve seen there, that I think may have once again been inspired by the Ruby on Rails community, is this concept of Ember engines. Would either of you care to explain what those are and how they work?

I don’t use engines myself, but I can give a quick explanation. The idea of engines is to be able to have an application that is composed of many separate applications. It is best used when you have teams that already work and operate separately, who need to have some sort of coordinated collection point for their application. Engines isn’t the norm amongst people who are building Ember apps, but it’s certainly one of the options that’s available.

Interesting. I was thinking about it – so I’m not an Ember developer, I haven’t done much there, but I used to do Rails a lot, and there one of the cool things was you could, for example, get authentication just out of the box. Rather than everyone having to build their own auth setup, you installed an engine of– I don’t remember; a device, or something like that, and you had authentication, and user management, and all these different things, without having to build that yourself. That’s something that I think on the front-end we’ve been lacking a lot. Everyone ends up rolling their own auth solution, or they use a third-party service, rather than just having something that works… So I was curious if that was how it was getting used. It sounds like it’s more being used for micro front-end type stuff inside of teams, to [unintelligible 00:09:29.13] independent teams, but…

Yeah, it’s more about that micro front-end type architecture. The equivalent of what you’re speaking about - it’s so nice to just be able to install something and have it be working… I also did Rails for a little while, and had a similar experience. When I was working in Node back-ends at a startup, every once in a while I would just think to myself “Oh, I wish this was a Rails app… I really do.“Because I was writing a whole bunch of things myself.

But in Ember we have npm packages that we refer to as add-ons. Add-ons are especially made to work within the Ember ecosystem. They have a pretty cool system of backwards-compatibility that lets – you know, if I’m using Ember 3.15, I can use an add-on that’s 3.12. And likewise, if I’m on 3.12 and the add-on is on 3.16, if that add-on author has followed their best practices, that add-on is still gonna work for me. Those add-ons do include things such as authentication, so… A huge, huge library of different plug and play options there.

Yeah, that’s something that’s really powerful, when there’s so much structure around the application. First off, if you go to a new Ember project, it’s probably going to be similar to the other Ember projects that you’ve done, because it’s following a very similar directory structure, and things like that… But then it really makes it easy to build those add-ons, because you can contribute to everyone, because everyone is kind of following – going the same path and not reinventing the wheel, so it makes it really easy for a plugin author or an engine author to be able to also plug in and probably work with your application as well.

Yeah. And it does take a bit of work on their end. The add-on author has to do things like run tests against all of the long-term support versions of Ember if they want to make sure that their add-on works for everybody… But new add-ons kind of come with that structure out of the box… Again, to nudge people towards this way of building apps that is more focused on providing backwards-compatibility, but still taking advantages of the latest feature.

So they might use things like polyfills, for example, in order to let them bring in newer features, that might not necessarily be included in the users’ apps.

[11:58] The approach to backwards-compatibility and upgrade paths is something that I feel like at least in the JavaScript community seems to be pretty unique to Ember. One of the things I remember talking with somebody about and there was actually some confusion about is this idea that new features are never released in major versions. Major versions are used for getting rid of old, deprecated features… Which when you kind of walk through, it ends up making an incredible amount of sense for maintainability, but is not how most people use versions. Would either of you like to sort of walk through how that works in Ember and why it’s helpful?

Yeah, it’s pretty unique, and even within the Ember community it sometimes is tough for people to wrap their brains around, just because there aren’t that many examples of other places doing it.

Octane, which I know we haven’t really gotten to that yet, but it’s a really good example of this use case. Whenever new features get added, we try to do so without deprecating things in the same sweep. So if someone proposes an RFC and says “Hey, I really wanna see this feature be available, and also we need to remove this other thing”, we work with them to decouple those, so that we get the new feature in, we make it compatible with the codebase that’s already there, then introduce the deprecations.

Some of the ways that we can achieve big, splashy, different, what would be like breaking features, you might say, is through the use of opt-in flags. For example, say I really wanna adopt some totally different way of doing something - I could turn on that flag, or I could not. And this gives teams a way to migrate slowly, at their own paces, and not have things changing out from under them. Even if it’s someone who’s building an app solo, they don’t need to be concerned about what’s changing all the time. They can just kind of move at their own pace and deal with new features when they feel like it.

So our major releases really are just like cleaning up. It’s paving the way for things that are not able to be implemented without those breaking changes… And we are only on Ember 3, despite having existed for all of those years, doing releases every six weeks etc. So from my perspective, it seems to be working pretty well. As a developer, I haven’t had to confront – I use Ember myself, and I haven’t had to confront breaking changes only like twice.

Particularly in this ecosystem that is bizarre and amazing… [laughter] Where so many of us are on this treadmill of having to stay up, having to keep up, having to upgrade, and when you talk about you as a developer, you can move at your own pace and you don’t have to worry about that, because the framework is gonna take care of you - that sounds amazing.

Yeah, there’s some trade-offs to that, too. It takes more work. We as the core team developers and our key community contributors take on that burden of “What’s the migration path? What needs to be backwards-compatible? What will someone need to do if they’re using this other super-popular add-on, and these things that we wanna do are clashing?” That takes time and effort to work out, and that’s handled by the framework development side of things, as opposed to the app developers themselves.

Another big piece of that is providing code mods. We made some big changes, with feature flags and everything; there’s all these new syntaxes and styles that just became available, and a considerable amount of time was – we said like “Okay, we think that everything’s almost set, and now we have to work on code mods.” Those let – if someone says “Hey, I like this feature. I want it”, they should be able to run a [unintelligible 00:16:00.21] anything that can be updated programmatically is. And the things that can’t be, they receive some guidance on.

[16:09] That also takes time, but it’s something that I would love to see integrated into the other tools that I use forward. It’s something that we’d be happy to share with, and talk with other framework teams. We learn from them, and we really hope that this is one of the things that they can learn from Ember, as well.

There’s a whole other class of things that are upgraded slowly over time, that we’re kind of not quite talking about. Everything we’ve talked about so far is like a new feature that you actively want to use… So something about how you develop Ember day-to-day changes in some subtle or major way, and then you either opt into this new change, or you use a new API, or something like that.

There’s been a few cases in the past where we’ve had relatively major upgrades to the rendering engine that required no updates from a user’s perspective. So again, another thing - if you’re new to Ember, you’ll probably notice that we have this template syntax that’s not JSX, it’s not JavaScript, it’s not DOM APIs or anything like that. It’s this thing that looks a little bit like Handlebars, but it’s very far away from what Handlebars.js actually is nowadays.

So you write your templates, and that’s how you interact with Vue, that’s how you build HTML or DOM… But because there’s this clean API between your templates and what it’s actually generating, we can update the thing that turns those templates into actual DOM without people having to change anything. So when we first moved over to – I think it was called Htmlbars… So we moved from Handlebars.js to Htmlbars, it was a little bit painful, because actually there was a little bit of syntax change… But then we moved to the rendering engine being powered by Glimmer under the hood, and developers didn’t have to change anything, unless they were doing weird bugs, weird edge cases.

I did, I had a bug…

You had a bug? [laughter]

Yeah, it was a really funny one. Everything got faster when I did the upgrade, and it revealed a race condition that I had in my own code… [laughter]

Oh, yes…

I love it. I think when we upgraded the Glimmer 2 (I think it was), one of the things that happened was that the compiled output of templates went down 30% for most people. So you just upgrade a thing, things get faster, and your bundle size suddenly gets a bit smaller, which is kind of cool.

Those are the best type of updates. Speaking of updates, I think we’re at a good point to take our first break, and when we come back, we’ll talk about the big update that just shipped, Ember Octane.

Welcome back! We’re talking Ember, with Jen Weber and Chris Manson. Let’s talk about Ember Octane. It just shipped, I saw the announcement post go out in December… So let’s talk about it. What’s in this box? What is this big release that’s getting all this buzz?

Octane is a name that we’re giving for a brand new style of building Ember apps. It’s an overhauled approach that focuses in on HTML and components first. The easiest way to see the difference is if someone learned Ember right before we released Octane, they went through our guides and tutorials and things, and they did that at the beginning of December, versus they did that today… They’re gonna have pretty different experiences.

To our point earlier about the upgrade paths and things like that though - both of the apps are still gonna keep working, even if they’re on the latest version of Ember. So someone who learned it in December doesn’t have to be sad that like “Oh no, my stuff is broken and I have to throw it away.” It all still works.

For me, the thing that I’m most excited about is really the HTML and components-first aspects of this. In the learning materials we used to teach a lot of the JavaScripty stuff upfront. We used to talk a lot about the data layer upfront, and people who wanted to learn Ember had to confront all of these concepts all at once, and start thinking about them. They’re the concepts that we as web developers all have to encounter eventually, if you wanna take something into production. But we can’t. A bit of a difficult start there…

So now instead we start with “Here’s where you write HTML, here’s where you write styles”, and then introducing piece by piece the aspects of Ember that kind of help to bring those templates to life and make them dynamic. So it kind of just inverts the whole thing, and we’re pretty excited about it.

Yeah, I actually went through the Getting Started Ember app today, and created my own, so I’m pretty much an expert now… [laughter]

Congratulations…

But I did like that. The cool thing with the components is I used the CLI to generate a new – I think it was a people list component, and by default it only generated… It was a .hbs file, so it was a Handlebars file, or…?

We just refer to it as a template, yeah.

Okay. Yeah, so I created the template file and nothing else, so I could just use that. And then a later step was “Well, I actually want to bring in data and use that”, so I actually just created a JavaScript file of the same name and put a class in there, and then I was able to just keep going and working. So that was pretty cool, being able to only create what I need, and for a lot of components that might only be HTML and CSS. So that’s really cool.

One thing that’s pretty important, at least to me, and I would say to Ember in general, is keeping those boundaries in place between the HTML and the JavaScript and whatnot, so that you can focus in on just the file that you need to do work in. I worked with a designer at one point who didn’t know any front-end development. I was kind of teaching him some HTML and CSS… I was able to kind of just point him at those files, tell him just the littlest bits of information that let him bring some of his designs to life in the app. And he didn’t need to touch the JavaScript side. When he was done, I did all of the JavaScripting, sometimes together with him, so he could see what it looked like… But that’s one thing that I really enjoy about it.

Nice. I’m curious, when you have a component like that – I guess I’m curious what’s the testing story like for a component?

Go ahead, Chris. If you wanna talk about testing, Chris loves testing.

[laughs] Yeah, I’ve just been spending all day and most of this week working on testing, and it’s like – yeah, this is another thing that we should have probably said earlier on; one of the differences between Ember and some of the other frameworks is that we care about testing and we care about it upfront.

It makes sense from the Ruby past…

[23:56] Yes, exactly. I can’t remember exactly if this is true, but in the past when you create a component, it also creates a little test file for you… So you’ll see it does the template, and then something like tests – I think it’s an integration test, is the one that it generates automatically every time that you get a component. And this is one of the things I love, where first of all we have three different types of tests; we have unit tests, integration tests and acceptance tests.

So if you’re a super-testing wizard that knows all about this stuff, you know exactly what you wanna use and when, you can pick the right tool for the right job. But if you’re a beginner and you’ve never done testing like this before, you get a template, you get a test generated for you, and if you look in that, it just has a little sample that says “Render” and then a little bit of template code, and then an assertion that gives you an example of “Hey, let’s check to see if this thing was rendered.”

So you could, if you wanted to, write all of your integration tests, and just every component that you write, you just write an isolated test that checks that your APIs work the way you want it to… Or you could go one level up and just write an acceptance test that walks through a flow of your application, and it’s rarely quite easy, even for juniors, to just set up an entire testing suite without having any experience at this.

Yeah, and that’s something our tutorials – we have one official tutorial that kind of takes you all the way through a whole bunch of the Ember features. It also walks you through testing, writing tests that run in the browser… And along with that, since we’re running tests that run in the browser, it also lets us – you know, we can do accessibility testing, for example. There’s some accessibility testing that comes out of the box in Ember. When you install a new Ember app, it has linters installed, and those linters check for a bunch of common mistakes, like forgetting – if you try to put a click action, a click event on something that isn’t a button, it’s like “Hey, you probably don’t wanna do this. Learn more here about what to do instead.” So it kind of nudges you in the right direction, even before you’ve made commits, even before you’ve run your tests; you can see that right in your code editor if it’s got those plugin/ESlint installed.

Coming back a little bit to Ember Octane - a couple of the things that I saw also highlighted in the release were this concept of an element modifier and a new reactivity model. Can we dive into those a little bit?

Yeah, sure. Element modifiers are really cool. I did a livestream some time ago where I tried to figure it out on the live stream, and at first I was like “I don’t get it. Why is it like this? It’s not working… Wait, what?” and then when I hit that point, it’s super-magical. So the element modifier is in the template you can specify – I use some of the out-of-the-box ones that other people have written. Whenever an element is inserted into the DOM, I can actually run a function. And I can do that for different pieces of a component. It’s kind of tough to put into words without looking at the code for it, but let’s say I have a conditional helper where I say like “If the user has clicked a toggle button, show this stuff.” And that’s in one template I have all of that logic.

I can use an element modifier inside of this stuff I wanna show, and run updates, run animations, reset values of things… Basically, whatever I need to do, I can have a way to respond to the changes that are happening in the DOM. Ember gives you lots of ways to do this for the component itself as well, but it gets granular; all the way down to the element level I have lots of control.

[28:05] It’s something where if someone is just building a quick little to-do app for something, they probably wouldn’t find a use case for this, but in the case that I’m building some really dynamic dashboard, or data visualizations, or things like that, and I need really fine-tuned control over how things are presented, it’s a really cool pattern.

Interesting. It reminds me of the concept of a custom directive in Vue.js, where you’re basically defining lifecycle functions that can be applied to any element, not just to a component.

Yeah. And once you can break it down to even smaller pieces than the component - that’s really… It’s powerful, and it means that you don’t have to write new components every time you want to have something that reacts to changes in the DOM.

So this is something that you use in the template, and then does it replace that element with the contents of the element modifier?

No, you write – let’s say I have a section tag. I can say “section” and then [unintelligible 00:29:08.09] and then the function name that I wanna call. This means that I can always look at the template and read what the markup is going to be, without jumping back and looking at the JavaScript file for it. So it’s not replacing an element in the DOM, it’s just sort of adding another feature to it, you might say.

And the functionality, the way that that actually works is that – let’s say for example you have this function that you want to run when the section is added to the DOM. That function will receive the element as the first parameter. So it’s like any normal sort of DOM programming that you’re doing - you find the element, and then you do something to it.

One great example that I had with a client project recently was they wanted to have an intersect modifier, so that let’s say when a Buy Now button scrolled out of you, a separate little Buy Now button would pop up from the bottom. And because it was done as a modifier, you could encapsulate the implementation, and as Jen says, you know exactly in the DOM what’s happening. But they also can include clean-up code. So if you’re doing a – I can’t remember the actual DOM API that does that kind of intersection watching thing… But you have to remove it once that element is removed from the DOM, so you can actually provide that in your modifier, and then it cleans it up without you having to worry too much about component lifecycles and all that sort of thing.

Interesting. What’s the scope of what you’re supposed to – or what best practices are for what you’re manipulating when one of these are called? Because the situation you’ve just described - it’s a modifier on one element, but then it causes something completely outside of that element to occur. Is that a pattern that you’re seeing, or are these mostly used to add behavior on that particular element? Are these wiring together pieces of your application, or are they modifying in a contained way, or how are they being used?

In that particular case, we actually passed in – I can’t remember if it was a function or just a variable that we wanted to update… So in that case it was like when something scrolled out of view, it would set just a boolean on the component that we’re currently in, and then as Jen was saying earlier on, you’d have an if block somewhere else, that’s like if scrolled out of view, then it would just show the other element.

Got it. So it was a modifier that was kind of scoped to the component, in some way, but it was providing a way to react in a customized way.

[32:02] Yes. And it’s one of these things - and this is kind of another core concept of the Octane release… It’s that we’re removing some of the magic that was there in Ember, so the stuff that you didn’t know exactly what was happening. In the case of an element modifier, you’d just have a function that you’re passing information. And if you don’t pass the information that you need to that modifier, then it’s not gonna have it, it’s not gonna be able to get it from elsewhere. So it gets the element, but then if you want to pass other information to it, you need to do that, and it ends up passing that to the function that you’re connecting to.

Interesting. Okay. Yeah, it sounds a lot like directives in Vue. Huh. Cool. Are these things that you see being packaged up as libraries of reusable behavior, or do they tend to be specific to the component you’re using them in?

There are add-ons that people have published that share these behaviors with other apps. For example, the one that I gave, where I said “When the thing is inserted into the DOM, do this thing” - it’s called the “did insert modifier”. That’s actually a package that I installed, that somebody else wrote. It’s probably one of the most popular ones… But likewise, if I wanted to borrow from somebody else’s work to do something fancy with hover controls, people can publish those modifiers as separate packages.

Nice. What about that one last feature we’ve mentioned and we haven’t dug into yet? There’s a new reactivity model within Ember, and I know Ember has had the concept of reactivity and computed attributes and things like that for a long time… So what’s new and different here?

I imagine you’re talking about tracked in this case. Yeah, tracked is awesome. In Ember in the past if you wanted your component to respond to changing data, you would write a computed function and say “Hey, computed function, I want you to watch these five things, and run yourself an update whenever any of them change.” That works great when you’re working on one component, but what about when you have a component within a component within a component, and everything’s kind of depending on all sorts of things? In Octane we have tracked instead; so if the app should respond to changes for the value of that component property, you just label it with @tracked. And any functions you might write that depend on that are just gonna automatically run and update themselves. It’s way easier to maintain, because you just have to label it in one place, say “Hey, this is an important thing that my DOM state depends on. Watch this.” And my code is much cleaner. It’s a lot easier to debug when something isn’t showing up that should be.

Interesting. Are there particular places you can label that? Do they have to live on the component class, or how does it all tie together?

You can use tracked almost anywhere within the app, and pass those properties around as needed. To give an example, there’s a concept in Ember called services. A service exists once in the app, so for example let’s say I had a service that handled a WebSocket connection to something. I could use that service anywhere in the app, I could label some of that service’s properties as tracked, and then tell my components “Hey, render something based off of this property of a service.” So almost anywhere that you’re in an app, you can take advantage of being able to watch the properties.

[35:50] Awesome. And if we look at all these changes that are coming out in Octane – I mean, one of the ways I think about Ember as someone who’s been outside of the Ember community, but watching it for a long time, it reminds me a lot of Dojo, in that not many people use it, and yet it keeps introducing new innovations that then do stuff all over the ecosystem and get absorbed into new things. We’ll talk a little bit in the next segment about why we think not many people use it and what might change to get more people to use it, but I’m curious, of these features that Octane is introducing, which ones of them do you think are ripe for adoption across the ecosystem?

Personally, I think tracked is one of those features that if I was working on other apps and other codebases, I would be desperately wishing to have it available to me. So that’s my number one.

Yeah, one thing that I’ve heard a lot of people ask for is modifiers in other places. I won’t get into too much on this, because it’s a bit controversial at the moment, but React hooks are a thing, and they have a similar use case, but they’re slightly more complex to use… But if other people could take modifiers and use them in the kind of simple way that we are communicating them, then that would be great if that was a common thing in all web apps… Especially because one of the things that modifiers help you do is stop you with the footgun of not cleaning up event listeners, and things like that.

Awesome. Alright. Well, I think that wraps up a segment on Ember Octane. Anything else you wanna make sure that we talk about before we close that and start looking towards the future?

I guess I’ll mention if anyone wants to give it a try, there’s a tutorial that was written by primarily our colleagues Godfrey and Vaidehi. If anyone’s seen the basecs (basics) series before, Vaidehi is one of the people behind that, or the main person behind that. So give it a shot, and if anyone has feedback, let us know. Hopefully, even if maybe you never use Ember again, our hope is that you might learn something about web development along the way, that you can take with you into your other projects.

Awesome. We’ll include a link to that tutorial in our show notes. And with that, let’s take another quick break, and when we come back we’ll start talking about the future of Ember and where it’s going.

Alright, welcome back. As we were chatting quickly in the break, Nick mentioned he had one more question about Octane… So Nick, shoot. Go for it.

Yeah, so kind of just doing a comparison between the 3.15 and 3.14 docs, I noticed that the 3.15 is really using more of the built-in ES2015 pus features like classes, and things like that… Is that specifically part of the Octane release?

Yeah, it is. Ember started before there was such a thing as JavaScript classes, for example… And so everything in Ember was objects for a really long time. It’s really great to have classes be a much more well-known concept in JavaScript land, and to be able to say – you know, if someone wants to level up their Ember, they can go study classes. I would point them towards the basics of that. Once you know classes, then it’s much easier for you to see the boundaries between where, you know, “This is just how classes work in JavaScript” and “This is something special that Ember is doing for you.”

[40:11] That line is really a tough one to walk across all of the front-end frameworks, because someone who’s new may not know where that boundary is… And that’s a tough part. A lot of times what people attribute to the learning curve of different libraries and tools is actually like they’re trying to learn this way of writing JavaScript that they haven’t done before.

Yeah… What does a class mean in Ember versus a class in Dojo Toolkit, for example?

I have no idea. But.

Exactly.

I never used it, but JavaScript classes are kind of the foundation there.

I’m curious, was there a particular feature that you were waiting, or a certain amount of adoption for it to only now be part of the 3.15 release?

Yeah, so there was the elephant in the room around decorators that was holding us back a little bit. We saw with Angular and TypeScript where they adopted decorators very early on this – how do we refer to it now? Do we call it stage three decorators, or something? The one where they were super-dynamic, and you could do a whole bunch of things with the decorators.

We didn’t want to jump in on that too early, because we care so much about backwards-compatibility. The worst-case scenario for us would be something like what happened with Angular, where they made it a huge part of their system, and then what decorators meant changed in TC39. So we were kind of waiting partially for that to kind of land, but then obviously because it’s taken so long, we decided ultimately to make a little bit of a bet that the conversations are going in the right direction now.

One of the things that’s interesting to think about in this same conversation about classes and TC39 is that Ember has had a bit of an influence in the wider JavaScript community through some of the work that Ember core team members and founders of Ember have had on TC39. And I don’t know a lot of the details; you’d have to probably get either Tom Dale or Yehuda Katz, to chat to them about it… But a lot of the discussions that they were having early days in the class syntax and some of the decorator stuff have actually made it into the wider JavaScript community from the early experiments with these weird objects that used to be class-like in Ember before.

Yeah, and I’ll add - we put in support for classes maybe a year ago, and in 3.15 is when we flipped the switch on saying “Hey everybody, this is what you should use if you’re building Ember apps today.” So that boundary between if you wanna be an early adopter, try these things out, versus if you want the cohesive, happy path, all the things make sense together as a bunch, then wait for when Octane was released, in 3.15.

Let’s talk about the future of Ember. And as we talk about the future, one of the things that I know has been in the periphery of my awareness around this - I see a lot of criticism pieces of “Oh, this is what’s wrong with Ember. That’s what’s wrong with Ember”, and I didn’t realize until we were talking about this leading up that those are there because you ask for them. [laughs] Because the core team actually asks all of the Ember community to write up what are the biggest criticisms they have of Ember to move things forward. So far from being a sign of the lack of health of the framework, they’re actually a sign of the robustness of the community and their willingness to self-critique.

[44:09] So that’s super-cool… I’d like to talk about a couple of those common critiques, and use that as a springboard to talk about what the future of Ember looks like. One of those that you’ve heard many times is bundle size. Ember is pretty big. And Chris, you mentioned there was an improvement where - upgrade the templating engine, users didn’t have to do anything and suddenly you had a 30% reduction in some set of your bundles. But it’s still a problem. Ember is still very large relative to, for example, building a small React app, or a small Svelte app, or a Vue app… Though once you get up to large-scale applications, you’re gonna have to add a lot of that functionality anyway; the difference may be smaller.

But what are you all doing about bundle size? And particularly, I think one of the big areas is for folks who aren’t building the next Facebook or something else where you’re gonna have lots and lots of JavaScript no matter what - how are you gonna be able to empower those folks to build apps that are clean and simple and don’t take a megabyte of JavaScript to get going?

Yeah, so that is something that a lot of people are working on in many different angles when it comes to… Some work in progress is around – you know, we talked about deprecations; imagine if you don’t have any deprecations… Being able to ditch that code and not include it. That’s a big one; that’s something that I know there’s a couple people working on. I myself have spent some time – one of my colleagues, Edward Faulkner, wrote a new build pipeline for Ember apps that relies on Webpack instead… There’s some transformations that happen during that build that help an Ember app to play by the rules of module resolution… And if you play by the rules of how the code comes together, it means that you can rely on the optimizations that other people have built for things like Webpack and just instantly get some improvements in terms of code-splitting, and stuff like that. That’s an open RFC (request for comments). I don’t know if we gave a definition of that earlier, but basically, an RFC is where a proposal is posted publicly, and everyone is invited to comment on it and influence the design of that proposal, talk about their own specific use cases, things like that. So there’s an RFC open for that.

Once RFCs get merged - it’s when the greenlight for like “Hey, if this thing was implemented as a spec, as described, it could be part of Ember.” So right now that’s something that’s in a big – definitely up for discussion. It works today to build your app in these new ways, so that you make optimizations, but again, our job doesn’t stop there; we have to consider how it impacts all of the add-ons and things that people have already written, and make sure that we plan out those migration paths.

So it takes time, but it’s things that people are working on, and what we are really aiming for is, again, kind of that zero config, freebie update experience, where you don’t have to do anything, or maybe you’ll have to do a little bit and you get these benefits.

There’s also an extra thing to say, just back on the Octane conversation. One of the key features of Octane was removing the need for jQuery. This is one of the things where Ember has been around forever; back in the early days, when we were supporting IE6, we didn’t do all of the DOM updates ourselves. A lot of the code framework code was just built on top of jQuery… Which allowed us to move fast, and it was a great idea back at the time. But then as browser APIs did so much better at unifying, there was less and less of a need for jQuery as a core part of Ember.

[48:17] So if you opt in to the removal of jQuery and any new app after Octane, when you generate it, it will already not have any jQuery in it, you can install it again if you need to use jQuery for something specific. But that’s already – I think it was like 80 kilobytes compressed, just knocked off the vendor bundle in one flag switch.

Another critique that I think is pretty interesting, and it sounds like Octane goes a long way towards addressing it, was that Ember was very slow to move to the component-focused model of web development. This is something that React really blazed the path forward on, but it seems as though every framework has been moving in that direction, of thinking about the way that we structure our applications as a set of components that interact.

There’s a phenomenal blog post that I think you sent me, Jen, where Andrew Callahan talks about how there were so many different ways in which “Well, this is almost a component, but not quite, because you do it in this other way. This is almost a component, but not quite, and you do it in this other way.” And it sounds like that is changing; I’ve love to get a sense of “Is that totally fixed now? Is that in the process of being fixed? Is that something where you see a different path forward?” How are you thinking about the way that Ember structures its world on how you think about an Ember application moving forward? Is it moving to this idea of completely component-oriented architecture, or are there still more pieces?

One of my fellow core team members, Chris Garrett, did a write-up a year or two ago where he described his wish for Ember to be what he referred to as a component service framework… With the idea being that we as developers spend most of our time writing components, but you still also need other types of things in your app that help to tie them all together, and that’s referred to as the services.

Truly, I think the biggest shift for Octane when it comes to putting components first is really [unintelligible 00:50:31.26] learning resources. Since Ember is maintained and led by people from all different companies, we don’t have a dedicated person who sits and works full-time on our docs, or goes around to do dev rel, and stuff like that… We rely on many, many, many hands, and also many insights, to pull that together. But that kind of restructuring, of like “How do you even teach someone to use Ember?” is an enormous amount of work. And with Octane and that kind of push of “Hey, there’s all these other things that are new and different”, this is the opportunity for us to overhaul it and really present a different mental model and a different learning path to people.

I’m super-thankful for a bunch of people who took huge chunks of time out to do those rearrangings, and then plus all of our communities members who updated the small pieces and all of the things that needed to change in syntax. So I think, from my perspective, we took the opportunity to do the big overhaul on a bunch of different levels, and it was time.

[51:50] I think this is also a great example where if we’re talking about the future of Ember, we really need to talk about RFCs in this context, where yes, there are situations in Ember currently where you have to do this special type of template that’s not a component to be able to do a route in a particular way. Now, if you talk to some people in Ember, that’s a positive thing, because there’s various things that you get by having this route-first model. But if you talk to other people, you get the opinions like the article that you were talking about, where it’s like “Oh, why do we have routes at all? Why don’t we just have components?” And the only real way forward for something like that in a community-driven project like Ember is for somebody to write an RFC, propose a way forward, and for us all to agree on that way forward… And then once that RFC is accepted or merged or whatever the right verb is there, for people to start doing the work. It’s something that [unintelligible 00:52:51.15] and Jen are quite passionate about, where having an RFC merged doesn’t mean that in the next version of Ember we’re gonna get this new, shiny thing. It means it’s ready for people to work on.

Actually, if you really, really care about a feature like that, you should help get an RFC through the process, and then put your hand up and say “Hey, I’m interested in helping getting this feature through the process.” And I’ll tell you now, actually when I was first brought on to the Ember learning team - I wasn’t actually a member of the core team, I was just a friend, somebody who was on the outside, but I was mentored specifically by people like Jen, people like Mel Sumner, to figure out how to get things moving, how to get changes made in Ember… And if you are motivated, there are always people willing to help you navigate the harder parts of actually getting something done.

Yeah, and there’s a bunch of people who are focused on that routing thing that Chris just brought up. I think that’s probably one of the last remaining pieces, now that we’ve got Octane out, that I know a lot of community members and core team members are working on. You asked about where we can use tracked, for example, and I said “Almost anywhere.” There’s still a few features of Ember that you can only use within certain files, and certain contexts, and it’s got kind of like a sticky API around it. There are a few more of those that need work, that need cleanup. The efforts for that are underway by lots of different people.

Awesome. Maybe to wrap up this future-facing section, let’s ask each of you what is the thing - whether it’s an RFC, or under active development, or part of the community process, but what are you most excited about looking forward for Ember for the next year, year-and-a-half?

That’s a really good question.

I know my answer, if you want me to go first, Jen…

Go ahead. Yes, I need to think about it for a minute.

So the thing that I’m most excited about is – it was part of the original Octane RFC, and if anybody listening to this podcast is curious on finding out more, I would highly recommend going back and looking at that RFC… Because it is so detailed, it is such an interesting way to look at how in the past we kind of positioned Ember in the future. It’s really quite worthwhile reading. But one whole section in there was about marketing, and it’s not just about making things easier to develop, making it more component-focused, making the component experience easier for developers. It’s also about upgrading documentation so that actually we’re communicating that you should be thinking about things in a slightly easier way… And we should also be upgrading our marketing materials such as our website.

[55:56] I have been working with a bunch of other contributors for the last year, plus much longer; it feels like it’s been going on forever, but it’s been a lot of work, and we are hoping to launch a new Ember website that better reflects the new messages that we’re trying to communicate about Ember. If you read the Octane release blog post, you get a certain feeling about Ember that’s not communicated by the website. That’s something that I’ve been passionate about, and it’s not in the next year, it’s in the next month or so that the first website is gonna go out, and it’s gonna be over the following months that all the guides, the blog, the different parts of the website will get the new design and the new structure.

Awesome. We will include a link to that original RFC then in our show notes as well, so if you’re listening along, drop down and take a look at that. Jen, how about you?

Yeah, so I think I would summarize the thing I’m looking most forward to is opportunities for Ember to work together with other existing tools, with other things in the JavaScript ecosystem. Add-ons are very cool; they serve special purposes to help you do awesome things using Ember’s features, but what I also really love is when I can just install any npm package and start using it. That’s true right now in Ember, but I think would be even – if the new build pipeline work, when that comes through, if it comes through, would really just unlock Ember working together with a lot of other tools within the JavaScript community. So that’s gonna be a really long road, but I would be so excited to see that happen. Anytime that we as developers can build off of what other people have learned, and really lean into the power of open source, that’s just a really incredible synchrony.

Awesome. Well, thank you both for joining us today on JS Party. Anyone have any final closing thoughts? Nick, you’ve been quiet for a little while; anything you wanna close out with, or Jen or Chris?

Yeah, I think that Ember looks really cool. Octane really puts a modern look on it, with all of the new features, and I’m really excited to look more into - I’m forgetting the name of the… The element modifiers, to look into that more, and see how I might be able to pull them out and reuse them in other places… Because that’s really cool.

My big takeaway, if I were to have people listening do one thing and one thing only, would be to do what you did today, Nick, and just try the quick start, try the tutorial… Because if you tried Ember before, like any time in the last eight years, and you have a preconceived notion about what Ember is based on that memory, it’s very different now. It feels like an entirely new framework, even though it’s not. So just try it. Spend an hour or two… It’s a bit of fun, on a weekend.

My own closing thoughts - it would be that for anyone who’s listening to the podcast, to always be on the lookout for things that you can do in your code that help other people work together. Whether it’s the APIs that you design, it’s the way that you scope the different parts of your codebase… Try to put on the lens of how it helps other people and how it might make their lives easier as developers, so that we can all keep building cool things.

Alright, and with that we’re gonna close this week’s party. Thank you all for making this a party, especially live listeners; those of you who are out there, thank you. You are what make this a party every week. If you’re listening to this after the fact and you wanna listen live, come join us on Thursdays. We record at 10 o’clock Pacific time, and we broadcast it live. There’s a Slack channel you can join… It’s a ton of fun. You are what make this a party. Thank you all. This is Kball, signing out.