尤大親自評測 Vue3 和 Svelte(19個元件後Vue更好!)

程式設計師秋風發表於2021-07-12
Vue元件

本文已參與好文召集令活動，點選檢視：後端、大前端雙賽道投稿，2萬元獎池等你挑戰！

近日尤大親自建立了一個倉庫用來對 Svelte 和 Vue3 元件進行了評測。這其實對我來說非常的感興趣，因為我最近在業務專案中採用了 Svelte 進行了開發。

image-20210711185119613

那麼到底結果到底是如何呢？(期待的眼神，以為尤大要寫 Svelte 程式碼來進行評測了。

Vue 大家都很熟悉了，如果你不知道 Svelte 是啥？可以看後起之秀前端框架 Svelte 從入門到原理。

大體介紹一下，Svelte 是一個 No Runtime —— 無執行時程式碼 的框架。

下面是Jacek Schae大神的統計，使用市面上主流的框架，來編寫同樣的 Realword 應用的體積：

尤大親自評測 Vue3 和 Svelte(19個元件後Vue更好!)

下面就請看詳細的研究步驟，如果你對研究步驟不感興趣，可以直接跳到最後看結論。

研究的步驟

為了公平性，尤大選擇了 todomvc 來進行構建比較，然後列舉了一系列的步驟方案。

  1. 這兩個框架都實現了一個簡單的符合規範、功能相同的 todomvc 元件。

  2. 元件使用各自框架的線上 SFC 編譯器進行單獨編譯

  3. 編譯檔案使用 Terser REPL 壓縮，然後刪除 ES imports 和 exports。 這是因為在一個 bundle 的應用程式中，這些 imports/exports不需要或在多個元件之間共享。（可以理解為類似第三方程式碼，不會影響元件內部實現的大小）

    • Vue: todomvc.vue.min.js

    • Svelte: todomvc.svelte.min.js

  4. 然後把檔案使用gzip和brotli（Brotli是一個開源資料壓縮程式庫， 類似於 gzip ）壓縮

    • Vue: todomvc.vue.min.js.gz / todomvc.vue.min.js.brotli
    • Svelte: todomvc.svelte.min.js.gz / todomvc.svelte.min.js.brotli

  5. 另外，在 SSR 的環境下，Svelte 需要在 "hydratable" 模式下編譯其元件，這會引入額外的程式碼生成。 在編譯 Svelte 的時候使用選項 hydratable: true 來開啟 SSR 並重復 2-4 的步驟。

    Vue在 SSR 環境下生成的程式碼是完全相同的，但是引入了一些額外的 hydration-specific 執行時程式碼(~0.89kb min + brotli).

  6. 對於每個框架，預設使用 Vite 來建立和打包構建（Svelte 使用 hyderable: false）。 每個應用程式同時設定SSR的模式再構建一次。

預設 Vite 打包產生一個 vendor chunk（= 框架執行時程式碼）和一個 index chunk（= 元件程式碼）。

VueVue (SSR)SvelteSvelte (SSR)
Source3.93kb-3.31kb-
Compiled w/o imports (min)2.73kb-5.01kb (183.52%)6.59kb (241.39%)
Compiled w/o imports (min+gz)1.25kb-2.13kb (170.40%)2.68kb (214.40%)
Compiled w/o imports (min+brotli)1.10kb-1.88kb (170.91%)2.33kb (211.82%)
Vite component chunk (min+brotli)1.13kb-1.95kb (172.26%)2.41kb (213.27%)
Vite vendor chunk (min+brotli)16.89kb17.78kb1.85kb2.13kb

注意： w/o 的意思為 without ，"去除"的意思

尤大親自評測 Vue3 和 Svelte(19個元件後Vue更好!)

分析

在客戶端模式下，從 Vite vendor chunk (min+brotli) 這一欄分析 。 Svelte App 匯入1.85kb min+brotli 框架程式碼，比 Vue 輕15.04kb。這似乎看起來非常的強悍，但是這是因為框架執行時的差異。(Svelte 沒有執行時，Vue有執行時)

再來看看元件程式碼，Svelte 的 min + compressed 輸出大小是Vue的1.7倍。在這種情況下，單個元件會導致0.78kb的大小差異。在 SSR 的情況下，這一比例進一步上升到2.1倍，其中單個組分導致 1.23kb 大小的差異。

Todomvc 非常具有代表性，代表大多數使用者在應用場景中構建使用的元件。 我們可以合理地假設在現實場景中會發現類似的大小差異。 也就是說，在理論上，如果一個應用程式包含超過15.04 / 0.78〜= 19個 Todomvc 大小的元件，則 Svelte 應用程式將最終比Vue應用程式體積更大。

在 SSR 場景中，這個閾值會更低。 在 SSR 模式下，雖然框架差異為15.65KB，但是 Compnent Count 閾值下降到 15.65 / 1.23〜= 13！

顯然在真實世界應用程式中，有許多其他因素：將從框架中匯入更多功能，並將使用第三方庫。 大小曲線將受到專案中純元件程式碼的百分比的影響。 但是，保守估計 應用 APP 如果比 19個元件 這個閾值（或者在SSR模式下的13個 ）越大，Svelte 的體積優勢就越少。

結論

在倉庫的README中尤大給出了兩個結論，我就給它移到了最後。

  • Svelte 單元件在普通模式下比 Vue3 單元件約大70% ，在 SSR 模式下大110% （公眾號作者秋風注：其實這裡尤大說的有點問題，這個70%指的是當前 todomvc 元件的大小對比，並不代表著所有 Svelte 元件 比 vue 3 元件 大 70%， 換句話說如果一個 100k 大小的 Vue 元件，Svelte元件可能就只有 101k，而不是170k !）
  • 對於專案來說，當編寫的元件大於19個元件（SSR模式為 13個元件）Svelte 的優勢與 Vue3 相比就不存在了。

總的來說

本研究並的目的不是來說哪種框架更好 —— 它關注的是分析不同框架的策略對體積大小的影響。

從資料中可以看出，兩個框架在 bundle 大小方面具有不同的優勢 —— 取決於您的使用情況。 Svelte 仍然很棒，適用於一次性元件（例如，作為自定義元素包裝），但它在大規模 APP 中在體積大小方面實際上是它的缺點，特別是SSR。

在更廣泛的意義上，本研究旨在展示框架如何在compile-time 編譯時和 runtime spectrum 執行時找到一個平衡點：Vue 在原始碼上使用了一定的 compile-time 編譯時 優化，但選擇較重的 compile-time 返回較小的生成程式碼。 Svelte選擇最小的執行時，但具有較重生成的程式碼的成本。 Svelte 可以進一步改進其程式碼生成來降低程式碼輸出嗎？ Vue可以進一步改善tree-shaking，使基線(執行時框架)變小嗎？ 另外一點框架可以找到更好的平衡點嗎？ 對以上所有的問題的答案回答可能是肯定的 —— 但現在我們需要明確的是"框架大小"是比單單比較 Hello World 應用程式的大小的更加細緻的話題，這項研究就是為了證明這一點。

個人意見

以下為公眾號作者的個人意見，並非尤大調研中的觀點。

其實尤大總體來說就是想要凸顯出在框架的對比中，單單使用 Jacek Schae大神 統計的 那個 RealWord 應用程式來說是有些不公平的，應該需要更加細緻的對比。其實對於 Svelte 這個包大小這個問題，其實很早之前在 Svelte Github 中也對 React 和 Svelte 進行了廣泛的討論。

Inflection Point

Svelte 確實有一個閾值會使得它在一定程度後讓體積大小沒有了優勢，但是在一般情況下，只要不是特別複雜的中後臺管理應用，Svelte 應當會比其他框架體積小。

特別是在一些 H5 遊戲中，如果你想要獲得 React/Vue 資料驅動的方式編寫應用，但是你又不想要引入他們這麼大的執行時，確實來說是一個非常不錯的方案。最近在開發一個基於 Three.js 的移動端網頁，有一個初步的估計大約比使用 React 減少 30 - 50% 的體積，具體的數值因為還沒遷移完無法給出完整的資料。還有一點，非執行時的框架，對於首屏的渲染也是有一個極大的幫助，你可以將首屏元件進行拆分，非執行時的首屏元件其實是非常小的，這對移動端來說非常的友好，因為畢竟使用 SSR 對應服務端還是有一定的壓力要求的。

以上為個人看完尤大的分析比較後的一點愚見~ 如果不足之處請多多指出。

調研原文

github.com/yyx990803/v…

回看筆者往期高贊文章，也許能收穫更多喔！

結語

❤️關注+點贊+收藏+評論+轉發❤️，原創不易，鼓勵筆者創作更好的文章

關注公眾號秋風的筆記，一個專注於前端面試、工程化、開源的前端公眾號

相關文章