本文翻譯自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寫作，並在每個星期四將其傳遞給讀者。訂閱按鈕就在這篇文章下面。
下次再見…