Svelte + Sapper + Firebase = ❤

SvelteBase is a hobby project that was started few years ago with a goal - to create a lightweight simple and modern web framework that would make prototyping and development of web projects of any scale easy and fun, while leveraging the best out of modern tools and following simple and intuitive practices that ignite both creative and clever architecture.


Multi-language out of the box

  • Server-side generated content comes translated
  • Built-in JSON translator using GoogleTranslate
  • Ability to preserve dynamic values in the text content using XDATA (tricky hacky solution)
  • Translatable Firebase models solution

SEO Friendly

  • SSR - Server-side rendering provided by Sapper
  • Google Analytics component
  • Proper multi-language urls and meta hreflang usage
  • Sitemap generator

Sophisticated redirects

Server-side configurable redirects allow you to configure URL redirects with ease, as well as create complicated redirect rules and behaviors.

Blazing fast

Anyone who ever heard about Svelte first of all knows that it's absolutely the fastest and lightest complete SPA framework in the world.

SvelteBase didn't affect the performance of the Svelte and Sapper. Firebase is also one of the fastest BE if used properly.

Websites built with SvelteBase get 100 benchmark on the PageSpped for both desktop and mobile devices.

Firebase local emulators

Firebase is a mature system that provides enough features and tools to develop and test everything locally.

Issues and challenges

package.json and functions/package.json synchronization

Setting up SvelteBase requires to have /functions directory content of which will be deployed to the Firebase.

Hence it needs it's own package.json that includes packages required for both Svelte & Sapper and also for Firebase.

Essentially it means, that any package that is added to package.json during development process will needs to be added to added to functions/packages.json.

No access to lang attribute of html opening tag

In order to get the best out multi-language platform you also need to specify lang attribute on the root html tag.

But unfortunately current version of Sapper doesn't support custom placeholders in the template.html.

That's why by default lang attribute is not specified and we only use hreflang meta data.

Materialize CSS

Currently SvelteBase is using Materialize as CSS framework because it is simple and intuitively easy to use. However right it seems like it's not getting much improvements and doesn't grow. Also on my personal projects I already started to notice many limitations and now consider either switching to other CSS Framework or introduce ability to use different frameworks.

Server-side and client-side scripts can be confusing

  • Sapper pages use two types of runtime scripts: server-side and client-side
  • Server side scripts use node.js environment - they have context="module" attribute
  • Client side scripts use browser environment
  • If you want to get full benefits of SSR you need to use server-side scripts to render necessary content on server-side

Firebase downsides

Limited amount of projects on Firebase

By default you can create up to 5 projects on Firebase. But if you need more you will be asked to request extra projects.

Firestore pagination

With Firebase there's no way to implement classical pagination with offset and limit and instead you need to use concepts like "startAfter" or "startAt" to indicate after or at which point you want to get data set.

Firestore indexes synchronization

Firestore allows you (and for some queries requires) to use indexes to have proper performance of the queries.

However it allows to configure indexes using both Firebase Console and firestore.indexes.json.

But if indexes are configured using Firebase Console they will not be automatically reflected in firestore.indexes.json.

So you need to do it manually, because if you deploy your code to other Firebase project you will need to configure indexes again.

Slow network response

Firebase seems like to have cold-start delay, when node function is not executed often enough.