[Jacek Schae] 原作,授权 LeanCloud 翻译。
又到了评测前端框架的季节。我们在 [2017]、[2018]、[2019] 年都做了评测,今年(2020 年)是第四次评测。
首先申明,这个评测绝对没有钦定你下个项目该用哪个框架的意思。这只是一个小小的、相对简单的评测,只基于相似的应用比较框架的性能、尺寸、代码行数。
我们将基于 RealWorld 示例应用对比前端框架。RealWorld 示例应用的特点:
- RealWorld 应用
比待办事项类应用更复杂。通常待办事项类应用不足以传达足够多的知识见解构建实际应用。
- 标准化
项目遵循特定规则。提供后端 API、静态标记语言、风格、API 规范。
- 专业人士编写、审阅
理想情况下,会是高一致性、高真实度的项目,由使用该技术的专业人士编写或审阅。
比较的库和框架
撰写本文时,RealWorld 示例应用仓库共包括 24 个 Conduit (Medium.com 克隆应用)实现。
本文不考虑框架的流行程度,RealWorld 仓库中列出的前端框架皆纳入对比范围。
测度
性能
应用显示内容、可以使用需要花多久?
尺寸
应用有多大?我们只比较编译后的 JavaScript 文件大小。所有应用使用同样的 CSS 样式文件,CSS 文件加载自 CDN。所有应用使用的 HTML 也是一样的。这些框架都支持编译或转换为 JavaScript,所以我们仅仅测量 JavaScript 文件大小。
代码行数
根据规范创建 RealWorld 应用需要多少行代码?公平地说,某些实现的功能要略微多一点,但这应该没有什么显著的影响。我们仅仅测量每个应用的 src/
目录。
性能
我们将使用 Chrome 的 [Lighthouse Audit] 测试性能。Lighthouse 返回 0 至 100 间的评分。0 为最低分。详见Lighthouse 评分指南。
配置
所有测试均使用如下配置:
理据
首次渲染越快,到可以进行操作的时间越短,应用的用户体验就越好。
附注
我们跳过了 PureScript,因为它没有 Demo 应用。
结论
Lighthouse Audit 并没有停滞不前。你也许注意到了,在今年的评测中,一些没有维护更新的项目得分低于 90。如果你的应用得分超过 90,那么几分的差异基本不影响用户体验。话是这么说,AppRun、Elm、[Svelte] 的表现让人印象深刻。
尺寸
传输尺寸根据 Chrome 开发者工具的网络标签页统计,包括服务器送达的响应头和响应体(经过 GZIP 压缩)。
这取决于框架的尺寸以及额外依赖的尺寸,还有构建工具精简未使用代码的效率。
理据
文件越小,下载越快,需要解析的内容越少。(下图中的单位为 KB。)
附注
我们跳过了 PureScript,因为它没有 Demo 应用。
请别抱怨 Angular + ngrx + nx 的结果不对劲,你可以自行打开 Chrome 开发者工具 验证。如果发现我犯错,请告诉我。
计算 Rust + Yew + WebAssembly 的尺寸时包括了 .wasm
文件。
结论
[Svelte] 和 Stencil 社区做得很好,把尺寸控制在 20 KB 以内,了不起。
代码行数
我们使用 [cloc] 计算每个仓库的 src 目录的代码行数,不计空行和注释。为什么要比较代码行数?这是因为:
如果说调试是移除软件 bug 的过程,那么编程一定是植入 bug 的过程。Edsger Dijkstra
理据
下面的图表显示了给定的库/框架/语言有多凝练。根据规范实现几乎完全一样的应用(某些应用功能略多一点)需要多少行代码。
附注:
本文刚发表时没有 Svelte 的数据,感谢 [Svelte master] 提供计算 Svelte 项目代码行数的方法。
我们跳过了 riotjs-effector-universal-hot,因为 [cloc] 无法处理 .riot
文件。
Angular+ngrx 只计算了 libs
目录中的 .ts
和 .html
文件,如果你认为这么算不对,请告诉我正确的数字及其计算方法。
结论
就代码行数而言,只有 Imba 和 ClojureScript + re-frame 做到了用 1000 行代码实现应用。Clojure 以异常高的表达力而闻名。Imba 是今年评测中新加入的(去年的评测没有包括 Imba,因为 cloc 当时不能处理 .imba
文件格式)。如果你在乎代码行数,你知道要选哪些框架。
总结
别忘了这并不是一个精确公平的对比。有些实现分离了代码,有些没有。有些部署在 GitHub 上,有些部署在 Now 上,有些部署在 Netlify 上。如果你仍然要问哪个最好?你需要自己回答这个问题。
FAQ
1. 为什么不对比框架 X、Y、Z?
因为 RealWorld 仓库 中的实现不完整。考虑下贡献代码!用你最喜欢的库/框架实现一下,我们会在下次对比中包含它们!
2. 为什么称它为 RealWorld?
因为它的功能要比 To-Do 应用复杂。RealWorld 并不意味着我们会对比薪资水平、维护水平、生产率、学习曲线等要素,有其他调研回答了这些问题中的一部分。RealWorld 的意思是这个应用会像真实世界项目一样,连接一个服务器,认证用户,允许用户增删改查。
3. 你为什么没纳入我最喜欢的框架?
请回过头去看看上文的第一问。不过我这里还是想强调下:因为 RealWorld 仓库 中的实现不完整。这些实现是社区共同努力的结果,而非我一人所为。如果你想在对比中看到自己最喜欢的框架,考虑下贡献代码。
4. 对比的是哪个版本的库/框架?
本文撰写时(2020 年 3 月)可用的版本。详见 RealWorld 仓库。
5. 为什么没有对比某个流行得多的框架?
再一次,看看前面的问题。很简单,RealWorld 仓库 中的实现不完整。
如果你喜欢这篇文章,可以在 Twitter 上关注我。我只发编程、技术方面的推。
译者注:实现上的种种差异及其他因素对结果会有很大影响,因此图表仅供参考,并不能准确地体现框架的高下。况且,框架的选型涉及众多因素,大多数场景下,有许多因素的权重远高于性能、尺寸、代码行数。最好的框架是哪个,每个人可能有不同的答案。
**粗体** _斜体_ [链接](http://example.com) `代码` - 列表 > 引用
。你还可以使用@
来通知其他用户。