不知大家發(fā)現(xiàn)沒有，自從2021年以來，無虛擬DOM框架/庫/編譯器獲得了極大的矚目，最為典型的兩個項目：

• Svelte

• Solid.js

我們來看看他倆究竟有多勇：

(來自https://www.tecla.io/blog/top-js-frameworks)

可以看到Svelte去年一年在GitHub上增長的Star接近Vue，甚至力壓老牌經(jīng)典框架Angular！

再來看看這個：

滿意度甚至超越React和Vue，(吐槽：Angular這滿意度趨勢…)

感興趣程度同樣霸榜，只不過這回剛好反過來：Svelte力壓Solid，Vue力壓React(越來越多的人對Vue感興趣了哈)。Angular頹勢已顯，氣數(shù)已盡了？別擔心！下一個選項(Usage)讓Angular來告訴你，什么叫你大爺永遠是你大爺：

奇怪，感覺自己身邊明明沒那么多人用Angular，怎么肥四？這是因為調(diào)查對象主要以歐美地區(qū)為主(尤其美國)：

母語為英語的人占多數(shù)：

年輕人為主：

這就很完美的解釋了為什么Solid和Svelte的受歡迎程度會那么高，年輕??！折騰?。∧阋俏辶畾q了(在中國應該沒有這個歲數(shù)的程序員了吧)你也不愿意折騰那些亂七八糟的。

年輕不代表是新手，還是有相當一部分有經(jīng)驗的開發(fā)者參與調(diào)查的。

數(shù)據(jù)來源：https://2021.stateofjs.com/en-US/libraries/front-end-frameworks/

不過這些數(shù)據(jù)還不能證明Svelte和Solid已經(jīng)成為流行框架\庫\編譯器了，有相當一部分叫好不叫座的，我們來看看npm的數(shù)據(jù)：

哎呀！暴露了暴露了，再來看看Google搜索量：

可以看到三大框架依然是主流哈，而且Vue和Angular的差距已經(jīng)越來越小了，當然還因為有股神秘的東方力量屏蔽掉了大部分去Google搜索Vue的，不然我相信Vue的數(shù)據(jù)一定可以超越Angular的。

沒想到對Svelte最感興趣的居然是韓國人！雖然三大框架YYDS，但作為后起之秀并且在沒有明顯優(yōu)勢的情況下(綜合情況，光寫個Hello World確實誰也比不過Svelte)依然能夠從三大框架嘴里分一杯小小的羹，并且還能夠獲得如此巨大的關(guān)注度，那就證明無虛擬DOM的趨勢已經(jīng)悄然興起了。

為什么這玩意會成為一種趨勢呢？有啥好處？好處就是性能！

什么？虛擬 DOM 不就是為了提升性能的嗎？！是也不是

他們會火不是沒有原因的，我們來看看他倆的性能：

可以用傲視群雄這四個字來形容了，Vue之前一直以高性能為傲，但被人超了怎么可能會甘心？畢竟Vue和React不一樣，當數(shù)據(jù)更新時Vue是知道該更新哪個組件的，React不知道所以它只能用diff算法，沒有虛擬DOM根本不行。那Vue干嘛也要來一個虛擬DOM呢？尤雨溪也是這么想的！

其實他早就有過放棄虛擬DOM的想法了：在尤雨溪發(fā)表的《Vue3的設計過程》(翻譯版)一文中，尤大說：一種選擇是放棄虛擬 DOM 并直接生成命令式 DOM 操作，但這將消除直接編寫虛擬 DOM 渲染功能的能力，我們發(fā)現(xiàn)這對高級用戶和庫作者非常有價值。

那時候Vue3還沒發(fā)布呢，Vue3的createRenderer就是利用虛擬DOM來實現(xiàn)跨平臺的，但成天老是跨平臺跨平臺的，我們平時開發(fā)業(yè)務又有多少跨平臺項目呢？

現(xiàn)在追求的就是一個輕量級，沒有了虛擬DOM就沒有了Diff算法，不僅可以不用運行一些無謂的計算，而且打包出來的體積那可真是輕上加輕?。∷幌銌?？

但也不能完全放棄虛擬DOM啊，一方面虛擬DOM還是有它大展宏圖的場景的。另一方面你直接把虛擬DOM刪了，那些庫怎么辦？它們有多少是依賴虛擬DOM的API的呢？有多少組件庫用的是jsx呢。去掉了虛擬DOM的話，那些組件庫是不是就用不了了呢？那咱們可以搞個模式出來嘛！

無虛擬DOM模式

首先咱們先把尤大在發(fā)布會上說的話(重點部分)翻譯下，為了節(jié)省篇幅不重點的地方就不貼上來了：

主要的事情就是：我們想要探索一種新的編譯策略

我們都知道Vue是一個基于模板的框架，即使你能用jsx能用虛擬DOM，但大多數(shù)用戶還是會用template模板。

由于Vue的大部分用戶都用單文件組件來寫代碼，所以我們其實是有機會把組件編譯成原生JS、CSS的。所以編譯的這個步驟是有機會能讓Vue變成一個超級編譯器的！這將會很有趣，所以我們想要探索一下新的編譯策略，這也是受到了Solid.js的啟發(fā)。新的編譯策略可以把template模板編譯成命令式的DOM操作+響應式的setup綁定以代替虛擬DOM和render函數(shù)。所以想象一下，當我們寫了一個這樣的組件：

(此處省略一些廢話：這是script setup語法、看這里有個button按鈕、我們給按鈕綁定一個響應式的值之類的話)

我們生成的將會是這樣的代碼，生成出來的代碼量非常少，目前的想法是我們過一遍虛擬DOM樹然后生成真實DOM的操作。我們會在編譯期分析template模板里的HTML的結(jié)構(gòu)并將其字符串化：

為了能讓打包出來的內(nèi)容最小化，去掉了結(jié)束標簽以及各種綁定的屬性。然后再生成一個cloneNode：

通過分析得出哪些屬性是響應式的，把它們都放在effect里，再綁定事件，全部都是非常好理解的DOM操作：

(這不比Svelte生成出來的那一大坨好多了？)

兩種模式

這里的兩種模式指的并不是虛擬DOM模式和無虛擬DOM模式這兩種模式，而是無虛擬DOM模式下還可以繼續(xù)再往下細分出來兩種模式：

組件模式

比方說你現(xiàn)在手里已經(jīng)有了長期維護的Vue3項目，你要是直接換成無虛擬DOM模式那肯定是要出問題的，所以可以采用組件模式來精確控制哪些組件不需要虛擬DOM。

比方說你的項目中采用了尤大推薦的naive-ui這個組件庫，我們打開一個比較常用的組件Button來看一下：

tsx結(jié)尾，那虛擬DOM算是沒跑了。不過tsx也照樣可以給改成生成真實DOM的函數(shù)啊，solid.js不就是這么干的嗎？其實理論上來說確實是可以做到的，我們點進去再看一眼：

這里用到了h函數(shù)，這個函數(shù)是專門用來生成虛擬DOM的，假如你把項目全部換成了無虛擬DOM模式同時這些庫還沒來得及跟進的話，那肯定是不行的。

所以你可以控制，你哪個組件里沒用這個組件庫，你再給這個組件單獨的一個編譯策略(無虛擬DOM模式)。

既然有組件級的那就肯定有應用級的，比方說你想開發(fā)一個UI高度定制化的H5活動頁。

一般來說這樣的頁面不會用組件庫，都是自己寫樣式。另一方面這種活動頁當然是越小越好，越快越好啦！那么此時你就可以采用全局無虛擬DOM模式。

怎么感覺這是在搶Svelte飯碗呢？我看技術(shù)論壇已經(jīng)有人分享了自己用Svelte來開發(fā)一些小頁面的文章了，這回再有什么性能跑分之類的評測Vue應該不會再輸給Svelte了(看情況，組件越少Svelte越占優(yōu)，反之則Vue占優(yōu))

機遇與挑戰(zhàn)

最近前端可謂是越來越卷了，你要是去面試稍微高級點的崗位的話，估計很可能會問你Vue怎么編譯的兩種模式了(即使你并不感興趣)。

但我發(fā)現(xiàn)很多人對自己做一款組件庫非常感興趣，從文章列表里看一下究竟有多少組件庫相關(guān)的文章就能夠一探究竟了。而且很多教大家搭建組件庫的文章也是點贊量非常高，還有很多文章推薦自己做出來的組件庫。

只可惜大部分個人做的組件庫都是孤芳自賞，沒幾個人用。一方面的個人開發(fā)者可能隨時刪庫跑路，不穩(wěn)定。誰知道你寫的那玩意有多少bug呢？另一方面大家也更愿意用Star非常多的組件庫，證明其穩(wěn)定。

所以大家如果想從主流組件庫那里分一杯羹的話還是非常困難的。那現(xiàn)在這個無虛擬DOM模式是不是就是一個千載難逢的大好時機？不過我個人依然感覺希望不大，因為那些主流組件庫肯定會立馬跟進，搞一款無虛擬DOM適配版。

不過不管怎么說，我對這個實驗性特性還是非常期待的。因為這個編譯策略編譯成web components很可能會是一個非常不錯的選擇，總之，期待無虛擬DOM的到來！