[聚合文章] 【译】下一个你值得认真尝试的框架 —— 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大小（缩小）
Next.js	205 KB
工兵	11.4 KB:boom:

我以为我弄错了，所以反复测试了三次，但是事实就是如此。 请记住，我只是简单使用了基本的教程，在 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 写作，并在每个星期四将其传递给读者。订阅按钮就在这篇文章下面。

下次再见...