In my writing here on JavaScript Report, I try not to be a cheerleader. But every once in a while something comes along that gets me excited. Sapper is one of those things. It’s a new JavaScript framework built on top of the Svelte library. If you like fast websites, you’re going to love Sapper.
First, a bit about Svelte. It works differently than some of the other front end libraries/frameworks that you may be familiar with. Your code is compiled at build time and this has big performance benefits. In fact, Svelte is one of the best performers in recent benchmarks.
However, Svelte is similar to React in that it leaves things like routing, build process, etc. to the developer. Those things can be a lot of work to implement. That’s where Sapper comes in. It’s a framework that takes care of all that heavy lifting. It includes things like:
- Server rendering
- Routing
- Code splitting
- Progressive web app by default
- Prefetching of routes
- Per route head tags (meta, link, etc.)
- Ejecting as a static site
- Cypress tests (free, easy, end-to-end testing)
If you’re familiar with Next.js, the framework built on top of React, it’s the same idea, but with one major difference — better performance.
To test the potential performance benefits of Sapper, I decided to do a quick comparison of it with Next.js. In each case, I followed the basic “Getting Started” instructions for each framework. Both have very good documentation, so this part was smooth for both, although Svelte includes some demo routes, which was nice.
I then did a production build for both and the results were pretty amazing. Check it out:
| Framework | Total JS size (minified) |
|---|---|
| Next.js | 205 KB |
| Sapper | 11.4 KB 💥 |
I ran these tests three times thinking I had made a mistake, but no, those are really the numbers. Keep in mind, I was just stepping through the basic tutorials and there could be some cool things in the Next.js bundle that I don’t know about. But my first impression is — Wow!
Why This Is a Big Deal
Over the past few years there have been a lot of case studies published about web performance. The results show that even modest performance improvements can have very big impacts — more revenue, more user engagement, and reduced costs. One quick statistic from Google’s research — 53% of mobile sites that take longer than 3 seconds to load are abandoned. That’s pretty sobering.
In a recent article, Addy Osmani dug deep into why JavaScript has an especially big impact on web performance. A 100KB JavaScript file is not equivalent to a 100KB image. This is because JavaScript has parse and compile costs:
Spending a long time parsing/compiling code can heavily delay how soon a user can interact with your site. The more JavaScript you send, the longer it will take to parse & compile it before your site is interactive.
As a developer, I often forget that the average user has a much slower phone than I do. Below is an image that serves as a great reminder. It’s from Addy’s article and shows parse costs for 1MB of uncompressed JavaScript. The device highlighted in red is the average device (click image to view larger).
From the article:
There is a 2–5x difference in time to parse/compile code between the fastest phones on the market and average phones.
The article goes on to give a real-world example — the CNN website.
On the high-end iPhone 8 it takes just ~4s to parse/compile CNN’s JS compared to ~13s for an average phone (Moto G4). This can significantly impact how quickly a user can fully interact with this site.
Frameworks offer a lot of benefits to developers. They accelerate development, reduce bugs, and provide consistency across projects. They also have a lot of little things that add to “developer experience” and make our lives easier. Most of these things, however, come with a cost.
Frameworks like Sapper provide the best of both worlds — great developer experience and outstanding performance for users. Even on mobile!
One Caveat
For Sapper, it’s still early days. As the guide states:
Sapper is in early development, and some things may change before we hit version 1.
A very young framework like this isn’t going to be the right fit for every project, of course. But I’m excited to see what the future holds for Sapper. I plan on using it myself for an upcoming project. I’ll let you know how it goes!
If you’ve enjoyed this post, sign up for my weekly newsletter. I curate the best JavaScript writing from around the web and deliver it to readers every Thursday. The sign up form is right below this article.
Until next time, happy coding…