A similar tool in this space is Jason Miller's (@developit) WMR:
Why we switched from Webpack to Vite
11–20 of 229 posts
Re: Why we switched from Webpack to Vite
#12I 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…
> thus should know better
This reads as a very acrimonious, biased take. Authors choose the tools they use based on a number of criteria and personal preferences. It's one thing to disagree with them, it's another to project judgement without knowing the why.
Re: Why we switched from Webpack to Vite
#13Some 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…
This is informative.
How is the configuration overhead? Is it relatively easy to get Vite + a custom react app template + tsx + testing up and running?
CRA is bloated, but still one of the fastest ways to get a "full app" up and running with React.
Re: Why we switched from Webpack to Vite
#14I wonder how this compares to a proper manual Webpack configuration. Comparing it to CRA isn't really helpful to me, as CRA is already known to be very slow.
I would consider trying it if it has significant performance benefits over a manual Webpack config, especially one making use of esbuild-loader (https://github.com/privatenumber/esbuild-loader)
Re: Why we switched from Webpack to Vite
#15Frankly, 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.
Re: Why we switched from Webpack to Vite
#16Some 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…
This is informative. How is the configuration overhead? Is it relatively easy to get Vite + a custom react app template + tsx + testing up and running? CRA is bloated, but still one of the fastest ways to get a "full app" up and running with React.
I don't think Vite has a testing story yet. As for the rest, yes, it totally is straightforward. We only had to change one line of configuration in the base template for it to work on Replit. See https://replit.com/@templates/Reactjs
Re: Why we switched from Webpack to Vite
#17Frankly, 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, just adding more developers doesn't necessarily make things better, not to mention that the necessary quality control and code review demands for mature projects means many contributions are often misguided or not useful.
Re: Why we switched from Webpack to Vite
#18For people already on webpack, there's esbuild-loader ( https://github.com/privatenumber/esbuild-loader )
Ooh next uses webpack right? Might be some free speed. Thanks.
Yes but there are some difficulties you may run into when replacing the default loader nextjs uses, because it includes some custom babel plugins that get blown away when you replace the loader with esbuild-loader.
Re: Why we switched from Webpack to Vite
#19I 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…
> thus should know better
I would posit that perhaps they know better than you.
When pure performance is the concern it makes sense to go to a more performant language, like Go. But every time your JavaScript build tool moves away from JavaScript you close yourself off to a huge pool of potential code contributors and make it a lot more difficult to customise. So I think Vite has it just right: optimise the really intensive stuff, leave the rest more available and more editable.
Re: Why we switched from Webpack to Vite
#20Some 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?