4 ms·

You must work on small projects or use top tier hardware exclusively because the development startup time of vite vs webpack is simply not comparable. The proje

You must work on small projects or use top tier hardware exclusively because the development startup time of vite vs webpack is simply not comparable. The project I spend most of my time on maintained both build systems for a couple of years, and I used them interchangeably: under Webpack, the development build loaded in about two minutes (sometimes more), vite takes 3-5 seconds. Webpack configs have since been removed. I also agree with everything MrJohz said about zero (or close to zero) configuration required to use vite.

diggan 2y ago
> under Webpack, the development build loaded in about two minutes (sometimes more), vite takes 3-5 seconds. Now it was some time ago since I last used webpack, but if it takes 2 minutes for your build to load (or run?), something is severely wrong and it's not because of webpack. 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.
- veidelis 2y ago
  Thank you, well said. I'd like to add that one should try to understand (not saying Homebrewer didnt) what was the cause/bottleneck. Such general statements about "performance" are of little value without deeper insights about some particular problem or use case.
- preommr 2y ago
  > 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
- homebrewer 2y ago
  I don't think so, it's just a massive intranet project with tons of third-party dependencies¹ that spews out a 20 MB minified JS build. I don't think we even modified the original CRA configuration. No typechecking, no eslint or anything else during the build process, they were all run separately when they were needed. 1: like support for various file formats that are constantly needed by every user and it makes no sense to lazy load them

diggan 2y ago

> under Webpack, the development build loaded in about two minutes (sometimes more), vite takes 3-5 seconds. Now it was some time ago since I last used webpack, but if it takes 2 minutes for your build to load (or run?), something is severely wrong and it's not because of webpack. 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.

veidelis 2y ago
Thank you, well said. I'd like to add that one should try to understand (not saying Homebrewer didnt) what was the cause/bottleneck. Such general statements about "performance" are of little value without deeper insights about some particular problem or use case.
preommr 2y ago
> 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
homebrewer 2y ago
I don't think so, it's just a massive intranet project with tons of third-party dependencies¹ that spews out a 20 MB minified JS build. I don't think we even modified the original CRA configuration. No typechecking, no eslint or anything else during the build process, they were all run separately when they were needed. 1: like support for various file formats that are constantly needed by every user and it makes no sense to lazy load them