一個一致的、真正的項目，在理想情況下，由相關技術的專家建立或?qū)彶椤?/p>

我們比較哪些庫和框架？

截至撰稿時為止，在 RealWorld example app 的 repo 已經(jīng)中有18個 庫或框架的實現(xiàn)。

是否有大量的擁躉者并不重要。唯一要求是它是否出現(xiàn)在了 RealWorld 的代碼倉庫頁面上。

我們關注那些指標？

表現(xiàn)

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

大小

應用有多大？我們只會比較已編譯的 JavaScript 文件的大小。 CSS 對所有變體都是通用的，并從 CDN（內(nèi)容分發(fā)網(wǎng)絡）下載。 HTML 也適用于所有變體。所有技術都編譯或轉(zhuǎn)換為 JavaScript，因此我們只比較這種文件的大小。

代碼行數(shù)

作者根據(jù)規(guī)范創(chuàng)建 RealWorld app 需要多少行代碼？公平地說，一些程序過于花里胡哨，但它不應該產(chǎn)生重大影響。我們量化的唯一文件夾是每個程序中的 src/。

度量標準 #1：性能

我們將通過檢查 Chrome 附帶的 Lighthouse Audit 的效果得分。 Lighthouse 返回的性能分數(shù)在 0 到 100 之間，0 是低分。

審核設置

測試用的所有 Lighthouse Audit 設置

效果是基于以下指標的綜合得分

• 第一個有內(nèi)容的繪制
• 第一個有意義的繪制
• 速度指數(shù)
• 第一個 CPU 空閑
• 交互時間
• 估計的輸入延遲

有關詳細信息，請查看 Lighthouse評分指南。

簡述

越早進行繪制和工作，用戶的體驗就越好。

表現(xiàn)得分（0 -100）—— 越高越好

注意：由于缺少 Demo程序，因此跳過了 PureScript。

結(jié)論

大多數(shù)應用程序的得分都高于90，在性能方面，你可能感覺不到太多的差異。

指標 #2：大小

傳輸大小來自 Chrome 的 network 標簽中。 GZIPped 響應頭加上服務器提供的響應主體。這取決于框架的大小和你添加的額外依賴項，以及構(gòu)建工具如何消除捆綁包中未使用的代碼。

簡述

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

傳輸大小以KB為單位 - 越少越好

結(jié)論

這里發(fā)生了很多令人驚訝的事情。 Svelte —— 能夠隱身的 UI 框架 —— 這是真正適用于它的妙語。 Stencil 這個基準測試中的新手也表現(xiàn)不錯。兩者都相對較新，正在推動大小方面的限制。

指標 #3：代碼行數(shù)

我們用了 cloc 計算每個 repo 的 src 文件夾中的代碼行數(shù)?？招泻妥⑨屝胁挥嬋朐趦?nèi)。

如果說調(diào)試是刪除軟件錯誤的過程，那么編程必須是把它們加進去的過程 ?— Edsger Dijkstra

簡述

這顯示了給定庫、框架或語言的簡潔程度。根據(jù)規(guī)范，你需要多少行代碼才能實現(xiàn)幾乎相同的程序（其中一些會有更多的額外功能）。

#代碼行數(shù) - 越少越好

注意 Imba：由于 cloc 無法處理 *.imba 文件而跳過了它。

注意 Elm：Elm 開發(fā)人員縱向的進行開發(fā)，因此代碼行數(shù)很高 —— 至少我被告知是這樣的 。

注意 Angular + ngrx：在 /libs 文件夾內(nèi)完成的代碼行數(shù)計算，僅包括\*.ts 和 \*.html 文件。如果你覺得這是錯的，請告訴我正確的值是多少，以及你是如何計算的。

注意 Hyperapp：文章發(fā)布時代碼行數(shù)不正確，感謝 Mateusz Kwasniewski 指出錯誤并提供了正確計算方法。

結(jié)論

使用 ClojureScript 的 re-frame 為你提供了最佳效果。 Clojure 以其異常豐富的表現(xiàn)力而著稱。如果你對代碼行數(shù)很在意，應該關注 ClojureScript、AppRun 和 Svelte。

總結(jié)

請記住，這不是一個針對同類產(chǎn)品比較。有些實現(xiàn)使用了代碼分割，有些則沒有。其中一些托管在 GitHub 上，一些托管在 Now，還有一些托管在 Netlify。你還想知道哪一個是最好的嗎？最好的應該是能夠滿足你需求的那個！

**問：**你喜歡類型嗎？

**答：**要研究 Elm、PureScript 和 TypeScript 的話，請關注 Angular，AppRun，Dojo。

**問：**你寫一個占用空間非常小的程序？

**答：**請關注 Svelte、Stencil 和 AppRun。

**問：**你想用有最少的代碼來進行維護嗎？

**答：**關注使用 ClojureScript 的 re-frame、AppRun 和 Svelte 。

**問：**想學習新東西嗎？

**答：**選擇一個你不知道的庫或框架！

常見問題

#1 為什么在這個比較中沒有框架 X、Y 和 Z ？

因為 RealWorld repo 沒有完成它的實現(xiàn)。你可以考慮貢獻自己的代碼！用你喜歡的庫或框架中實施解決方案，下次我們將會把它加進去！

#2 為什么稱它為 real world ？

因為它比 To-Do 程序多一點。通過 RealWorld，并不意味著我們會對薪水、維護、生產(chǎn)力、學習曲線等進行比較。其他調(diào)查回答了其中一些的問題。我們所說的 RealWorld 是一個連接到服務器，驗證并允許用戶進行 CRUD 操作的程序 —— 就像真實世界的程序一樣。

#3 為什么不包含我最喜歡的框架？

請參閱上面的#1，但是為了以防萬一，再說一次：因為實現(xiàn)沒有在 RealWorld repo 中完成。我不做所有的實現(xiàn) —— 這是社區(qū)的努力。如果想在比較中看到你的框架，請考慮參與。

#4 你用的是哪個版本的庫或框架？

上線時可用的那個（2019年3月），我相信你可以從 GitHub repo中找到相關的信息。

#5 為什么你忽略了一個更受歡迎的框架？

最后再說一次，請見上文。 RealWorld repo 的實施并未完成，就這么簡單。

感謝 Rich Harris 和 Richard Feldman 在發(fā)布前進行了審閱。

歡迎關注公眾號：前端先鋒，獲取更多前端干貨。

轉(zhuǎn)載于:https://juejin.im/post/5cc2c819e51d456e7349dc74

總結(jié)

以上是生活随笔為你收集整理的在同一基准下对前端框架进行比较（2019年更新）的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。