- Vite has become the default for most SPAs
- Vite is now backed by the VoidZero company, which is moving full speed ahead on a suite of Rust-based build tooling: Rolldown for bundling, Oxc for parsing, etc
- Meanwhile, you've got Bytedance cranking out RSPack and RSBuild
and at least another half-dozen alternatives.
My worry isn't so much about the tech itself, but rather the governance issues—and it's not about "Make Webpack Great Again."
1. I genuinely like Vite's design and UX (I actually started my frontend career with Vite + Vue). My only concern is the ecosystem getting vertically integrated under a single commercial roadmap (Oxc => Rolldown => Vite). It feels like shifting from a community-driven ecosystem to a VC-driven product suite. I am worried about vendor lock-in, especially with commercial suites like "Vite+" existing.
2. Regarding Rspack/Rsbuild, I do treat them as one of the Webpack alternatives. Although ByteDance doesn't rely directly on build tools for profit like Vercel or VoidZero, and Rspack/Rsbuild reuses community results, I feel the vendor lock-in risk isn't that high. But Rspack/Rsbuild's current volume isn't huge -it's obviously much smaller compared to Webpack/Vite. So I think I might need to wait and see.
3. I previously valued Webpack 6.x mainly because of the governance structure. Like Node.js, it belongs to the OpenJS Foundation after all. I guess I feel that for such critical infrastructure, neutrality is quite important. When choosing tech for frontend projects, I also focus heavily on community governance. The only regret is that it's a bit old and has performance issues. So, I was kind of hoping it could solve some of its downsides.
I'd love to hear your thoughts on what I said above. Also, I am curious about your take on the current shift in the JS ecosystem. I think in the current JS ecosystem, commercial companies are increasingly dominating core infrastructure *directly*, and using that infrastructure as a core part of their business plans. Objectively speaking, this leaves *less and less room for neutral, community-driven governance*.
Webpack honestly needs official, guided tooling configurators. Documentation often mentions a block of code, but not exactly _where_ to put it. AI agents are apparently stumped by a 4-5 upgrade, documentation lets me down, no automated upgrade tooling, and a lot of the changes I've seen are just cheese movement - add nothing useful, but require upgrade maintenance.
If webpack wants to take the top spot again, they need to work on: - performance: this is the most obvious issue right now. Webpack builds aren't exactly fast, and the new breed of tooling, esp vite, blows webpack away - consistent api: stop moving cheese arbitrarily, or, if you have to change things, provide backwards compatibility shims or upgrade tooling - improvements to documentation: it should be so hard to figure out where suggested config blocks of code should go - providing real examples would help
Maybe for a few people who used to run Webpacker in Rails, and migrated to shakapacker instead of Vite, it will be good news.
When a tool like this (which was never pleasant to work with) loses the lead, it never restores it.