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

成都創(chuàng)新互聯(lián)公司云計(jì)算的互聯(lián)網(wǎng)服務(wù)提供商,擁有超過(guò)13年的服務(wù)器租用、成都二樞服務(wù)器租用托管、云服務(wù)器、虛擬主機(jī)、網(wǎng)站系統(tǒng)開(kāi)發(fā)經(jīng)驗(yàn)，已先后獲得國(guó)家工業(yè)和信息化部頒發(fā)的互聯(lián)網(wǎng)數(shù)據(jù)中心業(yè)務(wù)許可證。專(zhuān)業(yè)提供云主機(jī)、虛擬主機(jī)、域名注冊(cè)、VPS主機(jī)、云服務(wù)器、香港云服務(wù)器、免備案服務(wù)器等。

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

框架

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

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

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

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

框架能解決什么問(wèn)題？

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

聲明性編程

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

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

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

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

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

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

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

 return (
     
Hello {name}!

 )
}

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

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

 render() {
   return html`
Hello ${this.name}!
`;
 }
}

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

Hello {name}!

反應(yīng)性

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

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

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

邏輯

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

(1) 條件句

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

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

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

  Message

Svelte 提供了 #if 指令：

{#if state.error}
  Message
{/if}

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

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

(2) 列表

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

在 React 中，列表處理看起來(lái)像這樣：

contacts.map((contact, index) =>
 

   {contact.name}
 
)

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

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

  {contact => 
{contact.name}
 }

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

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

{#each contacts as contact}
  
{contact.name}

{/each}

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

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

組件模型

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

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

成本

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

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

包大小

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

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

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

構(gòu)建

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

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

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

調(diào)試

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

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

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

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

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

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

升級(jí)

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

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

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

總結(jié)

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

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

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

網(wǎng)頁(yè)標(biāo)題：Web框架能解決什么問(wèn)題？
網(wǎng)頁(yè)鏈接：http://www.5511xx.com/article/djidjgi.html