- 原文地址：A RealWorld Comparison of Front-End Frameworks 2020
- 原文作者：Jacek Schae
- 译文出自：掘金翻译计划
- 本文永久链接：github.com/xitu/gold-m…
- 译者：snowyYU
- 校对者：Baddyo、IAMSHENSH
来了来了，本篇写于 2020 年，往年的版本请看这里：2019、2018 和 2017。
首先，请务必明白 —— 本篇不是告诉你应该选择哪种作为你未来的前端框架，在此只简短浅显的对比三个方面：各 RealWorld 应用的性能，大小、代码行数。
请记住哦，好了，让我们开始吧：
我们对比 RealWorld 应用 —— 相较“to do”类型的应用，它的功能更加强大。通常来说，“to-dos”并不能说明各框架在实际应用中的表现情况。
项目有一定的规范 —— 一个符合特定规则的项目 —— 相关规范在此。提供了后端 API，静态 html 模版和样式。
项目的构建和检查都是由相关技术的大牛完成的 —— 一般来说，相关框架的技术大牛会构建并检查自己 real-world 项目，确保其和别的项目的一致性。
我们正在比较哪些库 / 框架？
截至撰写本文时，RealWorld 仓库 中已有 24 个相关实现。也许有受众更多的框架没有出现在这里。但进行对比的前提只有一个 —— 它必须出现在 RealWorld 仓库 页面里。
我们关注什么指标？
性能 —— 此应用需要多长时间才能显示内容并变得可用。
大小 —— 应用有多大的体积？我们只会比较编译后的 JavaScript 文件大小。HTML 和 CSS 对所有的 RealWorld 应用都是通用的，并且都可从 CDN 下载。此外，所有技术均可编译或转换为 JavaScript，综上，我们只比较编译后的 JavaScript 文件大小。
代码行数 —— 开发者需要多少行代码才能根据规范创建 RealWorld 应用？公平来说，有些应用有更多的功能，但这应该没啥大的影响。我们只看 src/ 文件夹中各文件的代码行数。即使它是自动生成的也可以 —— 你仍需要持续维护它。
指标 #1：性能
我们使用 Chrome 的拓展插件 Lighthouse Audit 来给各个项目的性能评分。Lighthouse 会给出一个范围在 0 到 100 的分数。0 是最低分。想了解更多，请戳 Lighthouse 评分指南。
插件相关的配置
基本原则
渲染的越快，用户就能越早地使用该应用，同样，用户的体验就越好。
备注
注意：由于缺少 demo 应用，这里忽略 PureScript。
总结
Lighthouse Audit 可没闲着。您可以看到未维护/未更新的应用程序跌破了 90 分。得分超过 90 分的应用在性能上差别不大。不得不说，AppRun、Elm 和 Svelte 表现的非常出色。
指标 #2：大小
需要加载的资源的大小可以从 Chrome 中开发者工具的 Network 标签中得出。服务器提供的 GZIP 响应头和响应主体。
这取决于框架的大小以及所添加的其他依赖包。同样，构建合适的打包工具可以忽略未使用的依赖。
基本原则
文件越小，下载速度越快，并且需要解析的内容越少。
备注
注意：由于缺少 demo 应用，这里再次忽略 PureScript。
Angular + ngrx + nx 方案的支持者可别打我哟 —— 看一下 Chrome 开发者工具中的 Network 标签里的加载情况，如果我算错了 — 还请告知。
Rust + Yew + WebAssembly 方案的大小计算，包括了以 .wasm 结尾的文件。
总结
Svelte 和 Stencil 社区完成的 RealWorld 应用太棒了，把需要加载的文件控制在了 20KB 以内，可以说是前无古人了。
指标 #3：代码行数
我们使用 cloc 计算每个库的 src 文件夹中的代码行数。不包含空白行和注释。考量这个指标的意义何在呢？
如果说调试是消灭 bug 的过程, 那么编码则是产生它的过程 —— Edsger Dijkstra
基本原则
下面这张图展示了各个库/框架/语言实现的 RealWorld 应用的简洁程度。根据规范，他们各自写了多少行实现了几乎相同的应用程序（其中一些应用具有更多的功能）。
备注
由于 cloc 无法统计以 .svelte 为后缀的文件，因此 Svelte 在此不做对比。
由于 cloc 无法统计以 .riot 为后缀文件，因此 riotjs-effector-universal-hot 在此也不做对比。
Angular + ngrx: 以/libs文件夹为基础完成的代码行数统计仅包括以 .ts 和 .html 为后缀文件。如果你觉得不应该这样统计, 还望告知正确的代码行数以及你是如何统计它的。
总结
只有 Imba 和 ClojureScript + re-frame 能在 1000 行代码以内实现 RealWorld 应用。Clojure 以独特的表现力而著称。Imba 第一次出现在这里（去年是因为 cloc 还不能识别以 .imba 为后缀的文件），看起来之后会一直出现在这里。如果你关心自己项目的代码行数，那么你现在知道该怎么做啦。
最后
请记住，这并不是一个公平、合理的比较。有些在应用的实现上使用了代码拆分，有些则没有。其中有些托管在 GitHub 上，有些托管在 Now 上，有些托管在 Netlify 上。你是否仍然想知道哪一个最好？这我可回答不了。
常见问题
#1 为什么在本篇对比中不包含框架 X，Y 和 Z 呢？
因为以该框架为基础构建的 RealWorld 应用尚未在 RealWorld 仓库上出现或按照规范构建完成。考虑做出你的贡献吧！选择你喜欢的库/框架然后来构建 RealWorld 应用吧，我们下次对比将包括它！
#2 为什么你们称其为 real world？
因为它不只是一个 To-Do 应用程序。通过 RealWorld 应用，我们并不是要比较相关技术能拿到的薪水，可维护性，生产力，学习曲线等方面。这有其他调查回答了其中一些问题。我们所说的 RealWorld 是指连接到服务器，进行身份验证并允许用户进行 CRUD 操作的应用程序 —— 就像现实世界中的应用程序一样。
#3 你为什么不比较我最喜欢的框架？
请参见问题 1，但以防万一，这里还是想强调下：因为以该框架为基础构建的 RealWorld 应用尚未在 RealWorld 仓库上出现或按照规范构建完成。以上所有的 Real World 应用又不是我自己搞出来的-这是整个社区的努力结晶。如果你想在下次对比中看到你喜欢的框架，请考虑为本项目做出贡献吧。
#4 包括了哪个版本的库/框架？
所涉及的库/框架在撰写本文时（2020 年 3 月）均可用。该信息来自 RealWorld 仓库。我确定你可以在 GitHub 仓库 中找到相关信息。
#5 有比本文中出现的更流行的框架，你怎么忘记比较啦？
同样，请参阅问题 1 和问题 3。以该框架为基础构建的 RealWorld 应用尚未在 RealWorld 仓库 上出现或按照规范构建完成；原因就是这么简单。
如果你喜欢这篇文章，请 在Twitter上关注我。我只写/推有关编程和技术的文章。
如果发现译文存在错误或其他需要改进的地方，欢迎到 掘金翻译计划 对译文进行修改并 PR，也可获得相应奖励积分。文章开头的 本文永久链接 即为本文在 GitHub 上的 MarkDown 链接。
掘金翻译计划 是一个翻译优质互联网技术文章的社区，文章来源为 掘金 上的英文分享文章。内容覆盖 Android、iOS、前端、后端、区块链、产品、设计、人工智能等领域，想要查看更多优质译文请持续关注 掘金翻译计划、官方微博、知乎专栏。
