Live data from Hacker News

Why we switched from Webpack to Vite

blog.replit.com

21–30 of 229 posts

Re: Why we switched from Webpack to Vite

#21

> Esbuild is a JS bundler written in Go that bundles dependencies 10-100x faster than JavaScript based alternatives like Webpack and Parcel. A JS library calling a golang js-build tool to get the job done. Too funny.

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?

Re: Why we switched from Webpack to Vite

#22
Webdev truly is one of a kind. Not only do you have your source code, you also have your build code, oddly dictating the organization of your source code. For extra fun, some libraries don't build with build system a, others require build system b, when you're lucky enough to have a working mix, changing build systems is better to be avoided. Of course periodically the officially blessed build system for your used libraries changes.

The webdev ecosystem is so broken, it's no wonder so many websites deliver assets that are extremely suboptimally optimised, big unused blobs of assets /scripts slowing page load, optimising it all is actually made harder than coding it all.

Re: Why we switched from Webpack to Vite

#23
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…

I’d like to see non-CRA numbers: I’ve found that a simple React + Webpack 5 project is not as bad to get off the ground as it used to be.

Re: Why we switched from Webpack to Vite

#24
I haven't tried Vite, but I tried ESBuild last weekend on a personal project and was absolutely blown away. Even as someone who's become pretty comfortable working in the Webpack trenches, I don't see myself starting a new project with Webpack ever again. There's just no reason to when you can get the exact same output, much faster, without any of the headaches.

Honestly it's so good I wonder if it will undercut Deno a little bit by lowering the barrier for bootstrapping a TypeScript project

Re: Why we switched from Webpack to Vite

#25

Webdev truly is one of a kind. Not only do you have your source code, you also have your build code, oddly dictating the organization of your source code. For extra fun, some libraries don't build with build system a, others require build system b, when you're lucky enough to have a working mix, changing build systems is better to be avoided. Of course periodically the officially blessed build system for your used li…

> The webdev ecosystem is so broken

Allow me to correct this statement: The Javascript ecosystem is so broken.

Working with Clojurescript and Elm is an experience that will make most developers fall in love with web development again.

Re: Why we switched from Webpack to Vite

#26

Webdev truly is one of a kind. Not only do you have your source code, you also have your build code, oddly dictating the organization of your source code. For extra fun, some libraries don't build with build system a, others require build system b, when you're lucky enough to have a working mix, changing build systems is better to be avoided. Of course periodically the officially blessed build system for your used li…

I see you have never worked on a C/C++ project.

Re: Why we switched from Webpack to Vite

#27
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…

I’d like to see non-CRA numbers: I’ve found that a simple React + Webpack 5 project is not as bad to get off the ground as it used to be.

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.

Re: Why we switched from Webpack to Vite

#28
post #27

Earlier quoted context omitted.

I’d like to see non-CRA numbers: I’ve found that a simple React + Webpack 5 project is not as bad to get off the ground as it used to be.

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.

I’d like to see the numbers: the webpack config CRA eject gives you is a monster.

Re: Why we switched from Webpack to Vite

#29
post #5

I was a little surprised that Vite, which depends on esbuild and thus should know better, is written in Javascript. I presume this is a considered choice, and that what Vite does is unlikely to be on the critical path for edit/build/view cycle time…

The speedup from tools like esbuild, swc, etc. are not because of the language they were written in but because they're competing against Babel. Babel is this single-threaded highly-extensible behemoth. On top of this, you're encouraged to install dozens of plugins, and each plugin has access to global state.

The new transpilers have worked around this problem by introducing various limitations. esbuild plugins literally can't modify the AST. It's basically a way for you to run a command on a string/file. So sure, if you redefine the problem as string transforms rather than AST transforms, you can get an O(N) speedup...

Re: Why we switched from Webpack to Vite

#30

> Esbuild is a JS bundler written in Go that bundles dependencies 10-100x faster than JavaScript based alternatives like Webpack and Parcel. A JS library calling a golang js-build tool to get the job done. Too funny.

This might shock you, but webpack runs on node/V8 which is written in C/C++.
Post reply on HN