前端开发时的 JavaScript 的成本考量

本篇最早收录于《ExplainThis 全端双周报》第 7 期

JavaScript 是让网页应用程式能够具有互动性的程式语言，也是前端工程不可或缺的一环，然而过多的 JavaScript 是有成本的。 《The Cost of JavaScript》是前端界很经典的一个演讲，讲者 Addy Osmani 上个月分享了 2023 年版本的内容。

在谈论 JavaScript 前，有个重要的概念需要放在脑中，那就是硬体与网路速度对网页的影响很大；而在这世界上，多数人仍是使用中低阶的装置，因此同样的程式在你开发的环境可能跑很快，但这不代表对那些用比较低阶装置的使用者是同样的速度。这也是为什么我们要在乎 JavaScript 成本，因为越大包的 JavaScript，载入与执行越慢，在中低阶装置上会特别有感。

从 JavaScript 的角度来看，平常我们在执行 npm install 时，每多装一个套件，就是多一个成本。要降低成本的一个方式，是拆分代码 (code splitting)，把打包出的 JavaScript 拆成多个模组，然后只在需要时加载该模组，这样可以避免在最开始加载一个大的模组导致时间变长。

近几年为了加快网页应用的加载，前端业界开始回归伺服器端渲染 (SSR)，在伺服器端渲染好 HTML，传送到客户端后才加上事件处理器 (又称为注水 hydration)，这个概念进一步延伸出岛屿架构 (Islands Architecture) 与渐进式注水 (Progressive Hydration)，等减少在最开始一次注水，进而提升速度。同时也有 Qwik 框架提出的 Resumability 概念，只在需要的时候创建事件处理器，确保最少量的 JavaScript。

另外也有许多框架开始推出了“零 JavaScript”的概念，其中包含 React 的 Server Components (RSC)，完全在伺服器端渲染好元件，然后透过串流的方式传到客户端，大幅加速了最开始的加载速度。

总结来说，在 2023 年的前端，有非常多过去没有的创新，能够协助我们更有效的控管过量的 JavaScript。在演讲的最后，Addy Osmani 重述不要把高阶装置与高速网路，视为理所当然；在开发时用中低阶的装置与一般的网速，会更贴近真实的使用状况。同时他建议每个前端团队，都要为效能设定目标，并且花时间与精力来确保不会超出设定的目标。