鑽石舞台

一、技術調研

最近幾年，前端框架層出不窮。近兩年，前端圈又出了一個新寵：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這種實現響應式的方式會帶來什麼問題呢？

•diff機制為runtime帶來負擔

•開發者需自行優化性能

•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大小是Vue的1/4，是React的1/20！單純從這個數據來看，Svelte這個框架對bundle size的優化真的很大。

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

二、項目落地

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

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

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

這裡看下核心的webpack配置：

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?'Showless':'Showmore'

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的逐一驗證。

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

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

三、實踐總結

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

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

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

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

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

•使用框架開發，更容易維護

•無框架依賴，可實現跨框架使用

•體積小

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

參考鏈接

svelte、react、vue對比

https://joshcollinsworth.com/blog/introducing-svelte-comparing-with-react-vue

你還沒有聽過svelte嗎？

https://developpaper.com/you-havent-heard-of-sveltejs-yet/

如何看待 svelte 這個前端框架？

https://www.zhihu.com/question/53150351

創作不易，加個點讚、在看支持一下哦！