副标题：为什么解决网络应用慢的问题不是一套更复杂的工具？
发布时间：2017年3月3日 - 7分钟阅读
前段时间，我在做一个Angular应用。让我印象深刻的是，Angular其实并不仅仅是一个框架，而是在Web平台之上构建了自己的整个平台。背后的原因是为了给开发者提供一个统一的方式来构建不同平台的应用。但是，使用这种抽象的代价是什么呢？
对于你来说，作为一个Web开发者，这意味着对于你知道如何在Web上做的大多数事情，在Angular中有一个（略微）不同的版本来完成。这也意味着，当新的Web技术出现时，你无法直接接触到它们，你需要等待Angular团队为它们添加支持。ServiceWorker支持就是一个很好的例子。 不过也许最重要的是，这意味着在你的应用代码和运行Angular平台的浏览器之间不可避免地运行着一层JavaScript。这对性能有什么影响？
Angular在Angular 2及后续版本中非常强调性能。性能构建了一个高度模块化的架构，一个Ahead-of-Time（AOT）编译器和预渲染。不过在编写Angular应用的时候，我不禁觉得我可以使用Web Components构建同样的组件式应用，并让它直接在浏览器中运行。当然，这样会更快吗？
我们能不能让事情变得更简单......更快速？
在Chrome开发峰会上，我听了Alex Russell关于Web应用性能的强烈意见的演讲，我的想法得到了支持。他甚至声称，如果你使用的是框架，那么在性能方面，你 "默认是失败的"。框架专注于迎合开发者，往往以牺牲终端用户为代价。开发者需要有意识地工作（有时围绕框架），为用户提供快速的体验。在Alex的演讲结束后，我赶上了他，我们就这些问题如何被现实生活中的设备和网络进一步恶化进行了有趣的讨论。
这时我很感兴趣，想看看事实上，我是否可以用除了Polymer之外的任何东西重新创建Angular，以及该应用是否会比优化后的Angular应用更快。
为了让事情更有针对性，我把我的发现分成了两篇文章。第一篇文章将涵盖我最初的问题，Web Components是否可以用来用更少的工具构建更快的Web体验？第二部分将看看用这两种方式构建应用的实际开发者体验，以及我们如何改进这些。
应用和橙子
现在有些人可能会想，把Angular这个框架和Polymer这个库进行比较，是不是有点像在比较苹果和橘子。毕竟，一个是用来构建应用程序的，而另一个只关心构建组件。
好吧，事实证明，你用组件构建应用的方式，是通过将更小的组件组合成更多更复杂的组件，直到最后得到一个应用。所以，要构建一个基于组件的应用，你需要的是一种制作组件的方式。
Angular和Polymer都自带一套工具来帮助开发者。最值得注意的是，两者都包含了一个命令行（CLI）工具，可以用来引导新项目，并构建应用进行部署。Polymer还包括一些类似框架的功能，比如支持路由。
我的测试设置
为了比较两种构建应用程序的方法，我需要用这两种方法构建同一个应用程序。我开发的应用程序是一个模拟门户应用程序，列出并显示患者的统计数据。它由三个视图组成。1）一个登录视图，2）一个具有主/细节编辑功能的列表视图，3）一个显示图表数据的分析视图。
Angular应用除了核心的Angular框架外，还使用了Kendo Grid和Charts。Polymer应用则使用了Vaadin Grid和Charts。虽然这些组件并不完全相同，但它们在复杂性和功能上非常接近，可以用于这次比较。
我按照生产构建的说明来构建应用程序。对于Angular 2，这意味着在构建中使用Ahead-of-Time (AOT)编译和生产模式（ng build --aot --prod）。对于Polymer，我使用polymer build来创建一个捆绑式构建（将依赖关系连接到尽可能少的文件中）。这两个应用都在每个视图中使用了依赖关系的懒加载。Polymer应用构建过程额外创建了一个服务工作程序，在用户登录时将后续视图预加载到缓存中。
两个应用程序都启用了Gzip，并与本地主机上的同一个REST API进行通信。为了得到更真实的测量结果，我在Chrome开发工具中使用了一个模拟的 "良好的3G "连接与 "高端设备"。
我用Chrome浏览器进行了所有测试。我还在webpagetest.org上与部署在GitHub页面上的版本进行了对比测试。
这个东西到底有多快？
在初始加载速度方面，有一个非常明显的赢家。基于Polymer的应用仅用了0.8秒就在视觉上完成并准备好了交互。而Angular应用则花了长达4秒的时间来完成（4.8s）。对于初始加载，Polymer比Angular快了6倍。
为什么会这样呢？即使采用AOT编译，Angular 2与Polymer相比也有两个明显的劣势。首先，由于所有的东西都是在JavaScript中，所以在任何东西展示给用户之前，都需要被下载、解析和评估。另一方面，Polymer可以使用浏览器内置的流媒体功能，在下载时显示应用程序。其次，Web Components是浏览器原生结构。无论Angular输出的JS如何优化，有些东西直接在浏览器本身上运行就会更快。
对于初始加载，Polymer比Angular快6倍。
对于后续的页面加载，差别就没有那么大了。有一些差异，但我怀疑这些差异主要归结于那些页面上使用的组件（图表和数据网格），而不是使用的技术。下图总结了整个应用的性能测量。
有趣的是，当使用Safari和Web Components polyfill时，应用的加载速度也更快。
两款应用的下载量（Polymer：630kB，Angular：689kB）和代码行数（Polymer：1999行，Angular：1953行）大致相同。
那么预渲染呢？
我可以在Angular应用中使用预渲染来提高感知速度。我之所以说感知速度，是因为虽然预渲染可以让用户更快地看到（好的估计）成品页面，但增加的复杂性实际上会让页面的交互速度变慢。当脚本加载时，页面看起来很完整，但当用户试图与页面交互时，什么都没有发生。
还有其他原因，比如SEO，为什么你可能想做预渲染，但就性能而言，我想关注的是让应用达到可用状态所需的时间。
需要注意的是，Polymer不支持预渲染。相反，Polymer团队提倡使用PRPL模式来实现与预渲染相当的速度，而不需要增加在服务器和浏览器中运行应用的复杂性。
结论
Web Components的速度很快。对于最初的加载，与用Angular实现的相同应用相比，我能够实现6倍的速度提升。而且我能够用一套简单得多的工具实现这一速度提升--没有AOT编译，没有预渲染。
但另一个问题依然存在--你能只用Web Components构建真正的、复杂的应用吗？如果我们不能用Web Components来构建app，那么Web Components再快也没有什么用。Frameworks的优势在于其提供的结构，可以帮助开发者构建大型的、可维护的应用。这一点是Polymer或者一般的Web Components所不具备的。
在本文的第二部分，我将深入探讨构建这些应用的开发者体验，以及我们可能会做什么来让开发者更容易构建炽热的快速Web体验。
这两款应用的源代码都在GitHub上。
原文发表于vaadin.com。
