JavaScript 开发的挑战与未来：简化与创新的平衡

JavaScript 代码交付领域正在发生重大变革，开发者们已经开始注意到这些变化。从 ReactConf 参会者对新近开源的 React 编译器的热情程度来看，社区对于优化 Web 代码交付的工具和标准有着巨大的需求。改进客户端代码交付解决方案不仅涉及代码编译，也在彻底改变代码打包、压缩、分割、摇树优化、转译和模块化的方式。这听起来有点复杂？确实如此，但即使你不完全理解这些技术的工作原理，重要的是你要知道这些复杂的转换器和优化器都是为了提升客户端体验而设计的，无论是通过加快浏览器的加载速度来改善最终用户体验，还是通过简化和快速构建来改善开发者体验。

作为一名需要记住大量 React 代码的开发者，我迫不及待地想要摆脱这一切。所以我对即将到来的 React 编译器感到无比兴奋。#reactconf

— Drew Butler (@DrewButlerMe) 2024 年 5 月 15 日

由于向浏览器传输代码（HTML、CSS 和 JavaScript）和资源（图片、字体和视频）的生态系统正在迅速发生演变，我们有必要停下来思考一番。Web 开发领域最近发生的事件（无论是争议还是新技术的发布）不仅对那些直接参与编码的开发者产生了影响，也对提供相关产品和服务的供应商产生了影响，并且这些事件还改变了风险资本的融资环境。关于这个领域有很多东西可以说，所以我不会试图在一篇文章中涵盖所有内容。我会用一系列文章来阐述为什么 JavaScript 项目构建步骤和向浏览器传输代码对于创新和投资来说是一个值得关注的领域。

代码编译，即把人类可读的代码翻译成机器可读的代码的过程，以及优化，比如为不同设备生成多种大小和格式的过程，在大多数 Web 开发中都是一个标准的过程。然而，这个构建步骤正在发生演变，有时甚至回归到早期不那么复杂的模式。

在很大程度上，是 Ryan Dahl 在 2009 年开发的运行时环境 Node.js 把我们带到了如今这种重构建的 Web 开发时代。与过去在 index.html 文件中直接添加脚本代码的标准做法不同，Node 让开发者能够使用 JavaScript 编写服务器和后端代码。虽然这一变化具有革命性，但这一变化也给 Web 开发带来了更多层次的复杂性。

但开发者对 Node 的依赖在很大程度上已经成为前端领域一个越来越明显的趋势，这种趋势使得 JavaScript 密集型的单页应用程序（SPA），如 React、Vue 和 Angular，所需的繁重构建过程变得司空见惯。它也反映了 Web 开发中的一种过度偏重，即过分强调开发者体验而不是用户体验。新的构建过程常常与开发者的幸福感相关，因为他们可以通过高级抽象的构建步骤来转换机器可读的代码。然而，开发者的快乐是以牺牲最终用户的 Web 体验为代价，尤其是那些使用旧设备和网络条件不佳的用户。

从 2010 年初开始，为了让服务器端 JavaScript 在浏览器中运行，催生了一系列开发者工具，这些工具旨在为浏览器打包 Node/npm 环境，包括 Browserify（2011 年）、Grunt（2012 年）、Gulp（2013 年）、Babel（2014 年）、Webpack（2014 年）、Rollup（2015 年）、SWC（2019 年）、Vite（2020 年）、ESBuild（2020 年）和 Rspack（2022 年），等等。今天，许多来自前端社区的开发者和风险投资提供支持的公司正在开发 Node 的替代品或至少是向后兼容的替代品，如 Deno（A 轮，Shasta Ventures、Sequoia Capital 等）和 Bun（种子轮，Y Combinator 和 Kleiner Perkins）。他们在争论 Web 开发是否应该摒弃编译器、打包器、优化器等，回归到 HTML、CSS 和 JS 基础。例如，在 2021 年，David Heinemeier Hansson（DHH）发表了一篇题为“无需 JavaScript 打包或转译的现代 Web 应用”的帖子，他在文章中表达了对复杂构建过程的反对。他写道：

使用 Babel 进行转译开启了一个复杂转译流程和工具的时代。使用最新的、尚未被所有浏览器广泛支持的 JavaScript 语言特性来编写代码并非没有代价。代价是不断扩大的复杂性网络，而这显然不是终点。

虽然 DHH 列举了许多可以结束打包和编译需求的创新举措，包括 ES6、HTML2、import map，但他意识到更重要的一步是浏览器的改进，这些改进使得构建步骤变得越来越没有必要。得益于引擎和标准的改进，开发者现在能够在浏览器中原生地完成各种任务。即使没有编译，前端工程师现在也能够编写嵌套 CSS（告别 Sass）并使用 WebAssembly 执行代码。

开发者已经注意到这些扩展能力，并开始思考它们对 Web 开发未来的意义。随着替代方案变得愈加主流，一些工程师，如 Prahlad Yeri，开始提出想“Node.js 有未来吗？”这样的问题。最近一期的 JSParty 播客也讨论了“Web 开发需要构建步骤吗？”这个话题。尽管 JSParty 小组成员不出所料地得出“视具体情况而定”的结论，但主持人 Kevin Ball 认为这个问题的核心在于：

确定试图解决的业务问题，并做尽可能少的事情——我们只需要拥有控制问题所需的最小一组事物，将其余的事情尽可能多地转移给工具、平台等。

这种“少即是多”的哲学在软件工程社区引起了共鸣，尤其是那些关注 Web 开发和 JavaScript 生态系统的人。大家似乎都认同当前的复杂性是不可持续的，而且在很大程度上是不必要的。本月早些时候，我在 RenderATL 技术会议上与 Request Metrics 和 TrackJS 的 CEO Todd Gardner 谈到了他在 JavaScript 构建领域所看到的情况。对于复杂性问题的共鸣，他反思道：

前端工程社区有一些非常聪明的人，但有时候聪明的人也需要面对挑战，为自己创造出新的问题。

对于 JavaScript 开发者来说，遵循 KISS 原则的呼声越来越高，但编译器和打包器的数量却在不断增加。事实上，当 Web 构建工具 Farm 推出时，在 Hacker News 上引发了热烈的讨论。JavaScript 构建领域需要做一些改变，而这些改变又是什么？开发者如何在性能和简单性之间找到平衡？哪些因素最有利于产品在当今市场中充分利用浏览器的客户端计算和交互能力？最后，选择使用 Rust 开发这些东西背后的原因又是什么？

原文链接：

https://redmonk.com/kholterhoff/2024/06/25/the-problem-of-javascript-code-delivery/

声明：本文由 InfoQ 翻译，未经许可禁止转载。