參考框架系統基準

by Jacek Schae

由Jacek Schae

帶有基準的前端框架的實際比較 (A Real-World Comparison of Front-End Frameworks with Benchmarks)

UPDATE: There is a newer version of this article

更新：本文有較新的版本

A Real-World Comparison of Front-End Frameworks with Benchmarks (2018 update)This article is a refresh of A Real-World Comparison of Front-End Frameworks with Benchmarks from December 2017.medium.freecodecamp.org

帶有基準的前端框架的實際比較(2018年更新) 本文是2017年12月以來的帶有基準的前端框架的實際比較的更新 。medium.freecodecamp.org

Over the last couple of years we have seen an explosion of front-end frameworks. Each one of them is more than capable of building great web applications. So how do you compare and decide which one to use for your next project?

在過去的幾年中，我們看到了前端框架的爆炸式增長。他們每個人都具有構建出色的Web應用程序的能力。那么，您如何比較并決定在下一個項目中使用哪個？

First of all, to make a meaningful comparison we need a few things:

首先，要進行有意義的比較，我們需要注意以下幾點：

Real World App - Something more than a “todo”. Usually “todos” don’t convey knowledge & perspective to actually build real applications.
真實世界的應用程序 -不僅僅是“待辦事項”。通常，“待辦事項”不會傳達知識和觀點來實際構建實際的應用程序。
Standardized - A project that conforms to certain rules. Hosted at the same place, provides a back-end API, static markup, styles, and spec.
標準化 -符合某些規則的項目。托管在同一位置，提供了后端API，靜態標記，樣式和規范。
Written by an expert - A consistent, real world project, that ideally an expert in that technology would have built. This is true, at least most of the time (see below).
由專家撰寫 -一個一致的，真實世界的項目，理想情況下，該技術的專家應會建立。至少在大多數情況下都是如此(請參閱下文)。

So how do we get such a project? The good news is that Eric Simons already created a RealWorld project. It’s a clone of the Medium blogging platform. Each implementation of this project uses the same HTML structure, CSS, and API spec, but a different library/framework. When it comes to expert knowledge it’s true most of the time. I wrote an implementation in ClojureScript and re-frame and I don’t consider myself an expert. In my defense an expert reviewed my code - thanks Daniel Compton.

那么我們如何獲得這樣的項目呢？好消息是Eric Simons已經創建了一個RealWorld項目。它是Medium博客平臺的克隆。該項目的每個實現都使用相同HTML結構，CSS和API規范，但使用不同的庫/框架。當涉及到專家知識時，大多數時候都是如此。我用ClojureScript編寫了一個實現并重新設計框架，但我不認為自己是專家。在我的辯護中，一位專家檢查了我的代碼-謝謝Daniel Compton 。

Now we have a baseline spec, we need a standard set of tests/metrics to compare them.

現在我們有了基準規范，我們需要一組標準的測試/指標來進行比較。

Performance. How long does this App take to show content and become usable?
性能。 此應用需要多長時間才能顯示內容并可用？
Size. How big is the App? We will only compare the size of the compiled JavaScript. The CSS is common to all variants, and is downloaded from a CDN (Content Delivery Network). The HTML is common to all variants too. All technologies compile or transpile to JavaScript, thus we only size this file.
尺寸。 該應用程序有多大？我們將僅比較已編譯JavaScript的大小。 CSS對于所有變體都是通用的，并且是從CDN(內容交付網絡)下載的。 HTML對于所有變體也是通用的。所有技術都可以編譯或轉換為JavaScript，因此我們僅調整該文件的大小。
Lines of Code. How many lines of code did the author need to create RealWorld app based on spec? To be fair some apps have a bit more bells and whistles, but it should not have a significant impact. The only folder we quantify is src/ in each app.
代碼行。 作者需要多少行代碼才能根據規范創建RealWorld應用程序？公平地講，某些應用程序有很多麻煩，但應該不會產生重大影響。我們量化的唯一文件夾是每個應用程序中的src /。

At the time of writing (Dec 2017) the RealWorld project is available in the following frameworks:

在撰寫本文時(2017年12月)，RealWorld項目在以下框架中可用：

React / Redux
React / Redux
Elm
榆樹
Angular 4+
角4+
Angular 1.5+
角度1.5+
React / MobX
React / MobX
Crizmas MVC
Crizmas MVC
CLSJ Keechma
CLSJ Keechma
AppRun
AppRun
CLJS re-frame (This is the one I did. It’s not yet listed at RealWorld Project).
CLJS重新構圖 (這是我所做的。它尚未在RealWorld Project中列出)。

指標1：效果 (Metric 1: Performance)

First meaningful paint test with Lighthouse Audit that ships with Chrome.

Chrome隨附的Lighthouse Lighthouse進行了首次有意義的油漆測試。

The sooner you paint, the better the experience for the person who is using the App. Lighthouse also measures First interactive, but this was almost identical for most apps.

涂漆越早，使用該應用程序的人的體驗就越好。 Lighthouse還可以測量First Interactive ，但這對于大多數應用程序幾乎相同。

指標2：大小 (Metric 2: Size)

Transfer size is from the Chrome network tab. GZIPed response headers plus the response body, as delivered by the server.

傳輸大小來自Chrome網絡標簽。服務器提供的GZIPed響應標頭以及響應正文。

Smaller file = faster download and less to parse.

較小的文件=下載速度更快，而且解析次數更少。

This depends on the size of your framework, any extra dependencies you added, and how well your build tool can make a small bundle.

這取決于框架的大小，所添加的任何其他依賴項以及您的構建工具可以制作小捆綁包的能力。

指標3：代碼行 (Metric 3: Lines of Code)

Using cloc we count lines of code in each repo’s src folder. Blank and comment lines are not part of this calculation.Why is this meaningful?

使用cloc，我們計算每個倉庫的src文件夾中的代碼行數。空白和注釋行不是此計算的一部分。為什么這有意義？

If debugging is the process of removing software bugs, then programming must be the process of putting them in - Edsger Dijkstra

如果調試是消除軟件錯誤的過程，則編程必須是將其放入程序的過程-Edsger Dijkstra

The fewer lines of code you have the smaller probability of an error and smaller code base to maintain.

代碼行越少，出錯的可能性就越小，要維護的代碼庫也就越少。

結論 (Conclusion)

性能 (Performance)

This is a RealWorld Comparison and not a benchmark in a vacuum. Tests were performed out of Europe (Switzerland). All Apps were hosted on Github. Values may differ for you, which is fine. Tests were performed couple of times for each app, then averaged, and rounded. Results were pretty linear when comparing throughout the day. Most of the libraries/frameworks are in the range of excellent and good. You won’t see a lot of difference when it comes to performance.

這是真實世界的比較，而不是基準測試。測試是在歐洲(瑞士)以外進行的。所有應用都托管在Github上。值可能對您有所不同，這很好。對每個應用程序進行了兩次測試，然后取平均值并四舍五入。全天比較時，結果呈線性關系。大多數庫/框架都在優秀和優秀范圍內。在性能方面，您不會看到太多差異。

尺寸 (Size)

The bundle size for each App is always the same. We are comparing similar implementations and look at how bundle sizes differ. AppRun is insane! I looked a couple of times because I couldn’t believe it. Elm is doing an amazing job when it comes to bundle size and especially when you look at lines of code.

每個應用程序的捆綁包大小始終相同。我們正在比較類似的實現，并查看包大小如何不同。 AppRun太瘋狂了！我看了幾次，因為我簡直不敢相信。在包大小方面，尤其是當您查看代碼行時，Elm做得非常出色。

代碼行 (Lines of code)

This has the biggest impact on you as a software developer. The more lines of code, the more you need to type and more to maintain. There are some trade offs here. Especially when it comes to typed vs. dynamic languages. Types give you more safety and come at a cost - more things to type.

作為軟件開發人員，這對您影響最大。代碼行越多，您需要鍵入的內容就越多，需要維護的內容也就越多。這里有些折衷。尤其是當涉及到打字語言還是動態語言時。類型為您提供更多的安全性，而且要付出一定的代價-要打字的東西更多。

輸入與動態 (Typed vs. dynamic)

Typed: Elm, Angular 4+ and AppRun.

鍵入：Elm，Angular 4+和AppRun。

Dynamic: React | Redux, Angular 1.5, React | MobX, Crizmas MVC, CLJS Keechma, and CLJS re-frame.

動態：React | Redux，Angular 1.5，React | MobX，Crizmas MVC，CLJS Keechma和CLJS重新構架。

So which is better? It’s not better or worse, it’s different. Like TDD (Test Driven Development), some people love it, some hate it. You can develop great software with or without it - pick the one that fits you better.

那么哪個更好呢？它不是好是壞，這是不同的。就像TDD(測試驅動開發)一樣，有些人喜歡它，有些討厭它。無論有無軟件，您都可以開發出色的軟件-選擇更適合您的軟件。

Vue，Preact，Ember，Svelte，Aurelia等在哪里？ (Where are Vue, Preact, Ember, Svelte, Aurelia and others?)

Seems like they are late to the party, but worry not. I’ll do another round when we have them. There are already open issues - consider contributing! Or start from scratch and open a new issue.

好像他們遲到了聚會，但不用擔心。有空的時候我再做一輪。已經存在未解決的問題 -請考慮做出貢獻！或從頭開始并打開一個新問題。

最后的話 (Final word)

This comparison is exactly what it says. Compares different implementations of similar real world web applications in a real world. I know, it’s not perfect. It differs based on server load, network traffic, and many other things that happen in the real world.

這種比較正是它所說的。比較現實世界中類似現實世界Web應用程序的不同實現。我知道，這并不完美。它根據服務器負載，網絡流量以及現實世界中發生的許多其他事件而有所不同。

Thanks to Daniel Compton for proof-reading.

感謝Daniel Compton的校對。

If you enjoyed this article, and would like to be notified when I release similar article consider following me on medium and twitter.

如果您喜歡這篇文章，并且希望在我發布類似文章時收到通知，請考慮在medium和twitter上關注我。