前端框架對比及評測

LeanCloud 受權轉載，原文連接：A RealWorld Comparison of Front-End Frameworks with Benchmarks。

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

• RealWorld 應用

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

• 標準化

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

• 專業人士編寫、審閱

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

比較的庫和框架

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

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

測度

性能

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

尺寸

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

代碼行數

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

性能

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

配置

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

性能評分基於如下測度得出：

• First Contentful Paint （頁面中內容元素首次渲染時間）
• First Meaningful Paint （頁面中有意義的內容元素首次渲染時間）
• Speed Index （頁面加載過程視覺上的變化速度）
• First CPU Idle （到 CPU 首次空閒的時間）
• Time to Interactive （到頁面可交互的時間）
• Estimated Input Latency （預計輸入延遲）

詳見 Lighthouse 評分指南。

TL;DR

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

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

結論

大部分應用的評分超過 90。因此，用戶大概感受不到這些框架的性能有什麼大差異。

尺寸

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

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

TL;DR

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

結論

這方面有很多驚人的結果。Svelte，魔法消失 UI 框架，無愧其名。Stencil 是一個比較新的框架，表現優異。這兩個框架相對而言都比較新，將尺寸推向了新的極限。

代碼行數

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

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

Edsger Dijkstra

TL;DR

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

注意：咱們跳過了 Imba，由於 cloc 沒法處理 .imba 文件。Elm 開發者寫代碼喜歡分行，因此行數較多（至少別人是這麼告訴個人）。Angular+ngrx 只計算了 libs 目錄中的 .ts 和 .html 文件，若是你認爲這麼算不對，請告訴我正確的數字及其計算方法。本文剛發表時 Hyperapp 的代碼行數計算有誤，感謝 Mateusz Kwasniewski 指出正確的代碼行數。

結論

就代碼行數而言，使用 ClojureScript 的 re-frame 給出了炸裂💥的結果。Clojure 以異常高的表達力而聞名。若是你在意代碼行數，應該瞭解下 ClojureScript、AppRun、Svelte。

總結

別忘了這並非一個精確公平的對比。有些實現分離了代碼，有些沒有。有些部署在 GitHub 上，有些部署在 Now 上，有些部署在 Netlify 上。若是你仍然要問哪一個最好？我只能說，最好的框架是最符合你需求的那個。

Q: 偏心強類型檢查？ A: 瞭解下 Elm、PureScript、TypeScript —— Angular、AppRun、Dojo.

Q: 想要一個很是輕量的框架？ A: 瞭解下 Svelte、Stencil、AppRun.

Q: 想維護儘量少的代碼？ A: 瞭解下 re-frame（使用 ClojureScript）、AppRun、Svelte.

Q: 想要學點新的？ A: 選擇你不瞭解的框架！

FAQ

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

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

2. 爲何稱它爲 RealWorld？

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

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

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

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

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

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

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

感謝 Rich Harris 和 Richard Feldman 在發表前審閱本文。

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

譯者注：實現上的種種差別（好比 Vue 是否搭配 Vuex）及其餘因素對結果會有很大影響，所以圖表僅供參考，並不能準確地體現框架的高下。何況，框架的選型涉及衆多因素，大多數場景下，有許多因素的權重遠高於性能、尺寸、代碼行數。因此，正如原文所說，最好的框架是最符合需求的那個。