<mark id="oztn4"></mark>
0
作為一名前端開發人員，持續學習是必備的技能之一。隨著新技術的不斷涌現，前端開發框架越來越多，各種框架現、版本的更新此起彼伏。
前端領域的技術不斷更迭，讓人眼花繚亂。面對這么多框架，我們應該如何選擇？為此，前端開發工程師 Jacek Schae 寫了一篇博文，對目前比較熱門的前端框架進行了總結和測評。以下便是他的全文。
首先聲明，本文絕對不是一篇教你如何選擇下一個前端框架的文章。文章從性能、大小、非常相似的應用程序的代碼行這三個方面進行了比較。
考慮到這一點，以下是本文遵守的原則：
我們正在比較現實世界中的應用程序，不僅僅是一個“待開發”的應用程序。后者通常不能傳達足夠的知識和觀點來實際構建應用程序。
它在某種程度上是標準化的，符合特定規則的項目，有自己的規范，提供后端 API、靜態標記和樣式。
由專家編寫或審查的一致的、現實世界的項目。
我們在比較哪些庫/框架？
在撰寫本文時，RealWorld repo 中有 24 個管道實現。關注者多少并不重要，只要它是出現在 RealWorld repo 頁面上就可以。
我們看什么指標？
性能：此應用程序需要多長時間才能顯示內容并變得可用？
大小：應用程序有多大？我們只比較編譯后的 JavaScript 文件的大小。HTML 和 CSS 對所有變體都是通用的，可以從 CDN（內容交付網絡）下載。所有技術都編譯或轉換成 JavaScript，因此我們只調整這個文件的大小。
代碼行：作者需要多少行代碼來創建基于spec 的 RealWorld 應用程序？公平地說，一些應用程序有更多華麗的點綴，但它不應該有重大影響。我們量化的唯一文件夾是每個應用程序中的 src/。不管它是不是自動生成的，你都需要維護它。
指標 1：性能
我們將檢查與 Chrome 一起發布的 Lighthouse Audit 的性能分數。Lighthouse 將返回一個 0 到 100 之間的性能分數。0 是可能獲得的最低分數。更多細節請查看 Lighthouse 評分指南。
測試設置
所有測試應用的 Lighthouse 測試設置
理論基礎
內容繪制越快，用戶就能更早開始做事情，使用這款應用的體驗就越好。
性能（評分 0-100 分，分數越高越好）
注意：由于缺少演示應用程序，PureScript 被跳過。
結論
Lighthouse Audit 不停止。你可以看到，今年沒有維護、更新的應用程序正在跌落到 90 分以下。如果你的應用程序得分大于 90，可能并不會有太大的不同。也就是說 AppRun、Elm、Svelte 真的令人印象深刻。
指標 2：大小
傳輸大小來自 Chrome 網絡選項卡。GZIPed 響應頭加上服務器傳遞的響應體。
這里的表現取決于框架的大小以及添加的額外依賴項。另外，構建工具如何從包中消除未使用的代碼也會有影響。
理論基礎
文件越小，下載越快，解析也越少。
、
傳輸大小（KB）越少越好
由于缺少演示應用程序，PureScript 被跳過。
Angular+ngrx+nx：檢查 Chrome 開發工具網絡選項卡，如果我計算錯誤，請告訴我。
Rust+Yew+WebAssembly 還包括 .wasm 文件
結論
Svelte 和 Stencil 社區的驚人工作，使它小于 20KB，這真的很了不起。
指標 3：代碼行
使用 cloc，我們計算每個 repo 的 src 文件夾中的代碼行數。空白行和注釋行不屬于此計算的一部分。這么做到底有什么意義？
如果調試是消除軟件錯誤的過程，那么編程必須是一個產生錯誤的過程
——Edsger Dijkstra
理論基礎
這展示了給定的庫、框架、語言的簡潔性。根據規范，如果是你自己來寫，需要多少行代碼來實現幾乎相同的應用程序？
代碼行，越少越好
Svelte 是在最初發布后添加的——多虧了 Svelte master。
由于 cloc 無法處理 .riot 文件，已跳過 riotjs-effector-universal-hot 。
Angular+ngrx:LoC 計算只使用 /libs 文件夾來完成，包括 .ts 和 .html 文件。如果你認為這是錯誤的，請告訴我你是如何計算的。
結論
只有帶 re frame 的 Imba 和 ClojureScript 才能在 1000LoC 下實現應用。Clojure 以其非凡的表現力而聞名。而 Imba 是第一次出現在這里。如果你在乎 LoC，你知道該做什么。
總結
請記住，這并不是一個完全統一標準的比較。有些實現使用代碼拆分，有些則不使用，有些在 GitHub 托管，有些在 Now 托管，有些在 Netlify 托管。如果你想知道哪一個是最好，試著自己比較一下吧。
常見問題解答
1.為什么框架 X、Y 和 Z 不包括在這個比較中？
因為 RealWorld repo 沒有完成實現。在你最喜歡的庫/框架中實現該解決方案，我們下次將包括它！
2.你為什么稱之為 RealWorld？
因為它不僅僅是一個待辦的應用程序。在 RealWorld 中，我們并不是要比較工資、維護、生產率、學習曲線等。還有其他的調查可以回答這些問題。我們所說的 RealWorld 是指一個連接到服務器、驗證并允許用戶 CRUD 的應用程序，就像一個真實的應用程序所做的那樣。
3.為什么沒有包括我最喜歡的框架？
請參閱上面的第一個問題：因為 RealWorld repo 沒有完成實現。這是社區努力的成果。如果你想在比較中看到你的框架，可以考慮貢獻。
4.這里面包含了哪個版本的庫/框架？
這里包含了 2020 年 3 月提供的版本，信息來自 RealWorld repo。你可以從 GitHub repo 中找到這一點。
5.為什么你忘了在比較中包含一個比這個更受歡迎的框架？
RealWorld repo 的實現并不完整，它很簡單。
via：https://medium.com/dailyjs/a-realworld-comparison-of-front-end-frameworks-2020-4e50655fe4c1
雷鋒網雷鋒網雷鋒網
