【译】下一个你值得认真尝试的框架 —— Sapper

本文翻译自Sapper — The New JavaScript Framework You Seriously Need to Try

---

在写关于JavaScript Report的文章中，我尽可能不要去作那一个趋之若鹜的家伙。可是每隔一段时间就会有一些事情让我兴奋。Sapper是其中之一，它是一个Svelte库的上层框架，若是你喜欢快速的网站，你会喜欢 Sapper。

首先说一下关于Svelte，它的工做方式与您可能熟悉的其余一些前端库/框架不一样。您的代码会在构建时被编译，这有很大的性能优点。事实上，Svelte是近期基准表现中性能最佳的框架之一。

可是，Svelte与React相似，它将路由，构建过程等工做都留给了开发者来完成。这些事情可能须要作不少工做才能实现。这就是Sapper出现的缘由。它为这一套繁重的工做提供了一套完整的解决方案。它包括以下内容：

• 服务端渲染
• 路由
• 代码分割
• 默认支持渐进式web应用（PWA）
• 预取路由
• 单独的头标签（meta，link等）
• 做为静态站点弹出
• Cypress测试（免费，简单，端到端的测试）

若是你熟悉Next.js这个基于React的框架的话，你就会发现它也是在作相同的事情，可是它们之间有一个主要的差别 - 更好的性能。

为了说明Sapper的潜在性能优点，我决定用Next.js作一个快速的比较。我都遵循每一个框架的基本“入门”说明来构建了一个基础应用。在这方面，二者都有很是好的文档，因此这部分进行得都很顺利，虽然Svelte包括一些演示路线，这也是很好的。

而后，我作了两个生产构建，得出的结论十分惊人，让咱们来一探究竟：

框架	总JS大小（minified）
Next.js	205 KB
Sapper	11.4 KB💥

我觉得我弄错了，因此反复测试了三次，可是事实就是如此。 请记住，我只是简单使用了基本的教程，在Next.js包中可能有一些很酷的东西，我不知道。但个人第一印象是 - “哇！”

为何这是一个大问题

在过去的几年里，已经有不少关于网络性能的案例研究。结果代表，即便是适度的性能改善也会产生很是大的影响 —— 它会带来更多的收入，更多的用户参与以及更低的成本。Google research的一个快速统计数据- 有移动网站被放弃由于加载时间超过3s而被53％的用户所放弃。这很是让人震惊。

在最近的一篇文章中，Addy Osmani深刻研究了为何JavaScript对Web性能有着特别重大的影响。一个100KB的JavaScript文件对性能的影响不等于一个100KB的图像，由于JavaScript除了加载还包含了解析和编译成本：

长时间的解析/编译代码会严重延迟用户与您的网站互动的时间。也就是说您发送的JavaScript越多，在网站交互以前解析和编译的时间就越长。

做为一名开发者，我常常忘记普通用户的手机比我慢得多。下面是一个很好的提醒图像。这是来自Addy的文章，并显示了解压缩1MB的未压缩的JavaScript的成本。以红色突出显示的设备是平均设备。

咱们能够从上图中得出如下结论：

在市场上最快的手机和普通手机之间解析/编译代码的时间有2-5倍的差别。

文章继续给出一个真实的例子 - CNN网站。

在高端的iPhone 8上，解析/编译CNN的JS须要花费大约4秒，而普通手机（Moto G4）则只须要13秒。 这能够显着影响用户与本网站彻底交互的速度。

框架为开发者提供了不少好处。好比加速开发，减小错误，并提供跨项目的一致性。他们也有不少小东西能够增长“开发者体验”，让咱们的生活更轻松。可是，这些东西大部分都是有代价的。

像Sapper这样的框架提供了一箭双鵰的功能 - 为用户提供了出色的开发者体验和卓越的性能。即便在移动端！

一个警告

对于Sapper来讲，如今就开始使用它还为时过早。正如指南所述：

Sapper正处于早期发展阶段，有些事情在咱们打到初版以前可能会改变。

固然，这样一个很是年轻的框架并不适合每个项目。可是我很高兴看到Sapper的将来会发生什么。我打算使用它本身为即将到来的项目。我会让你知道它是怎么回事！

若是你喜欢这个帖子，请注册个人每周通信。我策划来自网络的最佳JavaScript写做，并在每一个星期四将其传递给读者。订阅按钮就在这篇文章下面。

下次再见...