2020 年前端框架性能对比和评测

译者丨Jacek Schae

翻译者丨王磊

策画丨小光

他们又来做那个对照了。此次是 2020 年的版，除了以后的版：2019 年、 2018 年、 2017 年。

嘿嘿明晰一点儿——这首诗当然并非为的是说你该优先选择别的后端架构而写的。它而已两个较大型而相较单纯的点评，对照四个分项：以大致相同的应用领域程序为依据，赞扬相同架构制做出的应用领域的操控性、应用领域大小不一和标识符个字符。

读懂这一点儿后，他们上看具体内容的点评方式：

他们对比的此基础是 RealWorld 应用领域——这款应用领域并非单纯的巨集事宜（to do）应用领域罢了。常用的巨集事宜应用领域难以为前述的应用领域程序构筑提供更多足够多的科学知识和看法参照。

它在某种意义上是技术标准的——这是两个合乎特定准则的工程项目，有一套规范化。工程项目还提供更多了后端 API、动态记号和式样。

它是由一名研究者编写或审核的——这是两个完全一致的，虚拟世界的工程项目，其构筑或审核组织工作有研究者的参予。

在编写责任编辑时，在 RealWorld 存储库中有 24 种 Conduit 同时实现。架构与否盛行并不关键。惟一的评审委员前提是——它再次出现在 RealWorld 库房网页上。

操控性——这款应用领域需要多长时间才能显示内容并处于可用状态？

大小不一——这款应用领域有多大？他们只会对照已编译的 JavaScript 文件的大小不一。HTML 和 CSS 对所有变体都是通用的，并且是从 CDN（内容交付网络）下载的。所有技术都可以编译或转译为 JavaScript，因此他们只看那个文件的大小不一。

标识符个字符——译者需要多少行标识符才能基于规范化创建出 RealWorld 应用领域？公平地讲，某些架构做出的应用领域是有很多花边内容，但应该不会有什么重大影响。他们要量化的惟一文件夹是每个应用领域中的 src/。无论它与否是自动生成的都没关系——反正你都需要维护它的。

他们会检查 Chrome 随附的 Lighthouse Audit 的操控性分数。Lighthouse 返回的操控性分数在 0 到 100 之间。0 是最低的。更多详细信息，请参阅《Lighthouse 计分指南》。

内容绘制得越快，用户就能越早开始做事，应用领域的使用体验就会越好。

操控性（0-100 点）——越高越好

注意：由于缺少演示应用领域，因此跳过了 PureScript。

Lighthouse Audit 不会说谎。你可以看到在今年未维护 / 未更新的架构做出的应用领域跌破 90 分大关。如果你的应用领域得分超过 90，表现应该不会有太大区别。具体内容来说，AppRun、Elm 和 Svelte 确实令人印象深刻。

传输大小不一数据来自 Chrome 的网络标签。服务器提供更多 GZIP 压缩后的响应标头以及响应正文。

这里的表现取决于架构的大小不一以及它添加的其他依赖项的多少。还能看出构筑工具能否很好地去掉包中未使用的标识符。

文件越小，下载速度越快，并且需要解析的内容也更少。

传输大小不一（KB）——越少越好

备注：由于缺少演示应用领域，因此跳过了 PureScript。

Angular+ngrx+nx：Angular+ngrx+nx 这里不要怪我看错了，请检查 Chrome 开发工具网络标签，如果我算错了请说我。

Rust+Yew+WebAssembly 还包括.wasm 文件

Svelte 和 Stencil 社区所做的令人印象深刻的组织工作，将它们的应用领域体积压缩到了 20KB 以下，这确实是一项成就。

使用 cloc，他们可以计算每个存储库的 src 文件夹中的标识符个字符。空白行和注释行在这里都不算。为什么要考虑那个分项呢？

如果调试是消除软件错误的过程，那么编程肯定就是把错误放入软件的过程。——EdsgerDijkstra

那个分项说明了给定库 / 架构 / 语言的简洁程度。也就是说根据规范化，你需要多少行标识符才能实现几乎相同的应用领域（其中一些有更多的花边部分）。

标识符个字符——越少越好

备注：由于 cloc 难以处理.svelte 文件，因此 Svelte 被跳过。

由于 cloc 难以处理.riot 文件，因此跳过了 riotjs-effector-universal-hot。

Angular+ngrx：使用 /libs 文件夹完成的 LoC 计算仅包括.ts 和.html 文件。如果你认为这是错误的方式，请说我正确的数字应该是多少，以及如何计算它。

只有 Imba 和带 re-frame 的 ClojureScript 才能在 1000 行标识符内同时实现那个应用领域。Clojure 以非同一般的表达方式而著称。Imba 第一次再次出现在这里（去年的时候 cloc 难以分析.imba 文件格式），看起来它的地位会持续下去。如果你关心自己的 LoC，那么看到这里你就该知道选什么了。

请读懂，这并并非完全公平的对照。有些同时实现使用了标识符拆分，有些则没有。其中有些托管在 GitHub 上，有些托管在 Now 上，除了些托管在 Netlify 上。你还是想知道哪两个架构最好？那个问题就留给你自己来思考吧。

因为在 RealWorld 库房中尚未完成同时实现。你可以考虑做出贡献！用你喜欢的库 / 架构同时实现那个方案，他们下次将测试它的！

因为它不而已两个巨集事宜应用领域。在 RealWorld 中，他们并并非要对照薪水、维护、生产力和学习曲线等。其他一些调查可以回答其中的一些问题。他们所说的 RealWorld 是两个连接到服务器，进行身份验证并允许用户 CRUD 的应用领域程序，就像虚拟世界中的应用领域程序一样。

请参见上面的 #1，但以防万一再提一句：因为在 RealWorld 存储库中该同时实现尚未完成。我并没有完成所有的同时实现——这需要社区的努力。如果你想在对照中看到你的架构，请考虑做出贡献。

在编写责任编辑时（2020 年 3 月）可用的版。这里的信息来自 RealWorld 库房。你可以在 GitHub 存储库中找到相关数据。

同样，请参阅 #1 和 #3。在 RealWorld 存储库中该同时实现尚未完成，就这么单纯。

参照链接：

https://medium.com/dailyjs/a-realworld-comparison-of-front-end-frameworks-2020-4e50655fe4c1

进群”申请入群。大家可以和 InfoQ 读者一起畅所欲言，和编辑们零距离接触，超值的技术礼包等你领取，除了超值活动等你参加，快来加入他们吧！

点个在看少个 bug 👇