What’s Sapper ?
Built on top of Svelte, Sapper is an app framework (or “metaframework”) (which is a component framework). Its responsibility is to make it simple to create Svelte apps using all current best practises, including server-side rendering (SSR) and code-splitting, and to offer a project structure that encourages efficient and enjoyable development. It makes use of filesystem-based routing (as made popular by Next and adopted by many other frameworks, albeit with some improvements) in which the file structure of your project corresponds to the app’s actual structure.
Although the Svelte homepage and documentation advise you to degit the sveltejs/template repo to begin building an app, Sapper has long been our preferred method of doing so; in fact, this very blog post is being rendered with Sapper as of this writing!
Why are we moving to a new system?
First off, newcomers to Svelte may find the distinction between sveltejs/template and sveltejs/sapper-template confusing. We can streamline onboarding, lessen the maintenance and support burden, and perhaps even start to explore the new possibilities that are made possible by having a predictable project structure by having a single recommended way to start building apps with Svelte. (This final sentence is purposefully ambiguous because it will take some time to fully comprehend what those possibilities are.)
In addition to all of that, we have long been tempted to rewrite Sapper. This is partially due to the codebase becoming a little disorganised over time (Sapper started in 2017), but primarily because the web has undergone significant recent change, necessitating a reevaluation of some of our fundamental presumptions.
What distinguishes this new concept?
The first of those underlying presumptions is that in order to create apps, you must use a module bundler like Webpack or Rollup. In order to create code bundles that can be executed anywhere, these tools follow the dependency graph of your application, analysing and changing code along the way (converting Svelte components to JS modules, for example). Rollup was first developed by me, so I can vouch for the fact that it is a surprisingly complex issue with tricky edge cases.
When browsers didn’t support the import keyword natively a few years ago, you definitely needed a bundler, but that is much less true now. The unbundled development workflow is currently on the rise and is radically simpler: rather than eagerly bundling your app, a dev server can serve modules (converted to JavaScript, if necessary) on-demand, making startup virtually instantaneous regardless of how big your app grows.
This movement’s forerunner, snowpack, is what drives SvelteKit. We’ve been collaborating closely with the Snowpack team on features like SSR. It’s incredibly fast and has a beautiful development experience (hot module reloading, error overlays, etc.). If you’re used to using Sapper with Rollup, the hot module reloading is especially revelatory (which has never had first-class HMR support owing to its architecture, which prioritises the most efficient output).
Not that we’re completely giving up on bundlers, though. Your app must still be optimised for production, and SvelteKit uses Rollup to make your apps as quick and efficient as they can be (which includes things like extracting styles into static .css files).
The second fundamental tenet is that a server-rendered app requires, well, a server. Sapper essentially has two modes: sapper export, which bakes your app out as a collection of static files suitable for hosting on services like GitHub Pages, and sapper build, which creates a standalone app that must run on a Node server.
Static files can basically go wherever they want, but managing a Node server (and scaling it, monitoring it, etc.) is more difficult. Today, we see a move toward serverless platforms, which free app developers from having to worry about the complicated server environment in which their code runs. Vercel-sapper, for example, makes it possible for Sapper apps to run on serverless platforms, but it’s hardly idiomatic.
Both Node apps and fully pre-rendered (also known as exported) sites can still be produced.
The serverless paradigm is fully embraced by SvelteKit, which will launch with support for all the major serverless providers and a “adapter” API for aiming at any platforms we don’t officially support. Additionally, we’ll be able to perform partial pre-rendering, allowing us to generate static pages at build time while rendering dynamic ones only as needed.
When am I able to use it?
If you’re up for it, you can begin right away:
npm init next@svelte
A new project will be scaffolded and the @sveltejs/kit CLI, which offers the tools for creating an app, will be installed.
But we do not advise it! We won’t be able to provide any kind of support and there are no documents. Furthermore, it might break frequently.
While we’re still in exploration mode, the work is being done in a personal monorepo. Once a few issues have been resolved, we intend to release a public beta and make an announcement about it here. Until then, the repo will remain private, but we’ll set up a location to solicit feedback from the YOLO community. Following that, we’ll work towards a 1.0 release that requires opening the repo.
Because I dislike breaking promises, I won’t make any firm promises about timing. But I believe that instead of months, we are talking about weeks.
What if I decide against utilising SvelteKit?
You won’t have to because Svelte can always be used independently or with a bundler integration like rollup-plugin-svelte. No matter how specialised your workflow, we believe it is crucial that you can modify Svelte to fit it and use external app frameworks like Elder.js, Routify, Plenti, Crown, JungleJS, and others.
TypeScript?
We won’t launch without complete TypeScript support, so don’t worry.
How do I move my current Sapper apps?
A Sapper codebase migration should, for the most part, be fairly simple.
In general, a SvelteKit app will feel very familiar to Sapper users. There are some unavoidable changes (being able to run on serverless platforms means we need to replace custom server.js files and (req, res) =>… functions with more portable equivalents), and we’re taking the opportunity to fix a few design flaws.
What part can I play?
Watch for announcements about when we’ll start the public beta and open the repository. (Also, blog post TODO, but I’d be remiss if I didn’t point out that we now have an OpenCollective where you can donate money to the project if it’s been useful to you. Thank you so much to those of you who have already done so.)
How can I find out more?
Visit svelte.dev/chat and follow @sveltejs and @SvelteSociety on Twitter. In a future episode of Svelte Radio, Kevin and his co-hosts will question me about this project, so you should subscribe to that as well (and between now and next week when we record it, reply to this Twitter thread with your additional questions).