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