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

文章插图

我们又来做这个对比了。这次是 2020 年的版本，还有之前的版本： 2019 年、 2018 年、 2017 年。
先来明确一点——这篇文章绝对不是为了告诉你该选择哪个前端框架而写的。它只是一个小型而相对简单的评测，对比三个指标：以基本相同的应用程序为基础，评价不同框架制作出来的应用的性能、应用大小和代码行数。
记住这一点后，我们来看具体的评测方法：

我们对比的基础是 RealWorld 应用——这款应用不是简单的待办事项（to do）应用而已。常见的待办事项应用无法为实际的应用程序构建提供足够的知识和观点参考。
它在某种程度上是标准化的——这是一个符合特定规则的项目，有一套规范。项目还提供了后端 API、静态标记和样式。
它是由一位专家编写或审查的——这是一个一致的，真实世界的项目，其构建或审查工作有专家的参与。

我们要对比哪些库 / 框架？在撰写本文时，在 RealWorld 存储库中有 24 种 Conduit 实现。框架是否流行并不重要。唯一的参评条件是——它出现在 RealWorld 仓库页面上。

文章插图

我们对比哪些指标？

性能——这款应用需要多长时间才能显示内容并处于可用状态？
大小——这款应用有多大？我们只会对比已编译的 JAVAScript 文件的大小。html 和 css 对所有变体都是通用的，并且是从 CDN（内容交付网络）下载的。所有技术都可以编译或转译为 JavaScript，因此我们只看这个文件的大小。
代码行数——作者需要多少行代码才能基于规范创建出 RealWorld 应用？公平地讲，某些框架做出来的应用是有很多花边内容，但应该不会有什么重大影响。我们要量化的唯一文件夹是每个应用中的 src/ 。无论它是否是自动生成的都没关系——反正你都需要维护它的。

指标 1：性能我们会检查 Chrome 随附的 Lighthouse Audit 的性能分数。Lighthouse 返回的性能分数在 0 到 100 之间。0 是最低的。更多详细信息，请参阅《Lighthouse 计分指南》。
测试设置

文章插图

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

文章插图

性能（0-100 点）——越高越好

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

结论Lighthouse Audit 不会说谎。你可以看到在今年未维护 / 未更新的框架做出来的应用跌破 90 分大关。如果你的应用得分超过 90，表现应该不会有太大区别。具体来说，AppRun、Elm 和 Svelte 确实令人印象深刻。
指标 2：大小传输大小数据来自 Chrome 的网络标签。服务器提供 GZIP 压缩后的响应标头以及响应正文。
这里的表现取决于框架的大小以及它添加的其他依赖项的多少。还能看出构建工具能否很好地去掉包中未使用的代码。
基本原理文件越小，下载速度越快，并且需要解析的内容也更少。

文章插图

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

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

Angular+ngrx+nx：Angular+ngrx+nx 这里不要怪我看错了，请检查 Chrome 开发工具网络标签，如果我算错了请告诉我。
Rust+Yew+WebAssembly 还包括.wasm 文件
结论Svelte 和 Stencil 社区所做的令人印象深刻的工作，将它们的应用体积压缩到了 20KB 以下，这确实是一项成就。
指标 3：代码行数使用 cloc，我们可以计算每个存储库的 src 文件夹中的代码行数。空白行和注释行在这里都不算。为什么要考虑这个指标呢？