Why Webpack changed everything, and why it had to change | with Evan You

CultRepo| 00:05:46|Mar 26, 2026

Chapters7

Explains why Webpack became the de facto standard due to its extreme flexibility and plugin system that allowed customization for diverse use cases.

Webpack ruled the scene for years because of unmatched flexibility, but its complexity and sluggish dev builds prompted Evan You to rethink bundling for a better DX.

Summary

Evan You explains why Webpack rose to become the de facto bundler, praising its extreme flexibility and the ability to customize every part of the tool. He notes that so many frameworks and meta- frameworks built atop Webpack—Vue CLI, Create React App, and various loaders and plugins—because the tool could accommodate diverse opinions and use cases. However, with power came complexity: long configuration files, steep learning curves, and intimidating internals that even experienced developers wrestled with. As adoption grew, teams needed to understand Webpack internals just to customize workflows, leading to roles like configuration engineers who maintain project setups. Performance, especially development-time hot module replacement (HMR), emerges as the main pain point: even small projects see dev server updates creep from under a second to several seconds, or worse, over minutes in larger builds. You You reflects on his experience with Vue CLI built on Webpack and his frustration with slow scaffolding, startup, and HMR, which sparked his motivation to rethink build tools to improve Vue developers’ experience. The message is clear: Webpack’s dual legacy—unparalleled flexibility and growing performance pains—set the stage for a change in how modern web tooling approaches bundling and DX.

Key Takeaways

Webpack was the standard because it is extremely flexible and customizable, allowing plugins, loaders, and deep configuration for virtually any use case.
Frameworks like Vue (Vue CLI) and React (Create React App) built their own experiences on top of Webpack due to its versatility.
Over time, the very complexity that made Webpack powerful created intimidating, long configuration files (sometimes thousands of lines) and steep learning curves.
As adoption grew, more teams needed to understand Webpack internals, leading to roles like configuration engineers dedicated to setup and maintenance.
Development-time performance, especially hot module replacement, degraded as projects grew, with delays from under a second to several seconds or more.
Vue You personally confronted slow scaffolding, startup, and HMR in Vue CLI when using Webpack, motivating a search for a better developer experience.
Webpack prioritized fitting many use cases over build performance, which became a core reason to rethink the tooling landscape.

Who Is This For?

Frontend developers and engineering managers curious about the evolution of bundlers, especially those weighing the trade-offs of Webpack versus newer tooling. This is essential viewing for Vue/Vite users and anyone considering how build tools impact developer experience at scale.

Notable Quotes

""Webpack is I would say for a very long period it was the de facto standard bundler for the web. Almost everyone was using it.""

—Opening premise: Webpack's widespread adoption and the reason for its dominance.

""The main strength of Webpack is that you can pretty much configure or customize it to do anything you want.""

—Emphasizes flexibility as the core advantage.

""The downside of it is also the configuration is so complex... a thousand lines long.""

—Illustrates the complexity and intimidation factor of Webpack configs.

""When they dig into the internals of Webpack... they realize it's much more complex than they thought.""

—Describes the steep learning curve as users try to customize.

""The biggest issue is during development, the hot module replacement performance deteriorates as your project gets bigger.""

—Highlights the core pain point that motivated tooling change.

Questions This Video Answers

Why did Webpack become the de facto standard bundler and what were its key strengths?
How did Vue CLI and Create React App leverage Webpack under the hood and what were the drawbacks?
What caused Webpack's development experience to degrade as projects grew, especially for HMR?
What are the driving factors behind the shift away from Webpack to newer bundlers?
How does development-time performance impact developer experience in frontend tooling?

WebpackWebpack pluginsWebpack loadersVue CLICreate React AppHot Module Replacement (HMR)Developer Experience (DX)Web performance Frontend toolingBuild tooling evolution

Full Transcript

Webpack is I would say for a very long period it was the de facto standard bundler for the web. Almost everyone was using it. All the major frameworks were built on top of it and I think the reason for its popularity is because it is so flexible. It is extremely powerful. You can pretty much customize every part of it. It is designed to be as flexible as possible. And I think it was also a necessary design because in the early days of web development, there's so many differing opinions on how we should do things. People just disagreed on almost everything. So Webpack as a tool, it wanted to support all these different use cases and opinions. So it made itself extremely flexible and people started writing plugins and loaders on top of Webpack to essentially customize it uh to fit their use cases or preferences. Almost every framework had their own version of CLI. So Vue had Vue CLI, React had create react app and there are meta frameworks built on top of Webpack as well. All of them do very deep customization through plugins or confi complex configurations. So that is the main strength of Webpack is that you can pretty much configure or customize it to do anything you want. The downside of it is also the configuration is so complex and uh the API is is also so I would say um it's powerful but there are so many things you need to know and understand to be able to write a Webpack plug-in which makes it very intimidating for the average developer. Like I've seen Webpack projects with like a conf configuration file that's a thousand lines long. That's how complex it can get. I think in the early days people were fine with it because most people using Webpack are framework authors like me where we would research how to configure it and we would uh essentially wrap Webpack to provide a more streamlined experience to the end users. But as its popularity grew, more and more people had to actually deal with the internals of Webpack because um when they're using these wrapped up versions of Webpack, um they would run into limitations and now they would want to customize it by themselves. And when they dig into the internals of Webpack and how it actually works, they realize it's much more complex than they thought. But people had to learn it. So um a lot of teams I know in the past had like rows like we joke about it because like there are rows called like configuration engineers whose sole job is to create uh set up the Webpack configuration for each project and maintain it over the course of the project. So I think it's a double-edged sword, right? Uh the flexibility of Webpack really uh gave people the flexibility they needed to try different things, right? But over time it it is definitely like over time people started to converge on a lot of ideas like how do we handle CSS? How do we handle HTML? Uh how do we transpile components or future syntax of JavaScript? A lot of these things were done via plugins or loaders or configurations. Oftentimes people would use very bloated configurations, add a ton of loaders. Some huge Webpack projects can take up to a few minutes just to spin up the dev server. But Webpack was I would say Webpack was never written with build performance as a priority. It was mostly trying to cater to as many different use cases as possible. So as users start throwing more and more demanding workload at it, people start to run into build performance and scaling issues. And I think if it's just the build performance, uh, it probably wouldn't be that bad because let's say you need 10 minutes to build your project to production, it's still it still sounds acceptable. I think the biggest issue is during development, the hot module replacement performance deteriorates as your project gets bigger. Uh, I think that's the main thing that a lot of people started to get frustrated about. Um, imagine when you start a new project, you save the file and it updates the the component hot updates in under a second, right? That's a very smooth development experience. So, a month later, it gets down to two seconds. Another month goes by, it goes to 3 seconds. And it's um I think for a lot of people they're almost used to hitting save and just wait for like five, six or 10 seconds for Webpack to do its thing and then to to see the update. Um, so I think that is probably what I was also most frustrated with in my own projects because the Vue official Vue CLI was built on top of Webpack. And when I was debugging some user projects, I noticed that it was slow to scaffold a project. It was slow to start the project. It was also slow to hot update. I was really thinking why should Vue developers accept this level of developer experience? Is there a way to fundamentally make it a more pleasant experience when you're working on Vue projects? Um, and to be honest, my whole motivation of looking into build tools is all about improving the developer experience of Vue users.