鑽石舞台

作者：Noam Rosenthal

地址：https://www.smashingmagazine.com/2022/01/web-frameworks-guide-part1/

在本文中，Noam Rosenthal深入研究了一些跨框架通用的技術特性，並解釋了一些不同的框架如何實現它們以及它們的成本。

Noam Rosenthal是一名WEB平台顧問，WebKit & Chromium貢獻者、技術文章寫作者，也是一名經驗豐富的WEB開發者。他的工作重點是讓WEB開發和瀏覽器/標準開發二者之間聯繫的更加緊密。

我最近對比較框架和普通的JavaScript非常感興趣。它開始於我在一些項目中使用React時遇到的一些挫折，以及我最近作為一個規範編輯對web標準有了更深入的了解。

我感興趣的是這些框架之間有什麼共同點和不同點，web平台作為一個精簡的替代方案應該提供什麼，以及它是否足夠。我的目標不是抨擊框架，而是了解其成本和收益，確定是否存在替代方案，並看看即使我們決定使用框架，我們是否可以從中學習。

在第一部分中，我將深入研究一些跨框架通用的技術特性，以及不同框架如何實現這些特性。我還將討論使用這些框架的成本。

我選擇了4個框架來研究:React，它是當今的主流框架，還有3個新的競爭者聲稱他們的工作方式與React不同。

總結一下這些框架的不同點:

框架本身提到了聲明性、響應式和虛擬DOM。讓我們來探究一下這意味着什麼。

聲明式編程是一種定義邏輯而不指定控制流的範例。我們描述的是結果需要是什麼，而不是我們需要採取什麼步驟才能達到目標。

在聲明式框架的早期，大約在2010年，DOM api要簡單和冗長得多，用命命式JavaScript編寫web應用程序需要大量的樣板代碼。這時，「模型-視圖-視圖模型」(MVVM)[1]的概念開始流行起來，當時具有開創性的Knockout和AngularJS框架提供了一個JavaScript聲明層來處理庫中的複雜性。

MVVM現在不是一個廣泛使用的術語，它在某種程度上是舊術語「數據綁定」的變體。

數據綁定是一種聲明性的方式，用來表示數據如何在模型和用戶界面之間同步。

所有流行的UI框架都提供了某種形式的數據綁定，它們的教程都從一個數據綁定示例開始。

下面是JSX中的數據綁定(SolidJS和React):

Lit中的數據綁定:

Svelte中的數據綁定:

響應式是一種表達變更傳播的聲明性方式。

當我們有了一種聲明式表達數據綁定的方法時，我們需要一種有效的方法讓框架傳播更改。

React引擎會將渲染結果與之前的結果進行比較，並將差異應用到DOM本身。這種處理變更傳播的方法稱為虛擬DOM[2]。

在SolidJS中，這是通過其存儲和內置元素更顯式地完成的。例如，Show元素將跟蹤內部發生的變化，而不是虛擬DOM。

在Svelte中，會生成「響應式」代碼。Svelte知道哪些事件會導致更改，並生成簡單的代碼，在事件和DOM更改之間劃線。

在Lit中，響應式是使用元素屬性完成的，本質上依賴於HTML自定義元素的內置響應式。

當框架為數據綁定提供聲明性接口，並實現響應式時，它還需要提供某種方式來表達一些傳統上以命定方式編寫的邏輯。邏輯的基本構建塊是「if」和「for」，所有主要的框架都提供了這些構建塊的一些表達式。

除了綁定數字和字符串等基本數據外，每個框架都提供一個「條件」原語。在React中，它是這樣的:

SolidJS提供了一個內置的條件組件Show[3]:

Svelte提供了#if指令:

在Lit中，你可以在渲染函數中使用一個顯式的三目運算操作:

另一個常見的框架原語是列表處理。列表是ui的關鍵部分---聯繫人列表、通知列表等等——為了有效地工作，它們需要是響應式的，而不是在一個數據項發生變化時更新整個列表。

在React中，列表處理是這樣的:

React使用特殊的key屬性來區分列表項，並確保整個列表不會在每次渲染時被替換。

在SolidJS中，for和index是作為內置元素被使用的:

在內部，SolidJS使用自己的存儲庫和for和索引來決定在項目更改時更新哪些元素。它比React更顯式，允許我們避免虛擬DOM的複雜性。

Svelte使用了each指令，根據它的更新器進行編譯:

Lit提供了一個repeat函數，它的工作原理類似於React的鍵列表映射:

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

注: 這是一個很大的主題，我希望在以後的文章中討論它，因為這篇文章太長了。

框架提供了聲明性的數據綁定、控制流原語(條件和列表)和響應機制來傳播更改。

它們還提供了其他主要功能，比如重用組件的方法，但這是另一篇文章的主題。

框架有用嗎?是的。它們給了我們所有這些方便的特性。但這個問題問對了嗎?使用框架是有代價的。讓我們看看這些成本是多少。

在查看打包後的包大小時，我喜歡查看壓縮後的非gzip大小。這是與JavaScript執行的CPU成本最相關的大小。

不知怎麼的，我們習慣了「構建」我們的網絡應用。要啟動一個前端項目，必須先建立Node.js和Webpack這樣的打包工具，處理Babel-TypeScript的一些配置等等。

框架的包大小越小，表達能力越強，構建工具和翻譯時間的負擔就越大。

Svelte聲稱虛擬DOM是純粹的開銷[4]。這一點我同意，但也許「構建」(如使用Svelte和SolidJS)和定製客戶端模板引擎(如使用Lit)也是純粹的開銷，是一種不同的表現形式?

構建和編譯帶來了一定的開銷和成本。

當我們使用或調試web應用程序時，我們看到的代碼與我們寫的完全不同。我們現在依賴於不同質量的特殊調試工具來逆向工程網站上發生的事情，並將其與我們自己代碼中的錯誤聯繫起來。

在React中，調用棧從來不是「你的」——React為你處理調度。在沒有bug的情況下，這種方法非常有效。但是嘗試着去識別無限循環重新呈現的原因，你將會經歷一個痛苦的世界。

在Svelte中，庫本身的包大小很小，但你需要發布和調試一大堆神秘的生成代碼，這是Svelte的響應式實現，根據應用的需要定製。

使用Lit，它與構建無關，但要有效地調試它，您必須理解它的模板引擎。這可能是我對框架持懷疑態度的最大原因。

當您尋找自定義聲明式解決方案時，您最終會遇到更痛苦的命令式調試。本文檔中的示例使用Typescript作為API規範，但代碼本身不需要編譯。

在本文檔中，我介紹了4個框架，但還有很多框架(AngularJS、Ember.js和Vue.js等[5])。在它的發展過程中，你能指望這個框架、它的開發者、它的人氣和它的生態系統為你服務嗎?

有一件事比修復自己的漏洞更令人沮喪，那就是必須為框架漏洞找到變通方法。還有一件事比框架bug更令人沮喪，那就是當你沒有修改代碼就將框架升級到一個新版本時出現的bug。

確實，這個問題也存在於瀏覽器中，但是當它發生時，它會發生在每個人身上，並且在大多數情況下，修復或發布的解決方案是迫在眉睫的。此外，本文檔中的大多數模式都是基於成熟的web平台api;沒有必要總是去流血的邊緣。

我們深入了解了框架試圖解決的核心問題，以及它們如何解決這些問題，重點關注數據綁定、響應式、條件和列表。我們也看了成本。

在後面的部分，我們將了解如何在根本不使用框架的情況下解決這些問題，以及我們可以從中學到什麼。請繼續關注!

特別感謝以下每個人的勘校:Yehonatan Daniv, Tom Bigelajzen, Benjamin Greenbaum, Nick Ribal和Louis Lazaris。

在第二部分中，Noam提出了一些如何直接使用web平台作為框架提供的一些解決方案的替代方案的模式。

在前面的第一章節中，我們從框架試圖解決的核心問題的角度出發，研究了使用框架的不同好處和成本，重點關注聲明式編程、數據綁定、響應式、列表和條件。現在，我們將看到是否可以從網絡平台本身出現一個替代方案。

在沒有框架的情況下進行探索，似乎不可避免的結果是使用自己的框架來進行響應式數據綁定。在之前嘗試過這種方法，並看到它的代價有多大後，我決定在這次探索中遵循一條指導原則;我並不是要推出我自己的框架，而是想看看我能否以一種讓框架變得不那麼必要的方式直接使用web平台。如果您考慮使用自己的框架，請注意有一組成本沒有在本文中討論。

web平台已經提供了一種開箱即用的聲明式編程機制:HTML和CSS。這種機制是成熟的、經過良好測試的、流行的、廣泛使用的和有文檔記載的。但是，它沒有提供明確的內置概念，如數據綁定、條件呈現和列表同步，而響應式是跨多個平台特性的一個微妙細節。

當我瀏覽流行框架的文檔時，我可以直接找到第1部分中描述的特性。當我閱讀web平台文檔時(例如，在MDN[6]上)，我發現了許多令人困惑的如何做事的模式，沒有數據綁定、列表同步或響應式的結論性表示。我將嘗試繪製一些在web平台上解決這些問題的指導方針，而不需要框架(換句話說，通過普通的方式)。

讓我們回到錯誤標籤的例子。在ReactJS和SolidJS中，我們創建的聲明式代碼轉換為命令式代碼，將標籤添加到DOM或刪除它。在Svelte中，生成該代碼。

但是如果我們根本沒有這些代碼，而是使用CSS來隱藏和顯示錯誤標籤呢?

在這種情況下，響應式在瀏覽器中處理——應用程序對類的更改傳播到它的後代，直到瀏覽器中的內部機制決定是否呈現標籤。

這種技術有幾個優點:

在使用大量javascript的單頁應用程序(spa)時代之前，表單是創建包含用戶輸入的web應用程序的主要方式。傳統上，用戶將填寫表單並單擊「Submit」按鈕，然後服務器端代碼將處理響應。表單是數據綁定和交互性的多頁應用程序版本。毫無疑問，具有輸入和輸出基本名稱的HTML元素是表單元素。

由於表單api的廣泛使用和悠久的歷史，它積累了一些隱藏的優點，使得它們可以用於那些傳統上認為由表單解決不了的問題。

表單可以通過名稱訪問(使用document.forms "document.forms")，每個表單元素都可以通過名稱訪問(使用form.elements)。此外，可以訪問與元素相關聯的表單(使用form attributes[7])。這不僅包括input元素，還包括其他表單元素，如output、textarea和fieldset，這允許嵌套訪問樹中的元素。

在上一節的錯誤標籤示例中，我們展示了如何響應式地顯示和隱藏錯誤消息。這是我們在React中更新錯誤消息文本的方法(在SolidJS中也是如此):

當我們有一個穩定的DOM和穩定的樹形式和表單元素時，我們可以做以下事情:

它的原始形式看起來相當冗長，但它也非常穩定、直接和高性能。

通常，當我們構建SPA時，我們會使用一些類似json的API來更新我們的服務器或我們使用的任何模型。

這是一個很熟悉的例子(為了便於閱讀，是用Typescript寫的):

在框架代碼中，通過選擇輸入元素並一塊一塊地構造對象來生成這個Contact對象是很常見的。正確使用表單，有一個簡潔的替代方案:

通過使用隱藏的輸入和有用的FormData類，我們可以在DOM輸入和JavaScript函數之間無縫地轉換值。

通過結合表單的高性能選擇器穩定性和CSS響應式，我們可以實現更複雜的UI邏輯:

注意，在這個例子中沒有使用類——我們從表單的數據中開發DOM的行為和樣式，而不是手工更改元素類。

我不喜歡過度使用CSS類作為JavaScript選擇器。我認為它們應該用於將類似樣式的元素組合在一起，而不是作為一種改變組件樣式的萬能機制。

框架提供了自己的表達可觀察列表的方式。如今，許多開發人員也依賴於提供這類特性的非框架庫，比如MobX。

通用目的可觀察列表的主要問題是它們是通用的。這在降低性能的同時增加了便利性，而且還需要特殊的開發工具來調試這些庫在後台執行的複雜操作。

使用這些庫並理解它們的作用是可以的，而且不管UI框架的選擇如何，它們都是有用的，但是使用替代方法可能不會更複雜，而且它可能會防止在嘗試運行自己的模型時發生的一些陷阱。

ChaCha—也被稱為變更通道—是一個雙向流，其目的是通知意圖方向和觀察方向的變更。

ChaCha的接口通常可以從應用的規範中派生出來，而不需要任何UI代碼。

例如，一個應用程序允許你添加和刪除聯繫人，並從服務器加載初始列表(帶有刷新選項)，它可以有這樣一個ChaCha:

注意，這兩個接口中的所有函數都是void，並且只接收普通對象。這是故意的。ChaCha構建起來就像一個有兩個端口的通道來發送消息，這允許它在EventSource、HTML MessageChannel、service worker或任何其他協議中工作。

ChaChas的優點是易於測試:您發送動作並期待特定的調用返回給觀察者。

HTML模板是存在於DOM中但不被顯示的特殊元素。它們的目的是生成動態元素。

當我們使用模板元素時，我們可以避免所有創建元素並在JavaScript中填充它們的樣板代碼。

下面將使用模板將一個名字添加到列表中:

通過使用列表項的模板元素，我們可以在原始HTML中看到列表項——它不是用JSX或其他語言「呈現」的。你的HTML文件現在包含了應用程序的所有HTML -靜態部分是渲染DOM的一部分，動態部分在模板中表示，準備在時機成熟時被克隆和追加到文檔中。

TodoMVC[8]是一個TODO列表的應用規範，用於展示不同的框架。TodoMVC模板附帶了現成的HTML和CSS，以幫助您專注於框架。

你可以在GitHub庫中使用結果[9]，完整的源代碼[10]是可用的。

我們將從規範[11]開始，並使用它來構建ChaCha接口:

任務模型中的功能直接從規範和用戶可以做的事情中派生出來(清除已完成的任務，將所有任務標記為已完成或活動，獲得活動和已完成的計數)。

請注意，它遵循ChaCha的指導原則:

接下來，我將使用TodoMVC模板，並將其修改為面向表單的—表單的層次結構，輸入和輸出元素表示可以用JavaScript更改的數據。

我如何知道是否需要一個表單元素?根據經驗，如果它綁定到模型中的數據，那麼它應該是一個表單元素。

完整的HTML代碼[12]是可用的，但這裡是它的主要部分:

本HTML包括以下內容:

這個HTML不知道它將如何被樣式化，也不知道它將綁定到什麼數據。讓CSS和JavaScript為HTML工作，而不是讓HTML為特定的樣式機制工作。這將使更改設計變得更加容易。

現在我們在CSS中有了大部分的反應性，並且在模型中有了列表處理，剩下的就是Controller代碼——將所有東西連接在一起的管道膠帶。在這個小應用程序中，Controller JavaScript[14]大約有40行代碼。

下面是一個版本，並對每個部分進行了解釋:

在上面的代碼中，我們創建了一個新模型。

當一個項目被添加到模型中時，我們會在UI中創建相應的列表項目。

在上面，我們克隆了條目模板的內容，為特定的條目分配了事件監聽器，並將新條目添加到列表中。

請注意，這個函數，連同onUpdate、onRemove和onCountChange，都是從模型[15]中調用的回調函數。

當一個項目被更新時，我們設置它的complete和title值，然後失去焦點(退出編輯模式)。

當一個項目從模型中移除時，我們從視圖中移除它對應的列表項目。

在上面的代碼中，當完成或活動項目的數量發生變化時，我們設置適當的輸入來觸發CSS反應，並格式化顯示計數的輸出。

然後我們從哈希片段(以及在啟動時)更新過濾器。上面我們所做的一切只是設置一個表單元素的值——CSS處理其餘的事情。

這裡，我們確保表單提交時不會重新加載頁面。就是這條線把這個應用變成了SPA中心。

這將處理主要操作(創建、標記全部、清除完成)。

您可以查看完整的CSS代碼[16]。

CSS處理規範中的很多要求(為了便於訪問，還做了一些修改)。讓我們看一些例子。

根據規範，「X」(摧毀)按鈕只在懸停時顯示。我還添加了一個可訪問性位，使其在任務集中時可見:

當過濾器鏈接是當前鏈接時，它會得到一個紅色的邊框:

注意，我們可以使用link元素的href作為部分屬性選擇器——不需要JavaScript檢查當前的過濾器，並在適當的元素上設置一個選定的類。

我們還使用:target選擇器，這使我們不必擔心是否要添加過濾器。

標題輸入的視圖和編輯樣式會根據其只讀模式而改變:

篩選(即只顯示活動的和已完成的任務)是通過選擇器來完成的:

上面的代碼可能看起來有點冗長，使用CSS預處理器(如Sass)可能更容易閱讀。但是它所做的事情很簡單:如果過濾器是活動的，完成的複選框被選中，或者反之亦然，那麼我們隱藏複選框和它的兄弟元素。

我選擇在CSS中實現這個簡單的過濾器，以顯示它能走多遠，但如果它開始變得複雜，那麼它將完全有意義的移動到模型中。

我相信框架為實現複雜的任務提供了方便的方法，而且除了技術方面的好處，比如讓一組開發人員遵循特定的風格和模式。web平台提供了許多選擇，採用框架可以讓每個人至少部分地在某些選擇上站在同一頁上。這是有價值的。另外，聲明式編程的優雅也有值得說明的地方，而組件化的主要特性並不是本文討論的內容。

但是請記住，存在替代模式，通常成本更低，並不總是需要更少的開發人員經驗。允許自己對這些模式感到好奇，即使您決定在使用框架時從中挑選。

再次感謝各位同儕的文章勘校工作:Yehonatan Daniv, Tom Bigelajzen, Benjamin Greenbaum, Nick Ribal, Louis Lazaris。