3 ms·

> Migrating your build tool because you're hitting some edge-case or bug you don't understand doesn't bode well for your future use of other tools. I suppose t

> Migrating your build tool because you're hitting some edge-case or bug you don't understand doesn't bode well for your future use of other tools. I suppose the patronizing attitude is the price for you sharing your wisdom with us. FWIW I will also echo that webpack is very slow for me. For my current project, the initial build times were ~10 minutes and eventually balooned to 15+ after which I switched to rspack (~10seconds build times now). This comes with some caveats like I had ts typechecking vs swc (but I have ts watching separately, and it takes longer than rspack but is still around ~20s). For webpack 4, speed-measure-plugin used to work well (a long time ago I remember sass-loader being a bad bottleneck), but for v5 I've spent a decent amount of time trying to figure out issues, and it wasn't a simple process. The stats.json that gets generated was malformed for me, and I had to either modify it by hand, and even then it was pretty opaque. And I wasn't about to dive into profiling the node runtime to sort out the webpack issue because that time would be better spent on something like optimizing the chunks. And I was using webpack because while the inital build times were slow, the incremental builds were really fast. Vite is horribly slow on refresh if there are a lot of files.

diggan 2y ago
> I suppose the patronizing attitude is the price for you sharing your wisdom with us. Beats passive aggressiveness I suppose? > FWIW I will also echo that webpack is very slow for me. Judging by your description, and surely missing even more context, it sounds like individual loaders/modules are/were slow, rather than webpack itself. But since you switched webpack for rspack (with assuming, the very same loaders/modules) and it got faster, that would seem webpack being the slow part, so who knows what the core problem is/was. Personally I haven't hit any performance issues with webpack + lots of code, but then I mainly do JavaScript and try to stay away from TypeScript, maybe this could explain the difference in experience. In the end, we use the tools that work best, and if that happen to be Vite instead of webpack (or vice-versa) for you, then there isn't really much to discuss :)
- homebrewer 2y ago
  > like individual loaders/modules are/were slow, rather than webpack itself tbh this is just nitpicking, I'm not a react developer to do CRA debugging for them. They're paid by Facebook a couple orders of magnitude more than what we're making here, and if they're fine with the intact CRA configuration being that slow, while a third-party alternative rips through the massive pile of shit I'm working on while not bringing any obvious downsides, I'll just switch to the alternative. It's a well known problem: esbuild, which is the base of vite's HMR, boasts of speeds dozens to hundreds of times faster than webpack: https://github.com/evanw/esbuild?tab=readme-ov-file#why https://github.com/evanw/esbuild?tab=readme-ov-file#why

diggan 2y ago

> I suppose the patronizing attitude is the price for you sharing your wisdom with us. Beats passive aggressiveness I suppose? > FWIW I will also echo that webpack is very slow for me. Judging by your description, and surely missing even more context, it sounds like individual loaders/modules are/were slow, rather than webpack itself. But since you switched webpack for rspack (with assuming, the very same loaders/modules) and it got faster, that would seem webpack being the slow part, so who knows what the core problem is/was. Personally I haven't hit any performance issues with webpack + lots of code, but then I mainly do JavaScript and try to stay away from TypeScript, maybe this could explain the difference in experience. In the end, we use the tools that work best, and if that happen to be Vite instead of webpack (or vice-versa) for you, then there isn't really much to discuss :)

homebrewer 2y ago
> like individual loaders/modules are/were slow, rather than webpack itself tbh this is just nitpicking, I'm not a react developer to do CRA debugging for them. They're paid by Facebook a couple orders of magnitude more than what we're making here, and if they're fine with the intact CRA configuration being that slow, while a third-party alternative rips through the massive pile of shit I'm working on while not bringing any obvious downsides, I'll just switch to the alternative. It's a well known problem: esbuild, which is the base of vite's HMR, boasts of speeds dozens to hundreds of times faster than webpack: https://github.com/evanw/esbuild?tab=readme-ov-file#why https://github.com/evanw/esbuild?tab=readme-ov-file#why