大家好，我是 Sunday
昨天有位同学问我 webpack 的配置问题，一下子有种回到了远古时期的感觉。
看目前 “最先进的” webpack 5 也已经是 2020 年的产物了，距今已经 6 年了。。。
我作为远古时代的老登，我对 webapck 还是很有感情的。
很多人都说 webpack 已死，其实并没有，根据 npm 的下载量，虽然 vite 已经超过了 webpack，但是目前 webpack 依然可以稳居老二的位置。至少活下去，是没啥问题的
也有很多同学会想，webpack 还会有 6.X 吗？还是说以后就彻底摆烂了？
在 2026 年 1 月 12 日，Webpack TSC（技术指导委员会）开了一场会。
会议记录是公开的，我翻完了全程。传送门在这里：https://github.com/webpack/tsc/blob/main/notes/2026/2026-01-12-transcript.md
大致的内容就是 webpack 的核心开发者列出了 Webpack 2026 年的 Roadmap：
- CSS 支持（90% 完成）
- Universal target（98% 完成）
- TypeScript 内置支持（开发中）
- HTML 支持
- ESM 修复和改进
- 多线程 API
- 支持 Deno 和 Bun
看完我只能说：确实在做，但节奏真的慢。
这其实不能全怪 Webpack 团队。作为一个有着十几年历史的老大哥，它的历史包袱实在太重了。
大家回想一下 2018 年那个时代，浏览器对 ESM 支持还不成熟，工程化也没现在这么统一。大家做 Vue、React 项目的时候，第一件事也往往不是写业务，而是先把 webpack 的 loader、plugin、devServer 和 babel 这些东西配置好
Webpack 在那个时代，确实像神一样。
- 你要代码分割？它能搞。
- 你要按需加载？它能搞。
- 你要图片、字体、CSS、Less、Sass、TypeScript 全部塞进去？它也能搞。
啥都能搞。它的底层是完全基于 JavaScript 写的，在当时这绝对是个巨大的优势，因为咱们前端开发者都能看懂源码，随手就能写个 Loader 或者 Plugin，繁荣的生态就是这么搞起来的。
所以我一直觉得，Webpack 最大的历史功劳，不是快不快，而是 “统一”。
它统一了模块化，统一了资源处理，统一了构建思维，把当年混乱的前端工程，硬生生整理除了一个属于自己的秩序。
但是，现在时代变了呀。现在的前端构建，已经从之前的 “有没有工程化方案” 改成了 “我们的工程化方案有必要那么重吗？”
现在很多项目依然还在使用 Webpack，而且照样能跑，照样能上线，照样能挣钱。所以说 “Webpack 已死” 这种话其实挺标题党的。但你要说它还是不是今天最优解呢？
恐怕是已经不是了。
前端构建的生态，已经从原先的 “webpack 大一统”，变成了 “群雄割据” 的局面了
所以接下来，我们就一个一个来看。。。
Vite、Rspack、Turbopack：三个人，三条路
有了 webpack 这个前车之鉴，现在大家都已经意识到，Webpack 那套来的又重又全的方案，已经不能适应时代了。
所以说，不同的人，开始尝试走不同的路
- 有的人想全部重做，开发一种新的模式
- 有的人想做 “Webpack 的平替升级版”
- 还有的人，干脆就只服务自己的生态
Vite、Rspack、Turbopack，基本就是这三条路线的代表。
Vite 8 开发一种新的模式
Vite 这几年为什么能这么猛？
因为它一上来就抓住了前端最痛的那个点：开发体验。
Webpack 时代，很多人最痛苦的就是本地开发的时候，改一行代码，要等半天热更新。项目一大，心态爆炸。。。
Vite 当年就是靠这个杀出来的。
它利用浏览器原生 ESM，把先全量打包再启动的思路给绕开了。你改哪个模块，它就按需处理哪个模块，所以本地启动和热更新体验会非常顺。
但 Vite 之前一直有个很明显的问题，那就是：开发环境很快，但是生产构建却还是一样的慢
原因也很简单，Vite 的生产构建底层一直还是 Rollup。Rollup 的天花板就在那了，没法改。
所以，这次 Vite 8 就开始逐步引入 Rolldown 作为构建核心，原来 Rollup 那一套就直接不用了。官方给出的数据是：构建速度提升 10～30 倍。 传送门：https://vite.dev/blog/announcing-vite8-beta
Rspack “Webpack 的平替升级版”
Rspack 的思路就和 vite 完全不一样了。他的核心逻辑就是 能够无缝替换 webpack，并提供闪电般的构建速度。 （官网原话）
我们知道，很多公司 webpack 的项目都用了好多年了，迁移起来成本实在是太高
Rspack 就很聪明，它不跟你讲什么“颠覆式创新”，它讲的是：“你原来怎么配 Webpack，现在基本还怎么配。”
这就非常现实了。
这也是为什么很多人会把 Rspack 叫做 “Webpack 杀手”，但我觉得这个词还不够准确。
它更像是：Webpack 的继承者。
所以如果你问我，Rspack 最适合谁？
答案非常明确：
最适合那些已经深度绑定 Webpack，没有办法切换 vite，但又实在受不了性能的人。
Turbopack 只服务自己的生态
Turbopack 又是第三种选手。
它和 Vite、Rspack 最大的不同在于，它只服务好 Next.js，其他的什么都不管。
因为只服务一个生态，反而意味着它可以把很多优化做得非常深。
Turbopack 现在最核心的卖点，就是 增量编译。
这个词听起来有点抽象，说人话就是：不是每次都把全项目重新来一遍，而是你改了哪里，我就只处理哪里。
对于大型 Next.js 项目来说，这种收益是非常夸张的。
项目越大，模块越多，依赖越复杂，你就越能感受到这种增量编译带来的性能提升。以前一些大项目冷启动能把人等麻了，但是现在可以明显压下去。
当然，它的问题也同样明显。
如果你不是 Next.js 用户，那它和你基本没啥关系。所以 Turbopack 的强，是一种很“窄”的强。
三者最大的区别
很多文章写到这里，都会开始拉性能对比表。
但说实话，我觉得只看性能，其实有点窄了。
因为 Vite、Rspack、Turbopack 他们三个，真正的区别，不是谁更快，而是：他们分别站在三个完全不同的位置上。
- Vite 的立场是：让新项目用更轻、更顺、更符合今天前端开发习惯的方式启动
- Rspack 的立场是：让老项目不用重构，也能吃到下一代引擎的红利
- Turbopack 的立场是：我只做 Next.js 生态
它们更像是三种完全不同的解题思路。
也正因为这样，Webpack 才会显得有点尴尬。八面围城，好像各方各面都被堵死了。。。
写在最后
Webpack 从 2012 年开始，陪伴了前端 14 年，它是值得被尊重的。
但是时代在变，特别是现在的 AI 时代，Vibe Coding 越来越成熟。我们的时间更应该花在写业务上，而不是这些基础架构上。
