丨webassembly能夠為前端框架賦能嗎

逐漸從“舊時代”的jQuery、Prototype.js了以“MVVM”框架為主的“新時既然我們說Wasm于Web，并且它的出現(xiàn)會給未來的Web應(yīng)用開發(fā)模式，帶來一系列變化。那么，對于這些現(xiàn)階段在我們?nèi)粘９ぷ髦谐袚?dān)“主力”角色的Web端框架來說，Wasm會給它們帶來怎樣的變化呢？未來的Web前端開發(fā)框架會以怎樣的方式與Wasm緊密融合呢？相信這些問題，是每一個Web前端開發(fā)同學(xué)在接觸Wasm這項技術(shù)之后，都會存在的疑問。今天，我們就來看一看，在如今的WasmMVP標(biāo)準(zhǔn)下，對于這些基于JavaScript編寫的現(xiàn)代Web前端框架我們能夠做些什么。在上一章的“原理篇”中，我們從不同的角度講解了Wasm究竟是什么。那這里我們還是用最精簡的方式來概括一下：“Wasm是一種基于堆棧式虛擬機(jī)的二進(jìn)制指令集，它被設(shè)計成為編程語言的可移植編譯目標(biāo)。借助Web平臺提供的相關(guān)接口，我們可以在Web瀏覽器中高效地調(diào)用從Wasm模塊中導(dǎo)出的函數(shù)”。那我們就根據(jù)Wasm現(xiàn)階段所具有的這些能力，來討論一下Wasm對現(xiàn)代Web前端開發(fā)框架可以產(chǎn)生怎樣的影響。我將會根據(jù)Wasm與框架之間的可能融合程度，來從不同的使用Wasm完全重寫現(xiàn)有使用Wasm重寫現(xiàn)有框架的邏使用Wasm合框架增強應(yīng)用的部分功能使用其他語言構(gòu)建Web前端框架接下來，我將依次和你討論上面的這四種使用Wasm完全重寫現(xiàn)在這個方案下，使用Wasm完全重寫現(xiàn)有的Web前端框架。而這就需要我們通JavaScript之外的諸如C/C++、Rust等第靜態(tài)類型語言，將框架的邏輯全部重寫在此之前，Web前端框架的使用方式可以通過如下圖來大致描述。你可以看到，除去樣式文件（CSS）以外，我們的Web應(yīng)用程序僅由“框架代碼”和“應(yīng)用程序代碼”兩部分組成。這兩部分代碼全部由JavaScript語言進(jìn)行編寫。HTML文件負(fù)責(zé)將這些JavaScript代碼整合在一起，并確保在頁面加載時執(zhí)行它們。當(dāng)Web前端框架使用Wasm完全重寫后，事情又會變成另外一幅景象。此時Web應(yīng)用組成結(jié)構(gòu)將如下圖所示除了使用JavaScript編寫的“應(yīng)用程序代碼”，以及經(jīng)過編譯生成的Wasm字節(jié)碼格式的框架代碼以外，我們的項目中還會多出來一部分用作“GlueCode”（膠水代碼）的JavaScript代碼。那這部分GlueCode主要用來做什么呢？這就要從現(xiàn)階段的Wasm標(biāo)準(zhǔn)與Web瀏覽器的可交互性開始說起了。無法剝離的JavaScript代在現(xiàn)階段Wasm的MVP標(biāo)準(zhǔn)中，我們需要通過各類JavaScriptAPI與WebAPI來在Web臺上與Wasm碼（模塊）進(jìn)行交互。這些API只能夠通過JavaScript來進(jìn)行調(diào)用。而所有這些需要與Wasm模塊直接進(jìn)行的交互（互操作），都是由包含有API調(diào)用的GlueCode代碼完成的。恰巧在目前Wasm的MVP標(biāo)準(zhǔn)中，我們也同樣無法直接在Wasm字節(jié)碼中操作HTML頁面上的DOM元素。因此，對于這部分Web框架最的功能，便也是需要通過借助GlueCode調(diào)用WebAPI來幫助我們完成的。為了達(dá)到這個目的，我們需要將DOM操作相關(guān)的邏輯封裝成JavaScript函數(shù)，然后再通過Wasm模塊的ImportSection導(dǎo)入到模塊中供其使用。//externvoidintmain(intargc,char**argv)因此，框架//externvoidintmain(intargc,char**argv)4//創(chuàng)建一個空的；567return8然后下面是GlueCode對應(yīng)的JavaScript代碼//WebAssembly.instantiateStreaming(wasmBytes,4456789env://將函數(shù)導(dǎo)入到WasmcreateEmptyDivElement:()}可以看到，在GlueCode代碼中，封裝好的用于調(diào) .createElement”這個WebAPI去創(chuàng)建空div的JavaScript函數(shù)“createEmptyDivElement”，傳遞給了用于實例化Wasm模塊的WebAssembly.instantiateStreaming方法。在框架所對應(yīng)的C++代碼中，我們使用了這個從JavaScript環(huán)境導(dǎo)入到Wasm模塊中的“createEmptyDivElement”函數(shù)。這里在代碼中，所有通過“extern”指定的外部函數(shù)，都將會在編譯至Wasm二進(jìn)制模塊后，從模塊對應(yīng)的ImportSection中獲取實際的關(guān)于上述的代碼示例，你大致有一個印象即可。我們會在“實戰(zhàn)篇”中詳細(xì)介紹一Wasm目從01完整構(gòu)建流程跨上下文頻繁調(diào)用的開除了上面提到的，即使將Web前端框架完全重寫并編譯至Wasm，我們也無法在完全脫離JavaScriptGlueCode情況下使用框架。另一個由此帶來的問題在某些情況下可能會顯得更加“致命”，那就是“Wasm與JavaScript兩個上下文環(huán)境之間的函數(shù)調(diào)用開銷”在早期的Firefox瀏覽器（版本62以前）上，由于實現(xiàn)問題，導(dǎo)致不管是使用JavaScript調(diào)用從Wasm模塊中導(dǎo)出的函數(shù)，還是在Wasm模塊內(nèi)調(diào)用從Web瀏覽器導(dǎo)入到模塊內(nèi)的JavaScript函數(shù)，這兩種方式的函數(shù)調(diào)用成本都十分高昂。在某些情況下，同樣的函數(shù)調(diào)用過程會比JavaScript之間的函數(shù)調(diào)用過程慢約20倍。但好在Firefox在62之后的版本中修復(fù)了這個問題。并著重優(yōu)化了JavaScript與Wasm之間的函數(shù)調(diào)用效率。甚至在某些情況下，JavaScript與Wasm之間的函數(shù)調(diào)用效率要高于JavaScript之間的函數(shù)效率。雖然這個問題在Firefox上得到了修復(fù)，但不可否認(rèn)的是，在其他瀏覽器廠商的Wasm實Web前端框架作為一個需要與DOM元素，以及相關(guān)WebAPI強相互依賴的技術(shù)產(chǎn)品，可想而知其在實際使用過程中，必然會通過GlueCode去完成Wasm與JavaScript之間的頻繁函數(shù)調(diào)用。而以性能為重的Web前端框架，則無法忽視這些由于頻繁函數(shù)調(diào)用帶來使用Wasm重寫現(xiàn)有框架的邏在第二種方案下，使用Wasm重寫Web前端框架的邏輯，但并非全部如下圖所示，在這種情況下，Web應(yīng)用的主要組成結(jié)構(gòu)與上案類似，唯一的不同是增加了Web框架所對應(yīng)的JavaScript代碼實現(xiàn)部分。相較于將整個框架都通過Wasm來實現(xiàn)，僅實現(xiàn)框架的邏輯部分，可以說更具有現(xiàn)實可以遵循的原則是，這部分邏輯不會涉及與DOM或者WebAPI的頻繁交互，但其卻又是“計算密集（compute-intensive）”的這里的“計算密集”可以理解為：包的純數(shù)學(xué)計算邏輯。我們知道，Wasm十分擅長處理這樣的計算密集型邏輯。一個很具有代表性的，可以被Wasm重寫的組件便是ReactFiber架構(gòu)中的Reconciler（主要用來計算React中VDOM之間的差異）。使用Wasm配合框架增強應(yīng)用的部分我們繼續(xù)逐漸遞減Wasm與框架的“耦合”程度在第三種方案中，從本質(zhì)上來看，框架本身的代碼不會有任何的變化。而Wasm也不再著重于優(yōu)化框架本身的性能。相對地，框架與Wasm將會配合起來使用，以優(yōu)化整個應(yīng)用的某一部分功能。下面這張圖是在這個方案下，一個Web應(yīng)用的基本組成結(jié)構(gòu)?？梢钥吹剑@里Wasm本身只是作為一個模塊，用于優(yōu)化應(yīng)用的某方面功能。而Web框架本身的源代碼組成形式不會發(fā)生任何改變，應(yīng)用仍然還是使用JavaScript來構(gòu)建其主體事實上，這是Wasm在Web上的一種最為典型和常見的應(yīng)用方式。Wasm并不嘗試取代JavaScript，而是通過利用其優(yōu)勢來補足或者加以提升Web應(yīng)用在某方面的短板。一個最我們都知道，“編”實際上是十分單純的數(shù)學(xué)計算，那么這便是Wasm能夠大顯身手的地方。通過替換Web應(yīng)用中原有的基于JavaScript實現(xiàn)的編邏輯，使用Wasm來實現(xiàn)這部分邏輯則會有著明顯的性能提升。而且由于這個過程不涉及與WebAPI的頻繁交互，Wasm所能夠帶來的性能提升程度更是顯而易見的。使用其他語言構(gòu)建Web前端框最后案相較于之前的幾種可能會稍顯激進(jìn)，但隨著Wasm發(fā)展而不斷出現(xiàn)的，一批又一批基于此方案實現(xiàn)的Web前端框架，值得讓我們重新重視起來。在此方案下，使用諸如C++和Rust等靜態(tài)類型語言來實現(xiàn)Web前端框架。不僅如此，我們也同樣需要使用這些語言來編寫我們的Web應(yīng)用。類似的框架有基于Rust語言的Yew、Seed，以及基于Go語言Vugu等等。以相對較為“流行”的Yew框架為例，我們使用它來編寫Web前端應(yīng)用的大致思路，與React和Vue.js等傳統(tǒng)JavaScriptWeb前端框架的形式十分類似。以下代碼展示了如何使用Rust語言基于Yew框架，來構(gòu)建一個基本的Web前端應(yīng)用。7typeMessage=8typeProperties=9//應(yīng)用創(chuàng)建時執(zhí)行的生fncreate(_:Self::Properties,_:ComponentLink<Self>)-SelfApp}//應(yīng)用視圖更新時執(zhí)行的生命fnupdate(&mutself,_msg:Self::Message)->{}//定義應(yīng)用視圖結(jié)構(gòu)fnview(&self)->Htmlhtml! <p>{ o,world!" 23相信即使你不懂Rust，但如果你熟悉React，仍然可以發(fā)現(xiàn)基于Yew建的Web用，它的代碼組織結(jié)構(gòu)與React十分類似，整個應(yīng)用也同樣被劃分為不同的“生命周期”比如在上面的代碼中，“create”方法對應(yīng)應(yīng)用的創(chuàng)建時刻；update方法對應(yīng)應(yīng)用的狀態(tài)更新時刻，以及最后用于渲染應(yīng)用UI的view方法等等。不僅如此，在Yew中也同樣擁有組件的概念，使用方式與React類似。相對來說，拋開語言本身帶來的成本不談，單從性能來看，在目前Wasm的MVP標(biāo)準(zhǔn)下，Yew這類框架的潛力還沒有實際的來。Yew希望能夠借助Wasm的能力，將視圖（VDOM）差異的計算過程以更高性能的方式進(jìn)行實現(xiàn)。但鑒于目前MVP準(zhǔn)下的一些限制，實際上在最后的編譯產(chǎn)物中，GlueCode執(zhí)行時所帶來的成本則會與Wasm不僅如此，考慮到目前JavaScript在構(gòu)建Web應(yīng)用時的豐富生態(tài)和資源，單從性能角度進(jìn)行考量而使用Yew等框架也不是一個實際可行的方案。因此，未來這類“跨語言”Web前端框架的生態(tài)會變得如何，也只能夠讓我們拭目以待在介紹了上述四種，Wasm可能與Web前端框架相互結(jié)合的方案后。我們再回過頭來，看一看目前仍然流行的幾種JavaScriptWeb前端框架有沒有進(jìn)行與Wasm結(jié)合的相關(guān)嘗試。這里我選擇了React、Vue.js以及Ember.js這三種Web框架。作為目前Web前端開發(fā)領(lǐng)域中最流行的框架之一。React暫時還沒有計劃進(jìn)行任何與Wasm關(guān)的嘗試。如下圖所示，雖然社區(qū)中曾有人提議使用Wasm寫ReactFiber構(gòu)中的Reconciler組件，但由于目前Wasm還無法直接操作DOM元素等標(biāo)準(zhǔn)上的限制，導(dǎo)致我們可預(yù)見，現(xiàn)階段即使用Wasm重寫React的Fiber算法，框架在實際處理UI新時，可能也不會有著顯著的性能提升。因此，對于React隊來說，投入產(chǎn)出比是同React類似，Vue.js的社區(qū)內(nèi)也曾有過類似的討論，如下圖所但與React所不同的是，Vue.js與Wasm的“結(jié)合”方式根據(jù)框架的具體實現(xiàn)細(xì)節(jié)，可能有著的可能。不過一個不可否認(rèn)的事實是，Wasm仍然處在快速的發(fā)展階段。同樣的，基于Wasm構(gòu)建的各類應(yīng)用也同樣處在不穩(wěn)定的狀態(tài)中（比如，上述帖子中提到的Walt實際上于2019年便不再繼續(xù)更新）。而目前，正是一個“百花齊放”的時代。最后我們要來講講Ember.jsEmber.js的用戶雖然沒有ReactVue.js那么多，但它卻是第一個宣布嘗試與Wasm進(jìn)行“深度整合”的Web前端框架，Ember.js在了名為GlimmerVM的渲染引擎。與React通過使用Reconciler組件計算VDOM差異來更新UI的策略有所不同，GlimmerVM過將模板的構(gòu)建過程分解為獨立的虛擬機(jī)OpCode作，來對UI來自于EmberConf在EmberConf2018年的技術(shù)會議上，來自Ember.js團(tuán)隊的YehudaKatz向我們介紹了GlimmerVM與Wasm的整合情況。你通過上圖可以看到，除了OpCode模塊相關(guān)的部分邏輯仍然在使用JavaScript構(gòu)建以外，整個VM的大部分功能都已經(jīng)完成到Wasm的遷移。并且該Wasm版本的GlimmerVM也已經(jīng)通過了所有的測試集Case。但計劃趕不上變化，回到2020，我們再來看GlimmerVM，關(guān)于它與Wasm的消息貌似已經(jīng)沒有了太多。 Ember.js中我們可以看到，Ember.js在與Wasm進(jìn)行整合的過程中，其實遇到了很多問題，比如不支持GC導(dǎo)致Wasm線性內(nèi)存中使用的資源無法被及時清理。GlimmerVM還在繼續(xù)為將來能夠完全移植到Wasm做著準(zhǔn)備。但無論如何，這都不失為一次非常有意義好了，講到這，今天的內(nèi)容也就基本結(jié)束了。最后我來給你總結(jié)一在這節(jié)課里呢，我主要給你介紹了Wasm與Web前端框架的一些“故事”“Wasm否影響，或者說會如何影響現(xiàn)有的、基于JavaScript建的現(xiàn)代Web框架呢？”這是一個被很多Web前端工程師所提及的問題。在這節(jié)課中，我嘗試按照Wasm與Web前端框架的“整合程度”不同，將兩者能夠相互結(jié)合的可能方式大致分為在第案中，我們嘗試將整個Web框架的全部功能，使用同樣的Wasm版本進(jìn)行代替，而應(yīng)用代碼仍然使用JavaScript進(jìn)行編寫。但由于現(xiàn)階段WasmMVP標(biāo)準(zhǔn)的限制，在這種方案下，我們不得不借助JavaScriptGlueCode的幫助來實現(xiàn)框架的部分功能。而當(dāng)GlueCoe的代碼越來越多時，JaaSipt函數(shù)與Wasm導(dǎo)出函數(shù)之間的相用會更加頻繁，在某些情況下，這可能會產(chǎn)生嚴(yán)重的性能損耗。因此結(jié)合現(xiàn)實情況來看，整個方案的可用性并不高。在第二種方案中，我們嘗試僅使用Wasm來重寫框架的部分，比如ReactFiber架構(gòu)中的Reconciler組件。這類組件通常并不含有過多需要與WebAPI打交道的地方，相對純粹的計算邏輯更易于Wasm能力的發(fā)揮。同時這種方案也是現(xiàn)階段大多數(shù)Web框架正在嘗試的，與Wasm進(jìn)行交互的“常規(guī)”方式。在第三種方案中，我們僅使用Wasm來作為Web框架的輔助，以優(yōu)化Web應(yīng)用的某一方面功能。在這種方案中，框架本身的代碼結(jié)構(gòu)不會有任何的變化。實際上，這種方案也是傳統(tǒng)Web應(yīng)用在利用Wasm時的最常規(guī)方式。在最后一個方案中，我們介紹了一種更為激進(jìn)的方式。在這種方案下，包括Web