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.
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.
> 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 :)
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.
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.
> 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.
> 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.
> 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 :)
> 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:
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.
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
