【譯】下一個你值得認真嘗試的框架 —— 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寫做，並在每一個星期四將其傳遞給讀者。訂閱按鈕就在這篇文章下面。

下次再見...