前端框架哪家强？

小型全栈式 App RealWorld Conduit 最近更新了其基准测试结果。这款 App 分别采用 18 个不同的前端框架构建，并对它们进行了比较。结果显示，18 个框架当中有 13 个获得了顶级的 LightHouse 的分数（也就是在总分 100 分的情况下获得 90 以上）。在这 18 个框架当中，Svelte、Stencil、AppRun、Dojo、HyperApp 和 Elm 的网络传输负载最低（低于 30KB）。

自称为”演示 App 之母“的 Conduit 是对 Medium.com 的全栈式克隆，采用了一组[API 规范](https://github.com/gothinkster/realworld/tree/master/spec)，并带有具备真实世界复杂性的功能。[RealWorld 项目](https://github.com/gothinkster/realworld)核心维护者 Eric Simons 解释说：

> 它就像是[TodoMVC](http://todomvc.com/)，只是使用全栈技术实现。RealWorld 向大家展示了如何使用 React/Angular 等框架在 Node/Django 等平台上构建真实的博客平台。开发者可以把它们混合起来，因为它们都遵循相同的 API 规范。

RealWorld 基准测试始于 2017 年，最近更新了针对使用 18 个不同前端框架实现的 Conduit 的评估结果。2019 年的基准测试排名主要关注这三个方面：性能、大小和代码量。

性能分数是通过[LightHouse](https://github.com/GoogleChrome/lighthouse)来评估的。LightHouse 是一个非常流行的用于改进 Web 质量的自动化工具。LightHouse 对性能、可访问性和渐进式 Web App 进行审计，并基于[六个加权指标](https://docs.google.com/spreadsheets/d/1Cxzhy5ecqJCucdf1M0iOzM8mIxNc7mmx107o5nj38Eo/edit#gid=0)给出性能评估分数。这六个指标按照重要程度排序如下：

* TTI（[Time to Interactive](https://developers.google.com/web/tools/lighthouse/audits/time-to-interactive)）：让一个页面变得可交互需要多长时间。

* 速度指数（[Speed Index](https://developers.google.com/web/tools/lighthouse/audits/speed-index)）：页面处理内容的速度，分数越低也好。

* FCP（[First Contentful Paint](https://developers.google.com/web/tools/lighthouse/audits/first-contentful-paint)）：从导航一个页面到浏览器开始渲染 DOM 第一个字节的时间。

* FCI（[First CPU Idle](https://developers.google.com/web/tools/lighthouse/audits/first-cpu-idle)）：页面达到最小化可交互的时间（不需要等到页面上的所有元素都可交互，只要可以对大部分用户输入做出响应即可）。

* FMP（[First Meaningful Paint](https://developers.google.com/web/tools/lighthouse/audits/first-meaningful-paint)）：用户感知到页面主要内容可见的时间。

* 预估的输入延迟（[Estimated Input Latency](https://developers.google.com/web/tools/lighthouse/audits/estimated-input-latency)）。

LightHouse 将性能分数分为三组。90 到 100 分为顶级，表示性能最好的网站。在 RealWorld 基准测试中，大部分（18 个中有 13 个）Conduit 实现属于这一组。前 13 个框架中包括已经很成熟的框架（如 Elm、Dojo、Vue、Angular、Aurelia、Stencil、Svelte 和 React）、简约型框架（如 AppRun、Hyperapp）、较少被使用的框架（如 Crizmas 或 reframe）以及可编译成 JavaScript 的框架 Imba。

这 18 种 Conduit 实现也根据大小进行了排名。基准测试作者详细介绍了这一标准背后的原理及其计算方法：

> 传输大小是从 Chrome 开发者工具的 Network 页面获得的，包括 GZip 压缩的响应头和响应体……文件越小下载就越快，需要解析的东西就越少。

在性能最好的 13 个框架中，有 6 个（Svelte、Stencil、AppRun、Dojo、HyperApp 和 Elm）的传输大小小于 30KB：


他们通过[k-means 聚类算法](https://en.wikipedia.org/wiki/K-means_clustering)将 18 个框架的传输大小分为 5 类。

框架的特点可以用来解释为什么它们的传输大小可以达到这么小：

* Svelte 自称为”神奇的即逝 UI 框架“，将 API 编译成最优化的 JavaScript。

* Stencil 的运行时只有 6KB，并可以编译成 Web 组件。

* AppRun 和 HyperApp 的体积非常小（分别为 3KB 和 1KB）。

* Dojo 最近推出了自动代码拆分特性，并针对 PRPL 性能模式进行了优化。

* Elm 0.19 针对资产文件进行了优化。

前端框架的繁荣促成了基准测试的流行，这些[基准测试](https://github.com/krausest/js-framework-benchmark)旨在通过各种有意义的方式对框架进行比较。基准测试涉及的框架可能是各种各样的，具体取决于要比较哪些方面的内容、基准测试的方法和相关性以及分数的算法。但是，在选择前端框架时，还是要进行全盘考虑，包括质量和数量方面的指标。