建站
咨詢
售后
建站咨詢
新聞中心
尤大大從下面的三個(gè)前端領(lǐng)域的不同層次來展開了介紹：
創(chuàng)新互聯(lián)堅(jiān)持“要么做到，要么別承諾”的工作理念，服務(wù)領(lǐng)域包括：網(wǎng)站制作、網(wǎng)站設(shè)計(jì)、企業(yè)官網(wǎng)、英文網(wǎng)站、手機(jī)端網(wǎng)站、網(wǎng)站推廣等服務(wù)，滿足客戶于互聯(lián)網(wǎng)時(shí)代的新化網(wǎng)站設(shè)計(jì)、移動(dòng)媒體設(shè)計(jì)的需求，幫助企業(yè)找到有效的互聯(lián)網(wǎng)解決方案。努力成為您成熟可靠的網(wǎng)絡(luò)建設(shè)合作伙伴！
- 開發(fā)范式&底層框架（注：大家比較熟悉的Vue、React這些框架層面）
- 工具鏈（注：像webpack這樣的構(gòu)建工具）
- 上層框架（注：例如Next.js、Nuxt.js）
正式分享之前，尤大大提出聲明：“本分享只代表講著個(gè)人觀點(diǎn)，因?yàn)樽约菏强蚣芎蜆?gòu)建工具的作者，肯定會(huì)包含利益相關(guān)和個(gè)人的偏見，但是分享中會(huì)盡可能做客觀的看法，大家多多多包涵”，下面就讓我們飽享這頓“美味”吧！
下面的內(nèi)容是根據(jù)尤大大的分享進(jìn)行了一定的抽離和少許的個(gè)人總結(jié)，如果內(nèi)容出現(xiàn)歧義可以在評(píng)論區(qū)留言！
開發(fā)范式&底層框架方面趨勢(shì)
過去幾年中影響最大的開發(fā)范式層面的變化肯定就是我們的 React Hooks 隨著他的推出可以說是啟發(fā)了很多組件邏輯表達(dá)和邏輯復(fù)用的新范式，在 React 生態(tài)中徹底取代了 Class Components ，包括現(xiàn)在其實(shí)很少能夠在 React 中看到 Class Components 了，
不僅如此，其實(shí)在其他的框架中 React Hooks 也產(chǎn)生了很大的影響，比如說我們 Vue 推出的 Vue Composition API 組合式API，還包括受到 React Hooks 的啟發(fā)的 Svelte3 ，更有 SolidJS 他是語法上相似于 React Hooks 實(shí)現(xiàn)上更相似于 Vue Composition API 。
隨著 React Hooks 的推廣和開發(fā)者對(duì)其的廣泛使用，他開發(fā)中的一些體驗(yàn)問題也逐漸被正視，這里不可回避的一些體驗(yàn)問題的根本原因有以下幾點(diǎn)：
- Hooks 執(zhí)行原理和原生JS的心智模型的差異：因?yàn)镽eact Hooks 是通過把組件的代碼每一次更新都進(jìn)行重復(fù)調(diào)用來模擬一些行為，從而導(dǎo)致反直覺的一些限制；
- 不可以條件式的調(diào)用React force ；
- Stale Closure 的心智負(fù)擔(dān)：如果你不傳正確的依賴數(shù)組，那么就會(huì)產(chǎn)生過期閉包；
- 必須手動(dòng)聲明use Effect 依賴；
- 如何‘正確’使用use Effect 是個(gè)復(fù)雜的問題；
- 需要useMemo/useCallback 等手動(dòng)優(yōu)化，否則的話就會(huì)不知不覺的導(dǎo)致一些性能問題；
尤大大表示作為競(jìng)爭(zhēng)框架的作者，對(duì) React Hooks 框架的看法可能相對(duì)更直接一些，但這些也并非尤大大一個(gè)人的看法，而是近年來 React 社區(qū)和 React 團(tuán)隊(duì)也已經(jīng)意識(shí)到的問題，當(dāng)然 React 團(tuán)隊(duì)針對(duì)這些問題也在做改善的努力，據(jù)代表性的改善從下三個(gè)方面：
基于依賴追蹤范式
在上面的這些改進(jìn)之前，其實(shí)很多 React 的社區(qū)成員也包括一些本身就不適用 React 的用戶來說，雖然 React Hooks 產(chǎn)生了重大的影響但是大家也意識(shí)到了他的一些問題，反而是一些跟 React Hooks 相似的一些邏輯組合能力，另一方面基于依賴追蹤的范式開始重新得到了重視；比如在 React 內(nèi)部的 Recoil ，當(dāng)然在社區(qū)之外就有更多了比如：
我們可以看一下就基于依賴追蹤的范式而言上面三個(gè)方案的代碼：
SolidJS
//狀態(tài)
const [count,setCount] = createSignal(0)
//副作用
createEffect(() => console.log(`${count()`}
//狀態(tài)更新
setCount(count() + 1)
能夠看出其實(shí) SolidJS 和 React Hooks 非常相似
- 副作用中的 createEffect 跟 React 中的 use Effect 其實(shí)是類似的，但是 createEffect 并不需要去聲明依賴，在調(diào)用 count 函數(shù)的時(shí)候其實(shí)幫你收集了依賴；
- 狀態(tài)更新的時(shí)候我們也并不需要用到 useCallback 這種額外的方式去創(chuàng)造函數(shù)來去傳遞給我們的事件偵聽器；這些都是非常符合直覺的；
Vue Composition API
//狀態(tài)
const count = ref(0)
//副作用
watchEffect(() => console.log(count.value))
//狀態(tài)更新
count.value++
其實(shí) Vue 中使用的 Composition API 跟 SolidJS 本質(zhì)上的內(nèi)部實(shí)現(xiàn)幾乎是一樣的，只不過 SolidJS 看起來更像是 React ，而 Vue 是通過一個(gè) ref 對(duì)象，對(duì)象上的 value 機(jī)可以讀也可以寫，在讀和寫之中就會(huì)自動(dòng)的追蹤和更新依賴。
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 中的這個(gè) Cell 其實(shí)就和 Vue 中的 ref api 幾乎是一樣的，暴露出 count 為當(dāng)前的值和 set 方法來進(jìn)行狀態(tài)的更新
基于依賴追蹤范式—共同點(diǎn)
上面提到的三種基于依賴追蹤的范式他們的共同點(diǎn)有什么呢？
同時(shí)以依賴追蹤為一等功名概念的框架中，本身組件的設(shè)計(jì)肯定也是跟依賴追蹤有緊密的結(jié)合，所以組件的更新渲染也會(huì)有自動(dòng)的依賴追蹤，也就是說組件的更新會(huì)更精確，而不再依賴于一個(gè)狀態(tài)從父組件到子組件一層層傳遞下去，而是每一個(gè)即使是深層嵌套的組件也可以自發(fā)的更新，整體上的性能會(huì)更好。
在 react 生態(tài)中的 Recoil 這樣的方案，雖然也提供了依賴自動(dòng)的依賴追蹤和一定程度的逐漸的更新優(yōu)化，但是因?yàn)樗麄內(nèi)匀皇切枰?nbsp;React Hooks 的這個(gè)大的體系中使用的，所以在很多其他的方面依然會(huì)受制于 hooks 的問題，那么 Hooks 本身在這些方案之外，還是會(huì)存在過期閉包等等 user fact 這些問題。
React Hooks 確實(shí)是啟發(fā)了一個(gè)新范式的時(shí)代，但是慢慢的我們也發(fā)現(xiàn)他自己自身存在的一些問題，當(dāng)然 React 團(tuán)隊(duì)正在試圖解決這些問題，同時(shí)在 React 體系之外，開始有一些其他的具有同等的邏輯組合能力，但同時(shí)避免了 React Hooks 這些問題的這些方案存在，也漸漸的收到了前端社區(qū)的重視。
基于編譯的響應(yīng)式系統(tǒng)
不過即使是基于依賴追蹤的方案，我們也可以進(jìn)行一些基于編譯時(shí)的這個(gè)優(yōu)化，那這里首當(dāng)其沖的就是 Svelte3
Svelte
Svelte3 從一開始就是一個(gè)編譯時(shí)優(yōu)化方案，上面就是 Svelte 組件中的一個(gè)使用狀態(tài)的代碼，我們看到他跟他的狀態(tài)就是這個(gè) javaScript 的這個(gè) let 這樣聲明一個(gè)變量，就是一個(gè)響應(yīng)式的狀態(tài)，那么你要更新這個(gè)狀態(tài)就直接去操作這個(gè)變量就可以，
副作用是用一個(gè)神奇的編譯式的魔法，也就是這個(gè) $ ，這個(gè) $ 的一個(gè)label，這其實(shí)是 javaScript 的一個(gè)label語法來聲明， $ 之后的這個(gè)語句會(huì)自動(dòng)去追蹤count這個(gè)變量的變化，當(dāng)count變化的時(shí)候，這個(gè)語句就會(huì)自動(dòng)重新執(zhí)行，那么我們可以看到這個(gè)跟我們之前的這個(gè)幾個(gè)代碼范例，他所達(dá)成的目標(biāo)其實(shí)是一致的，只是他使用編譯的手段使代碼變的更加簡(jiǎn)潔，但也正是因?yàn)楹?jiǎn)潔所以存在下面的限制：
Vue Reactivity Transform
也正是受到上方的限制的啟發(fā)，Vue 在3.2的時(shí)候引入了一個(gè)實(shí)現(xiàn)性的功能 Vue Reactivity Transform 響應(yīng)式轉(zhuǎn)換 ，下面就是 Vue 轉(zhuǎn)化后的一段代碼：
還是一個(gè)簡(jiǎn)單的變量聲明，但是我們用一個(gè) $ref 這樣的一個(gè)函數(shù)，這個(gè)函數(shù)其實(shí)是一個(gè)編譯時(shí)的一個(gè)宏的概念，這個(gè)函數(shù)并不是真實(shí)存在的，只是給編譯一個(gè)提示，那編譯器通過編譯之后就會(huì)把它轉(zhuǎn)化成我們之前看到的基于真實(shí)的 ref 的代碼。
但是在使用時(shí)候，體驗(yàn)就變成了只是聲明一個(gè)函數(shù)，然后使用這個(gè)變量和更新這個(gè)變量就跟使用一個(gè)普通 javaScript 變量沒有區(qū)別。同時(shí)這個(gè)語法因?yàn)樵诼暶鞯臅r(shí)候會(huì)顯式的聲明，說哪個(gè)變量是響應(yīng)聲，哪個(gè)變量不是響應(yīng)式。
所以這個(gè)語法可以在嵌套的函數(shù)中使用，也可以在 TS/JS 文件中使用，他并不限制于 Vue 文件，所以這是一個(gè)更加樸實(shí)的編譯響應(yīng)式模型。
Solid -labels
在 Solid 的生態(tài)中，其實(shí)也受啟發(fā)于 Vue Reactivity Transform ，他的社區(qū)用戶做的一個(gè) Solid-label，也是基于 Solid 的響應(yīng)式方案，然后再做一層編譯式的優(yōu)化，那么可以看到跟 Reactivity Transform 能夠達(dá)成的效果是非常相似的。
那最終的目的就是讓大家可以用更簡(jiǎn)潔的代碼去表達(dá)組件邏輯，同時(shí)又不放棄這個(gè)邏輯組合，像 React Hooks 那樣進(jìn)行自由的邏輯組合的這些能力啊。所以說這也是一個(gè)很有意思的探索方向。
統(tǒng)一模型的優(yōu)勢(shì)和代價(jià)
優(yōu)勢(shì)： 和??Svelte???相比，Vue的 ??Reactivity Transform??? 和 ??Solid \-labels??? 都屬于統(tǒng)一模型，也就是他不受限于組件上下文，它可以在組建內(nèi)使用，也可以在組建外使用，優(yōu)勢(shì)就是有利于長(zhǎng)期的重構(gòu)和復(fù)用，因?yàn)楹芏鄷r(shí)候我們的大型項(xiàng)目中的邏輯復(fù)用都是在我們一個(gè)組件寫著寫著發(fā)現(xiàn)這個(gè)組件變得很臃腫，很大的時(shí)候我們才開始考慮要把邏輯開始重新組織抽取復(fù)用，那么由于 ??Svelte?? 的語法只能在組件內(nèi)使用，就使得把邏輯挪到組件外成為一個(gè)代價(jià)相當(dāng)大的一個(gè)行為，并不是一個(gè)簡(jiǎn)單把文把這個(gè)邏輯拷貝復(fù)制出去，而是需要進(jìn)行一次徹底的重構(gòu)，
因?yàn)榻M件外用的是完全一套不同的系統(tǒng)，但是像用 ??Reactivity Transform??? 和 ??Solid \-labels?? 這樣的方案呢，我們就可以把組件內(nèi)的這些邏輯原封不動(dòng)的直接拷貝到組件外，然后把它包在一個(gè)函數(shù)里面，抽取就完成了，那么這樣重構(gòu)時(shí)的這個(gè)代價(jià)就非常小，也就更鼓勵(lì)團(tuán)隊(duì)的這樣的優(yōu)化，對(duì)于長(zhǎng)期的維護(hù)性更有幫助。
代價(jià)： 因?yàn)槲覀冃枰@示的去聲明響應(yīng)式的變量，所以它會(huì)有一定程度的底層實(shí)現(xiàn)的抽象泄露，也就是說，用戶其實(shí)是需要先了解底層的響應(yīng)式模型的實(shí)現(xiàn)，然后才能更好地理解這個(gè)語法糖是如何運(yùn)作的，而不像 ??Svelte?? 組建中的這個(gè)語法，即使你完全不了解他底層如何運(yùn)作的也可以，幾乎可以零成本的上手，這就是一個(gè)長(zhǎng)期的可維護(hù)性和一個(gè)初期的上手成本之間的一個(gè)平衡和取舍。
基于編譯的運(yùn)行是優(yōu)化
講完了狀態(tài)管理，我們?cè)谶€可以聊一聊關(guān)于基于編譯的運(yùn)行時(shí)優(yōu)化，編譯的運(yùn)行時(shí)優(yōu)化又是三個(gè)主要的代表，如上圖所示，那首先我們可以看一下不同的這個(gè)策略：
Svelte 的這個(gè)代碼生成策略相對(duì)更更繁瑣一些，而 Solid 是基于先生成一個(gè)基本的HTML字符串，然后在里面找到對(duì)應(yīng)的 DOM 節(jié)點(diǎn)進(jìn)行綁定，而 Svelte 是通過生成一這個(gè)命令式的一個(gè)一個(gè)節(jié)點(diǎn)，然后把節(jié)點(diǎn)拼接的這些 javaScript 代碼，但這個(gè)策略就導(dǎo)致掉同等的這個(gè)組件源碼之下 Svelte 的每個(gè)組件的編譯輸出會(huì)更臃腫，所以雖然大家感覺 Svelte 是以輕量出名的，
但其實(shí)我們會(huì)發(fā)現(xiàn)在相對(duì)大型的項(xiàng)目中，在項(xiàng)目中組建超過15個(gè)之后，Svelte 的整體的打包體積優(yōu)勢(shì)就已經(jīng)幾乎不存在了，那么當(dāng)組建超過50個(gè)，甚至是達(dá)到100個(gè)的時(shí)候，所有的體積會(huì)越來越越來越臃腫。
而相對(duì)于而言，我們可以看到 Vue 和 Solid 的編譯這個(gè)輸出啊，整體的這個(gè)曲線就平緩很多，所以其實(shí)在越大型的項(xiàng)目中。反而是 Svelte 的體積優(yōu)勢(shì)反而是一個(gè)劣勢(shì)，據(jù)我所知，Svelte 團(tuán)隊(duì)也有在想要優(yōu)化這一方面的，可能會(huì)在下一個(gè)大版本中才能實(shí)現(xiàn)，那么我們也會(huì)拭目以待。
同時(shí)尤大大提出 Solid 的編譯性能確實(shí)是非常的猛，其實(shí)在我們的 Vue 引入了很多編譯時(shí)的優(yōu)化以后我們的性能已經(jīng)比 Svelte 好了，但是離 Solid 還是有一定的距離。
Vue Vapor Mode（input）
就上面提及到的編譯時(shí)性能優(yōu)化，其實(shí)我們的 Vue 在早期的時(shí)候也做了這方面的探索，如還在試驗(yàn)中的一個(gè)項(xiàng)目 Vue Vapor Mode 。
那同樣的這個(gè)只有單文件組件輸入，我們現(xiàn)在是通過把模板編譯成虛擬DOM 的一個(gè)渲染函數(shù)來進(jìn)行運(yùn)行時(shí)的實(shí)現(xiàn)。但是因?yàn)槟０迨且粋€(gè)編譯源，所以我們也可以選擇在另一個(gè)模式下把它編譯成不同的輸出，也就是一個(gè)更類似于 Svelte 輸出。
這里這個(gè)輸出的代碼只是一個(gè)示例代碼。并不一定是最終的代碼，也不是你需要書寫的代碼，它完全是一個(gè)編譯器的輸出啊，它的整體的思路就是一次性生成這個(gè)模板的靜態(tài)結(jié)構(gòu)、靜態(tài)節(jié)點(diǎn)，然后再去生成命令式的，找到動(dòng)態(tài)節(jié)點(diǎn)，并對(duì)把它跟狀態(tài)進(jìn)行響應(yīng)式的綁定的這樣一些代碼，這個(gè)策略本質(zhì)上就是 ??Solid?? 所采用的策略，
那么其實(shí)呢，這個(gè)策略可以被所有的模板引擎所使用，我們也在探索某個(gè)版本的 ??Vue?? 當(dāng)中會(huì)引入一個(gè)可選的這樣的一個(gè)模式，把模板編譯成這樣的，性能更優(yōu)的，運(yùn)行時(shí)的這個(gè)體積也更小的一個(gè)模式，當(dāng)然這不會(huì)是一個(gè)破壞性更新，因?yàn)槲覀兊哪繕?biāo)是可以讓你漸進(jìn)式的去使用這個(gè)功能。
工具鏈
原生語言在前端工具鏈中的使用
關(guān)于原生語言在前端工具鏈中的使用尤大大提出下面幾個(gè)見解：
工具鏈的抽象層次
最早的打包工具，包括 brow/webpack/rollup 他們都是專注于打包的，他們的抽象層次相對(duì)低，當(dāng)你想要用這些工具去做一個(gè)真正的應(yīng)用的時(shí)候，你需要使用大量第三方插件，以及大量的配置來達(dá)到一個(gè)滿足你自己要求的最終的形態(tài)。
那么在這個(gè)基礎(chǔ)上就產(chǎn)生了像 Parcel/Vue-cli/CRA ，這樣的一些所謂的腳手架，更高抽象層次的這些工具，這些工具的特點(diǎn)是他們的抽象層的高，也就說他們專注于應(yīng)用，專注于解決一個(gè)完整的應(yīng)用方案呢，它的相對(duì)而言的缺點(diǎn)就是它是一個(gè)比較復(fù)雜、比較龐大的一個(gè)黑盒兒。
當(dāng)你需要去進(jìn)行自定義的定制的時(shí)候，你就會(huì)不可避免的遇到一些問題，比如說你跟他默認(rèn)的功能產(chǎn)生一些意見上的沖突的時(shí)候，你就會(huì)比較痛苦。
那么我們現(xiàn)在做的這個(gè)新項(xiàng)目 Vite 其實(shí)可能有一些同學(xué)已經(jīng)在用了，其實(shí)我們是在思考過這個(gè)抽象層次的問題之后才決定的他要走一個(gè)怎么樣的路線，也就是說 Vite 的 CLI 它是專注于應(yīng)用層次啊，它的抽象層次高，它有很多的開箱記，就是事先幫你寄配置好的功能，那么大部分的情況下，你開箱即用就可以達(dá)到跟 Parcel/Vue-cli/CRA 幾乎同等的這些功能啊，但是我們的API層面啊，這個(gè)可能用到的同學(xué)會(huì)少一些，
但是它的API層面其實(shí)是專注于支持上層框架，我們這個(gè)抽象層次會(huì)更低一點(diǎn)，我們只解決一些所有的夠 meta framework 都必須要解決的問題，但是對(duì)于上層框架，你用什么，我們并不會(huì)做過多的限制，反而是要做的更盡可能的靈活，能夠支持任何上層框架的用例，所以這也是為什么 Vite 現(xiàn)在幾乎成為了下一代的meta framework 共同的一個(gè)基底層選擇。
基于 Vite 的上層框架
我們看到上面這么多的上層框架都在基于 Vite 說明我們 Vite 走的路線還是相對(duì)成功的。
上層框架 Meta Frameworks
JS全棧的意義是什么 ？
如果我們講到這個(gè) Meta Frameworks，也就是最典型的例子，也就是NextJS 、NuxtJS、以及現(xiàn)在React社區(qū)中的新秀 Remix 等等，那么當(dāng)我們思考這樣類型的JS全棧的時(shí)候，我們做全棧的意義是什么？
那么相信在國(guó)內(nèi)很多大企業(yè)的朋友都知道，因?yàn)槲覀兛梢杂猛粋€(gè)語言去做前后的連接，我們可以做一些純前端和純后端都各自做不到的事情，或者說之前需要很復(fù)雜的聯(lián)調(diào)才能達(dá)成的一些事情，那么JS全?？梢愿玫娜ネ瓿梢粋€(gè)語言讓我們可以把前后打通。那么我們能夠打通什么呢？
數(shù)據(jù)的前后端打通
類型的前后端打通
JS全棧的代價(jià)
一些新的全?？蚣埽F(xiàn)在在試圖去改善的一些問題首先。我們現(xiàn)有的這些前端框架，比如說像主流的像 React、Vue 我們?cè)谧隽朔?wù)端渲染之后，還需要在前端要進(jìn)行一次所謂的注水，也就是 Hydrate 在追尋的過程中，我們要確保在客戶端和前端有同樣的數(shù)據(jù)，所以其實(shí)雖然我們的數(shù)據(jù)已經(jīng)用于渲染HTML，
這些數(shù)據(jù)理論上在HTML里面已經(jīng)都用過了，但是我們還得再把這個(gè)數(shù)據(jù)再發(fā)送一次，一起發(fā)送到前端，讓前端去進(jìn)行 Hydrate 這樣一個(gè)過程。因?yàn)闆]有這個(gè)數(shù)據(jù)，我們?cè)谇岸司蜎]有辦法保證 Hydrate 的正確性啊。
在客戶端，有些組件它可能在客戶端是不，需要交互的是靜態(tài)的，但是他在服務(wù)端用到了動(dòng)態(tài)的這個(gè)數(shù)據(jù)，但這個(gè)組件依然會(huì)被發(fā)到服務(wù)端，它依然會(huì)可能產(chǎn)生這個(gè)javascript 運(yùn)行時(shí)的代價(jià)啊，以及緩慢的這個(gè) Hydrate 會(huì)影響頁面的交互指標(biāo)，也就是 time to interactive。
有一些比較復(fù)雜的龐大的項(xiàng)目，他可能這個(gè)注水的過程會(huì)把頁面卡頓，以至于雖然能看到頁面，但是沒法交互，要等個(gè)一秒鐘才能交互等等，會(huì)產(chǎn)生這樣的問題。
社區(qū)探索的方向
社區(qū)現(xiàn)在新一代的這些全?？蚣芏荚谠噲D解決這些問題啊，比如說像 React 提出了 server only components 其實(shí)從這個(gè)定義上，我們就發(fā)現(xiàn)他是沒有一個(gè)全?？蚣?，圍繞一個(gè)全?？蚣苋プ?，其實(shí)用戶是沒有辦法簡(jiǎn)單地使用的一個(gè)概念，所以 React server only components 其實(shí)是一個(gè)必須要全站才能做的概念，Next 當(dāng)然也會(huì)去做，然后，其實(shí) Nuxt 最近也開了一個(gè) server only components 的一個(gè)提案，所以說這個(gè)已經(jīng)就是說 server only components 其實(shí)不僅僅是一個(gè) React 獨(dú)有的概念，在很多其他的框架中，我們可能慢慢都會(huì)出現(xiàn)類似的這個(gè)類似的東西。
還有一個(gè)方向就是減少注水，hydration 的這個(gè)成本，那么也就是局部的注水，或者也叫 island architecture 就像大海中一個(gè)小島，只有這些小島去對(duì)他進(jìn)行注水，讓他交可交互啊。那么比較代表性的就是 astro、isles 和生態(tài)里面的 fresh 這些框架。
然后呢，還有一個(gè)探索方向，就是所謂的 fine-grained+resumabl hydration，就是細(xì)粒度懶加載，這個(gè)數(shù)據(jù)其實(shí)是Qwik這個(gè)框架所發(fā)明的，Quick 的作者就是 Misko Hevery，也就是 Angular 的原作者，離開Google之后，現(xiàn)在新開發(fā)的這個(gè)框架啊，那么 Qwik 它主打的就是說它的特點(diǎn)就是不需要再把數(shù)據(jù)重新發(fā)送一遍。
他是直接在生成的渲染的html里面嵌入所需的數(shù)據(jù)從而使得客戶端的js可以直接在html里面獲得所要的數(shù)據(jù)，甚至是可以跳過一些需要執(zhí)行的js步驟，直接跳到一個(gè)已經(jīng)完成的狀態(tài)上面去，這就是所謂的resumable ，也是一個(gè)比較值得關(guān)注的一個(gè)方向。
以及我們的 Vue 生態(tài)里面生態(tài)里面有一個(gè)我們的 VitePress，我們其實(shí)探索的是一個(gè)在我們頁面的核心內(nèi)容：其實(shí)是靜態(tài)的MD文件的前提下如何做高效率的 hydration 那么我們做的是所謂的 hydration 就是整個(gè)的外部的這個(gè)一個(gè)框架內(nèi)容外包著的這一層ui是動(dòng)態(tài)的，然后呢在內(nèi)部靜態(tài)的里繼續(xù)進(jìn)行局部的注水，然后這樣的話，我們依然可以獲得一個(gè)單頁應(yīng)用的體驗(yàn)，但又獲得很好的客戶端注水的性能。
文章名稱：尤雨溪解讀2022Web前端生態(tài)趨勢(shì)
本文網(wǎng)址：http://www.dlmjj.cn/article/dpocijh.html
