尤大大從下面的三個前端領(lǐng)域的不同層次來展開了介紹：

• 開發(fā)范式&底層框架（注：大家比較熟悉的Vue、React這些框架層面）
• 工具鏈（注：像webpack這樣的構(gòu)建工具）
• 上層框架（注：例如Next.js、Nuxt.js）

正式分享之前，尤大大提出聲明：“本分享只代表講著個人觀點，因為自己是框架和構(gòu)建工具的作者，肯定會包含利益相關(guān)和個人的偏見，但是分享中會盡可能做客觀的看法，大家多多多包涵”，下面就讓我們飽享這頓“美味”吧！

下面的內(nèi)容是根據(jù)尤大大的分享進(jìn)行了一定的抽離和少許的個人總結(jié)，如果內(nèi)容出現(xiàn)歧義可以在評論區(qū)留言！

開發(fā)范式&底層框架方面趨勢

過去幾年中影響最大的開發(fā)范式層面的變化肯定就是我們的 React Hooks 隨著他的推出可以說是啟發(fā)了很多組件邏輯表達(dá)和邏輯復(fù)用的新范式，在 React 生態(tài)中徹底取代了 Class Components ，包括現(xiàn)在其實很少能夠在 React 中看到 Class Components 了，

不僅如此，其實在其他的框架中 React Hooks 也產(chǎn)生了很大的影響，比如說我們 Vue 推出的 Vue Composition API 組合式API，還包括受到 React Hooks 的啟發(fā)的 Svelte3 ，更有 SolidJS 他是語法上相似于 React Hooks 實現(xiàn)上更相似于 Vue Composition API 。

隨著 React Hooks 的推廣和開發(fā)者對其的廣泛使用，他開發(fā)中的一些體驗問題也逐漸被正視，這里不可回避的一些體驗問題的根本原因有以下幾點：

• Hooks 執(zhí)行原理和原生JS的心智模型的差異：因為React Hooks 是通過把組件的代碼每一次更新都進(jìn)行重復(fù)調(diào)用來模擬一些行為，從而導(dǎo)致反直覺的一些限制；
• 不可以條件式的調(diào)用React force ；
• Stale Closure 的心智負(fù)擔(dān)：如果你不傳正確的依賴數(shù)組，那么就會產(chǎn)生過期閉包；
• 必須手動聲明use Effect 依賴；
• 如何‘正確’使用use Effect 是個復(fù)雜的問題；
• 需要useMemo/useCallback 等手動優(yōu)化，否則的話就會不知不覺的導(dǎo)致一些性能問題；

尤大大表示作為競爭框架的作者，對 React Hooks 框架的看法可能相對更直接一些，但這些也并非尤大大一個人的看法，而是近年來 React 社區(qū)和 React 團(tuán)隊也已經(jīng)意識到的問題，當(dāng)然 React 團(tuán)隊針對這些問題也在做改善的努力，據(jù)代表性的改善從下三個方面：

基于依賴追蹤范式

在上面的這些改進(jìn)之前，其實很多 React 的社區(qū)成員也包括一些本身就不適用 React 的用戶來說，雖然 React Hooks 產(chǎn)生了重大的影響但是大家也意識到了他的一些問題，反而是一些跟 React Hooks 相似的一些邏輯組合能力，另一方面基于依賴追蹤的范式開始重新得到了重視；比如在 React 內(nèi)部的 Recoil ，當(dāng)然在社區(qū)之外就有更多了比如：

我們可以看一下就基于依賴追蹤的范式而言上面三個方案的代碼：

SolidJS

//狀態(tài)
const [count,setCount] = createSignal(0)
//副作用
createEffect(() => console.log(`${count()`}
//狀態(tài)更新
setCount(count() + 1)

能夠看出其實 SolidJS 和 React Hooks 非常相似

• 副作用中的 createEffect 跟 React 中的 use Effect 其實是類似的，但是 createEffect 并不需要去聲明依賴，在調(diào)用 count 函數(shù)的時候其實幫你收集了依賴；
• 狀態(tài)更新的時候我們也并不需要用到 useCallback 這種額外的方式去創(chuàng)造函數(shù)來去傳遞給我們的事件偵聽器；這些都是非常符合直覺的；

Vue Composition API

//狀態(tài)
const count = ref(0)
//副作用
watchEffect(() => console.log(count.value))
//狀態(tài)更新
count.value++

其實 Vue 中使用的 Composition API 跟 SolidJS 本質(zhì)上的內(nèi)部實現(xiàn)幾乎是一樣的，只不過 SolidJS 看起來更像是 React ，而 Vue 是通過一個 ref 對象，對象上的 value 機(jī)可以讀也可以寫，在讀和寫之中就會自動的追蹤和更新依賴。

Ember Starbeam

//狀態(tài)
const count = Cell(0)
//副作用
DEBUG_RENDERER.render({render: () => console.log(count.current)})
//狀態(tài)更新
count.set(prev => prev + 1)

Ember Starbeam 中的這個 Cell 其實就和 Vue 中的 ref api 幾乎是一樣的，暴露出 count 為當(dāng)前的值和 set 方法來進(jìn)行狀態(tài)的更新

基于依賴追蹤范式—共同點

上面提到的三種基于依賴追蹤的范式他們的共同點有什么呢？

同時以依賴追蹤為一等功名概念的框架中，本身組件的設(shè)計肯定也是跟依賴追蹤有緊密的結(jié)合，所以組件的更新渲染也會有自動的依賴追蹤，也就是說組件的更新會更精確，而不再依賴于一個狀態(tài)從父組件到子組件一層層傳遞下去，而是每一個即使是深層嵌套的組件也可以自發(fā)的更新，整體上的性能會更好。

在 react 生態(tài)中的 Recoil 這樣的方案，雖然也提供了依賴自動的依賴追蹤和一定程度的逐漸的更新優(yōu)化，但是因為他們?nèi)匀皇切枰?nbsp;React Hooks 的這個大的體系中使用的，所以在很多其他的方面依然會受制于 hooks 的問題，那么 Hooks 本身在這些方案之外，還是會存在過期閉包等等 user fact 這些問題。

React Hooks 確實是啟發(fā)了一個新范式的時代，但是慢慢的我們也發(fā)現(xiàn)他自己自身存在的一些問題，當(dāng)然 React 團(tuán)隊正在試圖解決這些問題，同時在 React 體系之外，開始有一些其他的具有同等的邏輯組合能力，但同時避免了 React Hooks 這些問題的這些方案存在，也漸漸的收到了前端社區(qū)的重視。

基于編譯的響應(yīng)式系統(tǒng)

不過即使是基于依賴追蹤的方案，我們也可以進(jìn)行一些基于編譯時的這個優(yōu)化，那這里首當(dāng)其沖的就是 Svelte3

Svelte

Svelte3 從一開始就是一個編譯時優(yōu)化方案，上面就是 Svelte 組件中的一個使用狀態(tài)的代碼，我們看到他跟他的狀態(tài)就是這個 javaScript 的這個 let 這樣聲明一個變量，就是一個響應(yīng)式的狀態(tài)，那么你要更新這個狀態(tài)就直接去操作這個變量就可以，

副作用是用一個神奇的編譯式的魔法，也就是這個 $ ，這個 $ 的一個label，這其實是 javaScript 的一個label語法來聲明， $ 之后的這個語句會自動去追蹤count這個變量的變化，當(dāng)count變化的時候，這個語句就會自動重新執(zhí)行，那么我們可以看到這個跟我們之前的這個幾個代碼范例，他所達(dá)成的目標(biāo)其實是一致的，只是他使用編譯的手段使代碼變的更加簡潔，但也正是因為簡潔所以存在下面的限制：

Vue Reactivity Transform

也正是受到上方的限制的啟發(fā)，Vue 在3.2的時候引入了一個實現(xiàn)性的功能 Vue Reactivity Transform 響應(yīng)式轉(zhuǎn)換 ，下面就是 Vue 轉(zhuǎn)化后的一段代碼：

還是一個簡單的變量聲明，但是我們用一個 $ref 這樣的一個函數(shù)，這個函數(shù)其實是一個編譯時的一個宏的概念，這個函數(shù)并不是真實存在的，只是給編譯一個提示，那編譯器通過編譯之后就會把它轉(zhuǎn)化成我們之前看到的基于真實的 ref 的代碼。

但是在使用時候，體驗就變成了只是聲明一個函數(shù)，然后使用這個變量和更新這個變量就跟使用一個普通 javaScript 變量沒有區(qū)別。同時這個語法因為在聲明的時候會顯式的聲明，說哪個變量是響應(yīng)聲，哪個變量不是響應(yīng)式。

所以這個語法可以在嵌套的函數(shù)中使用，也可以在 TS/JS 文件中使用，他并不限制于 Vue 文件，所以這是一個更加樸實的編譯響應(yīng)式模型。

Solid -labels

在 Solid 的生態(tài)中，其實也受啟發(fā)于 Vue Reactivity Transform ，他的社區(qū)用戶做的一個 Solid-label，也是基于 Solid 的響應(yīng)式方案，然后再做一層編譯式的優(yōu)化，那么可以看到跟 Reactivity Transform 能夠達(dá)成的效果是非常相似的。

那最終的目的就是讓大家可以用更簡潔的代碼去表達(dá)組件邏輯，同時又不放棄這個邏輯組合，像 React Hooks 那樣進(jìn)行自由的邏輯組合的這些能力啊。所以說這也是一個很有意思的探索方向。

統(tǒng)一模型的優(yōu)勢和代價

優(yōu)勢： 和??Svelte???相比，Vue的 ??Reactivity Transform??? 和 ??Solid \-labels??? 都屬于統(tǒng)一模型，也就是他不受限于組件上下文，它可以在組建內(nèi)使用，也可以在組建外使用，優(yōu)勢就是有利于長期的重構(gòu)和復(fù)用，因為很多時候我們的大型項目中的邏輯復(fù)用都是在我們一個組件寫著寫著發(fā)現(xiàn)這個組件變得很臃腫，很大的時候我們才開始考慮要把邏輯開始重新組織抽取復(fù)用，那么由于 ??Svelte?? 的語法只能在組件內(nèi)使用，就使得把邏輯挪到組件外成為一個代價相當(dāng)大的一個行為，并不是一個簡單把文把這個邏輯拷貝復(fù)制出去，而是需要進(jìn)行一次徹底的重構(gòu)，

因為組件外用的是完全一套不同的系統(tǒng)，但是像用 ??Reactivity Transform??? 和 ??Solid \-labels?? 這樣的方案呢，我們就可以把組件內(nèi)的這些邏輯原封不動的直接拷貝到組件外，然后把它包在一個函數(shù)里面，抽取就完成了，那么這樣重構(gòu)時的這個代價就非常小，也就更鼓勵團(tuán)隊的這樣的優(yōu)化，對于長期的維護(hù)性更有幫助。

代價： 因為我們需要顯示的去聲明響應(yīng)式的變量，所以它會有一定程度的底層實現(xiàn)的抽象泄露，也就是說，用戶其實是需要先了解底層的響應(yīng)式模型的實現(xiàn)，然后才能更好地理解這個語法糖是如何運作的，而不像 ??Svelte?? 組建中的這個語法，即使你完全不了解他底層如何運作的也可以，幾乎可以零成本的上手，這就是一個長期的可維護(hù)性和一個初期的上手成本之間的一個平衡和取舍。

基于編譯的運行是優(yōu)化

講完了狀態(tài)管理，我們在還可以聊一聊關(guān)于基于編譯的運行時優(yōu)化，編譯的運行時優(yōu)化又是三個主要的代表，如上圖所示，那首先我們可以看一下不同的這個策略：

Svelte 的這個代碼生成策略相對更更繁瑣一些，而 Solid 是基于先生成一個基本的HTML字符串，然后在里面找到對應(yīng)的 DOM 節(jié)點進(jìn)行綁定，而 Svelte 是通過生成一這個命令式的一個一個節(jié)點，然后把節(jié)點拼接的這些 javaScript 代碼，但這個策略就導(dǎo)致掉同等的這個組件源碼之下 Svelte 的每個組件的編譯輸出會更臃腫，所以雖然大家感覺 Svelte 是以輕量出名的，

但其實我們會發(fā)現(xiàn)在相對大型的項目中，在項目中組建超過15個之后，Svelte 的整體的打包體積優(yōu)勢就已經(jīng)幾乎不存在了，那么當(dāng)組建超過50個，甚至是達(dá)到100個的時候，所有的體積會越來越越來越臃腫。

而相對于而言，我們可以看到 Vue 和 Solid 的編譯這個輸出啊，整體的這個曲線就平緩很多，所以其實在越大型的項目中。反而是 Svelte 的體積優(yōu)勢反而是一個劣勢，據(jù)我所知，Svelte 團(tuán)隊也有在想要優(yōu)化這一方面的，可能會在下一個大版本中才能實現(xiàn)，那么我們也會拭目以待。

同時尤大大提出 Solid 的編譯性能確實是非常的猛，其實在我們的 Vue 引入了很多編譯時的優(yōu)化以后我們的性能已經(jīng)比 Svelte 好了，但是離 Solid 還是有一定的距離。

Vue Vapor Mode（input）

就上面提及到的編譯時性能優(yōu)化，其實我們的 Vue 在早期的時候也做了這方面的探索，如還在試驗中的一個項目 Vue Vapor Mode 。

那同樣的這個只有單文件組件輸入，我們現(xiàn)在是通過把模板編譯成虛擬DOM 的一個渲染函數(shù)來進(jìn)行運行時的實現(xiàn)。但是因為模板是一個編譯源，所以我們也可以選擇在另一個模式下把它編譯成不同的輸出，也就是一個更類似于 Svelte 輸出。

這里這個輸出的代碼只是一個示例代碼。并不一定是最終的代碼，也不是你需要書寫的代碼，它完全是一個編譯器的輸出啊，它的整體的思路就是一次性生成這個模板的靜態(tài)結(jié)構(gòu)、靜態(tài)節(jié)點，然后再去生成命令式的，找到動態(tài)節(jié)點，并對把它跟狀態(tài)進(jìn)行響應(yīng)式的綁定的這樣一些代碼，這個策略本質(zhì)上就是 ??Solid?? 所采用的策略，

那么其實呢，這個策略可以被所有的模板引擎所使用，我們也在探索某個版本的 ??Vue?? 當(dāng)中會引入一個可選的這樣的一個模式，把模板編譯成這樣的，性能更優(yōu)的，運行時的這個體積也更小的一個模式，當(dāng)然這不會是一個破壞性更新，因為我們的目標(biāo)是可以讓你漸進(jìn)式的去使用這個功能。

工具鏈

原生語言在前端工具鏈中的使用

關(guān)于原生語言在前端工具鏈中的使用尤大大提出下面幾個見解：

工具鏈的抽象層次

最早的打包工具，包括 brow/webpack/rollup 他們都是專注于打包的，他們的抽象層次相對低，當(dāng)你想要用這些工具去做一個真正的應(yīng)用的時候，你需要使用大量第三方插件，以及大量的配置來達(dá)到一個滿足你自己要求的最終的形態(tài)。

那么在這個基礎(chǔ)上就產(chǎn)生了像 Parcel/Vue-cli/CRA ，這樣的一些所謂的腳手架，更高抽象層次的這些工具，這些工具的特點是他們的抽象層的高，也就說他們專注于應(yīng)用，專注于解決一個完整的應(yīng)用方案呢，它的相對而言的缺點就是它是一個比較復(fù)雜、比較龐大的一個黑盒兒。

當(dāng)你需要去進(jìn)行自定義的定制的時候，你就會不可避免的遇到一些問題，比如說你跟他默認(rèn)的功能產(chǎn)生一些意見上的沖突的時候，你就會比較痛苦。

那么我們現(xiàn)在做的這個新項目 Vite 其實可能有一些同學(xué)已經(jīng)在用了，其實我們是在思考過這個抽象層次的問題之后才決定的他要走一個怎么樣的路線，也就是說 Vite 的 CLI 它是專注于應(yīng)用層次啊，它的抽象層次高，它有很多的開箱記，就是事先幫你寄配置好的功能，那么大部分的情況下，你開箱即用就可以達(dá)到跟 Parcel/Vue-cli/CRA 幾乎同等的這些功能啊，但是我們的API層面啊，這個可能用到的同學(xué)會少一些，

但是它的API層面其實是專注于支持上層框架，我們這個抽象層次會更低一點，我們只解決一些所有的夠 meta framework 都必須要解決的問題，但是對于上層框架，你用什么，我們并不會做過多的限制，反而是要做的更盡可能的靈活，能夠支持任何上層框架的用例，所以這也是為什么 Vite 現(xiàn)在幾乎成為了下一代的meta framework 共同的一個基底層選擇。

基于 Vite 的上層框架

我們看到上面這么多的上層框架都在基于 Vite 說明我們 Vite 走的路線還是相對成功的。

上層框架 Meta Frameworks

JS全棧的意義是什么 ？

如果我們講到這個 Meta Frameworks，也就是最典型的例子，也就是NextJS 、NuxtJS、以及現(xiàn)在React社區(qū)中的新秀 Remix 等等，那么當(dāng)我們思考這樣類型的JS全棧的時候，我們做全棧的意義是什么？

那么相信在國內(nèi)很多大企業(yè)的朋友都知道，因為我們可以用同一個語言去做前后的連接，我們可以做一些純前端和純后端都各自做不到的事情，或者說之前需要很復(fù)雜的聯(lián)調(diào)才能達(dá)成的一些事情，那么JS全棧可以更好的去完成一個語言讓我們可以把前后打通。那么我們能夠打通什么呢？

數(shù)據(jù)的前后端打通

類型的前后端打通

JS全棧的代價

一些新的全棧框架，現(xiàn)在在試圖去改善的一些問題首先。我們現(xiàn)有的這些前端框架，比如說像主流的像 React、Vue 我們在做了服務(wù)端渲染之后，還需要在前端要進(jìn)行一次所謂的注水，也就是 Hydrate 在追尋的過程中，我們要確保在客戶端和前端有同樣的數(shù)據(jù)，所以其實雖然我們的數(shù)據(jù)已經(jīng)用于渲染HTML，

這些數(shù)據(jù)理論上在HTML里面已經(jīng)都用過了，但是我們還得再把這個數(shù)據(jù)再發(fā)送一次，一起發(fā)送到前端，讓前端去進(jìn)行 Hydrate 這樣一個過程。因為沒有這個數(shù)據(jù)，我們在前端就沒有辦法保證 Hydrate 的正確性啊。

在客戶端，有些組件它可能在客戶端是不，需要交互的是靜態(tài)的，但是他在服務(wù)端用到了動態(tài)的這個數(shù)據(jù)，但這個組件依然會被發(fā)到服務(wù)端，它依然會可能產(chǎn)生這個javascript 運行時的代價啊，以及緩慢的這個 Hydrate 會影響頁面的交互指標(biāo)，也就是 time to interactive。

有一些比較復(fù)雜的龐大的項目，他可能這個注水的過程會把頁面卡頓，以至于雖然能看到頁面，但是沒法交互，要等個一秒鐘才能交互等等，會產(chǎn)生這樣的問題。

社區(qū)探索的方向

社區(qū)現(xiàn)在新一代的這些全棧框架都在試圖解決這些問題啊，比如說像 React 提出了 server only components 其實從這個定義上，我們就發(fā)現(xiàn)他是沒有一個全棧框架，圍繞一個全棧框架去做，其實用戶是沒有辦法簡單地使用的一個概念，所以 React server only components 其實是一個必須要全站才能做的概念，Next 當(dāng)然也會去做，然后，其實 Nuxt 最近也開了一個 server only components 的一個提案，所以說這個已經(jīng)就是說 server only components 其實不僅僅是一個 React 獨有的概念，在很多其他的框架中，我們可能慢慢都會出現(xiàn)類似的這個類似的東西。

還有一個方向就是減少注水，hydration 的這個成本，那么也就是局部的注水，或者也叫 island architecture 就像大海中一個小島，只有這些小島去對他進(jìn)行注水，讓他交可交互啊。那么比較代表性的就是 astro、isles 和生態(tài)里面的 fresh 這些框架。

然后呢，還有一個探索方向，就是所謂的 fine-grained+resumabl hydration，就是細(xì)粒度懶加載，這個數(shù)據(jù)其實是Qwik這個框架所發(fā)明的，Quick 的作者就是 Misko Hevery，也就是 Angular 的原作者，離開Google之后，現(xiàn)在新開發(fā)的這個框架啊，那么 Qwik 它主打的就是說它的特點就是不需要再把數(shù)據(jù)重新發(fā)送一遍。

他是直接在生成的渲染的html里面嵌入所需的數(shù)據(jù)從而使得客戶端的js可以直接在html里面獲得所要的數(shù)據(jù)，甚至是可以跳過一些需要執(zhí)行的js步驟，直接跳到一個已經(jīng)完成的狀態(tài)上面去，這就是所謂的resumable ，也是一個比較值得關(guān)注的一個方向。

以及我們的 Vue 生態(tài)里面生態(tài)里面有一個我們的 VitePress，我們其實探索的是一個在我們頁面的核心內(nèi)容：其實是靜態(tài)的MD文件的前提下如何做高效率的 hydration 那么我們做的是所謂的 hydration 就是整個的外部的這個一個框架內(nèi)容外包著的這一層ui是動態(tài)的，然后呢在內(nèi)部靜態(tài)的里繼續(xù)進(jìn)行局部的注水，然后這樣的話，我們依然可以獲得一個單頁應(yīng)用的體驗，但又獲得很好的客戶端注水的性能。