It's 2026 now. Is Webpack 6.x going to happen?
7 comments
I haven't looked specifically at Webpack's development lately, but having seen the overall activity and competition in the bundling ecosystem: no, a 6.x release seems unlikely, and also pretty irrelevant at this point. And no, I don't see Webpack becoming a default choice again.
- 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.
- 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.
Thanks for the reply.
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*.
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 is really powerful, however, it's a huge generalist, and I think the specializing tools are showing their speed. In addition, webpack has suffered the same unnecessary churn that a lot of J's projects do, where upgrades become incredibly difficult due to arbitrary changes without (easily implementable) backwards compatibility. The cheese moved, but to little or no benefit for the consumer. Ask me - I've been trying to upgrade a vue2/webpack4 project to vue3/webpack5 for a long time but can never get far enough - always hit a wall. I've been looking at ways to move to vite specifically because of this, and I thought I was blocked by some rather deep integration into webpack which facilitates building branded versions of our white label app, but I think I see a way with vite.
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
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
I agree with your point. From my observation, bundlers in the JavaScript ecosystem are indeed becoming more specialized. Meanwhile, tooling libraries and backend code are genuinely moving away from bundlers due to the growing popularity of the "Pure ESM" concept. If that's the case, bundlers may truly be relevant only for frontend scenarios now. Given this shift, it makes more sense to focus bundlers specifically on frontend use cases, and we no longer need those "general-purpose" bundlers. Moreover, Webpack really is overly complex.
Any release will definitely not restore Webpack as the "first choice". That ship has sailed and Webpack has accumulated a lot of bad rep.
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.
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.
According to your view, is Webpack becoming "the next jQuery" merely a matter of time?
Nothing wrong with jQuery. If a dev dependency irks me, I have no reason to revisit it no matter how better it got. We moved on.
However, looking at it from another angle, Webpack still maintains relatively active development on GitHub and hasn't officially entered "maintenance mode." The recent release of Babel 8 Beta also reminded me that these veteran infrastructure tools in the JS ecosystem are still capable of self-renewal and seeking breakthroughs.
I'd love to hear your thoughts:
1. Do you think Webpack will actually release a version 6.x? Or will they just continue evolving on 5.x for the long haul?
2. If they do release it, what major changes do you expect? Will they introduce Rust into the core?
3. Could the release of a 6.x version potentially restore Webpack as the "first choice" for new projects?