JavaScript 膨胀的三大支柱：为什么现代 Web 应用如此臃肿

JavaScript 膨胀的三大支柱：为什么现代 Web 应用如此臃肿

一篇题为「JavaScript 膨胀的三大支柱」的深度技术文章在 Hacker News 上获得了 308 分，引起了厌倦于 Web 应用体积不断增长的开发者的强烈共鸣。作者指出了推动现代 Web 开发中 JavaScript 膨胀的三个根本力量。

三大支柱

支柱一：框架抽象层

现代框架在开发者和浏览器之间添加了多层抽象：

• React/Vue/Svelte 将 JSX/模板编译为 JavaScript
• 状态管理库（Redux、Zustand、Pinia）添加了自己的运行时
• 组件库（MUI、Ant Design、Chakra）打包了数百 KB 未使用的 CSS/JS
• 构建工具（Webpack、Vite、esbuild）添加了自己的运行时代码块

结果：一个简单的待办事项应用很容易需要 500KB+ 的 JavaScript。

支柱二：依赖扩散

npm 生态鼓励小的、单一用途的包，级联成依赖树：

• 平均 Node.js 项目有 500+ 个传递依赖
• left-pad 事件（2016）展示了这个生态系统有多脆弱
• Tree-shaking 有帮助，但仅对 ES 模块有效——许多包仍然使用 CommonJS
• 跨包的重复依赖造成膨胀

支柱三：开发者体验优于用户体验

现代 DX 工具以牺牲运行时性能为代价优先考虑开发者便利性：

• 热模块替换（HMR）增加了运行时开销
• Source map 有时被发送到生产环境
• TypeScript 类型定义增加了包大小
• 调试工具和仅开发环境的代码路径泄漏到生产包中

数据

文章提供了令人震惊的例子：

• 一个简单的 React 待办应用：~200KB gzipped JavaScript
• 一个中型电商网站：~1.5MB gzipped JavaScript
• 一个复杂的 SaaS 仪表板：~3-5MB gzipped JavaScript
• 对比：「JavaScript」的整个维基百科文章约 50KB 文本

解决方案与替代方案

作者不只是抱怨——他们提供了可行的解决方案：

1. 审计依赖：添加包之前使用 bundlephobia.com 检查包大小
2. 选择更轻量的替代品：Preact（3KB）vs React（42KB），Zustand（1KB）vs Redux（7KB）
3. 服务端组件：Next.js App Router 等框架将渲染移到服务器
4. 岛屿架构：Astro、Qwik 发送最少的 JavaScript，仅激活交互式组件
5. 渐进增强：从 HTML 开始，仅在需要的地方添加 JavaScript

为什么这很重要

JavaScript 膨胀不仅是开发者的关注点——它对用户有实际影响：

• 加载时间：在 3G 网络上 1MB JavaScript 可能增加 3-5 秒
• 电池寿命：JavaScript 执行是 CPU 密集型的，会消耗移动设备电池
• 可访问性：沉重的 JS 可能导致布局偏移和缓慢的交互性
• 环境影响：为臃肿 JavaScript 服务的服务器消耗更多能源

行业趋势

有反潮流运动的迹象：

• HTMX 和服务器优先的方法越来越受欢迎
• Deno 和 Bun 旨在简化 JavaScript 运行时
• Web Components 提供了与框架无关的可复用 UI 元素
• "Web 平台"（CSS Grid、Container Queries、View Transitions）正在赶上框架提供的功能

来源: 43081j.com | HN 讨论