Why we switched from Webpack to Vite • Hacker News Board

Re: Why we switched from Webpack to Vite

#101

Post by ng12 » Wed, Apr 28, 2021, 10:16 PM UTC

mariusmg wrote: post #91

amasad wrote: post #6

Some stats not mentioned in the post. Create React App (webpack) vs Vite (esbuild) on Replit containers: - 1 second start up time on Vite vs 15 seconds for CRA - React.js hello world project is 234mb on CRA and only 34mb on Vite - 1GB RAM for Vite dev server vs 3GB+ for CRA This is a perfect example of how fast and efficient tools can be, and I think we can do even better! Super excited about the future of JavaScript…

>Super excited about the future of JavaScript tooling ecosystem with more focus on efficiency and speed. Well they can't get worse than now... 234mb for a friggin hello world app

Would you count the size of the JVM when you do Hello World in Java?

Re: Why we switched from Webpack to Vite

#102

Post by eliseumds » Wed, Apr 28, 2021, 10:18 PM UTC

theon144 wrote: post #93

eliseumds wrote: post #46

I literally just spent days trying out Vite and comparing it to Webpack 5, and I can comfortably say that they are in two very distinct leagues. It isn't fair to compare Vite to a CRA build with Webpack. You can greatly improve Webpack's performance by: * Making sure `mode` is set to "development" (don't specify it all if in doubt) * Ditching babel-loader and using esbuild-loader instead * Adjusting build targets and…

>* It has a weird mix of own and Rollup config settings that seems somewhat unpredictable Oh god, this is a giant red flag. This is precisely one of my biggest gripes with Quasar (a Vue framework), which, on top of webpack/vue adds its own config that are intermingled with vue's and webpack's, and its honestly a mess, and oftentimes just straight up makes problems harder to solve. I am obviously not railing against c…

I'd be dishonest if I told you I was able to compare them 1-to-1. I couldn't finish my Vite setup because of bugs and lack of proper SSR support.

I believe that, at this point, people are just nitpicking. When working on a client-side-only app, Vite is faster, but not by that much. In one of our apps, I saw it starting up in 1s compared to 2s with Webpack, and reloads in 100ms compared to 250ms. This is a Preact/TS/Emotion app that outputs almost 7MB of assets, 61 files to be precise, and works on IE11. And I hadn't even tried persistent caching with it yet. Webpack 5 with esbuild is a fast-enough solution.

NextJS is a well-established tool now and version 10.2 uses Webpack 5 under the hood. V11 is looking insanely fast (I suspect they replaced Babel with esbuild, and did some witchery): https://twitter.com/shuding_/status/1378086219708473344.

So yeah, slow performance with Webpack is definitely caused by a bad set of loaders/plugins. Eject a CRA app and you'll see a monster coming out.

Re: Why we switched from Webpack to Vite

#103

Post by bavell » Wed, Apr 28, 2021, 10:19 PM UTC

mumphster wrote: post #36

amasad wrote: post #27

Earlier quoted context omitted.

I'm sure it's less disk space because it has less deps but the most of the RAM and CPU usage in CRA is Webpack so I'd be surprised if that changed much.

webpack AND all the extra plugins and preprocessing and postprocessing CRA adds -- its not a small webpack setup by any means and you can get 1s build times with webpack pretty easily without CRA

Agreed, I use webpack for small and medium projects and it's basically instant. I use TS but not the compiler - I tell babel to strip types and use just a few plugins, transforms and loaders.

I'm not in love but it's a core tool in almost all of my projects, personal and professional.

Re: Why we switched from Webpack to Vite

#104

Post by andrewmcwatters » Wed, Apr 28, 2021, 10:19 PM UTC

shakow wrote: post #98

andrewmcwatters wrote: post #94

My position on web development for even consulting projects is just to not use build processes as much as possible. I still end up using them for things like JSX, but I don’t bundle anymore, nor do any web projects I build require installation out of the box. I’ve found that by doing so, I can just basically ignore, for years on end, all of the peddlers pushing how their projects make development easier or faster or…

> Very few fields work like this. Quite the opposite; I would argue that webdev is basically rediscovering the whole shebang, but decades later. Modern webdev with transpilation, linking, pruning, compilation to WASM etc. starts to dreadfully look like the classical native development paradigm.

Yeah, and basically none of that is necessary. Which is my point exactly.

Re: Why we switched from Webpack to Vite

#105

Post by jakelazaroff » Wed, Apr 28, 2021, 10:22 PM UTC

JMTQp8lwXL wrote: post #20

amasad wrote: post #6

Some stats not mentioned in the post. Create React App (webpack) vs Vite (esbuild) on Replit containers: - 1 second start up time on Vite vs 15 seconds for CRA - React.js hello world project is 234mb on CRA and only 34mb on Vite - 1GB RAM for Vite dev server vs 3GB+ for CRA This is a perfect example of how fast and efficient tools can be, and I think we can do even better! Super excited about the future of JavaScript…

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?

In my experience, the vast majority of use cases are covered by these "no config" tools. If your app isn't a typical CRUD app you might fall into that long tail, but FWIW almost every app I've built has not :)

Re: Why we switched from Webpack to Vite

#106

Post by [deleted] » Wed, Apr 28, 2021, 10:23 PM UTC

amasad wrote: post #6

Some stats not mentioned in the post. Create React App (webpack) vs Vite (esbuild) on Replit containers: - 1 second start up time on Vite vs 15 seconds for CRA - React.js hello world project is 234mb on CRA and only 34mb on Vite - 1GB RAM for Vite dev server vs 3GB+ for CRA This is a perfect example of how fast and efficient tools can be, and I think we can do even better! Super excited about the future of JavaScript…

[deleted]

Re: Why we switched from Webpack to Vite

#107

Post by trinovantes » Wed, Apr 28, 2021, 10:27 PM UTC

I wonder why all these new bundlers don't provide a webpack-compatible API to entice new users. I can't take the risk of investing in a new tool only to find that I can't migrate the last 20% key features that I need. I also don't have the bandwidth to constantly switch between vite, webpack, parcel, etc. every time I switch to a different project.

Re: Why we switched from Webpack to Vite

#108

Post by [deleted] » Wed, Apr 28, 2021, 10:28 PM UTC

ng12 wrote: post #101

mariusmg wrote: post #91

Earlier quoted context omitted.

>Super excited about the future of JavaScript tooling ecosystem with more focus on efficiency and speed. Well they can't get worse than now... 234mb for a friggin hello world app

Would you count the size of the JVM when you do Hello World in Java?

[deleted]

Re: Why we switched from Webpack to Vite

#109

Post by fastball » Wed, Apr 28, 2021, 10:32 PM UTC

trinovantes wrote: post #107

I wonder why all these new bundlers don't provide a webpack-compatible API to entice new users. I can't take the risk of investing in a new tool only to find that I can't migrate the last 20% key features that I need. I also don't have the bandwidth to constantly switch between vite, webpack, parcel, etc. every time I switch to a different project.

Because my main quibble with webpack is that its API is a mess and sucks.

Re: Why we switched from Webpack to Vite

#110

Post by hombre_fatal » Wed, Apr 28, 2021, 10:33 PM UTC

ng12 wrote: post #101

mariusmg wrote: post #91

Earlier quoted context omitted.

>Super excited about the future of JavaScript tooling ecosystem with more focus on efficiency and speed. Well they can't get worse than now... 234mb for a friggin hello world app

Would you count the size of the JVM when you do Hello World in Java?

You could, since it’s a runtime dep. But a better comparison would be to the client dev tool chains in other ecosystems, like Xcode (11GB), though still not very interesting. Turns out client dev is hard and it doesn’t make much sense hand wringing over dev tool size metrics.

Better to look at how well they solve their problem space.