Hacker News Reader

Comment by throwaway894345 | Hacker News Reader

> Any time you lose waiting for webpack to run you will get back 10x over by not fighting with your tooling because it doesn't handle a set of use cases you have.

Generally I think this is good advice for tools--stick with the mature thing. But my former company's webpack builds were 30+ minutes for a relatively simple site. No doubt something was misconfigured, but you really have to be a webpack expert to get any sort of insight into where the time is going, and even then it may not be especially actionable (or at least not obviously so). In our case, we were using a monorepo and we didn't have something like Bazel, so this was painful for backend engineers, data scientists, etc--not just frontend engineers.

Maybe our case was pathological, but we would have saved a ton of time moving to esbuild and building whatever additional features we needed from scratch.

View on HN

Your experience mirrors mine to a letter - I appreciate the wide variety of use cases that are covered by Webpack (a number of which are crucial to our build process), but its performance is abysmal (20m+ on CI) and totally inscrutable; making the potential switch from it rather enticing.

Especially as seeing that there is no good solution (but a lot of attempts at them), I feel it somewhat points to this overcomplexity being a problem central to Webpack.

> my former company's webpack builds were 30+ minutes for a relatively simple site

I’m genuinely curious what simple site would cause a 30+ minute build? Is it just one of those things that grow over time?

I wasn’t a frontend developer, so I’m not familiar with the details, but it seemed to be pretty slow from the start, but compounded as our app grew in size. I.e., there was some large coefficient associated with our web pack configuration.

How large was the bundle at the end? I'm not going to claim that webpack is fast for large applications, but I've never seen a build take longer than 3 minutes and this is for applications where our own source code was at the MB scale.

I don’t recall. We split it into multiple bundles in hopes of improving speed, but I don’t know the sizes in any case.

I feel like there just needs to be a good plugin that gives you proper stats as to how long things are taking and tips to improve things.

It’s usually slow css loaders, or too-inclusive patterns for loaders ending up processing node_modules, and not good enough disk caching.

There is a plugin called smc to monitor loader execution time.

Dll plugin was the best speed up to avoid recompiling things that don’t change, but now module federation is suppose to be a better solution. Disk caching in v5 will also do great things.

Thing is, it’s so complicated to setup, and debugging it involves so much config tweaking ans waiting.

I think we are a few years out from when we have nice speedy builds in webpack with good abstractions.

But then it’s a question of whether people move away from webpack because we don’t need all the plugins and transpiration and want native compile speeds.

One thing for certain though is the hype cycle will continue on...

Reply on news.ycombinator.com