2020 前端框架對比評測

[Jacek Schae] 原做，受權 LeanCloud 翻譯。

又到了評測前端框架的季節。咱們在 [2017]、[2018]、[2019] 年都作了評測，今年（2020 年）是第四次評測。

首先申明，這個評測絕對沒有欽定你下個項目該用哪一個框架的意思。這只是一個小小的、相對簡單的評測，只基於類似的應用比較框架的性能、尺寸、代碼行數。

咱們將基於 RealWorld 示例應用對比前端框架。RealWorld 示例應用的特色：

• RealWorld 應用

  比待辦事項類應用更復雜。一般待辦事項類應用不足以傳達足夠多的知識看法構建實際應用。

• 標準化

  項目遵循特定規則。提供後端 API、靜態標記語言、風格、API 規範。

• 專業人士編寫、審閱

  理想狀況下，會是高一致性、高真實度的項目，由使用該技術的專業人士編寫或審閱。

比較的庫和框架

撰寫本文時，RealWorld 示例應用倉庫共包括 24 個 Conduit （Medium.com 克隆應用）實現。

本文不考慮框架的流行程度，RealWorld 倉庫中列出的前端框架皆歸入對比範圍。

測度

性能

應用顯示內容、可使用須要花多久？

尺寸

應用有多大？咱們只比較編譯後的 JavaScript 文件大小。全部應用使用一樣的 CSS 樣式文件，CSS 文件加載自 CDN。全部應用使用的 HTML 也是同樣的。這些框架都支持編譯或轉換爲 JavaScript，因此咱們僅僅測量 JavaScript 文件大小。

代碼行數

根據規範建立 RealWorld 應用須要多少行代碼？公平地說，某些實現的功能要略微多一點，但這應該沒有什麼顯著的影響。咱們僅僅測量每一個應用的 src/ 目錄。

性能

咱們將使用 Chrome 的 [Lighthouse Audit] 測試性能。Lighthouse 返回 0 至 100 間的評分。0 爲最低分。詳見Lighthouse 評分指南。

配置

全部測試均使用以下配置：

理據

首次渲染越快，到能夠進行操做的時間越短，應用的用戶體驗就越好。

附註

咱們跳過了 PureScript，由於它沒有 Demo 應用。

結論

Lighthouse Audit 並無停滯不前。你也許注意到了，在今年的評測中，一些沒有維護更新的項目得分低於 90。若是你的應用得分超過 90，那麼幾分的差別基本不影響用戶體驗。話是這麼說，AppRun、Elm、[Svelte] 的表現讓人印象深入。

尺寸

傳輸尺寸根據 Chrome 開發者工具的網絡標籤頁統計，包括服務器送達的響應頭和響應體（通過 GZIP 壓縮）。

這取決於框架的尺寸以及額外依賴的尺寸，還有構建工具精簡未使用代碼的效率。

理據

文件越小，下載越快，須要解析的內容越少。（下圖中的單位爲 KB。）

附註

咱們跳過了 PureScript，由於它沒有 Demo 應用。

請別抱怨 Angular + ngrx + nx 的結果不對勁，你能夠自行打開 Chrome 開發者工具 驗證。若是發現我犯錯，請告訴我。

計算 Rust + Yew + WebAssembly 的尺寸時包括了 .wasm 文件。

結論

[Svelte] 和 Stencil 社區作得很好，把尺寸控制在 20 KB 之內，了不得。

代碼行數

咱們使用 [cloc] 計算每一個倉庫的 src 目錄的代碼行數，不計空行和註釋。爲何要比較代碼行數？這是由於：

若是說調試是移除軟件 bug 的過程，那麼編程必定是植入 bug 的過程。

Edsger Dijkstra

理據

下面的圖表顯示了給定的庫/框架/語言有多凝練。根據規範實現幾乎徹底同樣的應用（某些應用功能略多一點）須要多少行代碼。

附註：

本文剛發表時沒有 Svelte 的數據，感謝 [Svelte master] 提供計算 Svelte 項目代碼行數的方法。

咱們跳過了 riotjs-effector-universal-hot，由於 [cloc] 沒法處理 .riot 文件。

Angular+ngrx 只計算了 libs 目錄中的 .ts 和 .html 文件，若是你認爲這麼算不對，請告訴我正確的數字及其計算方法。

結論

就代碼行數而言，只有 Imba 和 ClojureScript + re-frame 作到了用 1000 行代碼實現應用。Clojure 以異常高的表達力而聞名。Imba 是今年評測中新加入的（去年的評測沒有包括 Imba，由於 cloc 當時不能處理 .imba 文件格式）。若是你在意代碼行數，你知道要選哪些框架。

總結

別忘了這並非一個精確公平的對比。有些實現分離了代碼，有些沒有。有些部署在 GitHub 上，有些部署在 Now 上，有些部署在 Netlify 上。若是你仍然要問哪一個最好？你須要本身回答這個問題。

FAQ

1. 爲何不對比框架 X、Y、Z？

由於 RealWorld 倉庫 中的實現不完整。考慮下貢獻代碼！用你最喜歡的庫/框架實現一下，咱們會在下次對比中包含它們！

2. 爲何稱它爲 RealWorld？

由於它的功能要比 To-Do 應用複雜。RealWorld 並不意味着咱們會對比薪資水平、維護水平、生產率、學習曲線等要素，有其餘調研回答了這些問題中的一部分。RealWorld 的意思是這個應用會像真實世界項目同樣，鏈接一個服務器，認證用戶，容許用戶增刪改查。

3. 你爲何沒歸入我最喜歡的框架？

請回過頭去看看上文的第一問。不過我這裏仍是想強調下：由於 RealWorld 倉庫 中的實現不完整。這些實現是社區共同努力的結果，而非我一人所爲。若是你想在對比中看到本身最喜歡的框架，考慮下貢獻代碼。

4. 對比的是哪一個版本的庫/框架？

本文撰寫時（2020 年 3 月）可用的版本。詳見 RealWorld 倉庫。

5. 爲何沒有對比某個流行得多的框架？

再一次，看看前面的問題。很簡單，RealWorld 倉庫 中的實現不完整。

若是你喜歡這篇文章，能夠在 Twitter 上關注我。我只發編程、技術方面的推。

譯者注：實現上的種種差別及其餘因素對結果會有很大影響，所以圖表僅供參考，並不能準確地體現框架的高下。何況，框架的選型涉及衆多因素，大多數場景下，有許多因素的權重遠高於性能、尺寸、代碼行數。最好的框架是哪一個，每一個人可能有不一樣的答案。