Categories
程式開發

2020年前端框架性能對比和評測


我們又來做這個對比了。這次是 2020 年的版本,還有之前的版本:2019 年2018 年2017 年

先來明確一點——這篇文章絕對不是為了告訴你該選擇哪個前端框架而寫的。它只是一個小型而相對簡單的評測,對比三個指標:以基本相同的應用程序為基礎,評價不同框架製作出來的應用的性能、應用大小和代碼行數。

記住這一點後,我們來看具體的評測方法:

  • 我們對比的基礎是 RealWorld 應用——這款應用不是簡單的待辦事項(to do)應用而已。常見的待辦事項應用無法為實際的應用程序構建提供足夠的知識和觀點參考。

  • 它在某種程度上是標準化的——這是一個符合特定規則的項目,有一套規範。項目還提供了後端 API、靜態標記和样式。

  • 它是由一位專家編寫或審查的——這是一個一致的,真實世界的項目,其構建或審查工作有專家的參與。

我們要對比哪些庫 / 框架?

在撰寫本文時,在 RealWorld 存儲庫中有 24 種 Conduit 實現。框架是否流行並不重要。唯一的參評條件是——它出現在 RealWorld 倉庫頁面上。

2020年前端框架性能對比和評測 1

我們對比哪些指標?

  • 性能——這款應用需要多長時間才能顯示內容並處於可用狀態?

  • 大小——這款應用有多大?我們只會對比已編譯的 JavaScript 文件的大小。 HTML 和 CSS 對所有變體都是通用的,並且是從 CDN(內容交付網絡)下載的。所有技術都可以編譯或轉譯為 JavaScript,因此我們只看這個文件的大小。

  • 代碼行數——作者需要多少行代碼才能基於規範創建出 RealWorld 應用?公平地講,某些框架做出來的應用是有很多花邊內容,但應該不會有什麼重大影響。我們要量化的唯一文件夾是每個應用中的 src/。無論它是否是自動生成的都沒關係——反正你都需要維護它的。

指標 1:性能

我們會檢查 Chrome 隨附的 Lighthouse Audit 的性能分數。 Lighthouse 返回的性能分數在 0 到 100 之間。 0 是最低的。更多詳細信息,請參閱《Lighthouse 計分指南》

測試設置

2020年前端框架性能對比和評測 2

基本原理

內容繪製得越快,用戶就能越早開始做事,應用的使用體驗就會越好。

2020年前端框架性能對比和評測 3

性能(0-100 點)——越高越好

注意:由於缺少演示應用,因此跳過了 PureScript。

結論

Lighthouse Audit 不會說謊。你可以看到在今年未維護 / 未更新的框架做出來的應用跌破 90 分大關。如果你的應用得分超過 90,表現應該不會有太大區別。具體來說,AppRun、Elm 和 Svelte 確實令人印象深刻。

指標 2:大小

傳輸大小數據來自 Chrome 的網絡標籤。服務器提供 GZIP 壓縮後的響應標頭以及響應正文。

這裡的表現取決於框架的大小以及它添加的其他依賴項的多少。還能看出構建工具能否很好地去掉包中未使用的代碼。

基本原理

文件越小,下載速度越快,並且需要解析的內容也更少。

2020年前端框架性能對比和評測 4

傳輸大小(KB)——越少越好

備註:由於缺少演示應用,因此跳過了 PureScript。

Angular+ngrx+nx:Angular+ngrx+nx 這裡不要怪我看錯了,請檢查 Chrome 開發工具網絡標籤,如果我算錯了請告訴我。

Rust+Yew+WebAssembly 還包括.wasm 文件

結論

Svelte 和 Stencil 社區所做的令人印象深刻的工作,將它們的應用體積壓縮到了 20KB 以下,這確實是一項成就。

指標 3:代碼行數

使用 cloc,我們可以計算每個存儲庫的 src 文件夾中的代碼行數。空白行和註釋行在這裡都不算。為什麼要考慮這個指標呢?

如果調試是消除軟件錯誤的過程,那麼編程肯定就是把錯誤放入軟件的過程。 ——EdsgerDijkstra

基本原理

這個指標說明了給定庫 / 框架 / 語言的簡潔程度。也就是說根據規範,你需要多少行代碼才能實現幾乎相同的應用(其中一些有更多的花邊部分)。

2020年前端框架性能對比和評測 5

代碼行數——越少越好

備註:由於 cloc 無法處理.svelte 文件,因此 Svelte 被跳過。

由於 cloc 無法處理.riot 文件,因此跳過了 riotjs-effector-universal-hot。

Angular+ngrx:使用 /libs 文件夾完成的 LoC 計算僅包括.ts 和.html 文件。如果你認為這是錯誤的方法,請告訴我正確的數字應該是多少,以及如何計算它。

結論

只有 Imba 和帶 re-frame 的 ClojureScript 才能在 1000 行代碼內實現這個應用。 Clojure 以非同一般的表達方式而著稱。 Imba 第一次出現在這裡(去年的時候 cloc 無法分析.imba 文件格式),看起來它的地位會持續下去。如果你關心自己的 LoC,那麼看到這裡你就該知道選什麼了。

總結

請記住,這並不是完全公平的對比。有些實現使用了代碼拆分,有些則沒有。其中有些託管在 GitHub 上,有些託管在 Now 上,還有些託管在 Netlify 上。你還是想知道哪一個框架最好?這個問題就留給你自己來思考吧。

常見問題

1. 為什麼評測中不包含框架 X,Y 和 Z?

因為在 RealWorld 倉庫中尚未完成實現。你可以考慮做出貢獻!用你喜歡的庫 / 框架實現這個方案,我們下次將測試它的!

2. 你為什麼叫它”真實世界”?

因為它不只是一個待辦事項應用。在 RealWorld 中,我們並不是要對比薪水、維護、生產力和學習曲線等。其他一些調查可以回答其中的一些問題。我們所說的 RealWorld 是一個連接到服務器,進行身份驗證並允許用戶 CRUD 的應用程序,就像真實世界中的應用程序一樣。

3. 你為什麼不測試我最喜歡的框架?

請參見上面的 #1,但以防萬一再提一句:因為在 RealWorld 存儲庫中該實現尚未完成。我並沒有完成所有的實現——這需要社區的努力。如果你想在對比中看到你的框架,請考慮做出貢獻。

4. 你測試的是哪個版本的庫 / 框架?

在撰寫本文時(2020 年 3 月)可用的版本。這裡的信息來自 RealWorld 倉庫。你可以在 GitHub 存儲庫中找到相關數據。

5. 為什麼你忘了測試一個比較流行的框架?

同樣,請參閱 #1 和 #3。在 RealWorld 存儲庫中該實現尚未完成,就這麼簡單。

英文原文

A Realworld Comparison of Front End Framworks 2020