Sean Thomas Larkin: Webpack 4: The State of the Art | JSConf Iceland 2018

how's it going that last talk was really freakin great like I wondered to myself I'm like I maintain this web compiler and like how many like tiny character tricks can we take from this but anyways maybe that's for a minute fire so yes thank you so the title of this talk is web pack for the state of the art and so for those who don't know me I am Sean Larkin and so I'm a project manager or program manager at Microsoft working at Microsoft edge and edge dev tools but you may know me as being one of the maintainer x' of the web pack core team and also spent time working on the angular CLI and just a general evangelist for open-source sustainability and then now kind of with my involvement through Microsoft and web pack helping represent you all at the node.js foundation for modules and also web assembly in their community group so a little bit about myself is I'm a tech support technical support rep gone rogue I got tired of not being able to solve people's problems and so I started learning AppleScript like who wrote AppleScript like yeah like that was my first programming language and then Ruby and then objective-c and then finally I found JavaScript you know I also like woodworking and Internet of Things but like I said sustainable open-source practices is one of probably my latest passions that I've been following now you can find me anywhere like anywhere most in most places with at the lark in and so if you wanted to tweet this out right now I'll give you a second take your time there's no rush but you can find me on any of those places so back back to the talk okay so web pack for the state of the art and state of the art so like I just wanted to pull up a little definition and there is that how you'd say it I stand off the list and is that the Icelandic version of that I'm not sure but you know we're talking about the recent stage of development or I don't want to call what we do avant-garde but at least you know the the latest release and what we're talking about today and so you know like it was mentioned we did just release webpack a hundred and twenty hours ago and it's here it's in latest web pack for is out and you can get it today but I want to talk about what web pack four represents and so for the first time we decided to take and give our major releases a codename and so this is called web pack legato so you might be like what like I know who's a like I'm a music major so in college so anybody else did music okay so you understand what legato means it's to express notes in a flowing matter without gaps in between them but we got this term from our major sponsor trivago so we we want to give the opportunity for one of our largest sponsors to name the to name this major release and so this was kind of their explanation you know at trivago we usually give our projects a name and a musical theme so for example they're all JavaScript framework was called harmony our new framework is called melody and on the PHP side they're using Symphony and the top layer is called Orchestra and so legato meaning to play without gaps expressive through through each note to them really embodied what it meant to have webpack for you know in their build system and how it ties everything together and you know before I go on and explain more I want you to just look at one of these slides or to each of them and if you see your company there or yourself I just want you to stand up right now so if any of this is you stand up I know I know there are many please so I want you to look around and I want to give I want you all to give them a round of applause because this is because without these people we would not be here today and webpack four may not exist so I just wanted to take take a second and recognize those people mm-hmm so you know we wanted to kind of create this higher level story about what webpack four meant meant for our users meant for us and so you know the first thing with smaller builds and faster builds the second was modernization and then finally probably one of the most important well I mean all of these are really important and not mutually exclusive which is developer experience and if I talk about smaller and faster builds and we try and break it down you can kind of categorize it here so like to have a smaller build you're going to need to do more analysis on the code and you're gonna have to process more of the module graph and then for faster builds though you're gonna have to do less work and reuse existing work that's already been done so these are kind of conflicting but for faster builds we completely reacted the way that we define what a chunk is and a chunk is just the in-memory version of the bundle you see created but we also added additional features like uglify j/s we're gonna be using it in parallel and cashing it out of the box and we also modernized a lot of the pieces that we had in just old es5 object syntax and we moved to using maps and sets but specifically I think one of the most important is the migration of our plug-in system we wrote it completely from the graph from the ground up and now we have what are called hooks which are create monomorphic code and we lazy compile them and I want to actually take a moment to explain well what is what is this mean who here is familiar with mano morphism or polymorphism okay so this may look familiar so this is an example of one of the methods that is available in our plug-in system prior to rewriting it and so if you see here this this method is what certain classes in web pack will call and plugins are listening to this event and what's passed in is a arbitrary like event string it's like an event emitter if you've ever used it before but the problem here is that this is polymorphic it can be any amount of arguments and there's no way for the JavaScript engine stopped mices so you know our initial answer was like oh why don't we get clever and just make separate methods with single arguments for each of them well that was not going to work one because we could have a plug-in system that's ginormous you have infinite amount of different event names and argument types that can be passed in and so it's unmaintainable and not really a great contributor experience and so it's like how could we how could we solve this where we're creating monomorphic functions but they're unique and you know we don't have a billion of them that we have to maintain so we use the technique to lazily compile based on what is listening to these events and I know I'm going a little deep here but it might make more sense in a moment but you can see at the bottom we're literally just composing a bunch of strings that are JavaScript that compile to these hooks and then we evaluate it and so like a really great resource if you're interested in this and I'll try not to butcher the name but V dot J's luff I got off wrote a great explainer article that you can go to and take a look at it to understand how this accomplishes monomorphic code and if you're on Twitter a lot like myself you may have seen this article that was like hey you may not need you know rust and webassembly to speed up your JavaScript well it turns out like how that looks pretty familiar the code that he showcased and look he's doing the same thing so the point is that we can create this monomorphic code but we're doing it kind of evaluative ly or lazy compiling it but please do not do this in your normal projects this is you know there are some parts of webpack that execute 19 million times on large code bases and so everything is in the hot path for us and so just as Benedict Moyer says or v8 senpai don't please don't do this please don't but so like what did this represent to us and so on most web pack builds we saw it get 98 percent faster so 98% of the build time was reduced just by people upgrading to web pack 498 yeah and you'd be like Shawn you're lying stop you embellish all the time and I'm like well it turns out that we have people who are reporting 6 hours of their build times on web pack 3 actually who's 9 hours but this he stopped at 6 on this run and so we were like we have an idea and after after showcasing this in the in the web pack for alpha we found 17 minutes 17 minutes from 9 hours so like there's the URL you can go to it I'm not lying and just to make sure so that people would be like Shawn you're still lying we just before once we got into our release candidacy I decided to you know play a little game to see hey 1 could we get people to upgrade to the beta so that we could catch early bugs warning signs things like that but - is this like speed boost really is this for real so um yeah I shot this out and like we seeing 75% on some cases we were seeing 90% 80% and so it's the real deal and so you know that build speed you know to sum it up we were able to accomplish that first piece in what our goals were but then we still had smaller builds now we have to do something basically completely opposite to what trying to get a faster build will do for you so the first thing that we tried to implement and we were able to do so is JSON tree-shaking so if you ever use JSON with webpack you'll notice that in version 3 it would bundle all of the pieces that you would import into it but we found out that really like JSON is just as a a stricter set of what JavaScript is and so we could treat it like an atmosphere module and only the pieces that are now used will actually get will stay in your code and so in this case you know you can just see we're just pulling in and importing one property and that's all that actually compiles when we minify the code we also have a feature well I'll explain the problem first so according to Equus grip module specification or the harmony module spec when you have multiple exports inside of a file every single one of them has to be evaluated and executed to ensure that they are not creating side-effects against each other so what does that mean well if lodash is exporting from a file essentially a thousand exports each one of them has to be included into your bundle so what we did and you can see that here in this tiny example so we did as we created this trick we had to tell the compiler some way like hey there are no side effects here you can go ahead and ignore those properties and so that's what we did we created the side effects property which now we're asking library authors to include in their package Jason's because what webpack will do in production mode is it will look for the presence of this this property and it will simply prune it out and in fact it actually makes builds faster when we are in the beta stages we found that our production builds were faster than the develop memo builds because of this feature because what you're doing is you're ignoring tracing those parts of the graph because you know they aren't actually used so in this case we saw something like in webpack 3 you know 200 KB of minimize code actually turned to 1 KB so hmm really all you need to do if you you know it's so easy all I have to do is just tree shake mangle your exports go POIs minimize and then package authors have to set side-effects oh that's ridiculous you shouldn't have to do any of that and that kind of gets into what developer experience is about all you should have to do is freakin run web pack and so out of the box now in web pack four we default to a production mode so all of those things you saw in that bullet point they just happen and so developer experience to us meant we need to lower the barrier to entry to people who are trying these tools for the first time not everybody understands the rigorous and obnoxious history of JavaScript modules and where they started and where they are now and we also need to have better defaults and thanks to libraries like parcel we can now coin something like zero config j/s and us zero config doesn't mean you know like letting you do whatever you want and shoving it into one package and then hoping not the feature that you don't use breaks and causes a major breaking change it means being able to actually extend a base scenario to your users so that it can you I oh you know bring your own zero config j/s and so this is really the line that we wanted to to cross so you know by defaults you don't even need a web pack config to use web pack for every property has been defaulted and what the future yeah now I'm not so that what I'm trying to say though is that not everybody will end up you know just ripping out their web pack config because the power of web pack is is deeply rooted in how extensible we are and so instead why don't we extend this idea so we also created this feature called mode and so mode is a property on the config or a flag that you can pass in the CLI and we default to production like I said and you know what it represents is that for development you're going to want to have tooling for the browser you're going to want to have really fast incremental compilation and you're gonna have better error messages that you know don't take up an entire console and then for production we're optimizing for size we're optimizing for the right kind of source code and we're optimizing for file paths that are understandable but don't leak you know information to the people using your website but it also means getting rid of things that used to really cause us problems like the Commons chunk plugin and web pack for it's gone we've replaced it with an API that does much of this out of the box by default but on top of that we have properties that give you more control than Commons chunk did and then finally you know build speed was something that we took so seriously that we wanted to be able to profile and analyze really deeply any long-running build and so we worked with Sam saucony from Google who helped us implement a special profiler that allows you to see every plug-in and how long takes right inside of the dev tools timeline viewer online yeah so now you can literally see and I mean this this information may be more valuable to us but it allows us to just say hey pop in a plugin and send us the events JSON file and it it's really useful for those who are creating plugins themselves and trying to analyze interactions and that kind of leaves us to you know the modernization in the Ryoka tech chure so you know one of the most important things that kind of held us back in web pack three is that we treat everything as a JavaScript module but we also were championed with being able to implement web assembly as a first-class citizen and so this gave us the opportunity to remove all of these everything is j/s hacks or it allowed us to actually implement wasm as a module type which allowed us to also implement JSON as a module type and it gave us JSON tree-shaking and then what we're working on right now is HTML and CSS module types so we had to take and remove all from you know our module factories is what we call them all of the code generation system that was specific to JavaScript and we've you know isolated it and so now with our web assembly is a first-class module type you have code like this this is um a newer library called Walt who has heard of Walt it's a subset of I guess you could say typescript and it allows you to write a very JavaScript like syntax as you see up at the top and then all you have to do is import it just like it's a JavaScript module into your code and you have used web assembly without doing anything else at your fingertips this is probably one of the most exciting things to me is that you want to use a frame or you want to use these things now what these these library authors can do is instantly compiled a web assembly module and if it's available in the package web pack will consume that instead of the JavaScript and so you get the 10x speed up instantly at your fingertips and so the other pieces were dropping node four so node four is no longer supported for web pack and node six is our minimum version but this allowed us to convert the rest of the codebase to using es6 features it a lot of code to be more readable easier to change using syntax that people understand and contributors want to actually leverage and now you know by using these this new code v8 actually has a great test bench for optimizing paths that aren't as hot yet that should be and I mean like as it was said there's we're just scratching the surface on all the different changes that we've made and so you know smaller builds and faster builds modernization developer experience that is where everything was routed in and so you might be like alright Sean this is great like how do i migrate so right now we have the pr pending for our migration guide and i'll talk about a little bit more and then what about four frameworks and plugins we've been working you know ever since we released our alpha behind the scenes with create react app pre-act CLI the angular CLI view CLI teams to make sure that and we we put extra focus on them to ensure that they had a steady path and there weren't blockers for them to test early but for right now you know in until we get that that migration guide merged i'd say jump on our medium publication or submit an issue and ask how you can help and like I said the angular CLI is actually going to be now supporting it in their next major release which I believe is like next week so look to have that automatically out-of-the-box for you and then you know a shameless plug to me you can always jump on my twitch livestream which I do two times a week and you can ask me questions any time we work with people just to help them migrate we also get people to contribute to the codebase and you know submit their first PR ever and even more so we wanted to make sure that this worked at scale and so Ken Shaw who's surprised appearing in these slides you know he is one of the lead engineers for the Outlook Web App team well as of I think a few days ago or was it yesterday the Outlook Web App is now using webpack for not only did the size of their builds instantly shrink without making any changes but their build times their inner dev loop jumped from a hundred seconds to 20 seconds and on a hundred fifty person team we're talking millions of dollars of Deb's time saved and so we're hoping to accomplish that not just for you know Microsoft and the outlook team but by vetting it in dogfooding it in that way we can ensure that it's a great experience for you so what's next like what's beyond web pack four so the things that we're gonna focus on are finishing the CSS is a module type HTML is a module type URL and file as a module type but as you can see what this means is you don't have to use extract text plug-in anymore you might not even need he I know you might not even need to have a CSS URL file loader we might just have this supported out-of-the-box as a module you'll be able to say hello to CSS code splitting something that doesn't exist today and actually you know cause this kind of a pain point for you know browser and load times but you could also have HTML as an entry point and then the other big feature that I'm really excited about which is called web packing lazon part two so you know when we introduce what web assembly is a first-class citizen we kind of can you know the module type is called web assembly / experimental and so the first thing is to stay lies it but then we're going to go ahead and add a bunch of the features that we that we already have on JavaScript and apply it to web assembly and so this means tree-shaking you can do that dead code elimination scope hosting wise modules and so this is super exciting because now web assembly goes from being something that you can use once or twice to using it just like any other JavaScript module and not taking a perfect or a size hit or a runtime hit and then maybe something that's really special for me is it's presets so like I said you know bring your own zero config j/s these are just examples that I played around with in a prototype but what if it would be just this easy to say at web pack can use Babel if exists you can install that package and it just reads your babel RC and throws in babel loader what if as a package author you have these composable parts that you can share and leverage this looks very similar to babel if you understand their package structure and we're you know at least i took the inspiration in this prototype to kind of leverage it but can use typescript really could just be can it resolve type scripting can it load it using a loader but the point is that this is how you can extend 0 config so with a couple packages that you would add you still don't need a web pack config yep thank you and so what's beyond what's beyond for point X so those are they're kind of like the things that we can do right now without causing a breaking change but what what's beyond that so one of the most important things that is lacking for web pack is that we don't have a fully persistent cache and so that's that's the first one that we're gonna be working on and so we actually kind of worked really closely with the author of hard source web pack plug-in new who has probably the most experience with our code base and you know disk caching and so he wrote up a specification and you can take a look at it on github think it's under the the webpack five tag but also things like multi-threading our builds actually when we saw the presentation or when I saw the presentation yesterday about having workers be native that was really exciting especially to us who wants to be able to have something right out of the box from node but also have all of our experimental module types become stable and then what if we could bring your own module type what if you could write a module type that makes you not even need a type script loader what if you could take those types and treat it as metadata and allow it to do static you know program flow analysis and make your code even smaller I see a future where it's you want to use typescript with web pack because it creates smaller bundles and so I really have a you know see a promise for bring your own module type I mean I mean to be honest these things are just a reflection of what you asked for and so did you know that every single one of you if you have a github account can go to web packages or forward slash vote and everyday even not as a contributor or sponsor you get one piece of influence every day that you can vote on a specific feature so I mean literally we put the power in you all because that's who we represent you saw our sponsors and backers we're a grassroots project that represents exactly what it means to have web performance and developer experience without making a sacrifice to each and you know finally you know we shipped web pack for what do we take away from it one of the things that we announced when we released the release candidate was that you know we we said here's 30 days log plugin and loader authors you get 30 days to upgrade we're not going to break any changes between our RCE and final and that was great for our team who owns a lot of the core plugins and loaders but it was a lot harder for people who you know third-party plugins and so I think what we're gonna do is focus more on providing a migration guide for loaders and plugins and even just general updating versus having a time window and I mean overall like you know like I just said I rambled about it a little early but we are like what we do is exactly what you asked us to and so we see this year of JavaScript as being you know no more talk of this fatigue but instead it's having this mindset of embracing the changes of our technology that are so beautiful in JavaScript some joke that we see a new framework every two weeks but that's the most beautiful part of our language in what other language do you get to use syntax that doesn't exist yet without a VM for you Java people does that doesn't count there is no other language it's it's a JavaScript Renaissance and so we embrace this we call it even a growth mindset at Microsoft and so we ask you to do the same and and help web pack just not be yet another build tool so thank you guys very much oh yeah and try web back today [Applause]

Channel: JSConf

Views: 15,001

Rating: 4.7849464 out of 5

Keywords:

Id: jUTE7lmrS70

Length: 30min 6sec (1806 seconds)

Published: Thu Apr 05 2018