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