Webpack in 5 Years?

Rate this content

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?

26 min
16 Jun, 2022


Sign in or register to post your comment.

AI Generated Video Summary

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. The initial configuration for Webpack can be overwhelming, but it is necessary due to the complexity of modern web applications. In larger scale applications, there are performance problems in Webpack due to issues with garbage collection, leveraging multiple CPUs, and architectural limitations. Fixing problems in Webpack has trade-offs, but a rewrite could optimize architecture and fix performance issues.

1. Webpack's Impact and Future

Short description:

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

Short description:

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.

3. Performance and Architecture Challenges

Short description:

In larger scale applications, there are performance problems in Webpack due to issues with garbage collection, leveraging multiple CPUs, and architectural limitations. To address these challenges, it would be beneficial to have an incremental processing and optimized architecture that scales with application size. Embracing a lazy-computated approach and ensuring incremental builds across different environments can also improve performance. However, it is difficult to fix these issues in Webpack without breaking the ecosystem and losing adoption. Consideration can be given to creating a new bundler with a redesigned architecture, but this approach has trade-offs and would require a significant migration effort.

It doesn't used to be the way. So if ten 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 collect a lot because of large model graphs which create a lot of objects and that is bad and using Javascript makes it difficult to leverage multiple CPUs to do computations. But there are also architectural problems. Our architecture is really built for flexibility. On each compilation we built up everything from the start. We have the best ability for plugins, the easiest way for plugins to make their changes but that is not the best architecture for performance. It would be really better to have some kind of incremental processing, optimised architecture.

So what we need to do, what we should do, but it is really difficult to fix that in Webpack is better it would be to use a native language, so that we can leverage multiple CPUs and also start with architecture that have this incremental build by design, like having it not depend on application size. It also brings me to the next point that is large-scale applications. Like, actually applications get bigger and bigger and that is a problem because the performance problems in Webpack are really exposed, because in Webpack, it is kind of fast for incremental build, 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 if we have an architecture that would scale with applications in a better way.

What I think we should do is, like, lazy must be default for the future, like everything should be lazy-computated and lazy just scales better with large applications, because then you probably don't work on the whole application at once, like we 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. And, yeah, what I always say, we should embrace an architecture where the incremental performance doesn't scale with the application size, it should be constant at all this, and it should be fast always. That would be great. I also think, like, if you embrace incremental stuff, you should also embrace it on everywhere, like production build should be incremental on CI, it should be incremental, dev build should be incremental, which they are, but we should be incremental everywhere, and we should also have less ways to opt out of incrementally, like, if you change the parentheses, why does it have to reset the cache? It should keep being incremental. That would be cool.

So, back to the slides. Okay, so, these problems with performance and architecture, we can't really change that in Webpack. We can't refactor the whole architecture and rewrite in the native language that would break every plugin, every loader, every user, and maybe every in-style processor and stuff like that. So, it actually would make more sense to create a new stuff which would maybe WhoopPack 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, we have 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, the plugins and loaders would be lost on this rewrite, and we need to regain adoption for Webpack, and, yes, that is hard, and it would take more than five years, probably, and it is also hard to make a migration for users to migrate to something like Webpack. Yes. But on the other side, we can't fix everything in Webpack, what we learnt, we can't change the architecture, we can't constrain the API surface, because it would also break all the So, it is impossible to fix some problems in existing Webpack.


Trade-offs and Recommendations

Short description:

Fixing problems in Webpack has trade-offs. A rewrite would lose the ecosystem and require regaining adoption, while fixing problems has the risk of breaking users. However, a rewrite could optimize architecture and fix performance issues. It is hard to do a rewrite and would take years, while fixing problems can be done incrementally with direct benefits for users. Trade-offs exist. As for questions, starting new React projects with Webpack is recommended for stability, but it depends on personal preference. Webpack brings a large ecosystem and prebuilt solutions for React development.

But there are trade-offs with that, and I try to summarise it a little bit. So, what fixing problems, we have 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, the plugins and loaders would be lost on this rewrite, and we need to regain adoption for Webpack, and, yes, that is hard, and it would take more than five years, probably, and it is also hard to make a migration for users to migrate to something like Webpack. Yes. But on the other side, we can't fix everything in Webpack, what we learnt, we can't change the architecture, we can't constrain the API surface, because it would also break all the So, it is impossible to fix some problems in existing Webpack. While in 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. Yes, on the other side, like, fixing problems could also, like, fixing the larger problems also has also a little bit of risk of breaking users while rewriting would break, like, every user, obviously. Actually, it wouldn't break users. You could keep using Webpack and migrate to Webpack later, so it makes sense. It is also hard to do a rewrite because it would like take maybe years to rewrite everything. You have like the same abilities of Webpack while in fixing problems in Webpack, it would make smaller steps towards the process and like 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? Thank you. So for those of you who have questions, don't forget you can go to slide.do and enter the code 1620 to 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? Yeah, I would recommend that because I created Webpack. I think it's like a matter of flavor, 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 bundles. I actually don't know what are the limitations of them. So you could run into something and they are younger, so you can start with them. And I guess you can also always start with something else and then change the stack later. So it's like fee-fee. 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? Yeah, it has a lot of ecosystem, and you have had large prebuilt solutions for React. So you can just start with a boilerplate or with tools that exist in the ecosystem.

Getting Started and Future Improvements

Short description:

Webpack is easy to get started with and has been a proven technology for many years. While there is no official roadmap, the team is continuously working to improve the ecosystem and address challenges incrementally. Funding and limited resources can be a challenge, but the open-source community plays a crucial role in the project's success. Webpack is open to learning from and collaborating with other building tools in the web ecosystem. The Q&A session has ended, but further discussions can be continued in the monetization of open-source discussion room and the speaker lounge.

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. Yeah, proven technology. All right.

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? Yeah, we don't have a roadmap, 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 those problems incrementally, and that's basically a roadmap. And yeah, I summarized 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 happen probably. Someday soon. Someday soon, yeah. But we don't have timelines, or we never had timelines for everything because it's like great pressure, and we don't want to have this pack-out. It's an open source project, and many, 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. It's like-

So beside you, how many people work on Webpack full-time? 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 like we also have less funding last time. So it's like, it's the winter for JavaScript ecosystem mostly, and yeah it might be a problem in the future that we have two small teams to make larger improvements. Yeah, it's weird that basically 9 out of 10 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. Alright.

I think we're gonna do one last question. Question is from Thomas. Where do you see yourselves standing against new building tools leveraging new browser features like feats? I think we will do something to make similar choices. So actually, probably we copy or steal stuff from new bundles, so 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 there's only one way. I think more like an ecosystem, the Web ecosystem, and we all benefit from these competitors and we benefit as ecosystem as a whole from these developments and 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. 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. See you there.

Check out more articles and videos

We constantly think of articles and videos that might spark Git people interest / skill us up or help building a stellar career

Remix Conf Europe 2022Remix Conf Europe 2022
23 min
Scaling Up with Remix and Micro Frontends
Do you have a large product built by many teams? Are you struggling to release often? Did your frontend turn into a massive unmaintainable monolith? If, like me, you’ve answered yes to any of those questions, this talk is for you! I’ll show you exactly how you can build a micro frontend architecture with Remix to solve those challenges.
React Summit 2023React Summit 2023
32 min
Speeding Up Your React App With Less JavaScript
Too much JavaScript is getting you down? New frameworks promising no JavaScript look interesting, but you have an existing React application to maintain. What if Qwik React is your answer for faster applications startup and better user experience? Qwik React allows you to easily turn your React application into a collection of islands, which can be SSRed and delayed hydrated, and in some instances, hydration skipped altogether. And all of this in an incremental way without a rewrite.
Remix Conf Europe 2022Remix Conf Europe 2022
37 min
Full Stack Components
Remix is a web framework that gives you the simple mental model of a Multi-Page App (MPA) but the power and capabilities of a Single-Page App (SPA). One of the big challenges of SPAs is network management resulting in a great deal of indirection and buggy code. This is especially noticeable in application state which Remix completely eliminates, but it's also an issue in individual components that communicate with a single-purpose backend endpoint (like a combobox search for example).
In this talk, Kent will demonstrate how Remix enables you to build complex UI components that are connected to a backend in the simplest and most powerful way you've ever seen. Leaving you time to chill with your family or whatever else you do for fun.
GraphQL Galaxy 2021GraphQL Galaxy 2021
32 min
From GraphQL Zero to GraphQL Hero with RedwoodJS
We all love GraphQL, but it can be daunting to get a server up and running and keep your code organized, maintainable, and testable over the long term. No more! Come watch as I go from an empty directory to a fully fledged GraphQL API in minutes flat. Plus, see how easy it is to use and create directives to clean up your code even more. You're gonna love GraphQL even more once you make things Redwood Easy!
JSNation 2023JSNation 2023
28 min
SolidJS: Why All the Suspense?
Solid caught the eye of the frontend community by re-popularizing reactive programming with its compelling use of Signals to render without re-renders. We've seen them adopted in the past year in everything from Preact to Angular. Signals offer a powerful set of primitives that ensure that your UI is in sync with your state independent of components. A universal language for the frontend user interface.
But what about Async? How do we manage to orchestrate data loading and mutation, server rendering, and streaming? Ryan Carniato, creator of SolidJS, takes a look at a different primitive. One that is often misunderstood but is as powerful in its use. Join him as he shows what all the Suspense is about.

Workshops on related topic

React Day Berlin 2022React Day Berlin 2022
86 min
Using CodeMirror to Build a JavaScript Editor with Linting and AutoComplete
Using a library might seem easy at first glance, but how do you choose the right library? How do you upgrade an existing one? And how do you wade through the documentation to find what you want?
In this workshop, we’ll discuss all these finer points while going through a general example of building a code editor using CodeMirror in React. All while sharing some of the nuances our team learned about using this library and some problems we encountered.
TestJS Summit - January, 2021TestJS Summit - January, 2021
173 min
Testing Web Applications Using Cypress
This workshop will teach you the basics of writing useful end-to-end tests using Cypress Test Runner.
We will cover writing tests, covering every application feature, structuring tests, intercepting network requests, and setting up the backend data.
Anyone who knows JavaScript programming language and has NPM installed would be able to follow along.
Node Congress 2023Node Congress 2023
63 min
0 to Auth in an Hour Using NodeJS SDK
Passwordless authentication may seem complex, but it is simple to add it to any app using the right tool.
We will enhance a full-stack JS application (Node.JS backend + React frontend) to authenticate users with OAuth (social login) and One Time Passwords (email), including:- User authentication - Managing user interactions, returning session / refresh JWTs- Session management and validation - Storing the session for subsequent client requests, validating / refreshing sessions
At the end of the workshop, we will also touch on another approach to code authentication using frontend Descope Flows (drag-and-drop workflows), while keeping only session validation in the backend. With this, we will also show how easy it is to enable biometrics and other passwordless authentication methods.
Table of contents- A quick intro to core authentication concepts- Coding- Why passwordless matters
Prerequisites- IDE for your choice- Node 18 or higher
React Summit US 2023React Summit US 2023
96 min
Build a powerful DataGrid in few hours with Ag Grid
Does your React app need to efficiently display lots (and lots) of data in a grid? Do your users want to be able to search, sort, filter, and edit data? AG Grid is the best JavaScript grid in the world and is packed with features, highly performant, and extensible. In this workshop, you’ll learn how to get started with AG Grid, how we can enable sorting and filtering of data in the grid, cell rendering, and more. You will walk away from this free 3-hour workshop equipped with the knowledge for implementing AG Grid into your React application.
We all know that rolling our own grid solution is not easy, and let's be honest, is not something that we should be working on. We are focused on building a product and driving forward innovation. In this workshop, you'll see just how easy it is to get started with AG Grid.
Prerequisites: Basic React and JavaScript
Workshop level: Beginner
Node Congress 2023Node Congress 2023
49 min
JavaScript-based full-text search with Orama everywhere
In this workshop, we will see how to adopt Orama, a powerful full-text search engine written entirely in JavaScript, to make search available wherever JavaScript runs. We will learn when, how, and why deploying it on a serverless function could be a great idea, and when it would be better to keep it directly on the browser. Forget APIs, complex configurations, etc: Orama will make it easy to integrate search on projects of any scale.
Node Congress 2022Node Congress 2022
128 min
Back to the basics
“You’ll never believe where objects come from in JavaScript.”
“These 10 languages are worse than JavaScript in asynchronous programming.”
Let’s explore some aspects of JavaScript that you might take for granted in the clickbaitest nodecongress.com workshop.
To attend this workshop you only need to be able to write and run NodeJS code on your computer. Both junior and senior developers are welcome.
Objects are from Mars, functions are from Venus
Let’s deep-dive into the ins and outs of objects and then zoom out to see modules from a different perspective. How many ways are there to create objects? Are they all that useful? When should you consider using them?
If you’re now thinking “who cares?“, then this workshop is probably for you.
Asynchronous JavaScript: the good? parts
Let’s have an honest conversation.
I mean… why, oh why, do we need to bear with all this BS? My guess is that it depends on perspective too. Let’s first assume a hard truth about it: it could be worse… then maybe we can start seeing the not-so-bad-even-great features of JavaScript regarding non-blocking programs.