2020排行榜！Realworld前端框架的比較
本文轉載自公眾號“讀芯術”(ID：AI_Discovery)
過去的三年我們都探討了這個話題，那么今年的情況會是怎樣呢?
首先聲明，此文并不是關于未來前端選擇的比較，而是從三個方面(性能，大小，相似應用下的代碼行數)來進行小范圍的簡單比較。
讀者需要注意:
- 本文是在比較Realworld軟件——而不是正在研發中的軟件，這些軟件通常缺乏足夠的知識和想法，因此難以實現。
- 由專家撰寫或評審過——理想情況下，該技術領域的專家會評估此項目。
- 以某種方式標準化—— 一個符合特定規則的項目存在一種規范，提供后端API，靜態標記和樣式。
正在比較哪些庫/框架?
撰寫此文時，Realworld存儲庫中有24種conduit實現As，它們之間的從屬地位并不重要，唯一的判定標準是看它是否出現在RealWorld repo page上。
關注的是什么指標?
性能—此應用程序需要多長時間才能顯示內容并可用?
大小—該應用程序有多大?我們將只比較已編譯的JavaScript文件的大小。HTML和CSS對所有變體都是通用的，并且是從CDN(內容交付網絡)下載的。所有技術都可以編譯或轉換為JavaScript，因此僅調整該文件的大小。
代碼行數—需要多少行代碼才能基于規范創建RealWorld應用程序?某些應用程序很麻煩，但應該不會產生重大影響。我們量化的唯一文件夾是每個應用程序中的src /。無論它是否是自動生成的，你仍然需要對其進行維護。
標準#1: 性能
我們通過Chrome隨附的Lighthouse Audit查看性能得分，得分在0到100之間。有關更多詳細信息，請參閱《Lighthouse計分指南》。
審查設置
所有經過測試的應用程序的Lighthouse審核設置
基本原理
越早開發的應用程序，人們越早開始使用，用戶體驗相對也更好。
性能得分 (0–100) — 越高越好
評論
注意: 由于缺少演示應用程序，因此跳過了PureScript。
總結
通過Lighthouse Aud，可以看到在今年未維護/未更新的應用程序跌破90關口。當然如果得分> 90，可能也不會有很大的不同。AppRun，Elm和Svelte的表現令人印象深刻。
標準#2: 大小
傳輸大小取決于Chrome網絡標簽，服務器提供的GZIPped響應標頭以及正文。
這取決于框架的大小以及所添加的任何其他依賴項。同樣，構建工具可以很好地清除捆綁軟件中未使用的代碼。文件越小，下載速度越快，解析的次數也更少。
文件大小：KB — 文件越小，傳輸越快
評論
由于缺少演示軟件，因此跳過了PureScript。Angular + ngrx + nx，請不要怪我用Angular + ngrx + nx-檢查Chrome開發工具網絡標簽，如果有計算錯誤的地方，評論區見。
Rust +Yew + WebAssembly 包括 also.wasm file(s)
總結
Svelte和Stencil社區將其壓縮到20KB以下的出色操作，確實是一項成就。
標準 #3: 代碼行數
cloc可以計算每個存儲庫src文件夾中的代碼行數，空白行和注釋行不算在內，意義何在?
如果調試程序是移除軟件缺陷的過程，那么編寫程序就是把軟件缺陷放進來的過程— EdsgerDijkstra
基本原理
這說明給定庫/框架/語言的簡潔程度。根據規范，你需要多少行代碼才能實現功能基本相同的應用程序(其中一些具有更多的功能)。
# 代碼行數— 越少越好
評論
由于cloc無法處理.svelte文件，因此跳過了Svelte。
由于cloc無法處理.riot文件，因此跳過了riotjs-effector-universal-hot。
Angular+ ngrx：使用/ libs文件夾完成的LoC計算僅包括.ts和.html文件。你的看法是什么呢?歡迎探討。
總結
只有重新構架的Imba和ClojureScript才能在1000LoC下實施該應用程序。Clojure以異常表達而著稱。Imba第一次出現在這個行列里(去年是cloc，沒有.imba文件格式)，并且看起來會繼續存在。如果您在意LoC，您就會知道該怎么做。
