我們再做一次。 這是2020年，還有2019年，2018年和2017年。
首先讓我開始-絕對不是您應該為前端選擇的比較。 它是對三個方面的比較小而相對簡單的：性能，大小和非常相似的應用程序的代碼行。
考慮到這一點，它是如何工作的：
我們正在比較RealWorld應用程序-不僅僅是"要做"的應用程序。 通常，"待辦事項"沒有傳達足夠的知識和觀點來實際構建實際的應用程序。
它以某種方式標準化-一個符合某些規則的項目-有一個規范。 提供后端API，靜態標記和樣式。
由專家撰寫或審查-一個一致的，真實世界的項目，理想情況下，該技術的專家應建立或審查。
我們正在比較哪些庫/框架？
在撰寫本文時，在RealWorld存儲庫中有24種Conduit實現。 是否有大量的追隨者都沒有關系。 唯一的條件是-它顯示在RealWorld回購頁面上。
我們看什么指標？
性能-此應用需要多長時間才能顯示內容并變得可用？
大小-該應用程序有多大？ 我們將只比較已編譯的JAVAScript文件的大小。 html和css對所有變體都是通用的，并且是從CDN（內容交付網絡）下載的。 所有技術都可以編譯或轉換為JavaScript，因此我們僅調整該文件的大小。
代碼行-作者需要多少行代碼才能基于規范創建RealWorld應用程序？ 公平地講，某些應用程序有很多麻煩，但應該不會產生重大影響。 我們量化的唯一文件夾是每個應用程序中的src /。 無論它是自動生成的，都沒關系-您仍然需要對其進行維護。
指標1：性能
我們將檢查Chrome隨附的Lighthouse Audit的性能得分。 Lighthouse返回的性能得分在0到100之間。0是最低的得分。 有關更多詳細信息，請參閱《燈塔計分指南》。
審核設置
Lighthouse Audit Settings for all tested Apps
基本原理
繪畫得越早，某人可以做某事的越早，使用該應用程序的人的體驗就越好。
Performance (points 0–100) — higher is better.
備注
注意：由于缺少演示應用程序，因此跳過了PureScript。
結論
Lighthouse Audit沒睡。 您可以在今年看到未維護/未更新的應用程序跌破90懸崖。 如果您的應用程序得分> 90，則可能不會有很大的不同。 也就是說，AppRun，Elm和Svelte確實令人印象深刻。
指標2：大小
傳輸大小來自Chrome網絡標簽。 服務器提供的GZIPped響應標頭以及響應正文。
這取決于框架的大小以及所添加的任何其他依賴項。 同樣，構建構建工具可以很好地消除捆綁軟件中未使用的代碼。
基本原理
文件越小，下載速度越快，并且解析的次數也更少。
Transfer size in KB — fewer is better
備注
由于缺少演示應用程序，因此跳過了PureScript。
Angular + ngrx + nx，請不要怪我Angular + ngrx + nx-檢查Chrome開發工具網絡標簽，如果我算錯了，請告訴我。
Rust + Yew + WebAssembly還包括.wasm文件
結論
Svelte和Stencil社區所做的驚人工作將其壓縮到20KB以下，確實是一項成就。
指標3：代碼行
使用cloc，我們可以計算每個存儲庫的src文件夾中的代碼行數。 空白行和注釋行不是此計算的一部分。 為什么這有意義？
如果調試是消除軟件錯誤的過程，則編程必須是將其放入其中的過程— Edsger Dijkstra
基本原理
這說明給定庫/框架/語言的簡潔程度。 根據規范，您需要多少行代碼才能實現幾乎相同的應用程序（其中一些具有更多的功能）。
lines of code — fewer is better
備注
由于cloc無法處理.svelte文件，因此Svelte被跳過。
由于cloc無法處理.riot文件，因此跳過了riotjs-effector-universal-hot。
Angular + ngrx：使用/ libs文件夾完成的LoC計算僅包括.ts和.html文件。 如果您認為這是錯誤的，請告訴我什么是正確的數字以及如何計算。
結論
只有具有重新構架的Imba和ClojureScript才能在1000LoC下實施該應用程序。 Clojure以異常表達而著稱。 Imba第一次出現在這里（去年是cloc，不知道.imba文件格式），看起來好像會保留下來。 如果您關心自己的LoC，那么您就會知道該怎么做。
常問問題
＃1為什么此比較中不包含框架X，Y和Z？
因為在RealWorld倉庫中尚未完成實施。 考慮做出貢獻！ 在您喜歡的選擇的庫/框架中實施該解決方案，我們下次將包括它！
＃2您為什么稱其為現實世界？
因為它不只是一個待辦事項應用程序。 在RealWorld中，我們并不是要比較薪水，維護，生產力，學習曲線等。還有其他一些調查可以回答其中的一些問題。 我們所說的RealWorld是一個連接到服務器，進行身份驗證并允許用戶CRUD的應用程序，就像真實世界中的應用程序一樣。
＃3您為什么不包括我最喜歡的框架？
請參見上面的＃1，但以防萬一，這里又來了：因為在RealWorld存儲庫中該實現尚未完成。 我并沒有完成所有的實現-這是社區的努力。 如果您想在比較中看到您的框架，請考慮做出貢獻。
＃4您包括哪個版本的庫/框架？
在撰寫本文時（2020年3月）可用。 該信息來自RealWorld回購。 我確定您可以在GitHub存儲庫中找到此內容。
＃5為什么您忘了包含一個比比較流行的框架？
同樣，請參閱＃1和＃3。 在RealWorld存儲庫中，該實現尚未完成； 就這么簡單。
如果您喜歡這篇文章，應該在Twitter上關注我。 我只寫/推特有關編程和技術。
摘要
請記住，這并不是蘋果之間的比較。 有些實現使用代碼拆分，有些則沒有。 其中有些托管在GitHub上，有些托管在Now上，有些托管在Netlify上。 您是否仍然想知道哪一個最好？ 我把它留給你。
(本文翻譯自Jacek Schae的文章《A RealWorld Comparison of Front-End Frameworks 2020》，參考：https://medium.com/dailyjs/a-realworld-comparison-of-front-end-frameworks-2020-4e50655fe4c1)
