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

elang發表於2019-02-26
前端框架

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

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

實戰示例應用 為我們提供了：

  1. 實戰應用——不只是一個 "todo" 應用。一般來說，"todo" 應用無法充分的傳達構建一個真實應用所需要的知識和觀點。
  2. 標準化——符合一定開發指南的專案。提供後端 API，靜態標記，樣式和規格。
  3. 由專家撰寫或稽核——一個實戰專案，理想情況下，由技術專家建立或稽核。

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

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

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

我們比較哪些庫/框架？

和 2017 年 12 月的文章一樣，我們包含了實戰應用倉庫中列出的所有實現方式。不管它有沒有大量的擁躉，唯一標準就是它出現在 實戰應用倉庫 頁面上。

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

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

我們看什麼指標？

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

指標 ＃1：效能

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

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

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

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

在效能方面你可能不會看到很多差異。

指標 ＃2：大小

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

檔案越小，下載速度越快(並且需要解析的資料也越少)。

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

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

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

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

指標 ＃3：程式碼行數

通過 cloc 我們計算每個倉庫的 src 資料夾中的程式碼行。空白和註釋行不會包含在內。這樣做的意義何在？

如果除錯是刪除軟體錯誤的過程，那麼程式設計就是引入錯誤的過程 — Edsger Dijkstra

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

程式碼行數——越少越好

您擁有的程式碼行數越少，那麼出現錯誤的概率就越小，而且你也只需要維護較小的程式碼庫。

結論

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

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

如果你對這篇文章感興趣，你可以在 Twitter 和 Medium 上加我。

如果發現譯文存在錯誤或其他需要改進的地方，歡迎到 掘金翻譯計劃 對譯文進行修改並 PR，也可獲得相應獎勵積分。文章開頭的 本文永久連結 即為本文在 GitHub 上的 MarkDown 連結。

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

相關文章