JavaScript 臃肿现状深度解析：我们为何在重复造轮子？

📌 一句话摘要

深入剖析 JavaScript 生态臃肿的三大根源——旧版运行时兼容性、过度原子化架构和过期补丁，同时提供 e18e 倡议等实用解决方案。

📝 详细摘要

该视频对困扰现代 Web 开发的 JavaScript 臃肿问题进行了全面批判。主讲人拆解了臃肿的三大支柱：（1）为大多数开发者从未遇到的古老运行时提供的过度兼容层；（2）造成依赖地狱和安全漏洞的超原子化 npm 包；（3）原生支持早已到位却仍留在依赖树中的僵尸补丁。通过 is-string、shebang-regex、globalthis 等具体案例，视频揭示了现代项目如何继承数千个不必要的依赖。内容不止于批评，还提供了可执行的解决方案——如用于依赖审计的 knip 工具和 e18e 社区生态清理倡议。主讲人还赞扬了 Hero Devs 维护遗留系统的默默无闻的工作，并呼吁社区支持开源维护。

💡 主要观点

- 旧版运行时兼容性造成臃肿的依赖链，加重现代开发者负担 像 is-string 这样的包拉入数十个子依赖来处理 IE6 和远古 Node 版本的边缘情况——而这些场景与 99% 的项目无关。当 Hero Devs 将兼容补丁合并回主线时，所有人都要为此买单。

包的过度原子化增加了攻击面并浪费资源 像 shebang-regex（2 行代码，每周 1.33 亿次下载）和 arrify（1 行代码，每周 3200 万次下载）这样的微包违背了 Unix 哲学的精神。每个包都增加了 npm 请求、解压开销和供应链风险。

僵尸补丁在原生支持到位多年后仍残留在依赖树中 像 is-array（2010 年原生支持，每周 1.6 亿次安装）和 globalthis（2019 年支持，每周 4900 万次安装）这样的包因为没人移除而继续被下载。当 LTS 引擎支持这些特性时，库作者应该果断清理它们。

个人开发者可以审计并清理自己的依赖树 像 knip 这样的工具可以识别未使用的代码和依赖。e18e 倡议提供迁移指南（如从 chalk 迁移到 picocolors）和社区协调，实现全生态系统的清理。

💬 文章金句

- 大多数在 Web 上传输的 JavaScript 是完全不必要的。

• Unix 哲学不应该应用到单行代码层面。
• 每一个微小的包都是潜在的攻击点。
• 我们都在为极少数人的极端边缘架构需求买单。
• 在我们生态系统中做着最吃力不讨好的工作的人，收入却最少。

📊 文章信息

AI 评分：87

来源：Theo - t3․gg

作者：Theo - t3․gg

分类：软件编程

语言：英文

阅读时间：11 分钟

字数：2586

标签： JavaScript, npm, 依赖管理, 性能优化, e18e

播放完整视频