前端開發時的 JavaScript 的成本考量

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 重述不要把高階裝置與高速網路，視為理所當然；在開發時用中低階的裝置與一般的網速，會更貼近真實的使用狀況。同時他建議每個前端團隊，都要為效能設定目標，並且花時間與精力來確保不會超出設定的目標。