?作者 ｜ shuan feng，攜程高級前端開發工程師，關注性能優化、低代碼、svelte等領域。

一、技術調研

最近幾年，前端框架層出不窮。近兩年，前端圈又出了一個新寵：Svelte?。作者是 Rich Harris?，也就是 Ractive?, Rollup? 和 Buble的作者，前端界的“輪子哥”。

通過靜態編譯減少框架運行時的代碼量。一個 Svelte 組件編譯之后，所有需要的運行時代碼都包含在里面了，除了引入這個組件本身，你不需要再額外引入一個所謂的框架運行時！

在Github上擁有 5w 多的 star！

在最新的State of JS 2021和Stack Overflow Survey 2021的排名情況中，也一定程度上反映了它的火熱程度。

在早前知乎的如何看待 svelte 這個前端框架？問題下面，Vue的作者尤雨溪也對其做出了極高的評價：

去它的官網看一下：

官網上清楚的表明了三大特性：

• Write less code
• No virtual DOM
• Truly reactive

1.1 Write less code

顧名思義，是指實現相同的功能，Svelte的代碼最少。這一點會在后面的示例中有所體現。

1.2 No virtual DOM

Svelte?的實現沒有利用虛擬DOM?，要知道Vue和React?的實現都是利用了虛擬DOM?的，而且虛擬DOM不是一直都很高效的嗎？

Virtual DOM 不是一直都很高效的嗎？

其實 Virtual DOM?高效是一個誤解。說 Virtual DOM? 高效的一個理由就是它不會直接操作原生的 DOM? 節點，因為這個很消耗性能。當組件狀態變化時，它會通過某些 diff? 算法去計算出本次數據更新真實的視圖變化，然后只改變需要改變?的 DOM 節點。

用過 React? 的同學可能都會體會到 React? 并沒有想象中那么高效，框架有時候會做很多無用功，這體現在很多組件會被“無緣無故”進行重渲染（re-render?）。所謂的 re-render? 是你定義的 class Component? 的 render 方法被重新執行，或者你的組件函數被重新執行。

組件被重渲染是因為 Vitual DOM? 的高效是建立在 diff? 算法上的，而要有 diff? 一定要將組件重渲染才能知道組件的新狀態和舊狀態有沒有發生改變，從而才能計算出哪些 DOM 需要被更新。

正是因為框架本身很難避免無用的渲染，React? 才允許你使用一些諸如 shouldComponentUpdate，PureComponent? 和 useMemo? 的 API 去告訴框架哪些組件不需要被重渲染，可是這也就引入了很多模板代碼。

那么如何解決 Vitual DOM? 算法低效的問題呢？最有效的解決方案就是不用 Virtual DOM！

1.3 Truly reactive

第三點真正的響應式?，上面也提到了前端框架要解決的首要問題就是：當數據發生改變的時候相應的 DOM? 節點會被更新，這個就是reactive。

我們先來看下Vue和React分別是如何實現響應式的。

React reactive

通過useState?定義countdown?變量，在useEffect?中通過setInterval使其每秒減一，然后在視圖同步更新。這背后實現的原理是什么呢？

React? 開發者使用 JSX? 語法來編寫代碼，JSX? 會被編譯成 ReactElement?，運行時生成抽象的 Virtual DOM。

然后在每次重新 render? 時，React? 會重新對比前后兩次 Virtual DOM?，如果不需要更新則不作任何處理；如果只是 HTML? 屬性變更，那反映到 DOM? 節點上就是調用該節點的 setAttribute? 方法；如果是 DOM? 類型變更、key? 變了或者是在新的 Virtual DOM? 中找不到，則會執行相應的刪除/新增 DOM 操作。

Vue reactive

用Vue?實現同樣的功能。Vue背后又是如何實現響應式的呢？

大致過程是編譯過程中收集依賴，基于 Proxy?（3.x) ，defineProperty?(2.x) 的 getter，setter? 實現在數據變更時通知 Watcher。

像Vue和React這種實現響應式的方式會帶來什么問題呢？

1. diff 機制為 runtime 帶來負擔
2. 開發者需自行優化性能

• useMemo
• useCallback
• React.memo
•  ...

那么Svelte又是如何實現響應式的呢？

Svelte reactive

其實作為一個框架要解決的問題是當數據發生改變的時候相應的 DOM? 節點會被更新（reactive?），Virtual DOM? 需要比較新老組件的狀態才能達到這個目的，而更加高效的辦法其實是數據變化的時候直接更新對應的 DOM 節點。

這就是Svelte?采用的辦法。Svelte?會在代碼編譯的時候將每一個狀態的改變轉換為對應DOM?節點的操作，從而在組件狀態變化的時候快速高效地對DOM節點進行更新。

深入了解后，發現它是采用了 Compiler-as-framework? 的理念，將框架的概念放在編譯時而不是運行時。你編寫的應用代碼在用諸如 Webpack? 或 Rollup? 等工具打包的時候會被直接轉換為 JavaScript? 對 DOM? 節點的原生操作，從而讓 bundle.js? 不包含框架的 runtime。

那么 Svelte? 到底可以將 bundle size? 減少多少呢？以下是 RealWorld? 這個項目的統計：

由上面的圖表可以看出實現相同功能的應用，Svelte的bundle size?大小是Vue的1/4?，是React的1/20?！單純從這個數據來看，Svelte?這個框架對bundle size的優化真的很大。

看到這么強有力的數據支撐，不得不說真的很動心了！

二、項目落地

為了驗證Svelte?在營銷 h5 落地的可能，我們選擇了口罩機項目：

上圖是口罩機項目的設計稿，不難看出，核心邏輯不是很復雜，這也是我們選用它作為Svelte嘗試的原因。

首先項目的基礎結構是基于svelte-webpack-starter創建的，集成了TypeScript、SCSS、Babel?以及Webpack5?。但這個基礎模板都只進行了簡單的支持，像項目中用到的一些圖片、字體等需要單獨使用loader去處理。

啟動項目，熟悉的hello world：

這里看下核心的

當然開發環境使用?webpack?有時不得不說體驗不太好，每次都要好幾秒，我們就用Vite?來替代了，基本都是秒開：

Vite的配置也比較簡單：

2.1 組件結構差異

和 React? 組件不同的是，Svelte? 的代碼更像是以前我們在寫 HTML、CSS? 和 JavaScript?時一樣（這點和Vue很像）。

所有的 JavaScript? 代碼都位于 Svelte? 文件頂部的 <script></script>? 標簽當中。然后是 HTML? 代碼，你還可以在 <style></style>? 標簽中編寫樣式代碼。組件中的樣式代碼只對當前組件有效。這意味著在組件中為 <div>? 標簽編寫的樣式不會影響到其他組件中的 <div> 元素。

2.2 生命周期

Svelte? 組件的生命周期有不少，主要用到的還是 onMount?、 onDestoy、beforeUpdate、afterUpdate，onMount? 的設計和 useEffect? 的設計差不多，如果返回一個函數，返回的函數將會在組件銷毀后執行，和 onDestoy 一樣：

2.3 初始狀態

接下來是對初始狀態的定義：

我們發現代碼在對變量更新的時候并沒有使用類似React的setState?方法, 而是直接對變量進行了賦值操作。僅僅是對變量進行了賦值就可以引發視圖的變化, 很顯然是數據響應的, 這也正是Svelte的truly reactive的體現。

2.4 條件判斷

項目中使用了很多的條件判斷，React?由于使用了JSX?，所以可以直接使用JS?中的條件控制語句，而模板是需要單獨設計條件控制語法的。比如Vue?中使用了v-if。

Svelte?中則是采用了{#if conditions}、{:else if}、{/if}?，屬于Svelte?對于HTML的增強。

上面代碼中有這么一行：

$: buttonText = isTextShown ? 'Show less' : 'Show more'

buttonText?依賴了變量isTextShown?，依賴項變更時觸發運算，類似Vue?中的computed?，這里的Svelte?使用了$:?關鍵字來聲明computed變量。

這又是什么黑科技呢？這里使用的是 Statements and declarations? 語法，冒號:前可以是任意合法變量字符。

2.5 數據雙向綁定

項目中有很多地方需要實現雙向綁定?。我們知道React?是單向數據流，所以要手動去觸發變量更新。而Svelte和Vue都是雙向數據流。

Svelte?通過bind?關鍵字來完成類似v-model的雙向綁定。

2.6 列表循環

項目中同樣使用了很多列表循環渲染。Svelte?使用 {#each items as item}{/each}? 來實現列表循環渲染，這里的item?可以通過解構賦值，拿到item里面的值。

不得不說有點像ejs

2.7 父子屬性傳遞

父子屬性傳遞時，不同于React?中的props，Svelte? 使用 export? 關鍵字將變量聲明標記為屬性，export? 并不是傳統 ES6 的那個導出，而是一種語法糖寫法。

注意只有 export let 才是聲明屬性

2.8 跨組件通訊（狀態管理）

既然提到了父子組件通訊，那就不得不提跨組件通訊?，或者是狀態管理?。這也一直是前端框架中比較關注的部分，Svelte? 框架中自己實現了 store?，無需安裝單獨的狀態管理庫。你可以定義一個 writable store, 然后在不同的組件之間進行讀取和更新：

每個 writable store? 其實是一個 object?, 在需要用到這個值的組件里可以 subscribe? 他的變化，然后更新到自己組件里的狀態。在另一個組件里可以調用 set和update 更新這個狀態的值。

2.9 路由

Svelte 目前沒有提供官方路由組件，不過可以在社區中找到：

• svelte-routing
• svelte-spa-router

svelte-routing和react-router-dom 的使用方式很像：

而svelte-spa-router?更像vue-router一點：

2.10 UI

項目中也用到了組件庫，通常react?項目一般都會采用NFES UI?，但畢竟是react component?，在Svelte?中并不適用。我們嘗試在社區中尋找合適的Svelte UI?庫，查看了Svelte Material UI、Carbon Components Svelte等，但都不能完全滿足我們的需求，只能自己去重寫了（只用到了幾個組件，重寫成本不算很大）。

2.11 單元測試

單元測試用的是@testing-library/svelte：

基本用法和React是很類似的。

業務代碼遷移完畢，接著就是對原有功能case的逐一驗證。

為了驗證單單使用Svelte?進行開發的效果，我們沒有進行其他的優化，發布了一版只包含Svelte?的代碼到產線，來看下bundle size?（未做gzip?前）和lighthouse?評分情況：

除此之外，我們遵循lighthouse?給出的改進建議，對Performance、Accessibility和SEO做了更進一步的優化改進：

Performance?的提升主要得益于圖片格式支持webp?以及一些資源的延遲加載，Accessibility和SEO?的提升主要是對meta標簽的調整。

三、實踐總結

通過這次技改，我們對Svelte有了一些全新的認知。

整體來說，Svelte 繼前端三大框架之后推陳出新，以一種新的思路實現了響應式。

因其起步時間不算很長，國內使用程度仍然偏少，目前來說其生態還不夠完備。

但這不能掩蓋其優勢：足夠“輕”。Svelte?非常適合用來做活動頁，因為活動頁一般沒有很復雜的交互，以渲染和事件綁定為主。正如文章最開始說的，一個簡單的活動頁卻要用React?那么重?的框架多少有點委屈自己。所以對于一些營銷團隊，想在bundle size?上有較大的突破的話，Svelte是絕對可以作為你的備選方案的。

另外現在社區對于Svelte?還有一個很好的用法是使用它去做Web Component，好處也很明顯：

• 使用框架開發，更容易維護
• 無框架依賴，可實現跨框架使用
• 體積小

所以對于想實現跨框架組件復用的團隊，用Svelte?去做Web Component也是一個很好的選擇。