[譯] 前端開發框架的實戰對比（2018 年更新）

• 原文地址：A Real-World Comparison of Front-End Frameworks with Benchmarks (2018 update)
• 原文做者：Jacek Schae
• 譯文出自：掘金翻譯計劃
• 本文永久連接：github.com/xitu/gold-m…
• 譯者：geniusq1981
• 校對者：Hopsken 、zephyrJS

本文是是對 2017 年 12 月發表的 前端開發框架的實戰對比 一文的更新。

在對比中，咱們將展現不一樣框架之間去實現幾乎相同的 實戰示例應用 有怎樣的差異。

實戰示例應用 爲咱們提供了：

1. 實戰應用——不僅是一個 "todo" 應用。通常來講，"todo" 應用沒法充分的傳達構建一個真實應用所須要的知識和觀點。
2. 標準化——符合必定開發指南的項目。提供後端 API，靜態標記，樣式和規格。
3. 由專家撰寫或審覈——一個實戰項目，理想狀況下，由技術專家建立或審覈。

上一版本的不足（2017 年 12 月）

✅ Angular 沒有用於生產環境。以前實戰應用倉庫列出的示例應用使用的是一個開發版本，感謝 Jonathan Faircloth，它如今已是生產版本！

✅ Vue 沒有包含在實戰應用倉庫，所以未包括在對比中。正如你能夠想象的那樣，Vue 在前端引發了很大的熱度。怎麼能夠不考慮 Vue 呢？你究竟是怎麼想的？這一次咱們加入了Vue.js！謝謝 Emmanuel Vilsbol。

咱們比較哪些庫/框架？

和 2017 年 12 月的文章同樣，咱們包含了實戰應用倉庫中列出的全部實現方式。無論它有沒有大量的擁躉，惟一標準就是它出如今 實戰應用倉庫 頁面上。

前往 github.com/gothinkster… （2018 年 4 月）

咱們看什麼指標？

1. 性能： 應用須要多長時間能顯示出頁面內容並可用？
2. 大小： 應用程序多大？咱們只會比較已編譯過的的 JavaScript 文件大小。 CSS 對於全部不一樣實現框架都是通用的，而且從 CDN (內容分發網絡)下載。 HTML 也是通用的。全部技術都編譯或轉換成 JavaScript，所以咱們只計算這些文件的大小。
3. 代碼行數： 開發者根據開發指南須要寫多少行代碼來作一個實戰應用？爲了公平，雖然有些應用程序有一些花裏胡哨的東西，但它不該該對結果產生影響。因此咱們惟一量化的目錄只用每一個 app 中的 src/ 目錄。

指標 ＃1：性能

使用 Chrome 自帶的 Lighthouse Audit 工具進行 首次有效繪製 的測試。

繪製速度越快，應用的使用體驗就越好。Lighthouse 也測試 First interactive ，但對於大多數應用來講，這幾乎是相同的，而它還處於測試階段。

首次有效繪製（毫秒）——越低越好

在性能方面你可能不會看到不少差別。

指標 ＃2：大小

傳輸大小來自 Chrome 的網絡標籤，包含從服務器傳送的壓縮的響應頭和響應正文。

文件越小，下載速度越快(而且須要解析的數據也越少)。

這取決於你的框架以及你添加的依賴庫的大小，還有你的編譯工具的好壞也有必定影響。

傳輸大小（KB）——越低越好

您能夠看到 Svelte，Dojo 2 和 AppRun 作得很是好。我不能說 Elm 也表現足夠好——特別是當你看下一張圖時。我也想看看 Hyperapp 的表現。可能下次吧，Jorge Bucaran ？

指標 ＃3：代碼行數

經過 cloc 咱們計算每一個倉庫的 src 文件夾中的代碼行。空白和註釋行不會包含在內。這樣作的意義何在？

若是調試是刪除軟件錯誤的過程，那麼編程就是引入錯誤的過程 — Edsger Dijkstra

代碼行數——越少越好

您擁有的代碼行數越少，那麼出現錯誤的機率就越小，並且你也只須要維護較小的代碼庫。

結論

我想說，很是感謝 Eric Simons 建立了 實戰示例應用 ，還有大量的提供不一樣實現的貢獻者們。

更新: 感謝 Jonathan Faircloth 提供生產版本的 Angular。

若是你對這篇文章感興趣，你能夠在 Twitter 和 Medium 上加我。

若是發現譯文存在錯誤或其餘須要改進的地方，歡迎到 掘金翻譯計劃 對譯文進行修改並 PR，也可得到相應獎勵積分。文章開頭的 本文永久連接 即爲本文在 GitHub 上的 MarkDown 連接。

---

掘金翻譯計劃 是一個翻譯優質互聯網技術文章的社區，文章來源爲 掘金 上的英文分享文章。內容覆蓋 Android、iOS、前端、後端、區塊鏈、產品、設計、人工智能等領域，想要查看更多優質譯文請持續關注 掘金翻譯計劃、官方微博、知乎專欄。