参考框架系统基准

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上关注我。