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
- 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)|
|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.
As a developer, I often forget that the average user has a much slower phone than I do.
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!
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'd like to connect, I'm on Twitter and my DMs are open.