[[421840]]

大家好，我卡頌。

這些年前端框架一直呈螺旋狀發(fā)展。

具體來(lái)說(shuō)，很多主流前端框架采用的技術(shù)實(shí)際上很早就被發(fā)明了。比如10年，「細(xì)粒度更新」就在Knockout中首創(chuàng)。

新框架的出現(xiàn)一般遵循：

一個(gè)新的「主意」 + 現(xiàn)有技術(shù)的排列組合

最近2年，最受歡迎的「主意」便是Svelte帶來(lái)的「重編譯時(shí)」概念了。

這也讓他成為StackOverflow21年開(kāi)發(fā)者報(bào)告中最受歡迎的框架。

然而，開(kāi)源界和工業(yè)界可能是兩幅光景：

開(kāi)發(fā)者嘴上說(shuō)著"哎呦，這個(gè)框架不錯(cuò)哦"，等到寫(xiě)項(xiàng)目時(shí)身體卻很誠(chéng)實(shí)的選擇了React。

這也不能怪開(kāi)發(fā)者。畢竟，生態(tài)才是前端框架最重要的部分。

本文要講的，就是個(gè)很可能制約Svelte生態(tài)發(fā)展的因素。

從VUE聊起

當(dāng)初VUE3在技術(shù)選型時(shí)，有個(gè)考慮的點(diǎn)是：

• 要不要移除「虛擬DOM」，擁抱「重編譯時(shí)」

「虛擬DOM」的作用是：找到交互造成的UI變化的部分。

但是，VUE3采用「細(xì)粒度更新」，理論上只要粒度足夠細(xì)，就完全不需要「虛擬DOM」。

通常，依賴(lài)「虛擬DOM」的框架，「虛擬DOM」會(huì)占據(jù)運(yùn)行時(shí)一大半工作量(比如React、VUE)。

如果能移除「虛擬DOM」能帶來(lái)如下好處：

打包后的框架代碼體積減少

運(yùn)行時(shí)交互造成UI更新的流程更短

但是，VUE3最終保留了「虛擬DOM」，其中一個(gè)很重要的原因是：

• 「虛擬DOM」能彌補(bǔ)「模版語(yǔ)言」的局限

虛擬DOM的優(yōu)勢(shì)比如，當(dāng)你需要在VUE中實(shí)現(xiàn)「布局組件」：

<Layout level={1}> 
  <div>1</div> 
  <div>2</div> 
  <Layout level={2}> 
    <div>33</div> 
    <div>44</div> 
  </Layout> 
</Layout> 

期望的效果是：嵌套在Layout中的結(jié)構(gòu)有不同縮進(jìn)。

輸出的HTML如下：

<div class="layout"> 
  <div class="layout--1"> 
    <div>1</div> 
    <div>2</div> 
    <div class="layout"> 
      <div class="layout--2"> 
        <div>33</div> 
        <div>44</div> 
      </div> 
    </div> 
  </div> 
</div> 

這需要用到slot特性。

但是注意這部分，需要根據(jù)組件傳入的level prop動(dòng)態(tài)改變：

<div class="layout--1"> 
  // ... 
</div> 

 比如：level = 1對(duì)應(yīng)class="layout--1"。

單純使用「模版語(yǔ)法」，已經(jīng)沒(méi)辦法描述這個(gè)特性了。

此時(shí)，就需要你手寫(xiě)「render函數(shù)」。

所以，為了編寫(xiě)復(fù)雜組件，VUE為開(kāi)發(fā)者開(kāi)放了「模版語(yǔ)法」與「手寫(xiě)render函數(shù)」兩條路子。

之所以能有兩條路子，是因?yàn)檫@兩條路最終都通向「虛擬DOM」。

[[421841]]

前端框架生態(tài)中很重要的一環(huán)，便是組件庫(kù)的豐富程度了。

為了一個(gè)好用的組件庫(kù)換框架是常有的事。

所以，為了減少開(kāi)發(fā)者編寫(xiě)復(fù)雜組件的成本，VUE保留了「虛擬DOM」。

Svelte永遠(yuǎn)閉上的門(mén)

作為和VUE一樣采用「模版語(yǔ)法」的框架，Svelte選擇「重編譯時(shí)」道路。

這就意味著他永遠(yuǎn)拋棄了「虛擬DOM」，也拋棄了「虛擬DOM」帶來(lái)的靈活性。

在討論Render functions的PR[1]中，官方明確表示：

Svelte永遠(yuǎn)不會(huì)考慮render函數(shù)

既然拋棄了「render函數(shù)」(以及背后的「虛擬DOM」)，那么當(dāng)編寫(xiě)復(fù)雜組件時(shí)，唯一的出路便是：

• 提供更多、更復(fù)雜的API以應(yīng)對(duì)復(fù)雜場(chǎng)景

比如：對(duì)于slot特性，Svelte提供了4個(gè)API：

• <slot>
• <slot name="name">
• $$slots
• <slot key={value}>

反觀React，由于極度靈活，壓根沒(méi)有對(duì)應(yīng)API。

我們可以大膽的推測(cè)，編寫(xiě)復(fù)雜組件的成本：

React < VUE < ... < Svelte

總結(jié)

如果一個(gè)框架只是概念新奇，會(huì)得到一時(shí)的關(guān)注。

但是，只有在DX(開(kāi)發(fā)者體驗(yàn))、UX(用戶(hù)體驗(yàn))都做到平衡的框架才能在工業(yè)界長(zhǎng)久存在。

這一點(diǎn)上，Svelte任重道遠(yuǎn)。

參考資料

[1]討論Render functions的PR:

https://github.com/sveltejs/svelte/issues/4971