前端技术演化史

Webpack

Properties1
tags工程化, webpack, 模块打包, loader, plugin, hmr, 构建工具

8分钟阅读

📦 Webpack

一句话定性

一句话概括它的世界观:“一切皆模块”——连 CSS、图片、字体都是模块。靠 loader + plugin 两套可扩展机制,加上 code splitting 和 HMR,Webpack 统治了前端构建整整十年。但成也打包,败也打包:它在 dev 模式也要把整个应用打成 bundle,项目越大冷启动越慢,最终被 Vite 在开发体验上击穿。

一、它是什么 & 出现的时代

Webpack(2014,作者 Tobias Koppers)是一个静态模块打包器(static module bundler)。它出现在 2013-2018 SPA时代 的中段,恰逢 React/Vue 崛起、组件化需求爆发。

它接过了 Browserify 的接力棒,但野心大得多:Browserify 只打包 JS 模块,Webpack 要把整个应用的所有资源(JS、CSS、图片、字体、HTML)都纳入一张统一的依赖图。

二、为什么会出现(解决上一代什么痛点)

组件化时代,资源不只是 JS

  1. Browserify 只懂 JS、只懂 CommonJS:一个 React 组件需要它的 JS、它的 CSS、它的图片,但 Browserify 管不了后两者。
  2. 任务流工具不理解依赖图:Gulp 不知道哪个组件用了哪张图。
  3. 首屏 JS 体积爆炸:SPA 把所有代码打成一个巨型 bundle,没法按需加载。
  4. 开发时改一行要刷新整页:状态丢失,体验割裂。

Webpack 的回答:如果一切都是模块,那么我就能用一张依赖图统一管理、统一优化、统一按需加载。

三、核心机制 & 为什么流行

四个支柱

① 一切皆模块 + 依赖图 从入口出发,递归解析 import/require,构建一张包含所有资源的依赖图。import './style.css' 是合法的,因为 CSS 也是模块。

② Loader — 转换单个文件 Webpack 本身只懂 JS。loader 是”翻译官”:css-loader 把 CSS 变成 JS 能理解的模块,babel-loader 调用 Babel 转译,file-loader 处理图片。loader 链式执行,从右到左。

③ Plugin — 干预整个构建生命周期 plugin 能 hook 进构建的任意阶段,做更大范围的事:HtmlWebpackPlugin 生成 HTML,MiniCssExtractPlugin 抽离 CSS,DefinePlugin 注入环境变量。loader 管”单个文件”,plugin 管”整个流程”。

④ Code Splitting + HMR

  • Code Splitting:基于依赖图,把代码拆成多个 chunk,配合动态 import() 实现按需加载——首屏只下必要的。
  • HMR(Hot Module Replacement):改一个模块,只热替换那个模块,不刷新整页、不丢状态。这是当年杀手级的 DX。

为什么统治十年:极致的灵活性 + 庞大的生态。任何资源、任何需求,总能找到对应的 loader/plugin。它成了 React/Vue/Angular 全家桶的事实标准底座。详细论证见 为什么Webpack统治了十年。

四、带来的新问题 / 副作用

灵活的代价是复杂,打包的代价是慢

  1. 配置地狱:webpack.config.js + loader + plugin + babel + polyfill,配置本身成了专业技能,新人劝退。
  2. dev 也要先打包:这是最致命的。开发模式下,Webpack 必须把整个应用打成 bundle 才能启动 dev server。项目越大,冷启动越慢(大项目几十秒到几分钟)。
  3. HMR 也随规模变慢:改一行,Webpack 要重新构建受影响的 chunk,大项目要等几秒。
  4. 性能触顶:Webpack 用 JS 写,再优化也快不过编译型语言。
  5. 心智负担重:tree-shaking、sideEffects、splitChunks 等概念,理解成本高。

核心矛盾:为了”按需加载、统一优化”,dev 模式付出了”必须先打包整个应用”的代价——而这正是开发体验的硬伤。

五、为什么会衰落 / 现状

衰落的根因,是一个前提的失效:

Webpack 诞生时,浏览器不支持模块,所以”开发时必须打包”是天经地义的。但到了 2020 年,现代浏览器原生支持了 ES-Modules——这个前提不再成立了。

Vite(2020)抓住这一点,提出 no-bundle dev:开发时不打包,浏览器请求哪个模块就编译哪个(按需),冷启动从几十秒变成几百毫秒。这是对 Webpack 在 dev 体验上的降维打击。详见 为什么Vite能取代Webpack。

现状(2026):

  • 新项目几乎都选 Vite,Webpack 在新项目里份额持续下滑。
  • 但存量极其庞大,Webpack 仍是许多大型/企业项目的底座。
  • Webpack 作者 Tobias 亲自操刀,用 Rust 写了 Turbopack 作为接班人——承认了”JS 写的打包器性能触顶”这件事。
  • Rspack(字节,Rust 重写 Webpack,兼容其配置)成为平滑迁移路径。

六、对后续技术的影响(因果链)

Browserify 证明"打包"可行,但只懂 JS
        │
        ▼
Webpack:"一切皆模块" + loader/plugin + code splitting + HMR
        │  ① 统一管理所有资源 ──► 组件化工程落地
        │  ② loader/plugin 生态 ──► 灵活到能解决一切需求(也复杂到劝退)
        │  ③ dev 也要打包 ──► 项目越大冷启动越慢(致命伤)
        │  ④ JS 实现 ──► 性能触顶
        │
        ├──► 慢 ──► 浏览器原生 ESM 成熟 ──► [[Vite]] no-bundle dev(开发体验降维打击)
        │
        ├──► 性能触顶 ──► Rust/Go 重写潮 ──► [[Turbopack]](作者亲自操刀)/ Rspack / esbuild
        │
        └──► tree-shaking 做得不如 ESM 优先的工具 ──► 库打包让位给 [[Rollup]]

历史地位

Webpack 是工程化时代的”基础设施之王”。它用”一切皆模块”统一了前端构建的世界观,用 loader/plugin 撑起了整个生态。它的强大(灵活)和它的衰落(慢、复杂)是同一枚硬币的两面——而它衰落的方式(被 Vite 用”重新审视前提”击穿,被 Rust 重写续命)本身就是一堂技术史课。

🔗 相关:前端工程化演进史 | Browserify | Rollup | Babel | Vite | Turbopack | ES-Modules | 为什么Webpack统治了十年 | 为什么Vite能取代Webpack | 2013-2018 SPA时代 | 2018-2023 工程化时代

关系图谱

反向链接