作者 | Loraine Lawson
編譯 | 言征
「JavaScript太重了。」雖然JS在全球開發語言中屬於巨無霸的存在，但從過去到現在，吐槽JS的聲音一直不絕於耳。
比如，要系統的學JavaScript，有一大套工具鏈，而且是非官方的工具鏈。許多新手一看到VS Code，NodeJS，Babel，Webpack，Jest，Gulp， TypeScript...頓時就被勸退。
再比如，語法特性也是亂成一團。弱類型，又可以面向對象，又可以函數式編程，還可以面向過程，還有this關鍵字，這些全部混著用。誰也不想接受這樣的屎山代碼！
就連Solid.js框架的創建者Ryan Carniato，也在近日發聲：是時候在Web中減少JS代碼了！
一、採用 0 Kb JavaScript？做不到！
Carniato目前在Web開發平台Netlify任職，近期他在「International JavaScript」會議的主題演講中向前端開發人員提出了一個問題：「你未來會採用 0kb JavaScript 嗎？」
當然，Carniato提出的這個問題更多是是一個假設性問題，因為 0kb 並不是真正的目標。更重要的是前端需要減少其JavaScript的占用空間。
「如果我們回顧過去和現在，就會發現關於降低 JavaScript 成本的討論一直在進行，而且證據充分確鑿。」
首先，他給開發人員展示了一組統計圖數據，圖中顯示了按內容類型劃分的網頁權重的中位數，很明顯，除了意料之中的圖片之外，讓網頁變得十分「沉重」的罪魁禍首便是JavaScript。
按內容類型劃分的頁面權重顯示了 JavaScript 在增加頁面重量方面的影響。
如何讓網頁變輕？「首先，如何優化圖像是眾所周知的，但 JavaScript 有點棘手，而且它恰好是所提供的最昂貴的資產之一，」他說。
同時，Carniato指出，這種情況在移動設備上則是一個更大的問題，根據設備和網絡的不同，要代價可能「非常高」。
他展示了一個 JavaScript 大小為 170 KB 的示例。JavaScript的處理時間要比圖像更「漫長」。
「在一台低端設備上，處理時間，即解析、執行、運行 JavaScript 代碼的時間，幾乎是3秒半，而圖像大約是 100 毫秒左右。」
不同高端低端設備的多核跑分
而且，高端設備和低端設備之間處理能力的差異，也存在越來越明顯的差距。2022 年的低端設備市場在處理能力方面與 2014 年的高級設備類似，因此 iPhone 6s 本質上就像擁有 Moto E 30。
這裡，Carniato提到了尤其會對電商公司 eBay 造成不小的影響，因為在電子商務領域，頁面加載至關重要。
「加載時間和購買率之間存在相關性，這已經不是什麼秘密了，」他說。「問題的真相在於水合（Hydration），而大型 JavaScript 有效負載也是我們架構責任的一部分。」
名詞解釋：1.水合作用的實質是水分子整體進入礦物晶格，從而使礦物體積增大的作用。這裡是指 Web開發中的一種交互性技術。
在web開發中，水合（Hydration）是一種為伺服器渲染的HTML添加交互性的技術。這是一種客戶端JavaScript通過將事件處理程序附加到HTML元素，將靜態HTML網頁轉換為動態網頁的技術。
近年來，水合開始被視為一個消耗內存並減慢啟動速度的黑客，尤其是在移動設備上。
二、前端開發者該為JavaScript瘦身了！
Carniato 給出了為Web中 JavaScript 代碼「瘦身」的幾種策略。
1.代碼分割/延遲加載
Carniato 說，代碼分割和延遲加載可以顯著減輕重量。「現在使用的幾乎所有元框架或工具幾乎都會在路線級別自動為您完成此操作，」他說。「所以你應該已經這樣做了。」
關於框架如何水合需要了解的一件事是，伺服器渲染的任何內容都需要水合，就好像它在頁面上可見一樣，這就是開發人員顯示其他內容並將其交換的原因。確實需要一些手動操作才能完成這項工作，他補充道，因為如果某些東西確實存在於投降 DOM 中並且它應該是交互式的，那麼它就會水合。
「延遲加載並不能阻止它。這就是這些框架的工作方式，因為它們基本上需要運行整個應用程式，」他補充道。
2.使用更小/更快的框架
Carniato 採用了一種有趣的方法來比較框架。他在開始時查看了它們的大小，然後隨著更多組件添加到框架中。結果令人驚訝，因為快速框架不一定保持快速。
JavaScript 框架速度
「是的，你的基線 [...] 開始較小，但實際上一旦編寫代碼情況就變了，」他說。「因此，在某個時刻，這些組件會構成更大的一塊。」
有些框架一開始很小，但隨著組件的添加，框架開始相互接近。他以 Svelte 為例。「例如，Svelte 從最小的開始；當你擁有 80 個獨特的組件時，它實際上比 React 和其他所有組件都大，」他說。
「所以大多數框架實際上在規模上非常相似，事實上，你可以看到最上面的那條線，那就是在開頭的React——它有相同的斜率。」
3.漸進式增強
漸進式增強基於這樣的理念：Web是建立在anchors 和表單之上的；他解釋說，因此，如果 JavaScript 不存在，開發人員可以依靠平台中已經內置的內容。
「漸進式增強確實得到了很大的推動，特別是在 Remix 和 SvelteKit 這樣的框架中，」他說。「只要將所有交互編寫為anchors 和表單，那麼它們無需 JavaScript 即可運行。我認為這是一件很棒的事情。」
不過，Carniato 認為，它不一定能替代其他減少JS代碼的方法，但它的確創造了一種非常不同的體驗。
「我之前提到的那個可憐的用戶，他使用的手機需要3秒半的時間來加載解析——假設總共需要7秒才能進行交互——他們點擊連結可見3秒的連結，已經過去6秒，」他說。「你猜怎麼著？JavaScript 還沒有加載。」
因此，現在他們必須重新加載整個頁面並再次等待七秒鐘，而不是使用一些可供性進行客戶端導航，他補充道。
「這當然OK，但這實際上並不是完全的勝利，它並不能解決問題，」
4.漸進式水合（Progressive Hydration）
他說，漸進式水合背後的想法是，頁面根據需要進行水合。當有人點擊文檔時，開發人員可以提前將一些事件處理程序附加到文檔，然後用它來做一些聰明的事情。他補充說，有時這被稱為選擇性水合。
漸進式補水合 繪製：Dan Abramov
Twitter上一位專家Dan Abramov為 Carniato 繪製了上圖，試圖展示如果 React 還沒有完全水合，並且有人點擊不同的分支（可能不是 React當前正在加載或水合的分支）會發生什麼，那麼它就會足夠聰明地擺脫它正在做的事情，然後優先考慮被點擊的那個分支。
「它仍然必須從父節點到子節點，但你可以給中間節點做水合，而不是繞過去；對我來說，無阻塞在這種情況下非常好，」Carniato 說道。
但事情也不是絕對的，你可能不會注意到，有時這也會導致總時間更長，另外，你會發現，後台中的CPU會嘎嘎作響，可能會在一定程度上影響體驗。
此外，Carniato 還給出了其他幾種 JavaScript 瘦身的辦法，後續我們會跟蹤報道，也歡迎諸位在評論區探討交流。
最後想說一句，有人認為拋開JavaScript的龐大生態，去吐槽JavaScript太臃腫，有點耍賴皮，誰讓現在基本所有的Web都在用它呢！