2020 前端框架測評總結(jié)

本文作者： skura

2020-04-09 15:27

導(dǎo)語：從性能、大小和代碼行三個指標(biāo)進行比較

2020 前端框架測評總結(jié)

作為一名前端開發(fā)人員，持續(xù)學(xué)習(xí)是必備的技能之一。隨著新技術(shù)的不斷涌現(xiàn)，前端開發(fā)框架越來越多，各種框架現(xiàn)、版本的更新此起彼伏。

前端領(lǐng)域的技術(shù)不斷更迭，讓人眼花繚亂。面對這么多框架，我們應(yīng)該如何選擇？為此，前端開發(fā)工程師 Jacek Schae 寫了一篇博文，對目前比較熱門的前端框架進行了總結(jié)和測評。以下便是他的全文。

首先聲明，本文絕對不是一篇教你如何選擇下一個前端框架的文章。文章從性能、大小、非常相似的應(yīng)用程序的代碼行這三個方面進行了比較。

考慮到這一點，以下是本文遵守的原則：

我們正在比較現(xiàn)實世界中的應(yīng)用程序，不僅僅是一個“待開發(fā)”的應(yīng)用程序。后者通常不能傳達足夠的知識和觀點來實際構(gòu)建應(yīng)用程序。
它在某種程度上是標(biāo)準(zhǔn)化的，符合特定規(guī)則的項目，有自己的規(guī)范，提供后端 API、靜態(tài)標(biāo)記和樣式。
由專家編寫或?qū)彶榈囊恢碌?、現(xiàn)實世界的項目。

我們在比較哪些庫/框架？

在撰寫本文時，RealWorld repo 中有 24 個管道實現(xiàn)。關(guān)注者多少并不重要，只要它是出現(xiàn)在 RealWorld repo 頁面上就可以。

2020 前端框架測評總結(jié)

我們看什么指標(biāo)？

性能：此應(yīng)用程序需要多長時間才能顯示內(nèi)容并變得可用？

大小：應(yīng)用程序有多大？我們只比較編譯后的 JavaScript 文件的大小。HTML 和 CSS 對所有變體都是通用的，可以從 CDN（內(nèi)容交付網(wǎng)絡(luò)）下載。所有技術(shù)都編譯或轉(zhuǎn)換成 JavaScript，因此我們只調(diào)整這個文件的大小。

代碼行：作者需要多少行代碼來創(chuàng)建基于spec 的 RealWorld 應(yīng)用程序？公平地說，一些應(yīng)用程序有更多華麗的點綴，但它不應(yīng)該有重大影響。我們量化的唯一文件夾是每個應(yīng)用程序中的 src/。不管它是不是自動生成的，你都需要維護它。

指標(biāo) 1：性能

我們將檢查與 Chrome 一起發(fā)布的 Lighthouse Audit 的性能分數(shù)。Lighthouse 將返回一個 0 到 100 之間的性能分數(shù)。0 是可能獲得的最低分數(shù)。更多細節(jié)請查看 Lighthouse 評分指南。

測試設(shè)置

2020 前端框架測評總結(jié)

所有測試應(yīng)用的 Lighthouse 測試設(shè)置

理論基礎(chǔ)

內(nèi)容繪制越快，用戶就能更早開始做事情，使用這款應(yīng)用的體驗就越好。

2020 前端框架測評總結(jié)

性能（評分 0-100 分，分數(shù)越高越好）

注意：由于缺少演示應(yīng)用程序，PureScript 被跳過。

結(jié)論

Lighthouse Audit 不停止。你可以看到，今年沒有維護、更新的應(yīng)用程序正在跌落到 90 分以下。如果你的應(yīng)用程序得分大于 90，可能并不會有太大的不同。也就是說 AppRun、Elm、Svelte 真的令人印象深刻。

指標(biāo) 2：大小

傳輸大小來自 Chrome 網(wǎng)絡(luò)選項卡。GZIPed 響應(yīng)頭加上服務(wù)器傳遞的響應(yīng)體。

這里的表現(xiàn)取決于框架的大小以及添加的額外依賴項。另外，構(gòu)建工具如何從包中消除未使用的代碼也會有影響。

理論基礎(chǔ)

文件越小，下載越快，解析也越少。

2020 前端框架測評總結(jié) 、

傳輸大?。↘B）越少越好

由于缺少演示應(yīng)用程序，PureScript 被跳過。

Angular+ngrx+nx：檢查 Chrome 開發(fā)工具網(wǎng)絡(luò)選項卡，如果我計算錯誤，請告訴我。

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

結(jié)論

Svelte 和 Stencil 社區(qū)的驚人工作，使它小于 20KB，這真的很了不起。

指標(biāo) 3：代碼行

使用 cloc，我們計算每個 repo 的 src 文件夾中的代碼行數(shù)?？瞻仔泻妥⑨屝胁粚儆诖擞嬎愕囊徊糠?。這么做到底有什么意義？

如果調(diào)試是消除軟件錯誤的過程，那么編程必須是一個產(chǎn)生錯誤的過程
——Edsger Dijkstra

理論基礎(chǔ)

這展示了給定的庫、框架、語言的簡潔性。根據(jù)規(guī)范，如果是你自己來寫，需要多少行代碼來實現(xiàn)幾乎相同的應(yīng)用程序？

2020 前端框架測評總結(jié)

代碼行，越少越好

Svelte 是在最初發(fā)布后添加的——多虧了 Svelte master。

由于 cloc 無法處理 .riot 文件，已跳過 riotjs-effector-universal-hot 。

Angular+ngrx:LoC 計算只使用 /libs 文件夾來完成，包括 .ts 和 .html 文件。如果你認為這是錯誤的，請告訴我你是如何計算的。

結(jié)論

只有帶 re frame 的 Imba 和 ClojureScript 才能在 1000LoC 下實現(xiàn)應(yīng)用。Clojure 以其非凡的表現(xiàn)力而聞名。而 Imba 是第一次出現(xiàn)在這里。如果你在乎 LoC，你知道該做什么。

總結(jié)

請記住，這并不是一個完全統(tǒng)一標(biāo)準(zhǔn)的比較。有些實現(xiàn)使用代碼拆分，有些則不使用，有些在 GitHub 托管，有些在 Now 托管，有些在 Netlify 托管。如果你想知道哪一個是最好，試著自己比較一下吧。

常見問題解答

1.為什么框架 X、Y 和 Z 不包括在這個比較中？

因為 RealWorld repo 沒有完成實現(xiàn)。在你最喜歡的庫/框架中實現(xiàn)該解決方案，我們下次將包括它！

2.你為什么稱之為 RealWorld？

因為它不僅僅是一個待辦的應(yīng)用程序。在 RealWorld 中，我們并不是要比較工資、維護、生產(chǎn)率、學(xué)習(xí)曲線等。還有其他的調(diào)查可以回答這些問題。我們所說的 RealWorld 是指一個連接到服務(wù)器、驗證并允許用戶 CRUD 的應(yīng)用程序，就像一個真實的應(yīng)用程序所做的那樣。

3.為什么沒有包括我最喜歡的框架？

請參閱上面的第一個問題：因為 RealWorld repo 沒有完成實現(xiàn)。這是社區(qū)努力的成果。如果你想在比較中看到你的框架，可以考慮貢獻。

4.這里面包含了哪個版本的庫/框架？

這里包含了 2020 年 3 月提供的版本，信息來自 RealWorld repo。你可以從 GitHub repo 中找到這一點。

5.為什么你忘了在比較中包含一個比這個更受歡迎的框架？

RealWorld repo 的實現(xiàn)并不完整，它很簡單。

via：https://medium.com/dailyjs/a-realworld-comparison-of-front-end-frameworks-2020-4e50655fe4c1

雷鋒網(wǎng)雷鋒網(wǎng)雷鋒網(wǎng)

雷峰網(wǎng)版權(quán)文章，未經(jīng)授權(quán)禁止轉(zhuǎn)載。詳情見轉(zhuǎn)載須知。