Experimenting With Svelte - Why? #

Introduction

This is part of a series of notes documenting some experiments with the Svelte and SvelteKit code stack. To see a full list of posts in this series visit the project link

What is Svelte?

Svelte 3 was released in 2019, and claims to be “a radical new approach to building user interfaces”. In the launch post Rich Harris explains:

Svelte is a component framework — like React or Vue — but with an important difference. Traditional frameworks allow you to write declarative state-driven code, but there’s a penalty: the browser must do extra work to convert those declarative structures into DOM operations, using techniques like virtual DOM diffing that eat into your frame budget and tax the garbage collector.

Instead, Svelte runs at build time, converting your components into highly efficient imperative code that surgically updates the DOM. As a result, you’re able to write ambitious applications with excellent performance characteristics.

In other words, it’s a compiler that outputs vanilla Javascript

And Svelte Kit?

In the real world a purely front-end framework only goes so far. Most apps need to authenticate users and pull data from APIs, and increasingly the most secure way of doing this is seen as the backend-for-frontend (BFF) pattern, in other words hosting the backend APIs on the same domain as the frontend app.

Although this has always been possible, historically the back-end was often written in a different language from the front-end, and sometimes in a seperate (but related) project.

There’s often an advantage in having a single language for front- and back-ends, especially if the same person or team is developing them. One approach is Microsoft’s inclusion of Blazor in ASP.Net, allowing C# code to be compiled to WebAssembly. In the Javascript world, specifically for teams using the React framework on the front-end, Next.js offers the abililty to build front- and back-end in a single project, with clever build technology separating the output packages appropriately. Add-in dedicated hosting like Vercel and single-click deployment of a front-end served fro the edge together with serverless functions to implement the back-end becomes a reality.

The equivalent of Next.js for Svelte is Svelte Kit, which in turn is a reevelopment of the team’s earlier application framework Sapper.

To quote from the Svelte Kit docs:

SvelteKit is a framework for building extremely high-performance web apps. Building an app with all the modern best practices is fiendishly complicated. Those practices include build optimizations), so that you load only the minimal required code; offline support; prefetching pages before the user initiates navigation; and configurable rendering that allows you to generate HTML on the server or in the browser at runtime or at build-time. SvelteKit does all the boring stuff for you so that you can get on with the creative part.

And SvelteKit does this all while providing a lightning-fast development experience where changes to your code show up in your browser automatically. We do this by leveraging Vite with a Svelte plugin, so that updates are instant and precise without reloading the page or blowing away application state.

In terms of hosting, the approach in Svelte Kit is to provide adapters which hook into the build process and modify the output to work on different hosts, such as Netlify, Vercel, or even for purely static files.

What do I want to find out?

Firstly I want to see if the promises of development speed and simplicty of code are reflected in reality.

Then I want to explore adding some key common features, such as:

  • mixing static, server-side rendered and client-side rendered content in an app
  • adding APIs
  • deploying to serverless hosts
  • adding authentication against external identity sources
  • managing authorization

The code from the experiments is on Github.

Avatar
Proactive application of technology to business

My interests include technology, personal knowledge management, social change

Related