 Awesome. Can everyone hear me? All right, so Ember CLI, this image is courtesy. This morning, working on your slide deck late works out pretty well when people are submitting pictures of what you should maybe have as a title screen. So this is from Mike. Mike North made this for me. It's wonderful, isn't it? Right? So who here went to the morning workout? All right, so I figured this would happen. So everyone's going to stand up now and we're going to do jump. No, I'm just kidding. Tomorrow, though, right? We're all going to go to the gym tomorrow. All right, so that's me on the internet. I don't actually have glowy star things, but I feel if I change it, then people won't recognize me on the internet. So it'll be there forever. I like Ember. I work on Ember, Ember CLI, and pretty much anything else people let me work on. I'm a crazy bird person. My wife loans me out to open source often, so we should thank her. I work at Yahoo, and largely work on Ember at Yahoo. They've been awesome stewards of my open source work, and it's been fantastic. Recently, I've also started attending TC39, which has been pretty intimidating, but learning a lot. And I think we're in good hands with TC39. JavaScript will continue to become better, and this is good. And throughout the talk, feel free to ask questions, but be mindful. We only have 30 minutes. And if I can't answer your question during this talk, come find me afterwards. I would love to talk about this stuff. Anyways, so we have a little bit of a history with build tools in the front end world, especially in the Ember and previously Sprout Core world. So back in the day, we had the Sprout Core tools. Just a question, who here used Sprout Core? I used Sprout Core a long time ago. Stuff has changed. Who remembers this guy, BPM? Yeah! Woo! This was a truly ambitious project, maybe a little bit too ambitious. And unfortunately, all that remains is this archive.org thing. Actually, the repos are up, but there's lots of things from there. We're starting to finally realize now many years later. So rake pipeline. Then this guy happened. He was like, Steph, stop with these Ruby build tools. So we can blame or congratulate and thank Chris C for Ember CLI as it is today. No, no I did not. So there was Ember tools with common JS, and then there was Ember app kit. And the selling feature here really was ES6 modules. This was the first time a big framework had dedicated entirely to using ES6 modules. And at first, it was like, is this really the right thing? And I think in retrospect, I think it totally was the right thing. So thanks, Yehuda, for pushing us in that direction. Who here out here, yes, who used Ember app kit here? OK, so more than Sprout Core, who here enjoyed the upgrade process? All right, yeah. Add-ons, build performance. It left something truly to be desired. And I'm pretty sorry about it. All of a sudden, a wild Ember CLI 0.0.0 appeared. And I gave an Ember Conf talk here two years ago, something like that on it. It was more or less vaporware. And thanks to people like Joe Fiorini, who also shared in this belief that we could make something cool here and the rest of the community, it actually became a real thing. And just out of curiosity, who here is building an Ember app and not using Ember CLI? I think there's one, two, three. Is that right, three? All right, that's all right. OK, we should talk. So even two years when I gave this talk, I was like, I don't know if this is going to be the thing people are going to use, but seems to be working. In this time, we have tried for relentless quality. And I think we've set a good bar for what DevTools should be in this environment. And an important detail I think is often forgotten is the UX is important, but it's also extremely important for developers. Maybe we coined the term DX. I went on Urban Dictionary and made sure it wasn't anything very inappropriate. So we could probably use DX to say developer experience. Or not. And now we end up in a place where generally Ember CLI, except for the three people here, is the de facto foundation for building our ambitious web applications. And some cool stuff. It's actually being explored by some others in the domain. So Angular CLI is currently exploring using it. There's actually an unofficial React CLI that uses it. And I've seen a few others. So I think today we have a little bit of street cred. This idea works. And here's some cool statistics. So in its existence, there's been 2,754 closed issues, 2,817 closed pull requests, 321 contributors. Now this is awesome. There's more than 321 people at this conference. So come on, guys. About 5,000 commits, 92 releases, over 2,000 public add-ons. I know at companies like LinkedIn and Yahoo, we have a high number of internal add-ons as well. So I suspect this number might be a little bit higher. And since the beginning of time, there's been about 100 million live reloads. So the number Tom gave yesterday is totally factual in the last year. Or so we've done about 50 million. But since the beginning of time, we've done about 100 million live reloads. It's a pretty big number. I don't think these numbers are just fluff or vanity metrics. They are. They make me feel good. They should make all of you feel good as well. But their real value is they are the principal for our future investment. They justify our past investment. And I hope they enable confidence in everyone here and everyone in the community at large in continued future investment. Now, warning, I did some math. And although I have lots of math experience, apparently simple math, it's hard now. So I use Google and stuff. So if there's something wrong in these next numbers, I'm going to be so embarrassed, but just pretend like they're right. So imagine with this large user base that we have about 100 million reloads, if we do a 20% build improvement, and if, assuming the average build is about a second, we save over 1,000 days of developer time. Oh, sorry. That is totals about 1,000 developer days, and we save about 200 developer days. That's cool. And we've seen some performance improvements in the last year. But I'm pretty sure that with two developers, ending maybe two months or so of time at most, it's totally realistic for us to see another 5x or even 10x improvement in this space. That's a lot of time. Big numbers, lots of days saved. But we can actually justify that time. And it's also worth noting that not all developers work 24 hours a day, 365 days a year. So the numbers are even more in our favor. On average, I think developers are productive for four to five hours a day if they're not pulled into too many meetings. So we've got some cool leverage here. So let's just do it. Let's be more pedantic. Let's continue to invest. And someone's weekend project will benefit everyone in this room and beyond. So with this type of leverage, being pedantic really pays off. We have contributed to countless third-party libraries at the rest of the ecosystem uses, CUNIT, Portfinder, Testim, Windows, Node, NPM, Glob, Wuxync, Minimatch, LibuV, and it's basically countless. So even though Ember, we have our very specific tool chain, our uses of this tool chain, our investment in this tool chain, is improving the Node ecosystem and development ecosystem at large. Again, this gives us the time that we need. We can justify the time. Now we're going to get to the second part of my talk. And I want to talk about a little bit of a retrospective of what has worked in the last two years, what hasn't worked, and what are our next steps. So I think we can probably all agree that these things have worked. The sort of batteries included experience. I get sad when I see someone needs three or four years of Grunt or something experienced in their job posting. I mean, I think Grunt is a great tool. We use it in Ember app kit. But let's be honest. If being a web developer means you must have five years of experience using the build tools, I think we may have missed the point. The add-on ecosystem, I think, is working quite well. Being bullish on reinvestment in our own tech and tech that we use, and most importantly, the awesome community. So what has kind of maybe kind of worked by accident a little bit occasionally is the stability of Ember CLI. But I'm only saying this because compared to Ember app kit, it's wonderful. But we have to be honest here, it must become better. And what didn't really work at all? I think this is largely my fault, is enabling the community at large on some of the larger efforts. I've found it quite difficult to delegate, communicate my intentions, write them down, share responsibility. And it shows. The dependency management story, that leaves something to be desired, who said we need two package managers to be successful here. Bundles, base href, who here base href? Yeah, okay, I'm sorry again. Broccoli plug-in perf by default, and the Windows experience. I think it is not quite at the level that we want. All right, so problem with stability. Active development risks instability. Luck isn't the recipe for success, and as we want to accelerate our productivity, we have to fix this. The solution is straightforward. We're gonna copy Ember's release channels. Problem of enabling the community at large. Delegation, knowledge sharing, this is hard. So the solution is obvious, share all the things, but it's harder than that. But we have a solution, and that is the Ember CLI core team. We publish weekly minutes. We do all of our communication in Ember CLI, dev Ember CLI on the community Slack, so come and pop by. And a public RFC process. This is our Ember CLI core team. So I matched a few characteristics of people. Worf, and Nathan's hair. Chad's boyish good looks. I'm having fun, okay. This is the last slide I made this morning. I probably shouldn't have made it. So this is, I think, our recipe for community and success here is core team, open communication, RFC process, and release channels. I think this will enable the community and allow us to be successful. Now the next problem is balancing Bower and NPM. So balancing depths between two package managers. Come on, let's face it, one of our package managers can't even do it. But we still actually have to deal, I think, with dependencies from Bower. So I think the solution is for us to, Bower helped us, but I think archerjectory should be to transition away. Transition largely to NPM, encourage NPM dependencies, and move Bower support to an Ember CLI add-on. Now there's a lot of add-ons existing that depend on Bower, and I think what we'll just do for the time being is we'll auto-detect this and install this add-on on the fly so it'll continue to transparently work. But default Ember CLI installs won't include Bower. Next thing, a few people have come up to me and they said, Steph, my app is pretty big. Gotta do something about this. And I don't think the apps are actually too big. So our app's getting big, I think, is a sign of success. Building really large, really comprehensive systems, there are going to be big. I know at Yahoo, we have some projects that can have anywhere from 12 to 50 UI developers working on it. And the problem, it just expands. The app is scaling quite well, but really single files don't scale. So one of the tricky problems here is defining the boundaries automatically. And I think our solution is pretty obvious. Ingen's an async engine. So the work that Dan Gebhart and Rob have been doing, we're gonna work hard to make sure that Ember CLI can provide the foundation for automatically producing bundles for your engines and also exposing some better lower level API to craft your own composition as required. And yeah, today's build system has inefficient escape valves. Cool thing, Chad actually built a proof of concept of a package or linker solution last year that exposed this. And we're hoping to resurrect that effort this year and make it a real thing. This should also enable, in his proof of concept, he actually enabled HTTP2 serving and other experiments. So I hope that we can bring this to the general community at large. Unused code, another thing, this is the second part of Chad's work. It's actually the linker. So this allows Broccoli to be aware of the contents of files and choose the appropriate files to be part of your build. Base href, you know, this should have worked. I'm very sorry, but it should have worked. I think really what happened, one of the biggest pain points here is surprisingly SVG and base href just really don't like each other. Maybe this is the thing we should poke around in the standards body, but we need a short-term solution. And Rob proposed one, I think that's pretty good, doing asset rewriting both in Dev and prod just to fix the problem. We're just gonna fix this problem, pull it forward to kicking and screaming, and we're going to make it work. Now, the next thing, I think this has worked out very well for us. Some aspects of it can be improved still, but I want to explain a little bit why we use Broccoli. So we wanted just to build pipeline. We wanted to be able to curate the experience around the build pipeline. We wanted a tool that focused on a single responsibility, a module that does one thing and one thing very well. This is Broccoli. It can be sometimes explained as react for the file system. So we wanted to build pipeline that composes. So this is a real example where one day you who does like hey, Steph, let's get Ember and Glimmer integrated. Like, oh, no problem. I'll just literally require Glimmer's build pipeline, find it, merge it with Embers, and done. It's pretty easy, and this is really cool. Glimmer's built with TypeScript and an entirely different build pipeline, but these just two work. Now you can develop on Glimmer and Ember at the same time. And we didn't pollute any internal knowledge to accomplish this. Actually, all of our add-ons introduced their own build pipelines. And most people don't notice. Okay, that fade is killing me. Oh, goodness. So every app, this is actually an empty app. This is, you can't see, this is what Broccoli does. Come on, man. But don't panic. Oh, goodness. I'm gonna run out of time because of this filter. But okay, so this is what computers are made for. And everything, oh man, let's just do this. I'm sorry. I shouldn't have added that image at the last minute. Bear with me, guys. Okay, so this is what computers are made for. And all of this actually happens in 100 to 150 milliseconds. But we can actually still make it way faster. So just a quick Broccoli primer. This is the most basic Broccoli plugin or Broccoli pipeline I could think of. We're going to babble everything in the app directory, then JS hint it. So what basically happens, we take a directory, we throw it through babble, JS hint comes out the end. Some plugins take multiple inputs, like merge. So they combine multiple files of some trees, output this. So the external API doesn't expose any internals. So the implementation from the outside, the public API, is really without too many public, too many fundamental perf problems. The plugins do all of the work. But a small number of people actually have to use these plugins. So when we improve plugins, we can actually do so without breaking people's applications. This is a win. We can still do some more work here, but it's a win. So how do we actually make them fast? So I was a bit pedantic and I just spent two full weeks last year authoring tooling for Broccoli. So last year, if you remember, people's apps had grown again and people were experiencing 20, 30 second rebuilds on POSIC systems. And that's not cool. So when I started at Yahoo, there was a big app. It took 30, 35 seconds on rebuilds. This was not cool. So they gave me the time and I was pedantic. There were some ideas about what the performance problems were, but I really wasn't sure. But after this instrumentation landed, it was blatantly obvious what the problems were. So now there's some cool debugging tools, cool diagramming tools, but they've actually been quite useful. So what was actually slow here? Well, the interface between Broccoli plugins is the file system. Everyone's like, Steph, we could have told you that. The file system's pretty slow. The file system actually isn't slow. It's only slow if you really abuse it. And it turns out, Broccoli was taking advantage of some features of the file system that it didn't need to. We could be a little bit more intelligent in our Blockly plugins. We could get some pretty good perf out of it without breaking people's apps. So we invested some more, got some perf out of it, and using the developer tools I mentioned earlier, I came up with Broccoli plugins that applied patches rather than having to rewrite their whole output directory. And this was pretty good. Took 30 second plus rebuilds and dropped into 600 milliseconds. So that's a, sorry, I actually said I in that. It was actually a group of people that worked on it. I'm just taking all the credit for it, I guess. Chad Hytella and David Hamilton were super instrumental in making that work. And, but in the end, we ended up with upwards of a 50X improvement. And in some cases more, and in some cases a little bit less, but my app that we use at work, it had this performance characteristic improvement. The cool thing is, with this instrumentation, I can actually definitively say that even though 600 milliseconds sounds pretty cool for an app that has like, I don't know, a couple hundred, three to 500,000 lines of JavaScript app code, I can tell you that 70% of the time is still wasted. So that means we could conceivably see an app that size, rebuild it under 100 milliseconds. What this means is, from a build tool standpoint, we have a lot of headroom. We can let some really big apps grow and be totally successful. If we combine that with engines and bundling, it's gonna be pretty cool. So what's next? So, broccoli plugins right now, their time, the largest amount of time that they're spending is actually reading the input tree from the file system. So the solution, again, without changing or breaking the public API for broccoli, just updating the plugins, is to have plugins instead track their changes rather than diffing their input. And this is basically the remaining time. This is non-trivial work, but we can do it. Another thing, window support for broccoli. I think we've come pretty far. We have app air builds thanks to Ray Tiley's company, who's donated app air builds to us. This has been invaluable. And out of curiosity, who here uses windows and broccoli? Is the experience like okay? It's okay. Could it be better? Definitely. So we've been working pretty close with Microsoft, who happened to like Ember. And, oh, some tangent here. This train tracking and diffing stuff, it actually will remove the need for simlinks in broccoli, and tons of disk IO, and I think this is gonna make a really big difference on Windows systems, as is. But today, if you were following the news, our friends at Microsoft had a really cool announcement, and that is Windows 10 users will soon be able to basically just be able to run actual bash. And I believe I'm a little bit hazy on the detail, so Felix, feel free to correct me, but I believe they can just bundle Ubuntu binaries and transparently make all of this work and not suck. So yesterday, I heard rumors of this. Basically, I saw a smile on Felix's face, and I knew he couldn't tell me something. And then this morning, I got a frantic set of tweets saying, it landed, it landed, it landed, it landed, it landed, the news broke, I can tell you now. And he sent me cool screenshots, and I added it here. But for our Windows users, this is gonna be fantastic. Anyways, there's another part, and that is although the broccoli performance improvements have landed, the benefits are still not for everyone in this room. I think there's probably not a good reason other than more work on my behalf and maybe your behalf, but everyone's builds here should be sub-second time for rebuilds. If you're not there yet, make sure to read this performance guide. And I think there's still a few broccoli plugins that are a little bit inefficient because it's a little bit too tricky to write these new types of broccoli plugins. So another ongoing effort that I would love help with is to come up with a better set of tools for broccoli plugins to use, just to do the right thing correctly. Do the Ember thing, whereas we want the broccoli plugin authors to fall into a pit of success by default, not require Robert or myself to go and fix every broccoli plugin in existence. Coming up with this API is really tricky. For anyone who's interested, ping me on Twitter, find us in the Ember CLI dev channel on Slack, open issues, I would love to work with a group of people to figure out what this API can be so that everyone who writes a broccoli plugin will get a fast-performant plugin by default. So that was just an example of being pedantic, scratching my own itch, my app was slow. It's pretty worth it, 50X performance improvement, that's awesome, but there's countless examples of that in Ember CLI. For example, Eric Trom spent a lot of time making sure that our port finder implementation worked. He actually went and fixed the port finder, he learned how all of these details work on Linux and on Windows and on OS X, and I think if he was just working on his own project, he wouldn't have been able to justify that investment, but because that investment benefited everyone in this room and beyond, it was totally worth it and it was totally justified and it was super exciting when that pull request landed. So come help us invest in the SDK for the web, thanks. The question was, is Ember CLI 113 and Ember CLI 2.4 compatible with Ember 113 applications? So this is probably under documented, but Ember CLI has very little coupling to Ember itself, so it's totally possible, although maybe undocumented, to get an Ember 113 or Ember 1.0 application working on the latest version of Ember CLI. We actually did upgrade, it's all working now, it's just I was holding back because it wasn't very clear as to whether you were using anything and I was afraid that maybe under the covers you might use some feature that's not available yet. Yeah, so the answer is totally no, it would have worked, maybe a little bit of massaging your dependencies, but the 2.4 branch of Ember CLI will totally be able to build a 1x13 version of Ember. In the 2x series of Ember CLI, we're actually working to decouple it even more, so blueprints will actually be pinned to your version of Ember and pinned to your version of Ember data. So if you have a 2.4 version of Ember CLI and some other version of Ember Ember data, you'll get the appropriate blueprints for that version of Ember. Thanks, no problem. Any other questions? Since there's no questions, I'm really excited to see all of you as new contributors. All right, thank you very much and I hope you enjoy the rest of the conference.