3 ms·

I use both at work. I'm not sure I see any reason why you would use Vite over Webpack, other then a sense that Vite is newer. Is there a reason? They both seem

I use both at work. I'm not sure I see any reason why you would use Vite over Webpack, other then a sense that Vite is newer. Is there a reason? They both seem perfectly fine but Webpack is mature with lots of support.

hu3 2y ago
Isn't Vite faster and less complex? That's my impression.
MrJohz 2y ago
All the different configuration you need for Webpack is built-in to Vite. This includes built-in support for a lot of stuff that would come as separate plugins in Webpack (CSS loading, Typescript support, asset bundling, minification, autoprefix/browserslist-based downleveling, env replacement, etc). But more importantly, it includes fairly optimal configuration. There's usually an optimal way to bundle your code, and one of the issues with Webpack was that finding that optimal way through a maze of documentation and third-party plugins. Vite does that work for you, because it's mostly a solved problem and it's not that hard. For example, rather than having a number of different CSS plugins that you need to enable and disable in different configurations — just use Vite, which will do hot-reloading of CSS in development and link to the CSS files as external files in production. In my experience, there are typically two types of Webpack configurations: fairly basic ones that include some essentials but are fairly unoptimised (either while developing or in production), or complex ones that include everything but are brittle and painful to update. Vite gives you the power and optimisation of the latter with the configuration ease of the former. Also, to be clear, I'm not trying to hype Vite up. There are other similar tools out there, and Vite isn't even the first tool to work like this — Parcel is older and also pretty good at doing zero/minimal-config builds that work how you expect out-of-the-box. Any of these tools are good, although Vite seems to be the most popular right now and so has the most support/documentation/information. But I would generally encourage any project using Webpack to migrate away from that where possible (and where time allows), because these low-config tools are such a timesaver in the long-run.
- diggan 2y ago
  > All the different configuration you need for Webpack is built-in to Vite. This includes built-in support for a lot of stuff that would come as separate plugins in Webpack (CSS loading, Typescript support, asset bundling, minification, autoprefix/browserslist-based downleveling, env replacement, etc). But more importantly, it includes fairly optimal configuration. We're just walking around in circles. Webpack originally came to be because the current (at the time) solutions were too opionated, and what was "fairly optimal configuration" changed so quickly that it seemed favorable to split out the parts that could change, so we could still use webpack but the specific areas within could move forward without waiting for the rest. Of course this time, we really have found the optimal-optimal configuration that will surely never be updated, because this time we really did it properly. > Also, to be clear, I'm not trying to hype Vite up. If your comment contains all praise for a tool without bringing up any of the tradeoffs/drawbacks, then that pretty much labels your comment as "hype" for that particular tool. And if you find that you cannot find any of the tradeoffs/drawbacks, then it's clear as day that you've fully drank the koolaid :)
  - veidelis 2y ago
    Yes, exactly. It's not about popular use cases that make webpack better. The best way to claim that some other tool is better would be to have a side by side comparison of some not so straight forward configs.
homebrewer 2y ago
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.

hu3 2y ago

Isn't Vite faster and less complex? That's my impression.

MrJohz 2y ago

All the different configuration you need for Webpack is built-in to Vite. This includes built-in support for a lot of stuff that would come as separate plugins in Webpack (CSS loading, Typescript support, asset bundling, minification, autoprefix/browserslist-based downleveling, env replacement, etc). But more importantly, it includes fairly optimal configuration. There's usually an optimal way to bundle your code, and one of the issues with Webpack was that finding that optimal way through a maze of documentation and third-party plugins. Vite does that work for you, because it's mostly a solved problem and it's not that hard. For example, rather than having a number of different CSS plugins that you need to enable and disable in different configurations — just use Vite, which will do hot-reloading of CSS in development and link to the CSS files as external files in production. In my experience, there are typically two types of Webpack configurations: fairly basic ones that include some essentials but are fairly unoptimised (either while developing or in production), or complex ones that include everything but are brittle and painful to update. Vite gives you the power and optimisation of the latter with the configuration ease of the former. Also, to be clear, I'm not trying to hype Vite up. There are other similar tools out there, and Vite isn't even the first tool to work like this — Parcel is older and also pretty good at doing zero/minimal-config builds that work how you expect out-of-the-box. Any of these tools are good, although Vite seems to be the most popular right now and so has the most support/documentation/information. But I would generally encourage any project using Webpack to migrate away from that where possible (and where time allows), because these low-config tools are such a timesaver in the long-run.

diggan 2y ago
> All the different configuration you need for Webpack is built-in to Vite. This includes built-in support for a lot of stuff that would come as separate plugins in Webpack (CSS loading, Typescript support, asset bundling, minification, autoprefix/browserslist-based downleveling, env replacement, etc). But more importantly, it includes fairly optimal configuration. We're just walking around in circles. Webpack originally came to be because the current (at the time) solutions were too opionated, and what was "fairly optimal configuration" changed so quickly that it seemed favorable to split out the parts that could change, so we could still use webpack but the specific areas within could move forward without waiting for the rest. Of course this time, we really have found the optimal-optimal configuration that will surely never be updated, because this time we really did it properly. > Also, to be clear, I'm not trying to hype Vite up. If your comment contains all praise for a tool without bringing up any of the tradeoffs/drawbacks, then that pretty much labels your comment as "hype" for that particular tool. And if you find that you cannot find any of the tradeoffs/drawbacks, then it's clear as day that you've fully drank the koolaid :)
- veidelis 2y ago
  Yes, exactly. It's not about popular use cases that make webpack better. The best way to claim that some other tool is better would be to have a side by side comparison of some not so straight forward configs.

homebrewer 2y ago

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.