最近，我對對比框架和普通的 JavaScript 產(chǎn)生了濃厚的興趣。這始于我在一些自由職業(yè)項(xiàng)目中使用 React 時遇到的一些挫折，以及我最近作為規(guī)范編輯，對 Web 標(biāo)準(zhǔn)有了更多的認(rèn)識。

我希望了解一下這些框架的共性和差異，Web 平臺作為一種更精簡的選擇，能提供什么，以及它是否足夠。我的目標(biāo)并非要抨擊這些框架，而是要了解成本和效益，找出有沒有其他選擇，甚至當(dāng)我們決定采用框架時，我們也能從中吸取教訓(xùn)。

在本系列文章的第一部分中，我將深入探討一些框架的共性技術(shù)特性，并介紹幾種不同的框架是怎樣實(shí)現(xiàn)這些特性的。我還要看一下使用這些框架的成本。

框架

我選取四種架構(gòu)進(jìn)行研究。React 是當(dāng)今的主流框架，還有三個較新的競爭者，它們聲稱自己的工作方式與 React 不同。

• React：“React 使創(chuàng)建交互式用戶界面變得不費(fèi)力。聲明性視圖使你的代碼更可預(yù)測，更容易調(diào)試?！?/li>
• SolidJS：“Solid 遵循與 React 相同的理念……但它的實(shí)現(xiàn)方式完全不同，放棄了使用虛擬 DOM?！?/li>
• Svelte：“Svelte 是一種全新的構(gòu)建用戶界面的方式……是一個在你構(gòu)建應(yīng)用時發(fā)生的編譯步驟。Svelte 不使用虛擬 DOM diffing 之類的技術(shù)，而是編寫代碼，當(dāng)你的應(yīng)用程序的狀態(tài)發(fā)生變化時，外科手術(shù)式地更新 DOM?！?/li>
• Lit：“在 Web Components 標(biāo)準(zhǔn)的基礎(chǔ)上，Lit 增加了……反應(yīng)性、聲明性模板，以及一些深思熟慮的特性?！?/li>

總結(jié)一下這些框架對其差異化的說法：

• React 通過聲明式視圖使構(gòu)建 UI 更容易。
• SolidJS 遵循 React 的理念，但是采用了另一種技術(shù)。
• Svelte 處理用戶界面采用了一種編譯時的方式。
• Lit 使用現(xiàn)有的標(biāo)準(zhǔn)，并增加了一些輕量級的特性。

框架能解決什么問題？

框架自身也提及了諸如聲明性、反應(yīng)性和虛擬 DOM 等詞。讓我們深入了解它們的含義。

聲明性編程

聲明性編程是一種范式，在這種范式中，邏輯被定義，而沒有指定控制流。我們描述需要的結(jié)果是什么，而不是我們會采取什么步驟。

在 2010 年左右，聲明性框架的早期，DOM 的 API 更加簡單，更加冗長。而使用命令式的 JavaScript 編寫 Web 應(yīng)用程序則需要大量的模板代碼。這時，“模型 - 視圖 - 視圖模型”(model-view-viewmodel，MVVM)的概念開始盛行，當(dāng)時具有劃時代意義的 Knockout 和 AngularJS 框架，提供了一個 JavaScript 聲明層，在庫內(nèi)處理這種復(fù)雜性。

今天，MVVM 并不是一個廣泛使用的術(shù)語，它在某種程度上是舊術(shù)語“數(shù)據(jù)綁定”的變種。

數(shù)據(jù)綁定

數(shù)據(jù)綁定是一種聲明性的方式，用來表示數(shù)據(jù)如何在模型和用戶界面之間同步。所有流行的 UI 框架都提供了某種形式的數(shù)據(jù)綁定，它們的教程都以數(shù)據(jù)綁定的例子開始。

以下是 JSX(SolidJS 和 React)中的數(shù)據(jù)綁定：

function HelloWorld() {
 const name = "Solid or React";

 return (
     <div>Hello {name}!</div>
 )
}

Lit 中的數(shù)據(jù)綁定：

class HelloWorld extends LitElement {
 @property()
 name = 'lit';

 render() {
   return html`<p>Hello ${this.name}!</p>`;
 }
}

Svelte 中的數(shù)據(jù)綁定：

<script>
  let name = 'world';
</script>

<h1>Hello {name}!</h1>

反應(yīng)性

反應(yīng)性是一種聲明性的方式來表達(dá)更改的傳播。

如果我們能夠用一種聲明的方式來表示數(shù)據(jù)綁定，那么我們就必須要有一個使框架能夠傳播更改的高效方法。

• React 引擎會把渲染的結(jié)果與之前的結(jié)果相比較，并將差異應(yīng)用于 DOM 本身。這種處理更改傳播的方式，被稱為虛擬 DOM。
• 在 SolidJS 中，這是以其存儲和內(nèi)置元素更明確地完成的。例如，Show 元素將跟蹤內(nèi)部的變化，而不是虛擬 DOM。
• 在 Svelte 中，生成“active”代碼。Svelte 知道哪些事件會導(dǎo)致變化，它會生成直接的代碼，區(qū)分事件和 DOM 更改。
• 在 Lit 中，反應(yīng)性是通過元素屬性來實(shí)現(xiàn)的，基本上是依賴 HTML 自定義元素的內(nèi)置反應(yīng)性。

邏輯

如果框架為數(shù)據(jù)綁定提供了聲明性的接口，并且能夠?qū)崿F(xiàn)反應(yīng)性，那么就必須提供一些方法來表達(dá)一些傳統(tǒng)意義上的邏輯，這些邏輯是以命令的方式寫的。邏輯的基本構(gòu)件是 “if” 和 “for”，而所有的主流框架都提供了這些構(gòu)件的一些表達(dá)。

(1) 條件句

除了綁定數(shù)字和字符串等基本數(shù)據(jù)外，每個框架都提供了一個“條件”原語。在 React 中，它看起來如下所示：

const [hasError, setHasError] = useState(false);  
return hasError ? <label>Message</label> : null;
…
setHasError(true);

SolidJS 提供了內(nèi)置的條件組件。

<Show when={state.error}>
  <label>Message</label>
</Show>

Svelte 提供了 #if 指令：

{#if state.error}
  <label>Message</label>
{/if}

在 Lit 中，你將在 render 函數(shù)中使用顯式三元運(yùn)算：

render() {
 return this.error ? html`<label>Message</label>`: null;
}

(2) 列表

另一個常見的框架基元是列表處理。列表是用戶界面的一個關(guān)鍵部分——如聯(lián)系人列表、通知等——要想高效工作，就必須有反應(yīng)性，而不是在一個數(shù)據(jù)項(xiàng)發(fā)生變化時，對整個列表進(jìn)行更新。

在 React 中，列表處理看起來像這樣：

contacts.map((contact, index) =>
 <li key={index}>
   {contact.name}
 </li>)

React 使用特殊的 key 屬性來區(qū)分列表項(xiàng)，它確保整個列表不會在每次渲染時被替換。

在 SolidJS 中，使用了 for 和 index 內(nèi)置元素：

<For each={state.contacts}>
  {contact => <DIV>{contact.name}</DIV> }
</For>

在內(nèi)部，SolidJS 將自身的存儲與 for 和 index 相結(jié)合，以確定在項(xiàng)目發(fā)生個更改時要更新哪些元素。它比 React 更清晰，使我們能夠避免虛擬 DOM 的復(fù)雜性。

Svelte 使用 each 指令，該指令根據(jù)其更新器被轉(zhuǎn)譯：

{#each contacts as contact}
  <div>{contact.name}</div>
{/each}

Lit 提供了一個 repeat 函數(shù)，它的工作原理類似于 React 的基于鍵的列表映射：

repeat(contacts, contact => contact.id,
    (contact, index) => html`<div>${contact.name}</div>`

組件模型

有一件事超出了本文的范圍，那就是不同框架中的組件模型，以及如何使用自定義 HTML 元素來處理它。

注意：這是一個很大的主題，我想在以后的文章里討論這個主題，因?yàn)檫@個主題會讓這篇文章變得太長。

成本

框架提供了聲明性的數(shù)據(jù)綁定、控制流原語(條件和列表)，以及傳播更改的反應(yīng)性機(jī)制。它們還提供了其他重要的東西，比如重用組件的方法，但這就是另一篇文章的主題了。

框架有用嗎?是的。它們帶給了我們所有這些方便的特性。但這是一個正確的問題嗎?使用框架需要付出一定的成本。讓我們來看一下這些成本。

包大小

在查看包大小時，我更愿意看到非 Gzip 的縮減大小。這個尺寸與 JavaScript 的 CPU 開銷有很大關(guān)系：

• ReactDOM 大約是 120 KB。
• SolidJS 大約是 18KB。
• Lit 大約是 16KB。
• Svelte 約為 2KB，但生成的代碼大小不同。

現(xiàn)在看來，在保持包大小上，現(xiàn)在的框架要優(yōu)于 React。虛擬 DOM 要求使用很多 JavaScript。

構(gòu)建

不知何故，我們習(xí)慣了“構(gòu)建” Web 應(yīng)用。如果不設(shè)置 Node.js 和 Webpack 這樣的捆綁器，不處理 Babel-TypeScript 啟動包中最近的一些配置更改，以及所有這些事情，就不可能啟動一個前端項(xiàng)目。

越是有表達(dá)力的框架，包大小就會變得更小，但構(gòu)建工具和轉(zhuǎn)譯時間的負(fù)擔(dān)就越大。

Svelte 宣稱，虛擬 DOM 完全是一種開銷。我同意，但是可能像 Svelte 和 SolidJS 這樣的“構(gòu)建”以及像 Lit 這樣的自定義客戶端模板引擎都只是單純的開銷嗎?

調(diào)試

在構(gòu)建和轉(zhuǎn)譯過程中，需要付出的成本也是不同的。

我們在使用和調(diào)試 Web 應(yīng)用程序時，所見到的代碼和我們所編寫的完全不一樣。我們現(xiàn)在依靠同樣品質(zhì)的調(diào)試工具，逆向設(shè)計(jì)出一個站點(diǎn)，并把它和我們自己的代碼中的 bug 相關(guān)聯(lián)。

在 React 中，調(diào)用棧從來不是“你的”事情——React 會為你處理調(diào)度。這一特性在沒有 bug 的時候非常好用。但是，如果你試圖找出無限循環(huán)重現(xiàn)的原因，你將會陷入痛苦的境地。

在 Svelte 中，庫本身的包大小很小，但你要傳輸和調(diào)試一大堆神秘的生成代碼，這些代碼是 Svelte 對反應(yīng)性的實(shí)現(xiàn)，根據(jù)你的應(yīng)用需求定制。

Lit 并不需要進(jìn)行大量的構(gòu)建，但是要想有效地進(jìn)行調(diào)試，你就必須熟悉其模板引擎。這也許是我對框架持懷疑態(tài)度的最大原因。

當(dāng)你尋求自定義的聲明式解決方案時，你將面對更加困難的命令調(diào)試。本文中的示例采用了 TypeScript 來對 API 進(jìn)行規(guī)范，但是該代碼本身并不需要轉(zhuǎn)譯。

升級

在本文中，我討論了四個框架，但是還有許多其他的框架，多得數(shù)不清(AngularJS、Ember.js 和 Vue.js，僅舉幾例)。你能指望框架、它的開發(fā)者、它的思想和它的生態(tài)系統(tǒng)在開發(fā)過程中為你工作？

除了修補(bǔ)自己的 bug 之外，還有一個更讓人沮喪的事情，就是必須為框架的錯誤找到變通方法。而且，還有一個更加令人沮喪的事情，那就是在沒有修改你的代碼的情況下，將框架升級為新的版本，會出現(xiàn) bug。

誠然，瀏覽器中也有這樣的問題，但是這種問題一旦出現(xiàn)，就會影響到所有人，而且在大多數(shù)情況下，修復(fù)或者發(fā)布一個解決方案，都是迫在眉睫的。此外，本文提到的大部分模式都建立在成熟的 Web 平臺 API 之上，并不一定都需要采用尖端技術(shù)。

總結(jié)

我們對框架所要處理的核心問題有了更深刻的理解，并且著重于數(shù)據(jù)綁定、反應(yīng)性、條件和列表。我們也對成本進(jìn)行了討論。

在本系列的第二部分中，我們將會了解到，在沒有框架的情況下，我們是怎樣處理這些問題的，以及我們可以從中學(xué)習(xí)到什么。敬請關(guān)注！

原文鏈接：https://www.smashingmagazine.com/2022/01/web-frameworks-guide-part1/