> 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 we switched from Webpack to Vite
21–30 of 229 posts
Re: Why we switched from Webpack to Vite
#22The 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
#23Some 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…
Re: Why we switched from Webpack to Vite
#24Honestly 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
#25Webdev 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…
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
#26Webdev 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…
Re: Why we switched from Webpack to Vite
#27Some 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
#28Earlier 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.
Re: Why we switched from Webpack to Vite
#29I 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 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.