Webpack in 5 Years?
From Author:
What can we learn from the last 10 years for the next 5 years? Is there a future for Webpack? What do we need to do now?
This talk has been presented at JSNation 2022, check out the latest edition of this JavaScript Conference.
FAQ
Webpack is funded and maintained through Open Collective, sponsors, and donations. Tobias Koppers, the creator, works full-time on Webpack as part of his job.
Webpack faces performance challenges due to its architecture, which is built for flexibility but not optimal for large-scale applications. Issues include garbage collection problems and difficulty leveraging multiple CPUs for computations.
Yes, Webpack is still relevant for new projects, especially if stability and a large ecosystem of plugins are important. However, new bundlers and tools are emerging, offering different features and potentially better performance.
In the next five years, Webpack is expected to remain relevant for existing projects. However, new tools and bundlers may emerge, offering alternatives for new projects. The focus will be on learning from the past decade and addressing current challenges.
Webpack is a module bundler for JavaScript applications, created by Tobias Koppers in 2012.
Webpack has significantly influenced web development by introducing code splitting, on-demand loading, and the concept of co-locating style sheets and assets with JavaScript modules. It has also promoted the use of bundlers for server-side processing.
Some key features of Webpack include code splitting, on-demand loading, a flexible plugin system, and the ability to bundle server-side applications.
Webpack is considered a stable choice because it has a large ecosystem of plugins, proven reliability over the past decade, and continuous growth in NPM downloads. It is particularly suitable for existing projects that require stability and flexibility.
Critics argue that Webpack's initial configuration can be overwhelming and complex, especially compared to its early days when a simple CLI command was sufficient. The complexity has increased due to the need to integrate various tools and preprocessors for modern web applications.
Future improvements for Webpack include optimizing default configurations, enhancing customization options, improving performance, and potentially adopting a new architecture for incremental builds.
Video Transcription
1. Webpack's Impact and Future
In the last 10 years, Webpack has shaped the way we develop web applications by introducing code splitting, co-locating style sheets and assets with JavaScript modules, and enabling bundling for server-side processing. Webpack's flexibility and large plugin system have also contributed to innovation in the ecosystem. While Webpack may not be the most hyped bundler, it remains a solid choice for stability, flexibility, and a wide range of use cases. Looking to the future, Webpack is likely to continue being used for existing projects, but new projects may have other choices. The lessons learned from 10 years of Webpack can guide future tools and improvements. However, due to time constraints, not all lessons can be covered in this talk, but they are available in the presentation slides.
So, my title is actually Webpack in Five Years, but actually that's only a click bait, so I looked you in. 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.
Oh, come on. So, my name is Tobias Koppers and I created Webpack in 2012, like 10 years from now, so maintenance, maintaining it for 10 years and I started with maintaining it for five 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 And maintain it as part of my job. I also have two children, five and three 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 it's like hundreds of years or so, and I think we can say that we at least shape the ecosystem a little bit and I try to find four things that we, I think Webpack shaped the way we develop 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 it's there to stay here and nowadays, every bundler is coming with code splitting on-demand loading and nearly everyone is using something like that. Another thing 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 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 modules spec and other things that embrace it and keep that in the ecosystem forever. And another little bit smaller thing is that we also learn to use like bundlers or pre-processing tools for server-side processing or Node.js. So often in an application that using Webpack and server-side rendering and stuff like that, then we also bundle our application on server-side, so that 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. 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 solution, new ideas can be developed combined with Webpack and also shapes new ideas in the ecosystem. So I think that's pretty good. But nowadays Webpack isn't the most hyped Bundler anymore, it's like more boring tools, maybe the stable choice or the choice if you already have something with Webpack, but in the Twitter ecosystem also, it's a 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 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 you 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 yes, 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, like, companies, 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 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 is 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. What happens in five years, I don't know. It's a really long time in the ecosystem. I decided to recap about the last ten years of Webpack and check what lessons we can learn from these ten years, and what we can, I can think what we can keep from Webpack, ten years of Webpack for the ecosystem and for Webpack in general. So, yeah. 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 there are so many lessons I collected preparing this talk that they actually don't fit in this talk. It's a hybrid conference, but what I did was prepared hundreds of slides for all this stuff and I showed them a split second and the remote audience can pause the stream and read all this stuff and see you in one hour after I discuss the important ones with the live audience. So the first one, initial configurations.
2. Webpack Configuration and Customization
The initial configuration for Webpack can be overwhelming, but it is necessary due to the complexity of modern web applications. Adapting to the ecosystem and having customizable defaults can help improve the development experience. Customization is important for both individual projects and the overall ecosystem, allowing for innovation and unblocking users. However, the current customization options in Webpack can be confusing, and the extensive API surface makes it difficult to iterate and maintain. To address these challenges, a simplified plugin concept and the inclusion of analytics for user feedback could be beneficial. Additionally, performance is an area where Webpack lags behind its competitors due to its use of Node.js.
So currently people often think that the initial configuration you need to get started with the project is too overwhelming, too large, too much stuff needed, and actually it didn't used to be that way in Webpack. When Webpack started you didn't need any configuration, it's just working with like a simple CLI command, but it actually was that we five years ago, we didn't develop that complex Web applications. Like nowadays everyone needs to use CSS, JavaScript, assets, they want to process image optimizing, they want JavaScript dialect like TypeScript or want to use stage three features that need to be transpiled for older bosses. They want to integrate extra compilers for their framework like React comes with JSX syntax, Svelte comes with a different compiler to compile the templates, Angular has like a preprocessing step for the production bits. Vue also has this cool single components, single file components which need to be processed. So there was a lot of tools added to like the web applications and Webpack didn't adapt to that a little bit, so it's kept having not really low defaults that are used that way.
So what can we do to fix that? Clickers not good. So I think we should be more optimized, in having defaults so we should adapt with the ecosystem. I also think we should acknowledge the fact that these 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 having presets that are versionised with 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, like, try it out, maybe publish it to npm, and let people use it, maybe it becomes the new standard we develop applications in the future. But it also helps to unblock users. If you're struggling with something that Bundler doesn't support, or your tool doesn't support, then you can actually go into modify, write a plugin, or customise the configuration to, like, have your use case, like, doing what you do, and actually get stuck with Bundler, and maybe have to switch because it doesn't support something. 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. And, 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. It is really complicated when you have to use the plugin loader combination with some configuration to do something, so it can be confusing. Another thing is that the API is, you can extend everything in Webpack. You have access to all the internals in Webpack. That's a problem because we don't know what is actually used. We can't change anything in our internal API, and that is really hard for us and also like makes easy to break stuff because it could change internals and that's weird. Yes. So, what can we do? So, what can we do? I think the idea is we shouldn't have this kind of plug in concept. I think it should only be like one plug in type which maybe has multiple levels of APIs. Like you have like a low level API and a higher level API where you can access both of these APIs from one single plug in and that would make it easier for people to use. Also makes the API surface more constrained to like only expose what we actually know is use by plug ins 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 communities like 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 what are the actually APIs used by plug ins so we can know what we should improve or what we can drop or duplicate in the future.
Another really large topic is performance. So like most competitors excel in performance because they are written in native languages and compared to Webpack, which is Node.js, Webpack is really bad at performance.
Comments