Why you shouldn't use Svelte's Sapper just yet published 2/22/2021 | 3 min read

TLDR;

If you know that Sapper will be replace soon with Svelte Kit and still want to use Sapper: read on!

Svelte is cool, almost every front-end developer will say so

Welcome everyone to a new devspedia story. Let's get straight to it; Svelte is cool, we know - check 2020 state of js -, and having an official framework to have all the SSR magic out of the box, is even cooler for performance and SEO.

The following is based on a real-world experience. I tried Svelte and Sapper before writing this. In fact, this site is running on Sapper.

Sapper is pretty good tool in terms of how simple and easy to use, however, it's lacking some core functionalities related to a universal app.

Universal code

So, since this is a universal app, there are node code, and browser code. If you're using a shared module between both, you'll start to get into issues, one of the biggest issues I faced was using Firebase & Firestore.

Try an alternative if you're planning to use Firebase

The only meaningful way to use Firebase in a Sapper app currently is either on the browser side, or in the node side, but not both at the same time.

The reason for this is firebase uses ESM module for the browser, and a common js module for node, both have different implementation based on the execution env.

So you'll need to load firebase ESM module on the browser, and firebase common js modules on node js side. This is doable using rollback configurations that Sapper have in both client and server, but if you choose to prioritize mainkey from package.json in rollup server config (so firebase can pick common js module), and module on the client side, then sapper itself will crash unfortunately. Only ESM works with Sapper internals.

Alternatives

Use Svelte (or lit-element) and implement SSR via Puppeteer or Playwright
Use next or nuxt

That's all for today's story. Thanks for reading devspedia, I love you, and I'll see you the next time :)