I gave a talk at CascadiaJS 2024 on what's new in Svelte 5. What follows is a full transcript of the talk. You can also grab the slides (Keynote and PDF available).

I gave this talk before Svelte 5 was officially released, but it should still be largely applicable.

Let's look at what's new in Svelte 5 and how it makes Svelte apps more performant, more scalable, and easier to reason about. We'll also unpack why the changes were made and how they were rolled out.

My name is Geoff. Svelte is a JavaScript framework that I contribute to, and today I’m going to talk about what’s changing in the next major version of Svelte and why.

But first — there’s a good chance that some of you have never heard of Svelte. So what is Svelte?

In one sentence, Svelte is a compiled, batteries-included, HTML-first JavaScript framework that prioritizes vibes.

Let's break that down.

If you know anything about Svelte, it’s probably that it’s a compiler. A compiler is a program that takes code written in one programming language and transforms it into another language. In Svelte’s case, it takes Svelte component code — which looks similar to HTML — and transforms it into tightly-optimized vanilla JavaScript.

This was a super novel approach to front-end frameworks when Svelte first came out in 2016; now having a compiler in your framework is less unique. SolidJS uses a compiler in ways similar to Svelte but uses JSX as the template language of choice. Vue has had compiler-driven optimizations for a while and is working on an experimental “vapor mode” that drops the virtual DOM completely in favor of a compiler. And last month React open sourced their experimental compiler “React forget” so you can stop hand-optimizing your React component rendering.

Something that I think makes Svelte special is that we are compiler-first and compiler-only. Compilation is not a separate mode for us; it is a fundamental of the framework. Svelte components don’t need to run in the browser as-is. So we can start with what we want the authoring experience to be, and use the compiler to make that possible. This results in component code with very minimal boilerplate, and also lets us make a ton of performance optimizations that result in small, fast web apps.

Svelte also aims to to be batteries-included. Instead of only being a component framework, we also provide solutions to common web-app concerns, like scoped styling, input bindings, intro and outro animations, accessibility warnings, and even spring physics.

Svelte is also HTML first. We think HTML is a pretty good language for describing UI, and want Svelte to feel like a reactive extension on top of HTML, not JavaScript. Whereas React starts with JavaScript and adds HTML to it with JSX, Svelte takes HTML and enhances it with JavaScript reactivity.

We also prioritize Svelte’s unique vibes. Being small and fast is great, and those are priorities for us — but what we optimize for is how it feels to write Svelte and the aesthetics of it. And vibes is something we’re going to come back to as we talk about the next major version of Svelte and what’s changing, because I think optimizing for vibes is a key part of successfully making a breaking change.

Part of making a change like this — and I’ll get to exactly what that change is in a second — is making sure that the project after the change still feels like the same project. People get attached to the vibes of the framework they use. If you’re changing your framework, you want the vibes to be the same, or at least similar.

Because if you make a breaking change and it feels like a completely different framework — well, maybe you should have just made a new framework? Despite the significant changes coming in Svelte 5, we still think it feels like Svelte, and we hope our users do too.

In case you haven’t used Svelte before, here’s what a component currently looks like in Svelte 4. A lot of this will be changing in Svelte 5, but the shape of a Svelte component will remain — and less may change than you might think. So, Svelte components look like HTML. Here we have a simple counter component

<script>
    export let text = 'Click me!';

    let count = 0;
    $: doubled = count * 2;
    $: if (count > 10) {
        console.log('more than 10')
    }

    function increment() {
        count++;
    }
</script>

<button on:click={increment}>{text}</button>

<p>Count: {count}</p>
<p>Doubled: {doubled}</p>

Down below you have the template for your component, and the logic lives in the script tag. You can also have a style tag containing scoped styles for the component, but we’re going to focus on the script section today.

On the first line we use export let to define a component prop, in this case a “text” prop to set the counter button’s text.

We can also define a state variable with let, just like you would declare a regular JavaScript variable. In this case, we’re defining a piece of state called count that we use in the template by wrapping it in curly braces.

Importantly, and what a lot of people like about Svelte, is that you can update that state variable directly, without needing to use a setCount function or other framework abstraction. When we call count++ in the increment function, the DOM will update with the new value of count.

You can also define derived values using the $: label syntax. In this case, we’re creating a variable called doubled, and saying that it should always be two times the value of count. Whenever we update count, Svelte will automatically update the value of doubled as well.

Finally, $: also defines a reactive block, where you can run some code after any of the state variables referenced in the block change. In this case, whenever count is updated, this block will run and log a message if count is greater than 10

So, Svelte works great today, and a lot of people love Svelte.

However, the core of Svelte hasn’t really changed in 5 years, since Svelte 3’s release in 2019. And so as the current API got more and more usage, we noticed some areas of improvement.

5 years is also a long time in the web dev world. 5 years ago:

• React had just released hooks
• If you were writing React, you were probably using create-react-app. That app might still be using create-react-app
• Vercel was called ZEIT
• Vue was still on version 2, and only just proposing what would become the composition API
• SolidJS wasn’t well-known yet
• Microsoft Edge was still its own browser engine instead of being Chromium in a trenchcoat
• If you were unlucky, you still had to support IE 11

Think of how much frontend frameworks and the frontend in general has changed since then. With Svelte 5, we’re taking advantage of all the learnings and innovations that other frameworks have made in the last 5 years, and using them to make Svelte even better than it already is.

So what does it mean to make Svelte better?

Summarized, Svelte 5’s main goal is universal, runtime reactivity. With this change, we hope to make Svelte more scalable and able to tackle projects of any size, and also make Svelte’s mental model more consistent and easier to learn.

universal reactivity

Let’s start with universal reactivity. Today, Svelte has two reactivity models. There’s the easy-to-use reactivity model inside Svelte components, but that reactivity model doesn’t work if we try to move it to a separate file. Let’s take another look at the example I showed.

<script>
    let count = 0;
    $: doubled = count * 2;
    $: if (count > 10) {
        console.log('more than 10')
    }

    function increment() {
        count++;
    }
</script>

Let’s say you wanted to wrap up the “counter” reactivity code into a utility that could be used anywhere. You can’t just copy paste the code into a JS file or even move it into a function inside the component — Svelte’s reactivity model only works at the top level of Svelte components. Instead, to move it we need to rewrite to a completely different reactivity API — stores.

Here’s what that might look like. Don’t worry about understanding this code — the details are beside the point.

import { writable, derived, readonly } from 'svelte/store';
import { onDestroy } from 'svelte';

export function createCounter() {
    let count = writable(0);
    let doubled = derived(count, $count => $count * 2);

    let unsub = count.subscribe($count => {
        if ($count > 10) {
            console.log('more than 10');
        }
    })

    onDestroy(unsub);

    function increment() {
        count.update(n => n + 1);
    }

    return { count: readonly(count), doubled, increment };
}

Just notice what I’ve highlighted — this is what you had to change in order to extract the code from the component. That’s a lot to change just so you could share this reactivity between multiple components. And because that makes refactoring difficult, Svelte components often grow larger than necessary.

But what if you could just copy-paste your reactivity code into a different file and it would work? What if we could use Svelte’s component reactivity model everywhere? Well — that’s universal reactivity in Svelte 5. But before showing what that looks like, let’s discuss the other big change.

runtime reactivity

Svelte 5 also moves from compiler-based reactivity to runtime reactivity.

Svelte 4’s reactivity uses compile-time static analysis. The compiler analyzes your code to determine which variables you’re updating where, and then adds code to invalidate data at the right time. This works well most of the time, but there are some extremely tricky edge cases that are hard to solve with a compiler based model. It makes other kinds of refactoring tricky as well.

For instance, looking at the component code from earlier, let’s say that doubling a number was a verbose operation that we wanted to move into its own function. In Svelte 4, if you do this, you’ll actually break Svelte’s reactivity and doubled will no longer respond to changes in count. Doubled’s dependency on count is now invisible to the compiler.

// this doesn't work!
$: doubled = timesTwo();
function timesTwo() {
  return count * 2;
}

Instead, in Svelte 4, you need to pass count as an argument so that the compiler understands that this function should re-run when count changes. But it’s unintuitive and easy to miss a variable when refactoring large reactive blocks.

// instead, do this
$: doubled = timesTwo(count);
function timesTwo(num) {
  return num * 2;
}

So in Svelte 5, the compiler is no longer responsible for determining reactive dependencies. Instead, those are determined when the code runs in the browser. This doesn’t mean Svelte is dropping the compiler — far from it. It’s just not using it for reactive dependency tracking anymore. We’ll talk more about the implications of this later. So, this is what Svelte 5 delivers — universal, runtime reactivity. Now let’s see what that looks like in practice. It’s time to talk runes.

runes

Runes are the new way to express reactivity in Svelte 5. That same Svelte 4 component we looked at, would look like this in the new reactivity system:

<script>
    let { text = 'Click me!' } = $props();

    let count = $state(0);
    let doubled = $derived(count * 2);
    $effect(() => {
        if (count > 10) {
            console.log('more than 10')
        }
    });

    function increment() {
        count++;
    }
</script>

Let's break this down.

In Svelte 5, those function-like symbols starting with a dollar sign are called runes. But they’re not actually functions and you don’t import them to use them. Think of them as instructions to Svelte’s compiler. These runes replace Svelte’s existing reactivity syntax.

• instead of export let, props are now destructured from a $props rune
• state variables are now declared with the $state rune. Under the hood, the $state rune will use something called a signal so Svelte can perform targeted updates when that value changes. However, as far as the component author is concerned, “count” is just a regular number, and you can access and update it just like you would any number in JavaScript. Count is not a special reactive object, or a function that needs to be called — it’s just a number. This is important for vibes reasons, and we’ll talk more about it later.
• instead of $:, derived values now use the $derived rune.
• and our reactive block turns into an $effect rune, which will re-run whenever any of the reactive variables inside it change.

On the surface, this may look like mostly a syntactical change. Let’s talk about how this solves some of the issues from earlier. First, unlike the $ label, $derived and $effect use runtime reactivity.

This means we can now safely refactor into functions without breaking anything. If you’re learning Svelte today, you don’t need to learn the gotcha about passing in reactive dependencies as arguments.

<script>
    let count = $state(0);
    // this works now!
    let doubled = $derived(timesTwo());
    function timesTwo() {
        return count * 2;
    }
</script>

With these runes, we now also have universal reactivity, which means it’s much easier to refactor this reactive counter into a separate file if we wanted to share between components. Earlier we showed how to do this in Svelte 4, and it involved rewriting to a completely different, more verbose reactivity API called “stores”. In Svelte 5, not only is the reactive logic more concise than the store version, it can be copied in a function verbatim.

function createCounter() {
  let count = $state(0);
  let doubled = $derived(count * 2);
  $effect(() => {
    if (count > 10) {
      console.log('more than 10');
    }
  });

  function increment() {
    count++;
  }

  return {
    get count() {
      return count;
    },
    get doubled() {
      return doubled;
    },
    increment
  };
}

There’s no need to convert the code to the store API. The only change is that the function needs to return data for the component to use.

Let’s take a closer look at what we’re returning here, because that may look unfamiliar to some of you.

Those function-looking values for “count” and “doubled” are called getters. In case you haven’t seen that syntax before — it’s not Svelte-specific, it’s Just JavaScript.

A getter is a special object function that maps to a property. When we access the count property on the returned object, it runs the count function to get that property’s value.

And this is important because we want to return a live reference to the count state. Remember that when you interact with count, it’s just a number. And if we just returned a number, then there would be no way to update that number after we returned it.

Instead, we want to always get the live value that the increment function is updating. And that’s what the getters give us — they let us return the same underlying value that the increment function is operating on.

When wrapping up reactive state like this, you can return regular objects, or you can also use classes.

This is also a valid way to write that same counter, with “count” and “doubled” as reactive class properties.

class Counter {
  count = $state(0);
  doubled = $derived(this.count * 2);
  constructor() {
    $effect(() => {
      if (this.count > 10) {
        console.log('greater than 10');
      }
    });
  }

  increment = () => {
    this.count++;
  };
}

Either way, you can use these similarly: import a function or class constructor and call them, and then use the values in your script tag.

are the vibes off?

I talked earlier about how when planning this change, we wanted to make sure to preserve Svelte’s vibes. So now the question is — did we succeed?

I think only the community can really decide that. For the most part, feedback has been positive and people are excited about Svelte 5.

But if anything looks less Svelte-like to you, it’s probably that you now have to type “$state” out instead of it being inferred. Why do we have to do that?

We could have switched to runtime reactivity without changing the syntax. But we also wanted to unlock universal reactivity.

And if we want to declare state outside of components, we need a way to declare it explicitly. We were able to get away with implicit state in Svelte 3 and 4 because it only applied to variables at the top level of a component.

So in this Svelte 4 example, name and numbers are reactive state variables, but sum and value are not, because they’re not at the top level.

<script>
    let name = 'world';
    let numbers = [1,2,3,4];

    function calculateSum() {
        let sum = 0;
        for (let value of numbers) {
            sum += x;
        }
    }
</script>

But now in Svelte 5, state can be anywhere — at the top level of a component, inside other functions, inside other files, or inside other functions inside other files. If we assumed every let was a state declaration like Svelte 4, it would get very confusing to figure out if a variable was truly reactive or not.

And it would also have a performance impact — making a value reactive isn’t expensive, but it would add up if we applied it to every variable in .svelte files.

It also brings a readability benefit. Code is read more often than it’s written, and now you have a clear visual signifier as to what is state and what isn’t.

And if you’re concerned about saving your fingers — well, that’s what editor autocomplete is for

Now, if the word “state” makes people nervous, there’s one other word that might frighten people… EFFECT.

I don’t think effect needs to be a scary word. Svelte had effects before now in the form of reactive blocks, we just didn’t call them that.

Side-effects are a natural concept in reactive UIs. They’re often overused — our docs encourage using derived state instead, if possible — but they’re necessary.

And one thing to note about Svelte’s “effect” — unlike useEffect, there’s no dependency array! If you’re familiar with Vue’s “watchEffect” or Solid’s "createEffect”, it works similarly — the effect determines when to re-run based on what reactive values you access inside it.

let color = $state('red');
let size = $state(0);
$effect(() => {
  const context = canvas.getContext('2d');
  // this will re-run whenever `color` or `size` change
  context.fillStyle = color;
  context.fillRect(0, 0, size, size);
});

As you can see in this example — by accessing the values of size and color inside the effect, Svelte will automatically re-run the effect when those values change. And if you just want to read the value in an effect without subscribing to updates, Svelte provides an “untrack” function.

Beyond the potentially visceral reaction to seeing words like “state” and “effect” in Svelte, the rest of what makes Svelte special is still intact.

For instance — you interact with the raw state values, instead of going through a setState function or an object with a value property. And to understand why that’s possible, we need to talk a little about signals…

Svelte 5 and signals

Svelte is finally on the “signals” train. Today it feels like every framework is either using signals or about to adopt signals, aside from React.

But what does “signals” actually mean? A deep dive is outside the scope of this talk. And our goal is that you should be able to use and learn Svelte 5 without even learning what a “signal” actually is.

But for the curious — a signal is an object that holds a value, and that can also track when the value is read. This means that when you update a signal, the signal knows all the other places that value is used, and can trigger updates in those places automatically. This lets you make very targeted, precise updates to your UI without a lot of wasted work.

But while signals are great for performance, interacting with them doesn’t feel very Svelte-like.

Part of what makes Svelte “Svelte” is this.

count += 1;

It’s the fact that you can take a reactive variable, and when you want to make changes to it you don’t have to use a “set” function or set a “value” property. You can just update the value like it was a normal JavaScript variable.

But then how do we get signals to work? Remember, signals need to be able to track when its value is read and written to, and there’s no way to do that with a regular number in JavaScript. And this is why other frameworks have set functions and value properties that we’re trying to avoid.

In Vue, when you declare a state variable with a number in it, you actually get an object back, not the number. Behind the scenes Vue uses a Proxy object that intercepts reads on the value property and wires up the signal properly.

const count = ref(0);
count.value++;

And this is why in Solid, you get back two functions that you call to read and write the value.

const [count, setCount] = createSignal(0);
setCount(count() + 1);

And there is nothing wrong with doing things this way — this is just a limitation of how JavaScript works — but it didn’t feel right for Svelte.

Luckily, Svelte doesn’t need to be limited by what is possible at runtime in vanilla JS — because, to quote Rich Harris when he discovered the core of Svelte 3 — "WE'RE A COMPILER, MOFOS."

In Svelte, we start with what we want the authoring experience to be, and use the compiler to make that possible at runtime. So in your Svelte component you write this…

let count = $state(0);
count += 1;

And Svelte compiles it to use signal methods under the hood.

let count = $.source(0);
$.set(count, $.get(count) + 1);

So we get the best of both worlds — an efficient, readable authoring experience that’s easy for humans to write, that is then transformed into valid, optimized JavaScript for the browser to execute.

Signals, but as an implementation detail. You can interact with state values like you’re writing vanilla JS and let Svelte’s compiler handle the rest. And with Svelte 5’s universal reactivity, that’s true inside Svelte components as well as regular JS files.

Svelte 5 and perf

Svelte 4 was already fast, but Svelte 5 has made even more significant gains in performance. A lot of that is thanks to Dominic Gannaway, creator of Inferno.js and former React team member, who joined the Svelte team last year and has been instrumental in eking out as much performance as possible.

If you look at the JS Framework Benchmark, which tracks how long it takes various frameworks to perform different DOM updates, Svelte 5 is doing very well, way better than Svelte 4 and neck and neck with Solid. And not only is Svelte 5 fast, but it also uses less memory and hydrates more quickly.

There are lots of reasons why Svelte is even faster now, many outside my expertise, I'll just mention a couple.

The compiler has been re-written from the ground up with performance optimization in mind, including making sure that the compiled JS code is easy for the browser engines to optimize. A lot of these may be microimprovements, but microimprovements add up.

And reactivity being signal-based means that updates can be more targeted and efficient than with Svelte 4’s compiled reactivity.

Svelte is not the absolute fastest framework out there, but it is definitely — almost blazingly? —fast. If you want to build a performant web app, Svelte is not going to require a lot of extra work from you.

does Svelte scale?

We’ve also made some tradeoffs in regards to bundle size.

In Svelte 4, a “hello world” app was only a few kilobytes, since Svelte had almost no runtime. However, because reactivity was compiled into the component, as you added more components the bundle size increased at a steeper rate than frameworks with larger runtimes. With code splitting, most apps would not hit this inflection point, but it was still something we wanted to address.

But now with Svelte 5, reactivity is now in the runtime, which means a slightly larger runtime, but smaller components. So a “hello world” app is slightly larger; but as you build bigger apps you’ll start to see the savings. Let’s look at an example.

An implementation of TodoMVC, the famous Todo app project used to demo different frameworks, is 7.2kb in Svelte 5 and 4.9kb in Svelte 4. So Svelte 4 is obviously smaller

But lets say you have an app that’s just three times the size of TodoMVC. At that point, the Svelte 5 app is actually smaller than Svelte 4 — 9.8KB instead of 10.1KB — because the larger runtime means that not as much needs to be compiled into each component.

And these savings only increase the larger your app is.

(For the methodology and benchmark code, see this repo).

but wait, there's more!

I’ve tried to talk about as much of Svelte 5 as I can, but there’s still more stuff and I only have 25 minutes! So — I’m going to fall back to a listicle.

These are more new features coming to Svelte 5 that I don’t have time to go into detail on. Check out the Svelte 5 docs, or come find me after for more on these.

• Snippets
• Event attributes
• $derived.by
• TypeScript in markup
• Reactive Sets/Dates/Maps/URLs
• $bindable
• Deeply reactive objects and arrays
• Fine grained reactivity
• $inspect

but wait, there's less!

But to me what’s exciting is not just all the APIs we’re adding, but the APIs we’re deprecating.

These are all APIs that existed in Svelte 4 that no longer need to exist in Svelte 5, either because they’ve been replaced by something simpler or because the problem they solved is no longer a problem with the new design

• createEventDispatcher → event attributes / callback properties
• <slot> and slot props → snippets
• <svelte:fragment> → snippets
• $$props, $$restProps, $$slots → $props
• beforeUpdate and afterUpdate → $effect.pre / $effect

This is the benefit of rethinking some of these APIs. Any design accumulates awkward bits over time as you discover use cases that weren’t considered originally or rethink priorities. Designing from first principles means you can create something that feels cohesive instead of tacked on.

incremental migration

One last piece I want to touch on before closing is the migration story. I talked about a lot of changes today for how you write Svelte components.

Importantly, while Svelte 5 is introducing new reactivity syntax with runes, you don’t have to convert everything to runes to start using Svelte 5.

Instead, you can use your Svelte 4 components in Svelte 5 today, and they should work the same. Runes take effect on a per-component level — so you can have some components written using the old reactivity, and some written using the new reactivity, and they should work together.

Being able to incrementally migrate to the new reactivity system is important to us, since requiring massive, big-bang rewrites would make Svelte 5 very difficult for a lot of projects to adopt.

In addition to supporting Svelte 4-style components in Svelte 5, we’ll also be supplying automated migration tooling to convert your components to runes. Because even though the old reactivity model is supported in Svelte 5, it will eventually be removed in Svelte 6 or 7 in favor of Runes.

While it’s great for adoption to support both syntaxes simultaneously, it’s not great for learning and understanding. We would essentially split the ecosystem, where some components would be written in the old syntax and some in the new, and newcomers to Svelte would have to decide which one they want to learn. In our mind, the benefits of runes are clear, and you should be using them eventually — but you don’t need to adopt them all at once, and you don’t need to do it all by hand.

where to next?

So that’s a very brief overview of Svelte 5 - the changes, the problems they solve, and the exciting improvements coming to Svelte. We talked a lot about how Svelte 5 compares to its predecessor, but its simpler mental model means this is also a great place to start trying Svelte.

If you’re interested in learning more or giving it a go yourself, there are a few places you can go.

For now, Svelte 5 is still in preview, so the main docs on svelte.dev are still for Svelte 4. You can find the docs for Svelte 5 as well as an interactive playground at svelte-5-preview.vercel.app. Once Svelte 5 is released, it will come with an interactive tutorial that will be the best way to learn Svelte 5.

If you prefer to work locally, run npm create svelte to start a new Svelte app, which will give you the option to install the Svelte 5 preview.

If you want to find me, head over to my website at geoffrich.net [note: you're here], where I have my blog and links to my various socials. That’s where you can also find my slides and notes from this talk.

Thanks so much for having me, and enjoy the rest of the conference.

<svg xmlns="http://www.w3.org/2000/svg">
  <defs>
    <symbol id="arrow-path" fill="none" stroke="currentColor" stroke-width="1.5" viewBox="0 0 24 24">
      <path stroke-linecap="round" stroke-linejoin="round" d="M16 9h5v0M3 20v-5m0 0h5m-5 0 3 3a8 8 0 0 0 14-4M4 10a8 8 0 0 1 14-4l3 3m0-5v5"/>
    </symbol>
    <symbol id="clipboard" fill="none" stroke="currentColor" stroke-width="1.5" viewBox="0 0 24 24">
      <path stroke-linecap="round" stroke-linejoin="round" d="M16 4a2 2 0 0 0-2-2h-3C9 2 9 3 8 4m8 0s0 0 0 0v1a1 1 0 0 1-1 0H9a1 1 0 0 1-1 0v0-1m8 0h2l2 2v14a2 2 0 0 1-3 2H7a2 2 0 0 1-2-2V6l1-2a48 48 0 0 1 2 0"/>
    </symbol>
  </defs>
</svg>

And then you can reference those icons in your HTML with the <use> element.

<svg height="24" width="24">
  <use href="#arrow-path" />
</svg>

This is great for performance, since instead of repeating the same SVG markup every time you use the icon, you define the markup one place instead and re-use it.

The SVG sprite sheet can either be in the same HTML document where you use it, or it can be an external asset.

<!-- reference in the same document -->
<svg height="24" width="24">
  <use href="#arrow-path" />
</svg>

<!-- reference an external /sprite.svg file -->
<svg height="24" width="24">
  <use href="/sprite.svg#arrow-path" />
</svg>

The benefit of making it an external asset is that your SVG icons can be cached independently of the page itself, decreasing page size. Unfortunately, there’s a problem: using an external sprite sheet means there’s an extra request that has to happen before the icon can be displayed, and your users might see the icons "pop in" as the SVG sprite sheet finishes downloading.

But that’s what preload links, are for right?

<link rel="preload" as="image/svg+xml" href="/sprite.svg" />

But that doesn’t work. In Chrome, you see a console warning:

must have a valid `as` value

Hm. What if we preload it as an image?

<link rel="preload" as="image" type="image/svg+xml" href="/sprite.svg" />

No console warning when the page loads… but a few seconds later:

The resource http://127.0.0.1:8080/sprite.svg was preloaded using link preload but not used within a few seconds from the window's load event. Please make sure it has an appropriate as value and it is preloaded intentionally.

And if you take a look at the network panel, "sprite.svg" is fetched twice. So the browser "preloaded" the SVG file but wasn’t able to actually use it for our sprite references. Ugh.

That preload would work if we were using an SVG as an image, but not as an <svg>.

<!-- in the head -->
<link rel="preload" as="image" type="image/svg+xml" href="/clipboard.svg" />
<!-- then these will be successfully preloaded -->
<span class="clipboard-bg"></span>
<img src="/clipboard.svg" width="24" height="24" />

<style>
  .clipboard-bg {
    background: url('/clipboard.svg');
    width: 24px;
    height: 24px;
    display: inline-block;
  }
</style>

It turns out there’s a Chrome (and fetch spec) issue for this behavior that has been open since 2020. For now, if you want to preload SVGs to use in <svg> elements, you’re out of luck. In fact, attempting to preload SVGs for this use case is actually harmful to performance due to the double request.

Workarounds for now:

• Accept the icons popping in.
• Inline the sprite sheet on each page. If you don’t have a ton of icons, the cacheability tradeoff may be okay.

Astro also has an interesting approach in their icon component where the first time you render an icon it includes the <symbol>, and subsequent usages refer back to that symbol. This way icons are inlined (so no preloading to worry about) and you only include the icons you actually use.

To test out SVG preloading yourself, see my demo repo.

A takeaway

One takeaway I had from this investigation is that it’s important to verify that code changes you make actually do something. I read a tutorial that suggested preloading the SVG sprite sheet for performance, and I could’ve just assumed that it would speed up my page. However, attempting to preload was actually causing a double request and increasing the amount of resources my page loaded.

Similarly, you may assume that adding ARIA attributes to an element will "help accessibility," but if you can’t actually check that then you may be doing more harm than good. "role=button" is harmful if you’re not adding the necessary keyboard interactions (probably just use a <button>), and "aria-label" does nothing on a div.

You can’t just assume things will work — you need to verify.

Back in 2022 I wrote an extensive post on using Vercel's Satori library to create social sharing images using Svelte. I just went back and updated that post, so it should still be relevant for 2024. However, the most awkward part of that first demo was needing to write a custom Vite plugin to let us import a font and transform it into the raw font data that Satori needs.

Part of the reason we needed to do this is because there wasn't a great way to read the file from the filesystem at runtime. Sure, at dev time we can use Node's fs.readFileSync to read the font data. However, once we deploy our app, we don't have the same guarantees about how the filesystem is structured, and accessing the asset gets more complicated.

SvelteKit's new read helper simplifies this. If you give it the URL of an imported asset, it will return a Response with the contents of that asset. So instead of writing a custom plugin to get the raw font data, I can do this instead:

import {read} from '$app/server';
import sourceSerifPro from '$lib/fonts/SourceSerifPro-Regular.ttf';
const fontData = read(sourceSerifPro).arrayBuffer();

// then later, when calling Satori:
satori(markup, {
  fonts: [
    {
      name: 'Source Serif Pro',
      data: await fontData,
      style: 'normal'
    }
  ]
});

Much cleaner! You can take a look at the deployed demo to see it in action.

Other quick notes:

• this functionality needs to be implemented by the adapter you're using. The initial PR included support for Vercel and Netlify (for serverless functions, not edge functions), as well as the regular Node adapter.
• because this uses Vite's asset handling, glob imports work too

For another look at this feature, see Rich Harris' demo video:

• how the browser can handle page transitions now
• using SvelteKit's onNavigate lifecycle hook to trigger a view transition
• how view transitions compare to Svelte's built-in transitions

You can listen to the episode on all major podcasting platforms. Here are some relevant links from the conversation:

• Jake Archibald's view transitions explainer
• the onNavigate lifecycle method
• sveltekit-view-transition, a library to make work with view transitions in SvelteKit easier
• my Svelte Summit talk on view transitions in Svelte
• everything I've written on view transitions

// +page.server.js
export async function load() {
  const slowData = getSlowData();

  return {
    nested: {
      slow: slowData
    }
  };
}

async function getSlowData() {
  await delay(2000);
  return '😴';
}

// helper to simulate a delay for the given number of milliseconds
function delay(ms) {
  return new Promise(res => setTimeout(res, ms));
}

We can then show a loading state using Svelte's await block:

{#await data.nested.slow}
	<p>Loading...</p>
{:then result}
	<p>{result}</p>
{/await}

“Nested” here has nothing to do with the object property name, but whether the property is inside the top-level object returned from load or nested inside another object. For example, in the following object panda is nested but tangerine is not. This means that SvelteKit will wait for promise2 to resolve before rendering the page, but will not wait for promise1 and will stream the result in after it resolves.

return {
  something: {
    panda: promise1
  },
  tangerine: promise2
};

For more, see the documentation.

However, streaming data comes with its downsides.

• It only works when JavaScript is enabled — if you stream data, the server-rendered HTML will not have the resolved value. Because of this, SvelteKit recommends you only stream non-essential data so users can still get the information they need when JavaScript is not available.
• Even if you don’t care about supporting users without JavaScript, if you server-side render your app then streaming data will cause a “flicker” of loading state on the initial page load, no matter how quickly the promise resolves.

Let’s see how we can resolve those issues by conditionally streaming data depending on the request.

Conditional streaming with await

First, let’s see how to conditionally stream a promise with SvelteKit. We saw earlier how to stream slow data, but how do you do that conditionally?

In our case, we just have to change one line:

export async function load() {
  const shouldStreamData = true;
  const slowData = getSlowData();

  return {
    nested: {
      // conditionally return here
      slow: shouldStreamData ? slowData : await slowData
    }
  };
}

Now, instead of always returning a promise, we return either a promise or the resolved value of that promise.

Importantly, we have to make sure to return the actual resolved value of the promise, not the resolved promise itself. This won’t work:

export async function load() {
  const shouldStreamData = true;
  const slowData = getSlowData();

  if (shouldStreamData) {
    // doesn't work!
    await slowData;
  }

  return {
    nested: {
      // this promise is resolved, but Svelte will first render the unresolved state
      slow: slowData
    }
  };
}

This is because we’re still returning a promise to the UI, so we’ll see a flash of loading state. At least for now, Svelte’s SSR renderer is synchronous. Promise values can only be retrieved asynchronously (even if already resolved), so Svelte can’t get the resolved value immediately. For more, see this Svelte issue.

Instead, you should return either the promise, or the resolved value of that promise.

const toReturn = shouldStreamData ? promise : await promise;

The great thing about this is you can still use the {#await} block you were using before. SvelteKit will also correctly generate the types so that data.nested.slow will either be a string or a Promise<string>.

So that’s how we can conditionally stream data and choose between showing a loading state quickly and rendering a complete page. When might we want to do this?

Preventing a loading flicker with Promise.race

Sometimes you don’t know if an API call is going to complete quickly or not. Maybe on a warmed-up cache it would return in 50ms, but in the worst case it could take up to a second or two. Because it can be slow, you want to stream in the data instead of waiting on it to render the page. However, if it does come back quickly, you’d rather return a rendered page with all the data present and prevent the dreaded loading state flicker.

We can use Promise.race to give our promise a few hundred milliseconds to resolve. Promise.race takes an array of promises, and resolves when any one of those promises resolve. We can pass our delay call and our data fetching call, and conditionally await the result depending on which one resolves first.

const TIME_TO_RESOLVE_MS = 200;
export async function load() {
  const slowData = getSlowData();

  const result = await Promise.race([delay(TIME_TO_RESOLVE_MS), slowData]);

  return {
    nested: {
      slow: result ? result : slowData
    }
  };
}

async function getSlowData() {
  // randomly delay either 50ms or 1s
  // this simulates variable API response times
  await delay(Math.random() < 0.5 ? 50 : 1000);
  return '😴';
}

function delay(ms) {
  return new Promise(res => setTimeout(res, ms));
}

In this example, we race two promises: a 200ms delay and the actual data call we want to make. If the delay resolves first, then the data call is taking longer than 200ms and we should go ahead and render the page with partial data. If the data call resolves first, then we got the data under the time limit and we can render the page with complete data.

This flicker is mainly relevant on the initial, server-rendered page load. Subsequent client-side navigations will preload the data when the link is hovered and the user might not see a loading state if the data comes back quickly enough. However, this can be a nice technique to prevent the flicker when the app is starting up.

Completely loading data on initial request

The promise streaming announcement blog post highlighted an important caveat:

One caveat: this feature needs JavaScript. Because of this, we recommend that you only stream in non-essential data so that the core of the experience is available to all users.

Because JavaScript is needed to load the result of the streamed promises, users without JavaScript available (more likely than you think) will not see the fully loaded data. Instead, they will only get whatever was present when the page first rendered. This might be okay for non-essential data, like comments on a blog post, but essential data, like the post itself, should be available for all users.

But what if you have slow data that is also essential? Ideally you can fix the data source so that it’s no longer slow, but that’s not always possible. Do you make all users wait on that data, even though JavaScript is likely available for most of them?

We can instead implement a hybrid approach. On the initial page load, we could wait for all data to resolve. That way, users without JavaScript will be able to see all the content on the page, even if it loads slightly slower. If you built your app in a progressively-enhanced way, they can even perform essential actions.

On subsequent page loads using client-side navigation, we can allow the slow data to be streamed in. Client-side navigation will only occur if JavaScript is available, so there are no downsides to using promise streaming. If the user doesn’t have JavaScript, each navigation will trigger a full page load, and we will again wait for all data to resolve.

We can switch between these two behaviors using the isDataRequest property on the RequestEvent passed to the load function. When this property is false, the request is for the HTML for the initial page load, and we should wait for all data to resolve. If the property is true, then the request is from SvelteKit’s client-side router and we can stream the data in.

export async function load({isDataRequest}) {
  const slowData = getSlowData();
  return {
    nested: {
      slow: isDataRequest ? slowData : await slowData
    }
  };
}

However, note that this will impact your Time to First Byte for all users, since the browser will not receive any HTML until the data has fully loaded. You should carefully consider the tradeoffs between response time and serving users without JavaScript, which will depend on your app’s userbase:

1. If all your data is fast, don’t worry about promise streaming
2. If some of your data is slow, but it’s non-essential, use promise streaming for that data
3. If some of your data is slow and essential, and it’s important to serve users without JavaScript, either speed up the slow data at the source or use isDataRequest to conditionally await data

I recorded a 90 minute SvelteKit crash course with This Dot Labs where we build a music library app (which I named "Sveltunes"). My goal was to give a overview of everything that makes me excited about SvelteKit, so we cover a lot. Topics include:

• directory-based routing, layouts, parameterized routes, and nested routing
• loading data with the load function (and how this is more efficient than loading data with onMount)
• preloading the data for the next page for snappy navigations
• streaming slow data from load functions by returning nested promises
• how SvelteKit lets you mix-and-match different rendering options (SSR, CSR, prerendering)
• submitting and validating data with form actions
• using the enhance helper to progressively enhance forms
• implementing optimistic UI

There's a lot we didn't get to, but hopefully this provides a good overview! The code for Sveltunes can be found on GitHub.

If you enjoyed this video, I recommend checking out the slides for the talk I gave at THAT Conference, where I build on the data loading and progressive enhancement concepts to build a nested "Favorite Albums" UI.

In fact, both of my in-person talks last month (the other was at SeattleJS) used the Sveltunes demo, and that was intentional — better to build one demo you can reuse instead of three!

Building Efficient, Resilient Web Apps With SvelteKit

Building web apps with all the modern best practices can be complicated. Not only do you want your app to be efficient and load data quickly and intelligently, you also want it to be resilient and stay upright > regardless of your users’ device or network.

Enter SvelteKit, a modern web framework built on top of the best-in-class Svelte JS component framework. Not only does it help you move fast with a minimal-boilerplate and fun developer experience, it also gives you the tools to provide an efficient, resilient user experience.

This talk will move beyond the basics and show how to use SvelteKit’s powerful toolkit to handle more advanced scenarios:

• preloading and streaming data for lightning-fast navigations
• crafting a minimum viable experience so your app still functions when your JavaScript fails
• sharing data between multiple routes by loading data in the layout
• avoiding “data waterfalls” that make your users wait for no good reason
• progressively enhanced forms
• customizing SvelteKit’s enhanced forms to implement optimistic UI
• using advanced Svelte store patterns to efficiently update data instead of over-fetching

We’ll use a music collection demo app to showcase these ideas, so that they’re tied to concrete examples instead of being purely theoretical.

The talk will not be recorded, but I've linked my slides and other resources below. I might transcribe a written version of this talk at a later date.

My slides were created using Slidev. You can find the source on my GitHub and the live version deployed to Vercel.

As part of the talk, I briefly showed a music library demo app (a.k.a. "Sveltunes"). The code for that app is also on GitHub, though it's not currently deployed anywhere because auth is mocked out and the "DB" is just an in-memory object.

If you want to learn more about Svelte and SvelteKit, I recommend the following resources:

• the interactive tutorial (start here!)
• the Svelte and SvelteKit doc sites

Web development, streamlined: an introduction to SvelteKit

SvelteKit is an exciting new web framework that recently launched version 1.0. It combines the well-loved Svelte JavaScript framework with everything you need to build a modern web app: routing, type-safe data loading, progressively-enhanced forms, a speedy Vite-powered dev experience, and more. In this talk, I’ll give a crash course on SvelteKit and how you can use it to build fast, resilient web apps of all shapes and sizes.

The talk will not be recorded, but I've linked my slides and other resources below. I might transcribe a written version of this talk at a later date.

My slides were created using Slidev. You can find the source on my GitHub and the live version deployed to Vercel.

As part of the talk, I briefly showed a music library demo app (a.k.a. "Sveltunes"). The code for that app is also on GitHub, though it's not currently deployed anywhere because auth is mocked out and the "DB" is just an in-memory object.

If you want to learn more about Svelte and SvelteKit, I recommend the following resources:

• the interactive tutorial (start here!)
• the Svelte and SvelteKit doc sites

Svelte 4 is mostly a behind-the-scenes update, and breaking changes should be minimal for most users. However, it does have some exciting improvements around custom element generation, IDE autocomplete, and hydration performance. See the full announcement and migration guide for more.

First, PodRocket had me on for an episode where I discussed what's new in Svelte 4 as well as what's changed on the revamped Svelte documentation site. This was a great chat with an impressive turnaround - it was edited and posted 24 hours after recording!

Then last week This Dot Labs (who previously hosted a State of Svelte event) had me and a couple other folks from the Svelte team (Ben McCann, Simon Holthausen, and Puru Vijay) on to discuss the release as part of a Svelte 4 Launch Party stream.

More Svelte 4 resources:

• full announcement
• migration guide
• another Svelte 4 PodRocket episode with Svelte maintainer Simon Holthausen (a.k.a. dummdidumm)
• a live Svelte Radio episode featuring Puru and Simon

I spoke at the Spring 2023 Svelte Summit on Svelte and view transitions. The View Transitions API is an exciting new browser API that streamlines the process of animating between two page states. While the headline use case is page transitions, it can also be used for all sorts of animation in your Svelte app. In this talk, I show how you can replace Svelte’s built-in flip and crossfade animations with view transitions, as well as the pros of cons of each approach.

Following is a transcript of the talk, and the entire event is available to stream on YouTube. My demo code is available on GitHub, or you can visit the demo site to see it in action. Note that the view transitions part of the demo will only work in Chrome at time of writing.

If you’re coming here after watching the talk, you can find a list of resources and further reading at the end of the page.

Hello, I’m Geoff, a Svelte maintainer and Senior Software Engineer at Ordergroove.

Svelte transitions and animations — everybody loves them. In fact, they’re usually one of the top three reasons people fall in love with Svelte, right next to “simple state management” and “feeling superior about not having a virtual DOM.”

There are 7 built-in Svelte transitions and 1 built-in animation function, but today, we’re going to focus on two: flip and crossfade. We’ll talk about why we need them in the first place and how new browser capabilities might provide an alternative. Maybe.

flip and crossfade

Let’s start with animate:flip. This is a directive that you can use inside an #each block to make reordering the elements in that block smoother.

For example, look at this row of playing cards. Clicking the “Shuffle” button reorders them, but they abruptly jump to their new positions — it’s hard to understand what playing card moved where.

<button class="shuffle" on:click={shuffle}>Shuffle</button>

{#each cards as card (card)}
	<div
		class="card"
		style:background-image="url({getSpriteUrl(card)})"
		data-card={card}
	></div>
{/each}

But! If I add animate:flip to the individual DOM elements, they instead animate to their new position. Much nicer! It’s worth noting you do need to provide a key in your each loop — otherwise Svelte can’t tell which card moved where. See the Svelte tutorial on keyed each blocks for more.

{#each selected as card (card)}
	<div
		animate:flip={{
			duration: 400
		}}
		class="card"
		style:background-image="url({getSpriteUrl(card)})"
		data-card={card}
	>
		<button class="select" on:click={() => deselect(card)}>Swap</button>
	</div>
{/each}

This is something you could implement in JavaScript, but you have to grab the DOM elements yourself and it gets a bit math-y, so it’s nice that Svelte makes it as simple as adding a single attribute.

But Svelte’s flip only works in individual each blocks. In this demo, you can also click a card to select it and move it to a separate row. If I want that transition to be animated, I need to reach for a different tool: the crossfade transition.

First we call crossfade to get the pair of transitions and then apply them to the elements in each row. We pass a unique key so Svelte knows that when we remove an element from the first block, it’s the same as the element we’re adding to the second block, and should be animated to its new position. In this case, the key is the card’s suit and rank, for example “10 hearts”.

<script lang="ts">
	import { flip } from 'svelte/animate';
	import { crossfade } from 'svelte/transition';
	import { quintOut } from 'svelte/easing';

	const [send, receive] = crossfade({
		duration: 500,
		easing: quintOut
	});

	// truncated for readability
	let cards, selected;
	function select(card) { }
	function deselect(card) { }
</script>

<div class="cards">
	{#each cards as card (card)}
		<div
			animate:flip={{
				duration: 400
			}}
			in:send={{ key: card }}
			out:receive={{ key: card }}
		>
			<button class="select" on:click={() => select(card)}>Swap</button>
		</div>
	{/each}
</div>

<div class="cards">
	{#each selected as card (card)}
		<div
			animate:flip={{
				duration: 400
			}}
			in:send={{ key: card }}
			out:receive={{ key: card }}
		>
			<button class="select" on:click={() => deselect(card)}>Swap</button>
		</div>
	{/each}
</div>

Once we apply the transition, swapping the card will animate it to its new position.

If you haven’t seen these before, go take a look at the official Svelte tutorial — they’re pretty fundamental bits of Svelte API, so I’m not going to dwell on the particulars much longer.

So Svelte’s FLIP and crossfade directives were introduced in 2019. Are there more options for animating UI states on the web in 2023?

Well, yes. Let’s talk about the View Transitions API.

The View Transitions API

The View Transitions API has been developed in Chrome for a while now. You may have heard about it under its previous name, “Shared Element Transitions”. According to the API explainer, it “makes it easy to change the DOM in a single step, while creating an animated transition between the two states.”

Up to this point in browser history, we had the tools to animate individual elements, but smoothly transitioning elements between two UI states was still a hard problem, and people often reached for libraries to solve it.

So, this API introduces a new document method: startViewTransition. When you call it, it will start a view transition and capture the current state of the page. Inside a callback passed to the function, you update the DOM somehow. Once you’re finished, it will capture the new state of the page, and then smoothly transition between the old and new states.

function performTransition() {
  document.startViewTransition(async () => {
    await updateTheDomSomehow();
  });
}

By default, it will fade the old state out while fading the new state in, but you can customize the transition in CSS just like you would any CSS animation. In addition, this API also introduces a new view-transition-name CSS property — you’ll see how we use this in a bit.

I’m barely scratching the surface here, so check out the official explainer for a much more detailed rundown.

Refactoring our code to use view transitions

Let’s look back at the demo we were working on before. How can we refactor this code to use startViewTransition instead of Svelte’s animate:flip and crossfade ? I’ve reverted back to before we added those functions, so we have a blank slate.

Let’s look at the shuffle functionality. To have shuffling trigger a view transition, we can wrap the actual state updates inside of startViewTransition. The browser then needs to know when the DOM has finished updating. In Svelte, we can do that by awaiting the tick function.

function shuffle() {
  document.startViewTransition(async () => {
    [cards, selected] = shuffleDecks(cards, selected);
    await tick();
  });
}

So with that, every time we shuffle, we have a transition happening - a fade. But that’s not quite what we want, is it?

This is because the browser only sees the old and new states — it doesn’t know whether a card moved somewhere or was replaced. Just like Svelte needed a key, so does the browser, which we can do by setting a view-transition-name.

.card {
  view-transition-name: var(--name);
}

Since this tag needs to be unique, I like to use a CSS custom property to inject the dynamic part of the transition tag. We can set the prop in a style directive, and then use it in our CSS. Like before, I can use the name of the card, which is unique for this demo.

{#each selected as card (card)}
	<div
		class="card"
		style:--name="card-{card}"
	>
	</div>
{/each}

And with that, the cards animate during shuffle.

I want to pause for a moment to call out just how cool this is. We have elements dynamically moving to their new positions, and there’s no JavaScript code doing calculations to make this happen. We didn’t have to write it and neither did Svelte. The browser is figuring it out for us.

So, should you go out and yank all the animate:flip and transition:crossfade from your codebase in favor of this new browser API? Well, not necessarily. Each version has their pros and cons — let’s compare them.

Comparing the two approaches

Let’s start with the pros of the view transition version:

• First, as I mentioned, the browser does all the heavy lifting
• You’re also able to use CSS to customize the animation, which is especially useful if you want to use media queries to target different device sizes or reduced motion preferences
• And because it’s CSS animation, you can easily debug the animations using Chrome’s animation devtools
• Also, there are no Svelte templating constraints — with animate:flip, you had to be in an each block. But the View Transitions API doesn’t care about that.
• This one probably isn’t significant enough to matter, but we do ship slightly less client-side JavaScript since we don’t need to include Svelte’s flip or crossfade code
• And because it’s a browser API, the knowledge is portable — you can’t use Svelte animations and transitions in other frameworks, but you can use view transitions.

On the other hand, it also comes with some cons.

It only works in Chrome, at least for now. While animation is a good progressive enhancement case — if this is broken, then your app should still work — losing this animation completely in non-Chrome browsers may be a dealbreaker. Hopefully, this won’t always be a con as the API is implemented by more browsers. Until then, make sure to check the API is supported before using it.

function shuffle() {
  if (!document.startViewTransition) {
    [cards, selected] = shuffleDecks(cards, selected);
    return;
  }

  document.startViewTransition(async () => {
    [cards, selected] = shuffleDecks(cards, selected);
    await tick();
  });
}

And while we can use CSS to customize the animation, targeting the animation for multiple elements can get wordy. If we wanted to change the animation duration for all of the cards, we would need to write a selector for every transition tag we use.

:root::view-transition-group(card-A♠),
:root::view-transition-group(card-2♠),
:root::view-transition-group(card-3♠),
:root::view-transition-group(card-4♠),
:root::view-transition-group(card-5♠)
/* and so on */ {
  animation-duration: 1s;
}

There’s a proposal to solve this problem by creating “classes” of transition groups, but that isn’t implemented right now.

Finally, we have to wrap every function that triggers a view transition in document.startViewTransition. So, If we want “swapping” a card to transition too, we also need to wrap it.

function select(card: Card) {
  document.startViewTransition(async () => {
    [cards, selected] = moveCard(card, cards, selected);
    await tick();
  });
}

Svelte transitions are more declarative in that you can add them to the element directly, and any state affecting that element will trigger the animation.

So while view transitions are great, they’re not a drop-in replacement for the Svelte transitions you’re already familiar with. And they’re not meant to be! They solve similar problems in different ways, with different tradeoffs.

We didn’t even talk about animated page transitions — arguably the headline feature of the View Transitions API, and something that is tricky to do with Svelte’s transitions today. Some of the cons I mentioned become much less relevant with the page transition use case — for example, for SvelteKit page transitions, you don’t have to wrap every link that should trigger a transition — you only have to wrap a single navigation lifecycle hook.

(Note: at time of recording, there is an open SvelteKit PR that will make the view transitions integration much smoother by adding an onNavigate lifecycle hook.)

Wrapping up

As much as we all love Svelte, it’s important to also know about the web platform’s APIs. There may come a point where Svelte is dead and gone, but the web platform is extremely backwards-compatible, and browser APIs and fundamentals are here to stay. There’s a good chance that view transitions will become an essential tool in your toolbelt for years to come, especially as they gain wider cross-browser adoption.

If you want to read more about Svelte and view transitions, head to my blog (Ed: you’re already here!), where I’ll have a written version of this talk as well as links to some further reading. I also recommend checking out my post on creating animated page transitions in SvelteKit using the View Transitions API.

Thanks for your time, and enjoy the rest of the talks.

Further reading

I barely scratched the surface with what's possible with view transitions, so check out these links to learn more:

• the official view transitions explainer. I frequently come back to this, it is very in-depth and covers a lot of edge cases.
• my blog: SvelteKit page transitions with the view transitions API
• my demos (viewable in Chrome only): fruit list, Svelte Summit, and Star Wars. See my view transition experiments write-up for some explanation and links to the source
• and while it's not up-to-date with the breaking changes in the latest version of the API, I really enjoyed Maxi Ferreira's experiments with view transitions and Astro

This Dot Labs hosted a "State of Svelte" livestream today with several folks from the Svelte team and community, including myself. If you’re curious about what’s happening with Svelte lately and where it’s going next, it's well worth a watch! Some of the topics include:

• how SvelteKit compares to the other server experiments in the ecosystem (Remix, Solid Start, React Server Components)
• the plan for Svelte 4 and a Svelte 5 wishlist
• testing your Svelte and SvelteKit apps
• switching the Svelte internals to JSDoc from TypeScript
• what makes the Svelte community special

If you’re not familiar with the API, the explainer linked above is well worth the read. tl;dr, it’s a browser API that “makes it easy to change the DOM in a single step, while creating an animated transition between the two states.”

Replacing Svelte’s FLIP and crossfade transitions

Last year I created this Star Wars demo to show off Svelte’s animation and transition capabilities. As an experiment, I ripped out all the Svelte animation code and replaced it with the View Transition API, and it worked quite well.

Here’s the experimental branch deployed to Vercel — it will only work if you use Chrome Canary or the latest Beta.

The implementation is slightly more complicated than the previous version using animate:flip and a crossfade transition. Essentially, every state update is wrapped in a helper function that starts a view transition and waits for the state update to complete using tick.

For example, the “select movie” button looks something like this (note the wrapping pageTransition call):

<IconButton
  on:click={() => pageTransition(() => select(movie.id))}
  label="select">{@html plus}</IconButton
>

Because multiple state updates can happen when a single piece of state is updated thanks to the power of reactive statements, the helper pageTransition function will only start one transition, but run all the different queued state updates before completing the transition.

The helper function uses a bit of code from Jake Archibald to gracefully handle the API not being available (in which case, no animation will play).

The full pageTransition function looks like this:

import {tick} from 'svelte';

let cbs = [];
let inProgress = false;

function clearCallbacks() {
  while (cbs.length > 0) {
    const cb = cbs.pop();
    cb();
  }
}

export function pageTransition(fn, shouldTransition = true) {
  // allows for easily toggling off the transition for certain state changes
  if (!shouldTransition) {
    fn();
    return;
  }
  cbs.push(fn);
  if (inProgress) {
    return;
  }
  inProgress = true;
  const t = transitionHelper({
    updateDOM: async () => {
      clearCallbacks();
      await tick();
      clearCallbacks(); // some callbacks may be queued in the middle of the transition, resolve those too
    }
  });

  t.finished.finally(() => {
    clearCallbacks();
    inProgress = false;
  });
}

// copied from Jake Archibald's explainer
function transitionHelper({skipTransition = false, classNames = [], updateDOM}) {
  if (skipTransition || !document.startViewTransition) {
    const updateCallbackDone = Promise.resolve(updateDOM()).then(() => {});

    return {
      ready: Promise.reject(Error('View transitions unsupported')),
      updateCallbackDone,
      finished: updateCallbackDone,
      skipTransition: () => {}
    };
  }

  document.documentElement.classList.add(...classNames);

  const transition = document.startViewTransition(updateDOM);

  transition.finished.finally(() =>
    document.documentElement.classList.remove(...classNames)
  );

  return transition;
}

If you want to take a closer look at the implementation, see the experimental branch on the repo.

SvelteKit page transitions

When I was experimenting with this API last year, I put together two SvelteKit page transition demos that I presented at the Svelte London meetup. I only blogged one of them, a simple fruit list demo (which I over-confidently titled “Part 1”). The other, a SvelteKit site displaying various Svelte Summit talks that I based on Jake Archibald’s demo, was mostly ready but never fully written up.

With the View Transitions API landing in Chrome Beta, I took the time to update these demos to the latest API, since there had been several breaking changes while the API was in an experimental state.

I’m pretty happy with how they both turned out — take a look (again, Chrome Canary or Beta only).

Fruit demo (source)

Svelte Summit demo (source)

For the full details of how the fruit list demo works, check out my updated post. The high level overview is that we set up some code in a beforeNavigate callback that starts the transition and resolves it once the navigation completes. We tell the browser which elements should transition together when changing pages by giving them the same view transition name.

The Svelte Summit demo used a similar approach, but had more complex transitions and was a bit trickier (which is why I put off doing a full write-up!) I ran into a few issues where the transitions weren’t happening due to race conditions — the new state was being shown before the transition had a chance to start, so it couldn’t capture the original state.

For instance, I tried to show a back arrow in the header based on which page we were on. This was originally a #if block in the component looking at the current value of $page.url. However, this caused a race condition where the $page store updated before the transition started, causing the back icon to disappear too soon.

Similarly, I had to change how I set view transition names on the video embed and thumbnail elements. Trying to do so via style directives was unpredictable, and sometimes the styles would be applied too late. Instead, I set the style on the transitioning DOM elements manually.

It’s unfortunate that we have to write our components in a less-idiomatic way, but the timing is tricky to get right.

But the worst race condition of the bunch was when I enabled SvelteKit’s preloading. When I did that, the transitions would consistently break — SvelteKit was just changing the page too fast! And there’s no way to tell it to wait to navigate, since beforeNavigate is synchronous.

The only way I could fix it was manually cancelling the navigation and restarting it with goto so the transition had a chance to start. This has some unintended side effects if another listener is checking the navigation type, and also doesn’t work for history traversals (e.g. hitting the back button). It doesn’t work all the time, but it’s much more consistent than before.

if (navigationType === 'link') {
  cancel();
  new Promise(res => setTimeout(res, 0)).then(() => goto(to?.url ?? ''));
}

Here’s the code snippet in context. I’m not happy with the workaround I found for this and want to find a better solution — maybe there’s a better API for SvelteKit to expose here?

Anyway, it was super fun to get back to these demos! I definitely spent a bit more time on them than expected. I love the effect and look forward to this API being implemented by other browsers (still TBD).

The problem: you’re working on some changes in a separate branch and want to update your branch with new changes from the main branch. How do you do it?

I used to take the long way round:

git checkout main
git pull
git checkout feature
git rebase main

However, I recently learned you can do this in two commands instead of four:

git fetch origin main:main
git rebase main

The first command fetches the latest changes from the remote and applies them to your local main branch. You then have the latest updates and can rebase your feature branch onto main (or merge, if you prefer).

Alternatively, if you’ve already fetched the latest changes (even if they haven’t been applied to your local main branch), you can do it in one command:

git rebase origin main

This will rebase your branch onto the latest changes from the remote main branch even if they haven’t been applied to your local main branch yet.

I have my IDE set to automatically fetch the latest changes, so I may find myself doing the second version more often.

I shared this tip over on Mastodon and went semi-viral (100+ boosts, 200+ favs) — well, as viral as a Mastodon post about git rebase can go.

• progressive enhancement: where possible, solutions should use native functionality (<a> and <form>) so they work without JavaScript and enhance when JavaScript is available.
• SSR-able: because you can't progressively enhance without starting with HTML, all solutions should be server-rendered (either at build or request time). SvelteKit enables this by default.

Originally I thought I thought I'd write a post exhaustively recounting each demo. However...

1. that's a lot of writing
2. very few people would read the whole post
3. and honestly, not every solution needs a detailed breakdown

So instead, I'm going to highlight my favorite 5 demos and link to the others at the end. In this post we'll show a few interesting techniques, including:

• progressively enhancing a search form that requests search results as the user types
• animating a details element open and closed with a Svelte action
• how to safely use random numbers in server-rendered Svelte components
• using recursion in Svelte components
• building a media player that works without JavaScript

One other minor change I made — the original solutions used Tailwind; I opted for Open Props and Svelte's scoped styles instead.

(Caveat: while I put a lot of time (too much?) into these, at the end of the day they are one-off demos that may not be ready for production. While I did my best, I haven't fully vetted the performance or accessibility of these solutions.)

Day 1: Product search bar

The challenge: build a debounced search bar for products using a dummy API.

I used a <form> so that I could progressively enhance the experience. With JS unavailable, it will submit your search via query params and reload the page. With JS available, it will still set query params, but update the results client-side without a full page refresh.

Note that there's no bind:value in this solution, which would only work with JS. Instead, I used an <input name="q"> inside a <form>. Submitting the form updates the URL and re-runs the load function, which passes the query param along to the external API. SvelteKit will automatically enhance <form method="get"> so that the page is updated client-side, though I implemented a custom submit handler myself to 1) replace URL state (so each new query doesn't add a new history entry) and 2) keep focus on the search box. There is an open feature request to make customizing this easier.

But using a form, how do we automatically load results as the user types? I used a debounced requestSubmit (not submit) call, which will behave the same as if the user clicked a submit button themselves. This is in contrast to the submit method, which will only submit the form — it won't run validation or custom submit handlers and will force a full-page reload. Make sure to check browser support before using this method. At time of writing, it was only recently supported in Safari (16.0 and above), but a polyfill exists.

const debouncedSubmit = debounce(() => {
  // not supported in all browsers
  if (typeof HTMLFormElement.prototype.requestSubmit == 'function') {
    form.requestSubmit();
  }
}, 300);

This is also a perfect case for using +page.js over +page.server.js, since we are calling a public external API. By putting it in the universal load function instead of the server load function, we can request the search results directly in the browser instead of passing the request through our app's server. Combined with SvelteKit preloading the data for the next page of results on hover, navigating feels instant!

I also implemented a declarative loading state: instead of toggling a boolean, I used a reactive statement checking the value of SvelteKit's navigating store.

$: isLoading = $navigating?.to?.url.pathname === $page.url.pathname;

Day 2: Christmas joke generator

The challenge: build a Christmas joke generator using the JokeAPI

I was super happy with the progressive enhancement on the joke reveal here. I used a details element for the "tell me!" button so that the joke was revealable without JS. To show the next joke, I used a form with only a submit button. This worked for the JS-less case, but I needed to call goto directly with invalidateAll when JS was available. Otherwise SvelteKit wouldn't do anything because you're navigating to a page you're already on (this could be a bug, I'm not certain.)

One problem with using the details element is there isn't a smooth transition when it expands. I couldn't use Svelte or CSS transitions either, since everything was already in the DOM and you can't animate height easily with just CSS. Instead, I adapted the approach from this CSS-Tricks article with a Svelte action. This is another example of progressive enhancement: when we have JS, the details animates. Otherwise, the content make sense without it.

Similar to the last one, we use +page.ts to load data so we can request it without passing through our server.

Here's the full +page.svelte (minus styles):

<script lang="ts">
	import { goto } from '$app/navigation';
	import { navigating, page } from '$app/stores';
	import type { PageData } from './$types';
	import Spinner from '$lib/Spinner.svelte';
	import animate from './animate';

	export let data: PageData;

	$: joke = data.joke;

	let open = false;

	async function handleSubmit(e: SubmitEvent) {
		const form = e.target as HTMLFormElement;
		await goto(form.action, { invalidateAll: true, replaceState: true });
		open = false; // close the summary
	}

	$: isLoading = $navigating?.to?.url.pathname === $page.url.pathname;
</script>

<h1>Christmas Joke Generator</h1>
<p class="setup">{joke.setup}</p>
<div class="wrapper">
	<details bind:open use:animate>
		<summary>Tell me!</summary>
		<div class="flex content">
			<p class="delivery">{joke.delivery}</p>
			<form on:submit|preventDefault={handleSubmit}>
				<button disabled={isLoading}
					>Another! 🎅
					{#if isLoading}<Spinner />{/if}</button
				>
			</form>
		</div>
	</details>
</div>

Day 11: Recursive Christmas lights

The challenge: create a lit Christmas tree using recursive components

This was an interesting way to use svelte:self, which otherwise doesn't come up very often. The <ChristmasTree> component recursively renders itself, similar to how a recursive function calls itself.

<!-- +page.svelte -->
<ChristmasTree size={7}>
  <ChristmasLights random={data.rng} />
  <ChristmasLights random={data.rng} />
</ChristmasTree>

<!-- ChristmasTree.svelte -->
<script lang="ts">
	import { fade } from 'svelte/transition';
	export let size = 1;
</script>

{#if size > 1}
	<svelte:self size={size - 1}>
		<slot />
	</svelte:self>
{/if}
<div class="tree" in:fade={{ delay: size * 100 }}>
	{#each { length: size } as _}
		<div class="leaf">
			<slot />
		</div>
	{/each}
</div>

Each of the <ChristmasLights> components randomly place a single light. I was surprised to see that not only could you use a Svelte <slot> multiple times in the same component, each occurrence of the slot has a unique instance of the slotted component. Even though I passed two Christmas light components into the tree's slot, there are more than two Christmas lights being rendered, and all have their own state. If this weren't true, each light would be in the same spot on each leaf, which is clearly not the case.

Another interesting challenge was getting random numbers to work with SSR. In purely-client-side Svelte, you can use Math.random without any consequences. However, with server-rendered Svelte, your component code runs twice: once on the server, and once during hydration. The second time your component code runs, the random number will be different and your UI will appear to "jump" to the new position. I ran into this issue with the lights, which used Math.random to place themselves randomly.

The way to fix this is to use a seeded random number generator, which given the same seed value, will generate the same list of random numbers. But then we run into a different problem: how do we generate a random seed? We could hard-code one, but then there would be no randomness — the lights would be placed in the same random position on every page load.

The solution I landed on could be a blog post by itself, but in short:

• generate a seed based on the current date in the root +layout.server.ts. By doing this in the root layout, it will only run once, so we don't unnecessarily hit the server to get a new RNG seed on each navigation. We need to do this in the server layout since +layout.ts will run again during hydration.
• then, +layout.ts uses that seed to create a random number generator (RNG). Any page can access this RNG via the data prop

import type {LayoutLoad} from './$types';
import seedrandom from 'seedrandom';

export const load: LayoutLoad = ({data}) => {
  return {
    // expose random number generator to be used in Day 11
    // we generate the seed on the server because the universal load runs twice
    rng: seedrandom(data.seed.toString())
  };
};

Now that we have a seeded RNG, we can pass that function to the <ChristmasLights> component to use instead of Math.random. You can tell that it's working by refreshing the demo page and seeing that the christmas lights stay where they are without jumping. Because the server- and client-render use the same seed, the component code generates the same random values.

This challenge was part 2 of a series of Christmas-tree-focused challenges that built on one another. The first was just the tree (no lights), and the third part added ornaments.

Day 14: Secret santa list generator

The challenge: build an app that will let you add names to a list and pair everyone up for Secret Santa.

This was a perfect challenge to take SvelteKit form actions for a spin! Pretty much every button on here triggers a progressively-enhanced form submission. The server code doesn't show on the demo page, so head over to GitHub if you're curious about the implementation.

The list of names is stringified and stored in a cookie so the server can access it. This was good enough for a POC where I didn't want to figure out a data layer, but it did cause some issues with concurrent updates. This is because the list of names is sent in a cookie with each request, so it doesn't get updated as other requests complete and it's possible to return stale data.

Typing in names again and again when testing got old quickly, so I added a "pre-fill" button powered by Faker.

This was also my first time taking Zod for a spin, which was very nice for parsing and validating the data in the cookie. Any Zod validation errors were caught and returned for the UI to render.

I also added some extra animation polish as elements were added and removed with Svelte's built-in FLIP animation and transitions. It's nice that this is only an extra line or two in Svelte instead of needing to reach for a separate library.

Day 15: Christmas radio

The challenge: build a media player with a list of Christmas-themed tracks

Instead of the stock audio tracks in the original challenge, I used snow-themed video game music songs.

This was slightly more challenging than the Vue version, since I didn't have useMediaControls and had to implement a lot from scratch (though Svelte's media bindings got me pretty far.) There were a lot of weird issues I ran into when running this demo on different browsers. For example:

• the audio element's paused binding got out-of-sync when the src changed
• you can't set media volume on iOS. Per MDN: "volume returns a value and is writable; however, the value is always 1, and setting a value has no effect on the volume of the media object."
• duration was not being set correctly when the audio element was rendered on the server

For all my hacky workarounds, see Controls.svelte. I'm pretty happy with where it ended up though.

Initially, I didn't make this work without JS (partly because of all the trouble I had working with audio elements). But the people on Twitter (well, one person) requested it and I couldn't stop thinking about it, so I got something working:

• the next/previous controls are form submit buttons that set the current query parameter. This is used to set the current track when the page loads.
• each selectable song is a link that also sets the current track (though in hindsight, I think using a button here may have been more accessible)
• buttons that only work when JS is enabled (e.g. fast-forward/rewind) are hidden when JS is disabled (detected via an inline script at the top of the body)
• and if JS is disabled, I rendered an <audio controls autoplay> element so that the audio element can be interacted with using the browser controls

The experience is much better with JS enabled, but it works.

And the rest

Here's a list of the other demos — click on whatever you find interesting and let me know if you have questions! Each page has a link to my solution's source code and original challenge. All the solutions are in the advent-of-sveltekit-2022 repo on my GitHub.

• a tic-tac-toe game, which I covered in a previous post. I was tempted to make this one work without JS like the SvelteKit Sverdle demo but didn't make time for it.
• a countdown to Christmas. The tricky bit of this one was getting the remaining time to server-side-render properly. I also really like the "rolling" animation as each digit counts down (made possible with CSS grid and a key block)
• a gift label generator and a gift price comparer
• drag 'n' drop the presents under the Christmas tree using the HTML drag and drop API
• an internationalized happy holidays message using Ivan Hofer's typesafe-i18n library as an alternative to vue-i18n. Ivan was kind enough to open a PR against my repo with suggested improvements. Of special interest is the WrapTranslation component I came up with, which lets you replace a certain portion of a translation with HTML (similar to vue-i18n's i18n-t element).
• sorting presents with some extra polish via animate:flip
• a Secret santa challenge, where I give three clues and you have to guess who I am. I used a SvelteKit form action for the final submission and Zod for validating the input.
• a gift puzzle visualization. This ended up being a visualization of the Josephus problem and my solution was wrong... oh well. One interesting thing about this solution is that I moved all the component logic into the +page.ts load function, so +page.svelte is a pure view layer that submits forms.
• a renderless component for calculating distance from the North Pole. The distance component doesn't render UI — it runs some logic and passes props to a slot. The consumer of the component can read those props and decide how to use them. This is another one that needs JS to run. While I could approximate location from IP address on the server, it seemed best to ask the user's permission for location data on the client first.

The site itself

I also had a fun time adding features to the site that hosted my solutions. For instance, I added animate:flip to the navigation above each challenge for that extra bit of polish.

I also implemented a custom layout load function that loads the raw source code for Svelte components in the current route (using Vite's import.meta.glob), so that I can display the code behind the solution on each page. I wasn't able to load the +page.server.ts code (since SvelteKit blocks you from importing server code on the client), but all of the other code is formatted using Prism and prism-svelte and shown under each solution.

// src/routes/day/+layout.ts
import type { LayoutLoad } from './$types';

const globs = import.meta.glob([`./**/*.{svelte,js,ts}`, '!**/*.server.{js,ts}'], { as: 'raw' });

export const load: LayoutLoad = async ({ url, route }) => {
	const segments = route.id?.split('/');
	const day = segments?.[2];

	let code: { filename: string; source: string }[] = [];
	const modules = Object.entries(globs)
		.filter(([k, v]) => k.startsWith(`./${day}/`) && !k.includes('.server'))
		.map(([k, v]) =>
			v().then((result) => {
				const segments = k.split('/');
				return { filename: segments.slice(2).join('/'), source: result };
			})
		);
	code = await Promise.all(modules);

	return {
		day: +day,
		code
	};
};

// this is then accessible via data.code in the +layout.svelte

Wrapping up

I had a ton of fun with these challenges and I'll definitely continue to use forms and progressive enhancement techniques in my other work. In fact, my previous post details how I applied some of the lessons I learned here to a search form in one of my side projects.

Also, I'm not the only one who tackled the Advent of Vue challenges in Svelte — check out Paolo Ricciuti and Antonio Sarcevic for alternate implementations. And if you also did them, let me know and I'll link you too!

These filters only worked on the client-side — you couldn't use them if you didn't have JS enabled, and any filters you applied would be lost when you refreshed the page. There was also a particular gnarly setup to keep track of selected creators/events/series across page loads — see the persistence section further down for more details on that.

I recently did a lot of progressive enhancement experiments with Advent of SvelteKit 2022 and wanted to bring over some of those techniques to this site. My goals were:

1. Move filter state into the URL to make sharing and persisting filter state easier
2. Use web platform primitives like <form> so that the site still works when JS is unavailable

(Note that this particular site doesn't call an API to do any filtering — I just get the raw data from the Marvel API and then implement any filtering needed myself.)

Here's a quick overview of what I did. Some of these techniques may be expanded into full posts in the future.

You can find the full PR on GitHub if you're really curious.

Goodbye bind:value, hello <input name>

To meet my goals, instead of reading the values of the inputs with Svelte input bindings and updating the state of the page accordingly, I needed to put them in a <form> and give them names so that the values would be submitted with the form.

<form>
    <label>Search <input type="text" name="search"/></label>
    <Select
        options={sortOptionText}
        values={sortingOptions}
        id="sorting"
        name="sortBy">Sort by</Select
    >
    <Select options={months} id="month" name="month">Release Month</Select>
    <label><input type="checkbox" name="ascending" />Ascending</label>
</form>

Since the form's method was GET, submitting the form would put the values of the inputs in the URL as query parameters (goal #1), and because it was a form, it would work without JS (goal #2).

I then needed to get the values out of the URL to use them to update the UI. In SvelteKit, this can be implemented as a reactive statement reading $page.url.searchParams, which holds the page's current query params. I'll show how I made this type-safe in a later section.

$: search = $page.url.searchParams.get('search');
$: sortBy = $page.url.searchParams.get('sortBy');
// and so on

But with this initial implementation, we introduced a UX regression — the page no longer updates as you fill in the form and toggle checkboxes. Instead, you have to click "Submit".

Automatically submitting the form with requestSubmit

To fix this, I reached for a method I used on quite a few Advent of SvelteKit challenges: requestSubmit. Unlike the normal submit function which only submits the form (and triggers a full-page refresh), requestSubmit will behave identically to the user clicking the submit button: it will run validation, custom submit handlers, and other goodies.

So, by calling requestSubmit on every form change, we'll automatically update the page and filter the displayed comics without the user needing to click "Submit". It ended up looking something like this:

<script>
	let form;
	const requestSubmit = () => form.requestSubmit();
	const debouncedSubmit = debounce(requestSubmit, 250);
</script>

<form
	bind:this={form}
	on:input={debouncedSubmit}
	on:change={requestSubmit}
>

For input events, I called a debounced version of the submit (using the zero-dependency utility library Just) that only fired every 250ms. This way we don't run the filter logic on every keypress; instead, we give the user a chance to finish typing. Since changing a select or checkbox are single actions, we'll immediately submit the form on change events.

But this introduced a new problem — SvelteKit will automatically trigger a client-side navigation when you submit a <form method="GET">, but it will also reset the page focus and add a new entry to the browser history. In this case, I didn't want that:

1. We don't want to move the user's focus away from the text box when they're still typing
2. We also don't want a new browser history entry for partial search strings. If they're typing "Black Panther," we don't want history entries for "Bla", "Black P", and "Black Panther".

There is a feature request to allow customizing this behavior on <form method="GET">, but for now, I implemented a custom submit handler that keeps focus and replaces the current history entry when submitting the form.

// add to form with on:submit={submitReplaceState}
export function submitReplaceState(e: SubmitEvent) {
  e.preventDefault();
  const form = e.target as HTMLFormElement;
  const url = new URL(form.action);
  // @ts-expect-error
  const params = new URLSearchParams(new FormData(form));
  url.search = params.toString();
  goto(url, {replaceState: true, keepFocus: true, noScroll: true});
}

It's worth noting that requestSubmit was only recently supported in Safari (16.0 and above), so I ended up polyfilling it. You could also consider falling back to submit, though keep in mind that will trigger a full-page reload if they don't support requestSubmit.

+page.ts or nah?

I briefly experimented with moving the query parameter parsing logic inside a +page.ts load function (a.k.a. universal load function). I wanted to keep it out of +page.svelte to avoid making that file too messy. Instead, the load function would return a filter object (parsed from the list of query params) that represented the state of the form. However, I wanted to make sure that while doing this I was not refetching the list of comics in the server load function on every form change, since that was a lot of data and would be wasteful.

Surprisingly, this worked — the universal load function re-ran when the query parameters changed, and it did not re-run the server load function in +page.server.ts. However, it did have an unintended side effect. Because the universal load function re-ran, it returned a new data object, and all the reactive statements that used that data object also re-ran. In particular, the code to transform the giant list of comics into a list of unique creators/series/events on those comics was re-running on every form change, which seemed wasteful.

Because of this, I kept the query param parsing logic inside +page.svelte, which seemed to work fine and did not invalidate the entire page data object. (The query param parsing logic will become one line in a later section, so the impact on +page.svelte length is negligible.)

Checkbox weirdness

Turning everything into a real form input did bring some weirdness with it. For instance, before these changes, I had a "Descending" checkbox that defaulted to "checked". However, I couldn't figure out a good way to default it to checked — if it was checked by default, but not in the URL, then how would we determine if we're in an actual "unchecked" state? It wasn't that big a deal, so I flipped it to be "Ascending" instead and default to unchecked.

Also, the creator/series/event filters had a massive number of checkboxes that used to be enabled by default. Now that they're in a form, submitting that form would make the URL absolutely ginormous, since each checkbox would appear as a query param (e.g. "&creator=1&creator=2&creator=3...").

To work around this, I updated the filter checkboxes to be unchecked by default, and for the UI to treat "no creators selected" the same as "all creators selected." This meant there wasn't an easy way to select all but one creator, but I don't think that's a common use case.

Now instead of "Check all" and "Uncheck all" buttons, there's just one "Select all" button that unchecks anything.

Type-safe query param parsing with zod-form-data

So everything is a query param now, which is cool for progressive enhancement, but everything being a query param means everything is also a string, which is bad for type safety. Enter: Zod, which will parse our search params, validate that they adhere to a given schema, and return a fully typed object. I also used zod-form-data (which was written for Remix, but can be used here since SvelteKit also uses web Request/URL objects) to make parsing URLSearchParams easier.

Here's what my schema ended up looking like:

import {z} from 'zod';
import {zfd} from 'zod-form-data';

const SortOptionEnum = z.enum(['BestMatch', 'Title', 'PublishDate', 'UnlimitedDate']);

const MonthEnum = z.enum(['all', 'Jan', 'Feb', 'Mar' /* etc. */]);

export const SortOption = SortOptionEnum.enum;
export const Month = MonthEnum.enum;

const multiCheckbox = zfd.repeatable(z.array(zfd.numeric())).catch([]);

export const filterSchema = zfd.formData({
  search: zfd.text(z.string().default('')),
  ascending: zfd.checkbox(),
  // use catch in case no value or bad value passed
  sortBy: zfd.text(SortOptionEnum.catch('BestMatch')),
  month: zfd.text(MonthEnum.catch('all')),
  series: multiCheckbox,
  creator: multiCheckbox,
  event: multiCheckbox
});

Which I could then use like so on the page:

$: filter = filterSchema.parse($page.url.searchParams);

Then filter would be something like this object, which I could use in my various filtering/sorting functions:

{
    search: "spiderman",
    ascending: false,
    sortBy: 'BestMatch',
    month: 'all',
    series: [],
    creator: [1,2],
    event: [67]
}

I made liberal use of catch to provide default values when the data couldn't be parsed.

This was extremely helpful to catch bugs when I was refactoring existing logic, since the new search params had defined types instead of just being a string. Some of the zod-form-data constructs were a little wordy, but I'm not sure if that's because I was using it incorrectly. I did run into a bug using ZFD with Vite, which I was able to work around by putting it in noExternal.

I'm pretty new to Zod, but look forward to exploring it more in the future.

Persistence

Now since everything is a query param, all I have to do to persist the filter state across different pages is append the query params to the next/prev links:

<a href="/year/{year + 1}{$page.url.search || ''}">Next year</a>

This also simplified the code around persisting the series/creator/event checkbox state between pages. This has been a tricky part of the code historically, since the checkbox options for those filters are completely different between pages — 1982 will have different series released than 1983 (though with some overlap). But I didn't want to reset the selected filters between pages. Ideally if you have "Avengers" selected on 1982 and click on to 1983, "Avengers" should still be selected.

The previous iteration of this code had a complicated custom store factory setup that kept track of the previous selected state and updated it to 1) remove any selected options not present on the new page and 2) keep selected options around that are on the new page. I didn't really want to touch this code now that everything is a query parameter. Instead, I wanted to see what happened if I simply forwarded on the selected query parameters and derive the new filter state based on that (solving requirement #2). So if you have ?series=2&series=3 in the URL, going on to the next page would keep those in the URL. And... this pretty much worked!

I don't have to worry about selected options not present on the new page — when the user selects another option, it will only put the new option in FormData (since this is how forms work) and not keep the old one around.

I probably could have simplified the code in a similar way without forms, but "thinking in FormData" unlocked this simpler solution for me.

Submitting when no JS available

Lastly, we automatically submit the form when JS is available, but what about when it's not? On the text input you can hit "Enter" to submit the form and reload the page, but this doesn't work well with the checkboxes — you would have to select a checkbox, focus the text input, and hit "Enter". This isn't a great experience. It would be much better if we had an actual submit button.

However, I didn't want a submit button when JS is available, because it wouldn't do anything since the form is automatically submitted.

EDIT: as pointed out by Jayphen on Twitter, we can short-circuit the rest of the section by wrapping the button in a noscript tag. Leaving the rest as an alternate approach (and you could use the classes for more fine-grained control of what happens when JS is unavailable).

One option would be to have a submit button on the page for the initial server render and then hide it using onMount or checking browser. Unfortunately, this could be jarring, since the submit button would render and then abruptly vanish when the page hydrates.

Instead, I added a short inline script to the top of the <body> in app.html that will run before anything renders. This toggles the no-js and has-js classes on the body.

<body data-sveltekit-preload-data="hover" class="no-js">
  <script>
    document.body.classList.add('has-js');
    document.body.classList.remove('no-js');
  </script>
  <div id="svelte">%sveltekit.body%</div>
</body>

I added some global utility classes to hide or show elements based on JS availability:

body.has-js .no-js-only {
  display: none;
}

body.no-js .js-only {
  display: none;
}

And then we can add a submit button like this, and it will only show when JS is disabled:

<button type="submit" class="no-js-only">Submit</button>

Like anything progressive enhancement, this is about tradeoffs. This won't have a FOMB (flash of misplaced button), but it will also hide the button when JS is enabled but not available yet (i.e. the page is hydrating).

Wrapping up

So that's how I spent my three-day-weekend — let me know if you have any feedback or suggestions!

Progressive form enhancement with SvelteKit is a topic I'm very interested in, so expect more content from me on that topic in the future.

It focuses on breadth instead of depth - 300+ tracks from 170+ games, including genres as varied as epic orchestral (God of War: Ragnorok), vibey electronica (Citizen Sleeper), Queen-inspired rock opera (Air Twister), and Peruvian folk music (Imp of the Sun). I tried to get as many 2022 game soundtracks on here as I could (at least what was available on streaming)!

• Spotify
• Apple Music

Special shout out to the following resources where I sourced soundtracks from, as well as trawling GOTY 2022 lists:

• A Closer Listen - The Year's Best Videogame Soundtracks
• The MinnMax Show - Our Favorite Game Music From 2022
• NOWPLAYING - Best of 2022
• VGC - These are the best game soundtracks of 2022, according to composers

Some of my favorite tracks:

• "Praise the Lamb", Cult of the Lamb
• "Yearning to Bloom", Mario + Rabbids Sparks of Hope
• "Once in a Lullaby", Risk of Rain 2: Survivors of the Void
• "Journey to Candle Hill", WaveTale
• "The Weight of Rain", TUNIC
• "Circling", Far: Changing Tides

And while they aren't on the publicly-available versions of this playlist (or available for purchase/streaming), I also greatly enjoyed the soundtracks to Kirby and the Forgotten Land, Xenoblade Chronicles 3, and Pokemon Scarlet/Violet.

Here's a list of all the songs for posterity (#OwnYourContent):

Writing

I wrote 12 articles this year (excluding posts that were linking to other content), which feels good to me. I'd always like to write more, but I have more ideas than time and an average of 1 a month feels like a good pace. My favorite posts were the ones where I did a deep dive on integrating Svelte with "something else"—the experimental view transition API, 11ty's framework-agnostic partial hydration solution, and Vercel's Satori library for custom og:images. For me, writing about something makes it real—if nothing else, so I can look back at my article titles from the last year and remember what I did.

My most popular post from this year was on Svelte's new style directive (~5k views), mostly from Google traffic—I assume it ranks well for "svelte style directive." My most popular overall was The many meanings of $ in Svelte (~6k views), which I wrote at the end of 2021 but also gets a consistent stream of traffic from Google.

I also did one freelance article for an external outlet—I wrote for Upstash on combining SvelteKit, Upstash Redis, and Vercel edge functions.

Speaking

I had a few speaking appearances this year:

• I introduced Svelte and contributing to open source on 20minJS
• I guested on Svelte Radio to talk about using Svelte at work and life so far as a core team member
• I also introduced Svelte on the TKYT YouTube show. This one was extra fun, since we built a small Star Wars watching order app and got to touch on almost all the basics of Svelte
• I gave one remote meetup talk for Svelte London on native page transitions in SvelteKit

All were very fun, though a little stressful beforehand, since I didn't always know where the conversation would go. I usually like to do a lot of prep work, which can be time consuming. However, I'd still love to do more of this in 2023!

Open source

In January 2022 I was asked to join the Svelte core team, which was an incredible honor. It was very exciting to see SvelteKit develop from the inside and all the work that goes with it. Most of my contributions focused around accessibility and trying to make sure that SvelteKit and the docs site are accessible, as well as providing feedback around new Svelte/SvelteKit API features and proposals. The contribution I'm most proud of was writing up some dedicated docs around SvelteKit and accessibility, and I really appreciated the reviews on that content from Melanie Sumner and Matthew Gibbons. In the new year, I definitely want to take a look at other accessible patterns we can document, as well as seeing if there's anything we can do to make our client-side routing more accessible—there's already been some Twitter feedback around that.

I also continued to maintain my SvelteKit adapter for Azure Static Web Apps. Most of this was keeping up with the breaking changes in the adapter API when SvelteKit was pre-1.0. I also got some PRs from external contributors, which was fun to see! I'm hoping to get this package to 1.0 this year—there are just some configuration things to work out first.

Personal life

Two big things happened to me personally this year. First, my wife and I bought our first house in April, and moved in May. While there has been a ton to get done, we're very happy to have our own space. The cats took a little while to adjust, but they eventually settled right in and appreciated all the extra windows.

Second, in August I left Alaska Airlines, where I had been for four years, and accepted a fully-remote role at Ordergroove, a startup in the e-commerce subscription space. I hugely appreciated my time and growth at Alaska, where I was a major contributor to our open-source design system and got to introduce Svelte, but it was time to take on some new challenges. I've been enjoying the new role and look forward to everything to come this year.

I was also hoping to make it to Svelte Summit in Stockholm in September 2022, but unfortunately got Covid only a couple days before leaving. Hopefully I make it this year—there are so many from the Svelte community I want to meet!

Finally, I did rethink my approach to social media a bit with all the upheaval at Twitter. It was a good reminder that social media is ephemeral, and you should be posting anything you care about on your personal site. Going forward, I want to be more intentional about posting content here that I would previously only tweet out, like random demos. I also have an account on Mastodon now, and I've enjoyed being a part of the community over there. For now, I'll still be posting new articles over on Twitter (and Mastodon), but any other musings will probably stay on Mastodon. (And if you are using Mastodon, I recommend giving the Elk client a try!)

Goals

I have a few goals in 2023:

• I want to read more prose. I read 14 prose books last year; this year I'd like to at least hit 20. I used to read a lot more than this, so I just need to be more intentional with how I spend my time.
• I want to continue to write an average of 1 blog post a month.
• I want to give a talk somewhere (meetup/conference/etc)

Favorite media of the year

On the off chance you care about my taste in media, here's what I enjoyed this year.

For video games, the game I played the most was the new Lego Star Wars, which was a blast (though I wouldn't have sunk nearly as many hours in it if I wasn't also listening to a podcast and recovering from Covid at the same time.) Even though it didn't come out this year, I also played a lot of Picross 3D for the Nintendo DS, another good podcast game. Honorable mentions: Return to Monkey Island, Shovel Knight Dig, 999 (from 2010)

Speaking of podcasts, my podcast listening time has gone down a bit since I stopped commuting, which is a blessing and a curse. Thankfully (?), the new house doesn't have a dishwashwer, so the dishwashing time has been making up for it. My absolute favorite podcasts have been Svelte Radio (of course), My Marvelous Year (a book club going through a curated list of Marvel comics), and A More Civilized Age (a Star Wars: The Clone Wars podcast)—these are the podcasts I listen to every episode of. Honorable mentions: Strong Songs (music analysis), Triple Click & Waypoint Radio (gaming), Shop Talk Show (web dev), Off Panel (comics interviews), Mangasplaining (manga book club)

For movies, the most fun I had in a theater was Glass Onion which I saw with the whole family after Thanksgiving. Just a wonderful rollercoaster of a whodunnit that never quite goes where you expect. RRR was also an Experience, though in a completely different way. In the words of Patrick Willems, "the best movie ever made about fighting colonialism with dance battles and armies of rampaging animals and most of all, friendship." And I also watched the Mission Impossible series for the first time, which was a great way to recover from Covid. Honorable mentions: Everything Everywhere All At Once, Avatar: The Way of Water, Nope, The Unbearable Weight of Massive Talent, Turning Red, AmbuLAnce

For TV, my show of the year had to be Star Wars: Andor, an extremely well-written and well-paced show about the rise of the rebellion. Having it released weekly enriched the experience, since the anticipation and discussion between episodes was part of the fun. That prison arc on Narkina 5... hoo boy. Honorable mentions: Severance, Our Flag Means Death, Only Murders in the Building, The Rehearsal, The Boys, House of the Dragon

I didn't read as much prose as I'd like this year, but my favorite book was Locklands by Robert Jackson Bennett, which concluded The Founders trilogy. I really recommend the trilogy if you like Sci-Fi/Fantasy books, especially if you are in the software field—the magic system in these books revolves around "scriving", essentially programming objects to do extraordinary things. From Tor.com's review of the first book:

Utilizing a complicated alphabet left behind by ancient, almost mythological figures called the Hierophants, mankind has figured out how to imbue everyday objects with something akin to sentience and convince these objects to do work for them. Some scrivings can convince wheels to move across flat surfaces as though they were rolling downhill. Others tell a sword that it is as sharp as ten blades in one, capable of cutting through nearly anything. Others tell a candle that it can never burn out. And in this world of scrivings, the four major Merchant Houses all vie for dominance in their enormous campuses, while outside of them, people like Sancia Grado cobble together enough to survive.

I probably would have enjoyed it more if I had been able to remember what happened in the previous two, though (which I read two years ago). Honorable mentions: Star Wars: Brotherhood, The Lost Metal, Leviathan Falls

I did read a lot of comics, though—mostly along with various "book club"-style podcasts I listen to (so a selection of manga and Marvel comics 1994-2000), but also some self-directed reading. My favorite was James Tynion IV's The Nice House on the Lake, where old friends are invited to a lake house for a getaway, and well... things happen. To say any more would ruin the experience, so if you have any interest at all, I recommend reading it without looking up more about it. I'm really looking forward to the second (concluding) volume later this year. I also read a bunch of the manga Blue Giant about a rising jazz saxophonist, which was another great read. Honorable mentions: A.X.E.: Judgment Day, MacKay's Moon Knight, Cantwell's Iron Man, Newburn

Most of the music I listen to is video game music. My favorite soundtrack of the year was Kirby and the Forgotten Land, which varies between the kind of cheerful music you'd expect from a Kirby game to a 5+ minute prog jazz epic. I also really enjoyed Shovel Knight Dig, which had a bunch of energetic Sega-inspired chiptunes—Jake Kaufman always delivers the goods. And of course, Xenoblade Chronicles 3 delivered a heaping portion (10, 11 hours?) of some of the best JRPG music ever. Honorable mentions: Pokemon Scarlet/Violet, Sonic Frontiers, TUNIC

On the non-VGM front, my favorite album was Jukebox the Ghost's Cheers, a wonderful album of Queen-inspired piano-driven rock. I also played a lot of Carlos Eiene's debut Insane in the Rain, a collection of original jazz fusion tunes that nonetheless are influenced by the style of Japanese video game music.

Wrapping up

So that's the year that was—hard to believe that was all this year! Here's to an even better 2023.

They sent out an early challenge to recreate the game tic-tac-toe. Here's the solution I came up with. The code is on GitHub, and I'll briefly explain it below. While building tic-tac-toe may seem simple, there are some interesting wrinkles, especially with regards to accessibility.

Rendering the board

I represented the board as a 3x3 array.

let board = [
  [Move.Empty, Move.Empty, Move.Empty],
  [Move.Empty, Move.Empty, Move.Empty],
  [Move.Empty, Move.Empty, Move.Empty]
];

Each item in the array is a TypeScript enum - either Empty if the space is empty, or X or O if the space is occupied.

enum Move {
  X = 'X',
  O = 'O',
  Empty = ''
}

In the template, we iterate over this array using #each loops.

{#each board as row, r}
    {#each row as col, c}
        <div class="cell">
            {#if col !== Move.Empty}
                <Icon move={col} />
            {:else}
                <EmptyCell on:click={() => place(r, c)} disabled={state !== State.Playing}>
                    <span class="visually-hidden">Place row {r + 1} column {c + 1}</span>
                </EmptyCell>
            {/if}
        </div>
    {/each}
{/each}

The <EmptyCell> is its own component for easier colocation of styles, but it's essentially a <button>. It represents an empty space on the board that the player can place their token on.

It's important that we use a <button> here. This helps ensure that people can interact with it even if they're using a keyboard or other assistive technology - a <div on:click> would not be the same.

<script>
	export let disabled = false;
</script>

<button on:click {disabled}>
	<slot />
</button>

<style>
	button {
		width: 100%;
		height: 100%;
		appearance: none;
		border: none;
		background: none;
		border-radius: var(--border-size-3);
	}

	button:hover,
	button:focus-visible {
		background-color: var(--gray-2);
		box-shadow: var(--shadow-3);
		cursor: pointer;
	}

	button:focus-visible {
		outline: solid var(--svelte);
	}

	button:disabled {
		cursor: not-allowed;
	}
</style>

Note the on:click - this instructs Svelte to forward the event so we can listen to the click event on the parent <EmptyCell> component.

Also, since we use a <slot>, the content inside <EmptyCell> will be placed inside the component's <button> element.

<EmptyCell on:click={() => place(r, c)} disabled={state !== State.Playing}>
    <span class="visually-hidden">Place row {r + 1} column {c + 1}</span>
</EmptyCell>

The <span class="visually-hidden"> gives our <button> a label. Even though we don't want any text to show visually, we still need to give the button a unique name so that assistive technology understands its purpose. If you haven't seen this technique before, this is a good article on visually-hidden and buttons.

In our case, we are uniquely identifying each button with the row and column it's at. For example, the middle space will have the name "Place row 2 column 2".

Playing the game

The click handler on the <EmptyCell> above calls place with the cell's row and column index. place updates the board at that position and swaps whose turn it is. It also manages focus, but we'll take a closer look at that in a bit.

function place(row: number, col: number) {
  board[row][col] = turn;
  turn = turn === Move.O ? Move.X : Move.O;
  tick().then(focusNextAvailableTile);
}

Because we update board, the reactive statements to update the winner and state also run.

$: winner = checkWinner(board);
$: state = getGameState(winner, board);

It's very nice to be able to declaratively write reactive logic like this. Instead of having to remember to check if there's a winner in every function we update the board, we instead say "hey, whenever board changes, update winner again." This means when we clear the board in reset, winner and state will automatically update too.

function reset() {
  board = getEmptyBoard();
  // no need to set winner and state here
  tick().then(focusNextAvailableTile);
}

Here's how we determine the winner of the tic tac toe game. We check all possible winning states and return the winner if there is one. (There's probably a more elegant way to do it, but this gets the job done.)

export function checkWinner(board: Move[][]) {
  for (const row of board) {
    if (row.every(v => v === Move.X) || row.every(v => v === Move.O)) {
      return row[0];
    }
  }

  for (let i = 0; i < board[0].length; i++) {
    if (board[0][i] && board[0][i] === board[1][i] && board[1][i] === board[2][i]) {
      return board[0][i];
    }
  }

  if (board[1][1] === Move.Empty) {
    return;
  }

  if (board[0][0] === board[1][1] && board[1][1] == board[2][2]) {
    return board[0][0];
  }

  if (board[0][2] && board[0][2] === board[1][1] && board[1][1] == board[2][0]) {
    return board[0][2];
  }
}

We also update the "game state". The tic-tac-toe game is either in the Won, Draw, or Playing state. This helps keep logic about the state of the game consistent - instead of checking winner and board in multiple places, we only need to check the state variable.

function getGameState(winner: Move | undefined, board: Move[][]) {
  if (winner) {
    return State.Won;
  } else if (board.every(row => row.every(col => col !== Move.Empty))) {
    return State.Draw;
  } else {
    return State.Playing;
  }
}

The state is mainly used to display a message below the game board.

<div class="status" bind:this={statusEl} tabindex="-1">
    {#if state === State.Won}
        {winner} won.
    {:else if state === State.Draw}
        It's a draw!
    {:else}
        It's {turn}'s turn
    {/if}
</div>

{#if state !== State.Playing}
    <button on:click={reset}>Play again?</button>
{/if}

Focus management

When a move is made, we replace the <button> with an icon showing which player moved there.

{#if col !== Move.Empty}
    <Icon move={col} />
{:else}
    <EmptyCell />
{/if}

This causes problems for keyboard and other assistive tech users because their focus will be lost abruptly. Instead, we should intentionally move focus somewhere after each player's move. For this project, I chose to move focus to the next available spot, or to the status element if there are no spaces left (i.e. the game has ended).

function place(row: number, col: number) {
  board[row][col] = turn;
  turn = turn === Move.O ? Move.X : Move.O;
  tick().then(focusNextAvailableTile);
}

function focusNextAvailableTile() {
  const nextTile = boardEl.querySelector('button:not(:disabled)');
  if (nextTile) {
    (nextTile as HTMLElement).focus();
  } else {
    statusEl.focus();
  }
}

A few things to note:

1. We use Svelte's tick function. This returns a Promise that resolves after all state updates have been applied. If we didn't use tick, then we would move focus too early. board would be updated, but the DOM would not reflect those updates yet, so we might move focus to a space that will be removed on the next tick.
2. We're using querySelector to get the first available button that isn't disabled. Using querySelector in Svelte is usually an antipattern, but in this case it makes a lot of sense. First, we are scoping it to the boardEl so that it only applies to elements inside the board. This is much safer than document.querySelector, which could return nodes anywhere in the document. Second, this is a much more efficient way to get the node. We could try to determine with JS which space is the first available one, and then call focus on a bound EmptyCell component corresponding to that space, which would call a focus method we expose inside that component. But that's a lot to wire up. That's not to say using querySelector is not without risk - if this was a production application, someone else refactoring the EmptyCell could unexpectedly break this logic. But for this demo, I think it's the best choice.
3. If no spaces are available, we focus the status element instead. This is a sensible place to move focus since if no spaces are available, it will announce who won or lost. The status element is a div, which can't normally receive focus, so we set tabindex="-1" on it. This makes it so the element can be programatically focused (like we're doing now), but it won't be focused by someone tabbing through the document normally.

<div class="status" bind:this={statusEl} tabindex="-1"></div>

Wrapping up

I hope that was a useful look at how I built something like this. I'm planning to work through the rest of the Advent challenges as they're released throughout December (though no guarantees). I'll be sharing them out as I go on Mastodon and/or Twitter.

This post was updated in January 2024 to use SvelteKit's new read method to read font data on the server.

When you share a blog post or site on social media, the first thing most people will see is a social card image, or "og:image". Adding one of these can massively increase the number of people who engage with your post. In the past, you either had to manually create these images or automatically generate them with a headless browser or service. However, Vercel recently launched a library that makes generating these images easier, faster, and cheaper. In this post, I’ll show you how you can use that library to generate social card images using Svelte components. Even though I’m focusing on Svelte, the concepts should transfer to any component framework that you can render to an HTML string.

What is og:image?

A deep dive on this is outside the scope of this blog post, but I’ll give the tl;dr. An og:image is a type of <meta> tag that you put in your site’s <head>. Social media sites will use this information to display the given image when you share that URL. For instance, one of my recent blog posts looked like this on Twitter:

Swyx has a blog post that does a good job explaining what they are and why you would want them on your site (though the information around generating them is out of date).

While there are other meta tags to display information like title, author, description, and so on, we’ll focus on the image today.

Previously, if you wanted an og:image on your site, you had a few options:

• you could choose a single static image to show for every page on your site. This was easy, but boring.
• you could create an image for each page manually.
• you could use a hosted service like Cloudinary to do it for you.
• you could automate og:image generation using Puppeteer to take screenshots of Headless Chrome. This let you write your templates as HTML and CSS, making it easy to update your template, but it could be slow. Chrome is also too large to fit in a serverless function, so you couldn’t host on common providers like Vercel or Netlify. GitHub uses this method to generate social share images for repos, issues, and PRs, but they also had to work around performance issues

In the past I tried using Puppeteer to generate my images, but ran into issues running locally (granted, I was on an old version of WSL at the time). I currently use the second option—I have a Figma template and update it for each post. This works, but it’s tedious. It is also time-consuming if I ever wanted to update my template for all previous posts. Some of my older blog posts still have an old card design that I don’t like but I haven’t updated them due to the time commitment.

Wouldn’t it be nice if there was an automated solution that was fast, easily deployable, and that could be configured using modern component syntax? Well…

Introducing @vercel/og

Last week Vercel launched a new library to generate social card images. Instead of spinning up headless Chrome and taking screenshots, this library library converts HTML and a subset of CSS into images. This makes for a solution that is easier (you’re just writing HTML), 5x faster, and 100x more lightweight than running headless Chrome. For more tech details, see this Twitter thread by creator Shu Ding.

When I saw this my first thought was: how can I use this in SvelteKit, and with a Svelte component? Since I use Svelte for my personal projects, it would be a very nice dev experience to write my social images in Svelte.

Unfortunately, all the official examples use JSX syntax and I didn’t want to take a dependency on React. But it is possible—you just have to wire some things together. Here is what we’ll be working with:

1. The key dependency here is Satori, the underlying library powering @vercel/og. It does the hardest part: taking HTML (well, JSX) and turning it into an SVG. It only accepts JSX, so you can either manually create React-like objects (e.g. { type: div, props: { children: "Hello world" } } ), or you can…
2. Use satori-html, a library from Astro’s Nate Moore that will turn an HTML string into an object Satori can use. You can write the HTML string manually, but we’ll be generating it from a Svelte component instead.
3. To get the HTML string from the Svelte component, you can import the component on the server and call .render() to get the HTML representation. This is possible via Svelte’s server-side component API. This step is also very performant, since rendering a Svelte component server-side is just string concatenation.
4. Finally, once we create an SVG from the HTML string using Satori, we can turn that into a PNG using resvg-js.

So the code for this ends up looking something like this:

const componentResult = component.render();
const htmlString = satoriHtml(componentResult.html);
const svg = await satori(htmlString, satoriConfig);
const image = new Resvg(svg, resvgConfig).render();
return new Response(image.asPng(), {
	headers: {
		'content-type': 'image/png'
	}
};

While the details here can get a little tricky, that’s not a lot of code! The pipeline ends being: Svelte → HTML → JSX → SVG → PNG. Whew!

(There might be a way to use @vercel/og directly with the same satori-html transform. This would give us less to implement, since @vercel/og will automatically construct a PNG response and allow you to use emoji, other languages, and Tailwind CSS. However, I ran into WASM errors when running locally with Vite. Vercel also specifies that @vercel/og is only compatible with the Edge Runtime.)

With the overview out of the way, let’s drill into the details.

Warning: both Satori and satori-html are pre-v1, so there could be breaking changes. This demo has been developed with satori@0.10.11 and satori-html@0.3.2.

Getting started

To follow along, create a new SvelteKit app following the instructions on the SvelteKit homepage. Select the skeleton project template when prompted. I’ll be using JavaScript (with JSDoc) for this post, but you can select TypeScript if you like.

npm create svelte@latest sveltekit-og
cd sveltekit-og
npm install
npm run dev -- --open

We’ll need a few dependencies, as mentioned above:

npm i satori satori-html @resvg/resvg-js -D

Satori also requires you to BYOF (bring your own fonts). It will use the raw font data to render any text to SVG paths. For this demo, download the Noto Sans font from Google Fonts. Unzip the folder and place the NotoSans-Regular.ttf file inside a folder at /src/lib.

Now that we have all the dependencies, let’s create a server endpoint that will generate OG images. We’ll start small, and just pass a "hello world" string for now. Once we get the basic image generation setup working, we can add a Svelte component.

Create a new file at src/routes/og/+server.js and paste in the following code:

import satori from 'satori';
import {Resvg} from '@resvg/resvg-js';
import NotoSans from '$lib/NotoSans-Regular.ttf';
import {read} from '$app/server';

const fontData = read(NotoSans).arrayBuffer();

const height = 630;
const width = 1200;

/** @type {import('./$types').RequestHandler} */
export const GET = async () => {
  const html = {
    type: 'div',
    props: {
      children: 'hello, world',
      style: {color: 'red'}
    }
  };
  const svg = await satori(html, {
    fonts: [
      {
        name: 'Noto Sans',
        data: await fontData,
        style: 'normal'
      }
    ],
    height,
    width
  });

  const resvg = new Resvg(svg, {
    fitTo: {
      mode: 'width',
      value: width
    }
  });

  const image = resvg.render();

  return new Response(image.asPng(), {
    headers: {
      'content-type': 'image/png'
    }
  });
};

This creates a SvelteKit server route that will generate OG images for us. We're using SvelteKit's read function to retrieve the raw font data. For more on how this function works, see my post about it.

With that change, you should be able to run the app and navigate to /og and see the generated "Hello, world!" image.

Wiring this up to a Svelte component

Now that we have the basics working, let’s generate our markup from a Svelte component instead. Create a Card.svelte file inside the src/lib folder and move our "Hello, world!" content in there.

<div style="color: red">Hello, world!</div>

We can import this component on the server and use it to generate our HTML instead of writing it by hand. We’ll use the excellent satori-html library I had you install previously. Add the following imports to the top of our +server.js…

import {html as toReactNode} from 'satori-html';
import Card from '$lib/Card.svelte';

…and replace the hard-coded element definition with the following lines:

const result = Card.render();
const element = toReactNode(`${result.html}<style>${result.css.code}</style>`);