- 原文地址：A RealWorld Comparison of Front-End Frameworks 2020
- 原文作者：Jacek Schae
- 譯文出自：掘金翻譯計劃
- 本文永久連結：github.com/xitu/gold-m…
- 譯者：snowyYU
- 校對者：Baddyo、IAMSHENSH
來了來了，本篇寫於 2020 年，往年的版本請看這裡：2019、2018 和 2017。
首先，請務必明白 —— 本篇不是告訴你應該選擇哪種作為你未來的前端框架，在此只簡短淺顯的對比三個方面：各 RealWorld 應用的效能，大小、程式碼行數。
請記住哦，好了，讓我們開始吧：
我們對比 RealWorld 應用 —— 相較“to do”型別的應用，它的功能更加強大。通常來說，“to-dos”並不能說明各框架在實際應用中的表現情況。
專案有一定的規範 —— 一個符合特定規則的專案 —— 相關規範在此。提供了後端 API，靜態 html 模版和樣式。
專案的構建和檢查都是由相關技術的大牛完成的 —— 一般來說，相關框架的技術大牛會構建並檢查自己 real-world 專案，確保其和別的專案的一致性。
我們正在比較哪些庫 / 框架？
截至撰寫本文時，RealWorld 倉庫 中已有 24 個相關實現。也許有受眾更多的框架沒有出現在這裡。但進行對比的前提只有一個 —— 它必須出現在 RealWorld 倉庫 頁面裡。
我們關注什麼指標？
效能 —— 此應用需要多長時間才能顯示內容並變得可用。
大小 —— 應用有多大的體積？我們只會比較編譯後的 JavaScript 檔案大小。HTML 和 CSS 對所有的 RealWorld 應用都是通用的，並且都可從 CDN 下載。此外，所有技術均可編譯或轉換為 JavaScript，綜上，我們只比較編譯後的 JavaScript 檔案大小。
程式碼行數 —— 開發者需要多少行程式碼才能根據規範建立 RealWorld 應用？公平來說，有些應用有更多的功能，但這應該沒啥大的影響。我們只看 src/ 資料夾中各檔案的程式碼行數。即使它是自動生成的也可以 —— 你仍需要持續維護它。
指標 #1：效能
我們使用 Chrome 的擴充外掛 Lighthouse Audit 來給各個專案的效能評分。Lighthouse 會給出一個範圍在 0 到 100 的分數。0 是最低分。想了解更多，請戳 Lighthouse 評分指南。
外掛相關的配置
基本原則
渲染的越快，使用者就能越早地使用該應用，同樣，使用者的體驗就越好。
備註
注意：由於缺少 demo 應用，這裡忽略 PureScript。
總結
Lighthouse Audit 可沒閒著。您可以看到未維護/未更新的應用程式跌破了 90 分。得分超過 90 分的應用在效能上差別不大。不得不說，AppRun、Elm 和 Svelte 表現的非常出色。
指標 #2：大小
需要載入的資源的大小可以從 Chrome 中開發者工具的 Network 標籤中得出。伺服器提供的 GZIP 響應頭和響應主體。
這取決於框架的大小以及所新增的其他依賴包。同樣，構建合適的打包工具可以忽略未使用的依賴。
基本原則
檔案越小，下載速度越快，並且需要解析的內容越少。
備註
注意：由於缺少 demo 應用，這裡再次忽略 PureScript。
Angular + ngrx + nx 方案的支持者可別打我喲 —— 看一下 Chrome 開發者工具中的 Network 標籤裡的載入情況，如果我算錯了 — 還請告知。
Rust + Yew + WebAssembly 方案的大小計算，包括了以 .wasm 結尾的檔案。
總結
Svelte 和 Stencil 社群完成的 RealWorld 應用太棒了，把需要載入的檔案控制在了 20KB 以內，可以說是前無古人了。
指標 #3：程式碼行數
我們使用 cloc 計算每個庫的 src 資料夾中的程式碼行數。不包含空白行和註釋。考量這個指標的意義何在呢？
如果說除錯是消滅 bug 的過程, 那麼編碼則是產生它的過程 —— Edsger Dijkstra
基本原則
下面這張圖展示了各個庫/框架/語言實現的 RealWorld 應用的簡潔程度。根據規範，他們各自寫了多少行實現了幾乎相同的應用程式（其中一些應用具有更多的功能）。
備註
由於 cloc 無法統計以 .svelte 為字尾的檔案，因此 Svelte 在此不做對比。
由於 cloc 無法統計以 .riot 為字尾檔案，因此 riotjs-effector-universal-hot 在此也不做對比。
Angular + ngrx: 以/libs資料夾為基礎完成的程式碼行數統計僅包括以 .ts 和 .html 為字尾檔案。如果你覺得不應該這樣統計, 還望告知正確的程式碼行數以及你是如何統計它的。
總結
只有 Imba 和 ClojureScript + re-frame 能在 1000 行程式碼以內實現 RealWorld 應用。Clojure 以獨特的表現力而著稱。Imba 第一次出現在這裡（去年是因為 cloc 還不能識別以 .imba 為字尾的檔案），看起來之後會一直出現在這裡。如果你關心自己專案的程式碼行數，那麼你現在知道該怎麼做啦。
最後
請記住，這並不是一個公平、合理的比較。有些在應用的實現上使用了程式碼拆分，有些則沒有。其中有些託管在 GitHub 上，有些託管在 Now 上，有些託管在 Netlify 上。你是否仍然想知道哪一個最好？這我可回答不了。
常見問題
#1 為什麼在本篇對比中不包含框架 X，Y 和 Z 呢？
因為以該框架為基礎構建的 RealWorld 應用尚未在 RealWorld 倉庫上出現或按照規範構建完成。考慮做出你的貢獻吧！選擇你喜歡的庫/框架然後來構建 RealWorld 應用吧，我們下次對比將包括它！
#2 為什麼你們稱其為 real world？
因為它不只是一個 To-Do 應用程式。通過 RealWorld 應用，我們並不是要比較相關技術能拿到的薪水，可維護性，生產力，學習曲線等方面。這有其他調查回答了其中一些問題。我們所說的 RealWorld 是指連線到伺服器，進行身份驗證並允許使用者進行 CRUD 操作的應用程式 —— 就像現實世界中的應用程式一樣。
#3 你為什麼不比較我最喜歡的框架？
請參見問題 1，但以防萬一，這裡還是想強調下：因為以該框架為基礎構建的 RealWorld 應用尚未在 RealWorld 倉庫上出現或按照規範構建完成。以上所有的 Real World 應用又不是我自己搞出來的-這是整個社群的努力結晶。如果你想在下次對比中看到你喜歡的框架，請考慮為本專案做出貢獻吧。
#4 包括了哪個版本的庫/框架？
所涉及的庫/框架在撰寫本文時（2020 年 3 月）均可用。該資訊來自 RealWorld 倉庫。我確定你可以在 GitHub 倉庫 中找到相關資訊。
#5 有比本文中出現的更流行的框架，你怎麼忘記比較啦？
同樣，請參閱問題 1 和問題 3。以該框架為基礎構建的 RealWorld 應用尚未在 RealWorld 倉庫 上出現或按照規範構建完成；原因就是這麼簡單。
如果你喜歡這篇文章，請 在Twitter上關注我。我只寫/推有關程式設計和技術的文章。
如果發現譯文存在錯誤或其他需要改進的地方，歡迎到 掘金翻譯計劃 對譯文進行修改並 PR，也可獲得相應獎勵積分。文章開頭的 本文永久連結 即為本文在 GitHub 上的 MarkDown 連結。
掘金翻譯計劃 是一個翻譯優質網際網路技術文章的社群，文章來源為 掘金 上的英文分享文章。內容覆蓋 Android、iOS、前端、後端、區塊鏈、產品、設計、人工智慧等領域，想要檢視更多優質譯文請持續關注 掘金翻譯計劃、官方微博、知乎專欄。