Live data from Hacker News

Why we switched from Webpack to Vite

blog.replit.com

81–90 of 229 posts

Re: Why we switched from Webpack to Vite

#81

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.

Vite uses Rollup for production builds, which is still much faster than webpack.

Re: Why we switched from Webpack to Vite

#82
I've been using vite for a while now and it has been super painless. However I use it in a pretty straight forward manner, about the most "advanced" thing I use is a proxy to redirect web requests to the backend during development. I haven't played around with things like SSR yet which is currently marked as experimental.

Re: Why we switched from Webpack to Vite

#83

Earlier 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

Can someone clarify what the new URL() thing is?

Re: Why we switched from Webpack to Vite

#84
post #74
post #61

Earlier quoted context omitted.

Nearly an order of magnitude reduction. What do you think of that?

They probably mean that "hello world".length == 11 // bytes

Most of the build tooling gets installed along the way.

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

#85
What about using native es6 imports cached by a service worker? If you don't have to support old browsers, this is a much better option than a compile step. Just pull from git and load it in your browser, no complications eating a weekend reading through docs and shotgun debugging.

Re: Why we switched from Webpack to Vite

#88

I 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…

Your experience mirrors mine to a letter - I appreciate the wide variety of use cases that are covered by Webpack (a number of which are crucial to our build process), but its performance is abysmal (20m+ on CI) and totally inscrutable; making the potential switch from it rather enticing.

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

#89

Frankly, 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…

A counter point would be to look at the Python ecosystem. They have many fewer libraries but the ones they have are very well maintained and widely adopted.

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

#90

Earlier 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.

Why so defensive? I didn't say anything about what you're allowed to do, I simply asked you a question about why you thought it was funny.
Post reply on HN