Earlier quoted context omitted.
As the "webpack" guy on my team, these numbers look extremely compelling, but I also know Webpack does a lot for us (e.g., through Webpack v4, it includes browserfied node libs as needed). Beyond node libs, there's a long tail of niche things that need to be taken of... am I trading coverage of that long tail for speed?
You still need webpack for production build :). So all is good.
Why we switched from Webpack to Vite
81–90 of 229 posts
Re: Why we switched from Webpack to Vite
#82Re: Why we switched from Webpack to Vite
#83Earlier quoted context omitted.
Exactly: 99% of the time, "webpack is slow" is just code for "I have Babel in my toolchain" and forgetting to set ts-loader as "transpile only". Personally I removed it years ago, and Webpack 5 even allowed me to get rid of more loaders now that there are Assets Modules that automatically detect assets and webworkers using the "new URL()" syntax, and Typescript does everything else I need.
The new URL() thing is amazing
Re: Why we switched from Webpack to Vite
#84Earlier quoted context omitted.
Nearly an order of magnitude reduction. What do you think of that?
They probably mean that "hello world".length == 11 // bytes
The compiled JS is hundreds of bytes at most, usually because React creates a bunch of boilerplate for you (a basic CSS file, an application, a web worker, etc) which you may remove.
Re: Why we switched from Webpack to Vite
#85Re: Why we switched from Webpack to Vite
#86Earlier quoted context omitted.
The new URL() thing is amazing
Can someone clarify what the new URL() thing is?
Re: Why we switched from Webpack to Vite
#87Earlier quoted context omitted.
The new URL() thing is amazing
Can someone clarify what the new URL() thing is?
https://webpack.js.org/blog/2020-10-10-webpack-5-release/#as...
Re: Why we switched from Webpack to Vite
#88I tried out both snowpack and esbuild recently, and while the approach of using es modules was neat, these tools are still wildly immature compared to webpack. Need to handle non-js assets in your bundle? Need to integrate into both node and browser environments? You should stick with webpack. 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…
> 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 s…
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.
Re: Why we switched from Webpack to Vite
#89Frankly, I would pass. The switchover of build tools in JS land is insane. I get that this has concrete performance improvements over alternatives, but I wonder if the same effort put towards improving an existing toolchain wouldn't get you a lot of similar efforts without breaking everything yet again.
That's the beauty of it, if the concrete performance improvements don't seem like a worthwhile tradeoff you don't have to use it. The idea that everyone should just contribute to one package instead of creating their own solutions is just silly, we are not able to dictate what people code up in their own time. Besides, there are dozens and sometimes hundreds of active contributors to every popular open source package…
JS/Node is full of unmaintained projects that people inevitably need to migrate away from.
Of all the new choices in bundlers today, it’s also inevitable that some won’t work out, yet they will drive hype and adoption, which could have been spent on already established tools such as webpack.
Yes, innovation is good and no one should tell someone what to do in their free time.
But it’s always going to be harder to build on top of old rather than to write something new, but what is new eventually becomes old...and the cycle repeats.
Re: Why we switched from Webpack to Vite
#90Earlier quoted context omitted.
Why is that funny? How is it conceptually different from any of the variety of scripting languages that call out to C bindings or binaries?
It’s funny because in order to compile/minify JS it passes said JS to golang which spits out JS to be run under JS. I’m not allowed to be amused by the circularity? Get a grip.