[译] 愿未来没有 Webpack - 掘金

Posted 2021-04-29 前端小苑

精品技术文章，热门资讯第一时间送达

• 译文出自：掘金翻译计划

• 本文永久链接：https://github.com/xitu/gold-miner/blob/master/TODO1/pika-web-a-future-without-webpack.md

• 译者：Badd

• 校对者：MarchYuanx, sunu

用 @pika/web 安装的 npm 包可以直接在浏览器中运行。这样的话你还需要一个打包工具（bundler）吗？

现在是 1941 年。你的名字是 Richard Hubbell。你在 CBS 旗下的一个试验性的纽约电视演播室工作。你将要主持一场重大电视新闻广播，这是世界上首批电视节目之一，你还有 15 分钟就要上场了。你知道你一会儿要干嘛吗？

在一个人们只知道收音机的世界里，你会坚信你的认知。而你此刻的认知就是，你要把新闻稿读出来。“Hubbell 主持的电视新闻节目几乎都是照本宣科，偶尔把镜头切到一张地图或者静态图片上。”还得过一阵子，人们才能在电视新闻上看到真实的视频片段。

作为一名身处 2019 年的 javascript 开发者，我也有同感。我们明明已经拥有了这个崭新的 JavaScript 模块系统（ESM），它可以直接在 Web 环境中运行。可每次开发点什么，我们还是得用打包工具处理一下。这到底为什么？

在过去的几年里，JavaScript 打包界的炙手可热已经从只优化生产环境转变到了逢开发必打包的程度。不论你喜欢与否，都很难否认打包工具给 Web 开发带来了变态级别的复杂性，而 Web 开发明明是一个一贯以源码可见和轻松上手的精神为荣的领域啊。

@pika/web 试图将 Web 开发者从打包地狱中解救出来。都 2019 年了，你使用打包工具应该是因为你想要用，而不是因为你不得不用。

Credit: @stylishandy

我们为什么要打包

JavaScript 打包不过是旧瓶装新酒罢了。在过去（哈哈，大概 6 年前），在生产环境中将 JavaScript 文件压缩并合并是家常便饭。这样做能够提升网站的加载速度，并绕开 HTTP/1.1 的并行请求瓶颈。

本来这个优化有它更好没有也行，怎么后来就变成了开发过程中绝对必须的步骤了呢？这就是最疯狂的地方：大多数 Web 开发者从来没有特地要求过必须打包。相反，打包只是个副作用，我们真正渴求的另有其物 —— npm。

npm —— 彼时代表着“Node.js 包管理工具” —— 正在逐渐成为有史以来最大的代码注册中心。前端开发者们希望能参与其中。唯一的问题在于，其 Node.js 风格的模块系统（Common.js 或 CJS）不经过打包就不能在 Web 环境中运行。故此，Browserify、Webpack 以及其他现代 Web 打包工具应运而生。

直观感受创建 React 应用：运行“Hello World”需要安装超过 1300 个依赖包

复杂性斯德哥尔摩综合征

如今，想要开发 Web 项目，不用 Webpack 之类的打包工具基本是不可能了。就拿 Create React App（CRA）快捷方式举例子，当你满心希望能快速创建项目，却发现需要先安装超过 1300 个不同的依赖包，整个臃肿的 node_modules  文件夹足足有 200.9MB 大小，而你只是想运行个“Hello World”啊！

就像 Richard Hubbell 那样，我们都深陷于打包工具的泥沼之中，太容易忽略事物本可以截然不同。我们现在有这么多优秀的现代 ESM 依赖包可以使用（npm 上差不多有 50000 个！）。是什么阻止我们直接在 Web 环境上使用它们？

嗯，还真有那么几个原因。