JS Nation

JSNation 2022

Webpack in 5 Years?

So my title is actually Webpack in 5 Years, but actually that's only a clickbait, so I will talk about the last 10 years of Webpack and what we can learn for Webpack and for the community as a whole and for the ecosystem about these last 10 years, what mistakes we made, what problems we have and what we can do better. So my name is Tobias Koppers and I created Webpack in 2012, like 10 years from now, so it's maintaining it for 10 years and I started with maintaining it for 5 years in part-time, like 10 hours per week, and then I migrated to full-time working on Webpack, funded from Open Collective, from sponsors, donations and stuff like that, and now I work more than one year for Versil and maintaining it as part of my job. I also have two children, 5 and 3 years, and live in Germany, in Bavaria, so nearby a little bit. So 10 years of Webpack, I think we should celebrate that, and it's actually a pretty long time for the web ecosystem, like 10 years in web years is like hundreds of years or so, and I think we can say that we at least shaped the ecosystem a little bit, and I try to find four things that we, I think Webpack shaped the way we developed web applications. So one thing why I started Webpack was to add code splitting to bundlers and on-demand loading, and I think that's something that has been established in the community since then and I think that is there to stay here, and nowadays every bundler is coming with code splitting on-demand loading and nearly everyone is using something like that. And another thing that we did promote or embrace is having this idea of combining, co-locating your style sheets, your assets and your other non-JavaScript stuff with your JavaScript modules, so it's like having this one graph of your application where everything is imported by each other, and I think that's also something that will stay in the community, and even specs involved, like CSS module spec and other things that embrace it and keep that in the ecosystem forever. Another little bit smaller thing is that we also learned to use bundlers or pre-processing tools for server-side processing on Node.js, so often in an application that's using Webpack and server-side rendering and stuff like that, then we also bundle our application on server-side, so that's something that wasn't there before Webpack, probably because we didn't need that, but I think that's also something that will probably stay in the community at least for a while. And another larger thing that I think Webpack embraced is flexibility. So Webpack started with really a flexible way, a large plugin system with huge abilities to extend and configure and customize your build, and I think that's something that really embraced the innovation in the ecosystem, and new solutions, new ideas can be developed combined with Webpack and also shape the new ideas in the ecosystem. So I think that's pretty good, but nowadays Webpack isn't the most hyped bundle anymore, it's more the boring tool, maybe the stable choice, or the choice if you already have something with Webpack, but they are in the Twitter ecosystem also, in the hype-based development team, there are new bundlers that come up, or new non-bundling tools that are pretty hyped and make good things, and probably everyone has a feature that's better than something in Webpack, and maybe performance or optimizing or something. So that's pretty much the hyped newest kind of things coming up. And I still think Webpack is still the solid choice when you want to have something that is really stable or really flexible and maybe covers a lot of use cases or also have a lot of ecosystem plugins you want to use. And actually I looked at the NPM downloads and Webpack is still growing, so it's not that it's declining or something that's happening here, but yeah, we see that there is a lot of new stuff coming up in the ecosystem. So what does the future look like for Webpack and for the ecosystem in general? Will Webpack still be used in five years? I think yes, at least for existing projects, because companies or teams don't change the stack so often, it's more like they use stuff for more years than we can think of. Actually people are still using Webpack 2, which is like five years old, and they don't mind not upgrading stuff for a long time if it's working. And I think it's deemed to work, at least. For new projects, there's another choice. I don't know what's happening in five years. It could be that something new is developed that might be better, or there are obvious other choices you can use and start with new projects. So what happens in five years? I don't know. It's a really long time in the ecosystem. So I decided to recap the last ten years of Webpack and check what lessons we can learn from these ten years and what I can think we can keep from Webpack, ten years of Webpack for the ecosystem and for Webpack in general. So I also want to say what we can do now, or we can do in future tools on Webpack to fix these problems or to keep these lessons learned. The problem is that there are so many lessons I collected during preparing this talk that they actually don't fit in this talk. What I did, it's a hybrid conference, so what I did is prepared hundreds of slides for all this stuff, and I showed them a split second, and the remote audience can pause the stream, read all the stuff, and we see one hour after I discussed the important ones with the live audience. So the first one, initial configuration. So currently people often think that the initial configuration you need to get started with a project is too overwhelming, too large, too much stuff needed. And actually it didn't used to be that way in Webpack. It was more when Webpack started, you didn't need any configuration, it's just working with a simple CLI command. But it actually was that five years ago, we didn't develop that complex web application. Like nowadays, everyone needs to use CSS, JavaScript, assets, they want to process image optimising, they want JavaScript dialect like TypeScript, or want to use stage 3 features that need to be transpiled for older browsers. They want to integrate extra compilers for their framework like React comes with JSX syntax, Vue comes with a different compiler to compile the templates, Angular has a preprocessing step for the production builds, Vue also has this cool single file components which need to be processed. So there was a lot of tools added to the web applications and Webpack didn't adapt to that a little bit. It kept being unoptimised, it kept having not really low defaults that used that way. So what can we do to fix that? Clicker's not good. So I think we should be more optimised and optionated in having defaults, so like we should adapt with the ecosystem. I also think we should acknowledge the fact that this defaults change over time, like ten years from now, maybe five years from now, we have probably very different defaults than we now have. What I think we can do is like having something, what some people already do is like versionising defaults, having presets that are versionised with the dependencies so we can slowly adapt with the ecosystem but also keep your project locked in a certain version of defaults without having a lot of breaking changes. Another topic is customising. So I think customising is really important and also really important for the ecosystem, even if you're not directly using it for your project, because it embraces this innovation concept of the ecosystem where you can look, like, you have a cool idea and can write a plugin for your bundler and for your tooling and try it out, maybe publish it to NPM and let people use it, maybe it becomes a new standard for web applications in the future. But it also helps to unblock users. So if you're struggling with something that bundler doesn't support or your tool doesn't support, then you can actually go into modify it, write a plugin, or customise the configuration to have your use case, like doing what you do, and to actually get stuck with a bundler and maybe have to switch because it doesn't support something. So I also think that was one success factor of Webpack in the early days and maybe also nowadays that it really has this idea of flexibility and customising and stuff like that. But it also is confusing in some kind of things. Like there are three levels of customising, you have configuration, you have plugins, you have loaders, and it's really complicated when you have to use a plugin-loader combination with some configuration to do something. So it can be confusing. Another thing is that the API is like you can extend everything in Webpack, you have access to all the internals in Webpack, and that's a problem because we don't know what's actually used, we can't change anything in our internal API, and that's really hard for us and also makes it easy to break stuff because we could change internals and that's weird. So what can we do? I think the idea is we shouldn't have this kind of loader-plugin concept. I think it should only be one plugin type which maybe has multiple levels of APIs. You have a low-level API and a higher-level API where you can access both of these APIs from one single plugin and that would make it easier for people to use it. Also makes the API surface more convenient to only expose what we actually know is used by plugins and don't expose all the internals which makes it hard for us to iterate on internals. What would also help but it's really difficult to embrace in the community is having some analytics where we actually get feedback from the user, maybe automated or maybe by opt-in or something like that, where you can report back what are the actually APIs used by plugins so we can know what we should improve or what we can drop or duplicate in the future. Another really large topic is performance. The most competitors excel in performance because they are written in native languages and compared to Webpack which is Node.js, JavaScript, Webpack is really bad at performance. It doesn't used to be the way, so like 10 years ago nobody or less people complained about performance and it was fine but at least in larger scale there are problems with performance because of reasons. Probably the most problematic stuff is that we are struggling with garbage collector a lot because of large module graph which are creating a lot of objects and that's bad for JavaScript and also using JavaScript in Node.js makes it really difficult to leverage multiple CPUs to do these computations. But there are also architectural problems. Our architecture is really built for flexibility so on each compilation we build up everything from the start and so we have the best ability for plugins to, the easiest way for plugins to make that changes but that's not the best architecture for performance. It would be really better to have some kind of incremental processing, optimized architecture. So what we need to, what we should do, but it's really difficult to fix that in Webpack is better it would be to use a native language where we can leverage multiple CPUs and also start with the architecture that have this incremental build by design, having it not depend on application size. It's also brings me to the next point, large scale applications. Actually applications get bigger and bigger and that's a problem because the performance problems in Webpack are really exposed because in Webpack it's kind of fast for incremental builds but a little bit it scales by application size and that gets more serious when the application grows and there are workarounds where you can split your applications in multiple small applications or even something like lazy compilation where you only compile on development what you're actually using. That helps but there are workarounds and I would prefer if we have an architecture that would scale with applications in a better way. What I think we should do is lazy must be the default for the future. Everything should be lazy computed and lazy just scales better with large applications because then you probably don't work on the whole application at once. You work on parts of that and if you only need to compile that part then the large scale of the application doesn't become so serious. What I always say, we should embrace an architecture where incremental performance doesn't scale with application size. It should be constant at all this and it should be fast all this. That would be great. I also think if you embrace this incremental stuff, you should also embrace it on everywhere like production build should be incremental, on CI we should be incremental, dev build should be incremental, which they already are, but we should be incremental everywhere and we should also have less ways to opt out of incrementally. We should change dependencies, why does it have to reset the cache? It should keep being incremental. That would be cool. Now the slides for the remote audience. Don't forget to pause the stream. Come on, optimisation, server components and more stuff that we can learn from the last ten years of Webpack. So back to the slides. Okay, so these problems with performance and architecture, we can't really change that in Webpack. It's like we can't refactor the whole architecture and rewrite in a native language that would break every plugin, every user, and maybe every install process and stuff like that. It actually would make more sense to create a new stuff which would maybe whoop-pack or something and that would have this new architecture. But there are trade-offs with that and I try to summarise it a little bit. So what fixing problems versus a rewrite, does it make sense? So when we fix the problems, we actually would keep the ecosystem, the trust and the adoption of Webpack, while a rewrite would lose all the ecosystem or the plugin would be lost on this rewrite and we need to regain adoption for whoop-pack instead of Webpack. And yeah, that's hard and it would take more than five years probably and it's also hard to make a migration for users to migrate to something like whoop-pack. But on the other side, we can't fix everything in Webpack, what we learned. We can't change the architecture, we can't constrain the API surface because it would also break all the users. So it's impossible to fix some problems in existing Webpack. While in the rewrite we could optimise our architecture for incremental builds, we could fix these deeper problems on the performance side. But is it worth it? I don't know. That's a good question. On the other side, fixing problems could also, like fixing these larger problems, has also a little bit of risk of breaking users while rewriting would break every user, obviously. It wouldn't break users, yeah. You could keep using Webpack and migrate to whoop-pack later. So makes sense, yeah? It's also hard to do a rewrite because it would take maybe years to rewrite everything. You have the same abilities of Webpack while in fixing problems in Webpack, it would make smaller steps towards the process and make direct benefits for the users and that can also be done with a smaller team and rewriting would be complicated. So trade-offs, as always. So thank you. I guess we have some questions. Yes, thanks a lot, Tobias. So for those of you who have questions, don't forget you can go to sly.do and enter the code 1620, I should have remembered this code, I can check. You can ask your questions and then I can ask them to Tobias right here. So first question is from Ro, would you recommend starting new React projects with Webpack and if yes, why? I would recommend that because I created Webpack. I think it's like a matter of flavour, I guess. So Webpack is probably the solid choice, a good choice if you want to have a stable choice. You can start with other bundlers. I actually don't know what are the limitations of them. You could run into something and they are younger so you can start with them. I guess you can always start with something else and then change your stack later. So the answer is, as a proper developer says, it depends. So for the people that want to go to the other track for the next talk, you can switch now because we're going to start that in a few minutes and you can, of course, stay here also. And next question is from Rob also, why should you use React? Why? Why should you use Webpack as a React developer? So what benefit does Webpack bring you as a React developer? It has a large ecosystem and it has large pre-built solutions for React so you can just start with the boilerplate or with tools that exist in the ecosystem. It's easy to get started with Webpack and it also works well, I think, and it used to work well for like five years or so, so I guess it's a good choice and makes sense. It's a proven technology. An anonymous question. The ideas of solving Webpack issues sound great. Does a roadmap exist for currently implementing those, and should we expect more improvements in future versions? We don't have an official roadmap, so it's like we never had one. It's more like we do what we think is currently best for the ecosystem. So it's like we're trying to improve these problems incrementally, and that's basically a roadmap. And, yeah, I summarised these challenges and problems in the talk, and I guess we can fix some of these problems right now, and many of them are kind of not that complicated to fix, like making defaults is something we could do. So I think that's going to be happening, probably. Someday soon. Someday soon, yeah. But we don't have timelines, or we never had timelines for everything, because it creates pressure and we don't want to have this package. It's an open source project and most of the contributors are working on free time on that, so it's not something that we want to create deadlines, and it's no need to have deadlines for us. So besides you, how many people work on Webpack full-time, then? Yeah, not that many, it's like two people working full-time on Webpack, so me and somebody else. But it's a little bit problematic, because we also have less funding last time, so it's the winter for JavaScript ecosystem mostly, and it might be a problem in the future that we have two small teams to make larger improvements. Yeah, it's weird that basically nine out of ten companies run on Webpack, and you have to run from open source contribution space. Yeah, that's the problem. So I think open source has a really hard time to get funded, and I guess there's also a discussion about that today, so feel free to join me there. All right. I think we're going to do one last question. Question is from Thomas. Where do you see yourself standing against new building tools leveraging new browser features like Vite? I think we will do something to make similar choices. So actually, we probably will copy or steal stuff from new bundlers. Or borrow. Yeah, it's not criminal. I think that's the benefit of the open source ecosystem. You're actually allowed to steal or copy stuff. I also think these tools copied a lot from Webpack, so it's not that it's only one way. I think more as an ecosystem of the Web ecosystem, and we all benefit from these competitors, and we benefit as an ecosystem as a whole from these developments. New ideas and new technologies emerge that all will benefit from them. Yeah, I guess that's a good way to go about it. You have to share from each other, and it's all open source. So that was all the time we have for Q&A. If you want to continue the conversation, you can go to the monetization of open source discussion room. And right now, you're going to go to the speaker lounge where people can also continue the conversation. See you there. Thanks, guys.


Tobias Koppers

React Summit

React Summit 2022

The Only Way to Eat an Elephant - Code Splitting With Server Side Rendering

Hi, my name is Lena and today I'm here to tell you about the only way to eat an elephant. You can probably remember it bit by bit. And I have one disclaimer to make. No, I do remember it's a React conference. But I will be telling my brief story of SSR code splitting and why you need to use them both using vanilla JS mostly. So it all started at the time when there was no React. Someone does remember these times and someone can't even believe that there was such time when there was no React. But that time all HTML pages were served as strings. You wouldn't believe that. But the whole content was a string served from servers and it looked something like this. One road for a whole HTML content and there were many of them as much as many roads you have. And actually everybody was happy that time. It was pretty straightforward actually until there they were not. And you can probably guess the reason. It was because of JavaScript. So it became too tedious to handle all the JavaScript, all DOM manipulation with jQuery, you know, with rendering tools like EGS, handlebars and many, many more in every server language. And also the server round trips made people suffer. And I can hardly tell you who suffered more, users or developers with all their JavaScript jQuery and handlebars. So JavaScript heroes came and they decided to have SPAs, single page applications. And they were imagining rendering content, all the content on the client side. And they decided that browser can handle navigation without going back to server. And they think, they thought it was cool. And also they decided they can do client side routing. Not because it is easy but because it is hard. But they can. And they changed the HTML because it became very small and shallow. And nothing actually was rendered on server anymore. Everything was rendered in client side with one of JavaScript frameworks. And there became more JavaScript. More tools to build it in one bundle. And more JavaScript problems to solve. More JavaScript conference to talk about these problems. And new monsters were born. Actually more JavaScript resulted in more, in bigger bundle sizes which resulted in worse performance. First rendering and everything else. And actually users became, started to suffer. And also business started to suffer. Because SEO was a problem. Crawlers can't read JavaScript. They need strings. So JavaScript heroes came back again and they decided to have SSR back. But this time was there the same JavaScript they wrote because it was so beautiful to throw it away. And they decided that the solution is to render this JavaScript they have to a string on server. And to have JavaScript function returning a string. So that was a good solution for SSR and it solved SEO problem. But it didn't solve bundle size problem, right? So they were using both the same JavaScript on client side and server side. So JavaScript heroes decided so that they need to come up with an idea of code splitting. And they did. They did this dynamic imports. Here you can see that there is one problem with this code. Not because it's not in React but because it's asynchronous. And it does solve the problem of a big JavaScript bundle. You can see that now the content not in one bundle but loads dynamically. But dynamic imports is for client side. And they can't be rendered on server side because server side needs to do it synchronously. So when the content, when your content depends on the route, meaning you need this content right away for client to see it, you can have code splitting both on server and client side. The only problem you need to solve is to decide on the environment you're in and to load it synchronously when you are not in client side environment and load it asynchronously when you are. So this is vanilla JS solution for this problem. And as much as I like vanilla JS, we all know it is, it doesn't scale. It solves the problem but it doesn't scale. But luckily we have React and library solution for it. And we have loadable components. And it is that easy with loadable components. As I wrote it in vanilla JS, all you need to do is have to feed this library information about all the chunks you have to ask it to render your content as a string on server side. And then loadable will decide as if by magic in what environment you are. And it will render your content server side and client side and with code splitting so you will not serve big bundles to your clients. So happily ever after, SSR codes was married to, SSR and code splitting were married to React and loadable components and our users are happy and our JS heroes ready for new monsters to conquer. Thank you. Thank you for coming.


Lena Zhukova

JSNation Live

JSNation Live 2020

Module Federation in Webpack 5

#webpack