Asynchronous Svelte #15845

Rich-Harris · 2025-04-28T22:19:29Z

Rich-Harris
Apr 28, 2025
Maintainer

This is a long document; get yourself a cup of tea.

tl;dr

You can now use the await keyword in Svelte — in your <script>, inside $derived expressions, and in your markup — by installing the async branch...

npm i https://pkg.pr.new/svelte@async

...and adding the experimental.async option to your svelte.config.js (or wherever you configure Svelte):

// svelte.config.js
export default {
  compilerOptions: {
    experimental: {
      async: true
    }
  },

  kit: {
    // ...
  }
};

You can also try things out in the async playground.

You will find bugs! This is in no way production-ready. The PR that accompanies this discussion is at #15844.

Background

In olden times, we did asynchronous work like fetching data inside onMount or an {#await ...} block. This works but it's quite verbose, and offers no coordination — if two components are both fetching stuff, then they will likely have independently managed error/loading states, often resulting in a janky UI with multiple spinners.

Frameworks like SvelteKit (or Remix or pre-App-Router Next.js, etc) offer an alternative: instead of fetching inside the component, we do our asynchronous work outside the component, for example in load functions. This typically results in better user experience (we can server-render the data, preload it, and coordinate everything) but it too has problems — prop-drilling, type shenanigans, coarse-grained invalidation, and logic that's hard to delete because it's often not obvious whether something in your load function is even being used.

In recent years component frameworks have explored a third way: putting asynchronous work back inside components, but in a way that is coordinated:

React has a variety of primitives — <Suspense>, startTransition, useTransition, use and React Server Components, that together allow you to manage async updates
Solid has a createResource API that can be used with <Suspense> and startTransition/useTransition for the same purpose
Vue allows you to use await inside a <script setup> in a component inside a <Suspense> boundary, though this experimental API only works for component creation, not subsequent updates

We believe Svelte's compiler-centric nature offers us a way to have component-level async work with significantly better ergonomics and fewer drawbacks than existing approaches.

Requirements

minimal ceremony — we want to just write code, ideally using the await keyword. Avoid framework-specific APIs and idioms to the extent possible
flexibility — it should be possibl 8000 e to use asynchronous values anywhere (in the <script>, inside $derived expressions, in the template, in attributes and component props, in control flow like {#if ...} blocks, or wherever else)
parallel by default — since expressions in the template can be safely assumed to be pure, sequential await expressions need not result in sequential async work. Similarly, asynchronous work in two sibling components (for example) should happen simultaneously
automatic coördination — if foo changes, and await bar(foo) is (or will be) visible on the page, any occurrences of foo in the UI should not update until bar(foo) resolves
overlapping updates — a state change that happens while asynchronous work is ongoing should be visible immediately without waiting for the work to complete (unless it results in more async work)

We also want this to have minimal impact on performance and memory for existing codebases, and to cause little or no breakage for existing apps.

Design

In a nutshell: you can now use await in three places that will today result in a syntax error:

at the top level of a component <script>
in a $derived expression
in a template expression (i.e. in a component's markup)

We also introduce a pending snippet to <svelte:boundary>, which allows you to provide UI when await expressions inside the boundary are first resolving. For now, await expressions must be inside a boundary with a pending snippet (however deeply nested — for example you might have a single boundary at the very root of your app), though this constraint will likely be relaxed in future.

If state is read inside a $derived or template expression with an await, changes to that state will not be reflected in the UI until the expression resolves. For example in a situation like this...

<h1>Weather forecast for {city}</h1>
<p>{await getWeatherForecast(city)}</p>

...the <h1> will not update until the <p> does. (If getWeatherForecast were to fail, it would activate the nearest error boundary.)

To know if an update is currently pending, you can use $effect.pending():

{#if $effect.pending()}
  <p>loading new data...</p>
{/if}

If unrelated state changes while an update is pending, it will be visible immediately (assuming it doesn't separately cause asynchronous updates).

Use cases

The most obvious use case is loading data (which could be as simple as fetch, but in many cases will likely involve yet-to-be-designed utilities for client-server communication), but others include:

demo preloading images to avoid jank (<img alt="..." src={await preload('...')}>)
demo lazily importing modules and components as needed
demo moving expensive computation to a web worker

Avoiding waterfalls

As much as framework authors like to witter on about rendering performance, the thing that really slows apps down is latency. In some cases you can reduce latency by speeding up your back end, or prefetching content you expect to need, or serving content from somewhere close to the user, but those things aren't always possible. What you can do is mitigate the effect of latency by minimising the number of round trips between the browser and the server.

Svelte helps by doing as much work as possible in parallel. For example here...

<li>apples {await getPrice('apple')} each</li>
<li>bananas {await getPrice('banana')} each</li>
<li>canteloupes {await getPrice('canteloupe')} each</li>

...the three calls to getPrice will happen simultaneously, even though they appear in sequence. Similarly, the three wise monkeys will do all their async work together:

<WiseMonkey verb="see" />
<WiseMonkey verb="hear" />
<WiseMonkey verb="speak" />

Not all work can be parallelized. Any await expressions inside the <script> run before expressions in the template, and in the sequence you would expect...

// `a` will be calculated and _then_ `b` will be calculated
let a = $derived(await foo(x));
let b = $derived(await bar(x));

...though note that if x subsequently updates, a and b will be recomputed in parallel. You can of course avoid the initial waterfall like so:

let aPromise = $derived(foo(x));
let bPromise = $derived(bar(x));

let a = $derived(await aPromise);
let b = $derived(await bPromise);

A brief digression on 'necessary' waterfalls and server components

While unnecessary waterfalls can generally be prevented by pushing async work as far into the 'leaves' of your application as possible, there are also necessary waterfalls to contend with. For example, you can't use Promise.all here, because you need to know artist.id before you can call getTrackListing:

let artist = $derived(await search(query));
let tracks = $derived(await getTrackListing(artist.id));

It's better if you can do both fetches on the server, near your database. There are two ways to solve this: either anticipate the need for the track listing when you do the search...

let [artist, tracks] = $derived(await searchAndGetTrackListing(query));

...or use a mechanism like React Server Components, where the rendering happens on the server. Option 1 has less-than-ideal ergonomics, though it's basically equivalent to SvelteKit's load function. Option 2 is optimal from a waterfall prevention perspective, but we feel RSCs have significant trade-offs.

We anticipate that opinionated data-fetching patterns will emerge over time, along with new approaches inspired by RSCs, to solve this problem.

Future work

The work presented so far is the first step of a multi-stage process. While it's useful in its current form, more value will be unlocked with later stages:

Async SSR

Today, server-side rendering is fully synchronous. Because of this, if a <svelte:boundary> with a pending snippet is encountered during SSR, the pending snippet will be rendered.

It would be better to render the content instead, but this requires that SSR become an asynchronous operation.

In an ideal world we would also be able to stream the result where appropriate. This is complicated by the fact that you ideally need to know what's in the <head> before you get to the <body>. We have some ideas for how to design this sensibly, but it's not a current priority.

Once we get to this part, it's likely that the requirement for await expressions to be contained in a <svelte:boundary> will go away.

Forking

In SvelteKit we preload the code and data necessary for a navigation before it even occurs: when you hover over a link, or tap it, we import any modules needed by the route and begin running whichever load functions need to run. (This behaviour is configurable, of course.)

To make this work in a world where asynchronous work happens inside components, we need to be able to pretend that a state change occurred, and do the resulting updates 'off-screen'. The result can either be applied or discarded.

Colloquially, we've been describing this as a 'fork'. You could imagine several unresolved forks coexisting simultaneously until one reality is chosen (by the user clicking on one of several links they've been close to interacting with, for example). Most likely, we'll add an API to Svelte that allows frameworks like SvelteKit (but also particularly ambitious application authors) to enter the multiverse.

This all sounds very complicated, but in reality it's not all that different to how asynchronous updates already work. Nevertheless, it will take some finagling to get right, and in the interests of shipping we haven't included this work in the current PR.

Client-server utilities

Unless we want to create server endpoints for everything we want to fetch inside a component, we'll need tools for interacting with the server. Those tools will need to consider security, HTTP caching, mutations and invalidation, optimistic UI, batching, streaming, custom serialization, type safety and lots of other things.

We're at the early stages of figuring out what this all looks like, but we're very confident that the foundation we're laying here will allow us to design something really good.

Improving SvelteKit

Anticipating everyone's reaction: no, we're not going to suddenly make you rewrite all your SvelteKit apps. But taking all the other stuff together, a picture starts to emerge: a version of SvelteKit that's a thinner layer on top of Svelte. For example, as proud as we are of our zero-effort type safety, it's something you no longer need if you're fetching data directly inside your component.

Meanwhile the framework internals could potentially get simpler, because we'd be able to rely on common primitives inside Svelte itself. (Today, we can't reuse that much code between the server and client portions of SvelteKit, and we rely a lot on virtual modules and generated code. Some of that is for historical reasons, but some is necessary because anything asynchronous has to happen outside Svelte.)

It seems likely that a lot of interesting new possibilities will open up as a result of this work, and it seems at least plausible that we'll collectively find ourselves drifting away from primitives like load. Exactly what this would look like is to be determined, and it's something that we'll figure out together as a community.

Nuances

No `startTransition`/`useTransition`

If you've used React or Solid's suspense implementation, you will have encountered startTransition and useTransition. These functions allows you to update state in such a way that the nearest suspense boundary doesn't show its fallback while waiting for any async work that is downstream of the state change.

In Svelte, we don't do this. Instead, state changes that result in asynchronous work always have their effects deferred until the asynchronous work is complete. While that work is ongoing, $effect.pending() is true. Any pending snippets are only shown when a boundary is first being created.

This does create the possibility that something distantly connected to a given piece of state has the power to delay (or prevent!) changes to that state from being reflected in the UI. We think this is preferable to the alternative (in which updates outside a useTransition or similar cause unwanted fallback UI to appear), though it may be necessary to develop techniques for identifying these chains.

Overlapping updates that touch the same state must be applied in linear order

In a case like this...

<p>{a} + {b} = {await fetch(`/add/${a}/${b}`).then((r) => r.json())}</p>

...it's possible to imagine a scenario in which a change to a is followed by a change to b while the first fetch is ongoing. If the second fetch somehow finishes first, we don't want the first fetch to be applied afterwards, since the resulting UI would show stale values.

As such, a given async expression must only resolve after its previous versions have also resolved.

Async deriveds are eager

Normally in Svelte, $derived expressions use 'push-pull' reactivity — they are invalidated when their dependencies change (the 'push') but are not re-evaluated until something reads them (the 'pull'). This doesn't work for async deriveds, because if we waited until the value was read the resulting promise would never resolve in time.

Instead, an 'async derived' is really just an effect and a source signal in a trenchcoat. We evalute the expression in the effect, and when the promise resolves, set the source value (unless the effect fired again in the interim).

For the most part, you don't need to think about this. There is one important implication though — while it's possible to create an 'unowned derived' (in other words, a derived that is not part of the 'effect tree', such as one created in an event handler) it is not possible to create an unowned async derived, because effects can only be created inside other effects. (Don't worry if you didn't follow this — it's inside baseball stuff, and describes an edge case you're unlikely to encounter. Svelte will tell you if you get this wrong.)

Context is preserved in expressions

When a reaction (i.e. an effect or derived) runs, we track its dependencies by seeing which values are read during its execution. In pseudo-code:

let dependencies = null;

function get(source) {
  dependencies?.add(source);
  return source.value;
}

function update_reaction(reaction) {
  dependencies = new Set();
  reaction.fn();
  reaction.dependencies = dependencies;
  dependencies = null;
}

(This is simplified and wrong, but you get the idea.)

For asynchronous functions, this presents a challenge. To understand why, consider the order in which things happen here:

function a() {
  console.log('a 1');
  b();
  console.log('a 2');
}

async function b() {
  console.log('b 1');
  await 0;
  console.log('b 2');
}

a();

This will log a 1, b 1, a 2, b 2 — in other words despite the fact that b isn't even awaiting an asynchronous value, b 2 isn't logged until after it has returned to a.

In Svelte terms, this would mean that $derived(await a + b) or an equivalent {await a + b} template expression would register a dependency on a but not on b. But since we're a compiler we have a trick up our sleeves: we wrap the await expression in a function that restores the effect context, so that b is treated as a dependency.

On one level this is spooky compiler magic. But on another, it's just making the system work how a reasonable person would expect it to work. It does mean that if you extract the logic out into a function — {await a_plus_b()} — it will be treated differently, but during development Svelte will catch those cases and help you fix them.

No async `$derived.by`

While you can do this...

let x = $derived.by(async () => await y);

...x will then be a Promise, not the value of await y. There's no sensible place to put the await that would result in x not being a Promise. (This is why it's pretty great that we're a compiler and can make the expression form the default, even though it makes other framework authors mad.)

If you have sufficiently complex logic that you need to use a function block, just declare the function and call it:

async function add(p1: Promise<number>, p2: Promise<number>) {
  return await p1 + await p2;
}

let sum = $derived(await add(p1, p2));

Note the aforementioned caveat around context preservation — make sure you pass state into the function, rather than having the function close over the state it references, so that dependencies are correctly attached.

Focused inputs are not overridden

Normally, state does not update in the UI until everything that depends on it has finished resolving. This does not apply to a focused <input> element, which in many cases will be the source of the state change in question — instead, the rest of the UI 'catches up' to the input.

Breaking changes

Because of how async reactivity works, there is one small and unavoidable breaking change: beforeUpdate and $effect.pre callbacks no longer run before control flow blocks are updated. If you're using those callbacks to set state that control flow logic depends on — which you absolutely shouldn't be — then you may experience breakage. As a result, we may have to wait until 6.0 for a non-experimental release of this stuff.

Ok so

That was a lot; congratulations to those of you still here. I am sure you have questions, and that's a good thing. This is the place to ask them, or to offer feedback on the design. Let's go!

ollema · 2025-04-28T22:51:46Z

ollema
Apr 28, 2025

so exciting!!

0 replies

JonathonRP · 2025-04-28T23:57:17Z

JonathonRP
Apr 28, 2025

Love it's a discussion introduction for such an awaited feature!

0 replies

Ocean-OS · 2025-04-29T00:31:42Z

Ocean-OS
Apr 29, 2025
Collaborator

This is really cool! I've been observing the async branch for a while now, trying to figure out what the changes were going to be, how it would work, etc.

How will pending state be handled? Currently, it seems like it just uses the last value, but I'm not entirely sure if that's the best choice.
How do $effects not run until all async $deriveds are updated? According to Ryan Carniato in his stream, this was an unsolvable issue without explicit dependencies.
About when will this be merged? If this will be merged when Svelte 6 is released (which seems likely, since it's a breaking change), will this be the only major feature in Svelte 6, or are there more features planned?
Why does async stuff dependent on sync stuff cause sync stuff to not update synchronously in the template? It seems unnecessary to delay synchronous updates.
Why doesn't doubled ever update in this code?
Should there be a renderAsync function for SSRing async components?
What other libraries/articles/frameworks inspired this?

8000

4 replies

SikandarJODD Apr 29, 2025

Doubled is updated..you can $inspect it : Preview

Ocean-OS Apr 29, 2025
Collaborator

Doubled is updated..you can $inspect it : Preview

In that code, it is, but in my code, it isn't.

Azarattum Apr 29, 2025

It seems convenient in some use cases (like the ones they've used in the examples). But I think we absolutely need a way to opt out of that behavior.

Rich-Harris Apr 29, 2025
Maintainer Author

How will pending state be handled?

The value is the value. The UI may display a previous value in order to maintain consistency, but it wouldn't make sense to have stale values elsewhere such as in event handlers

How do $effects not run until all async $deriveds are updated?

We just... don't run them? I haven't seen the stream so I'm not sure why it should be impossible.

About when will this be merged?

No idea! Soon hopefully.

Why does async stuff dependent on sync stuff cause sync stuff to not update synchronously in the template?

Because otherwise you'd see things like 2 * 2 = 2 and that's insane

Why doesn't doubled ever update in this code?

Because you're reading the state inside a setTimeout. There's no way for Svelte to associate the state read with the dependency in that case. There might be some way to catch those cases so we can warn on them, but it's probably just a matter of education

Should there be a renderAsync function for SSRing async components?

There's an 'Async SSR' section above that addresses this

What other libraries/articles/frameworks inspired this?

We researched prior art but didn't see anything we liked to be honest. We reached this design from first principles.

Thiagolino8 · 2025-04-29T03:11:35Z

Thiagolino8
Apr 29, 2025

When I read the document I was filled with excitement, fear and confusion
But after testing it a bit, only excitement remained
The only parts that don't sound so good are the behavior of states blocked by their asynchronous dependent reactions and derived states that 'catch up' to the input state, I can't think of a single occasion where these are desirable or expected behaviors
In this regard transitions seem infinitely superior, obsolete asynchronous derived states should simply be ignored without affecting the rest of the world
Otherwise, impressive work, congratulations to the whole team
I'm looking forward to the final result

15 replies

Thiagolino8 May 3, 2025

React — as soon as the delay exceeds the update frequency, the app breaks

Devbox not found 😢

Here's an example of ignoring stale promises

Unfortunately, by manually orchestrating this state machine you lose the advantages of suspense
And even if you create a version that works with suspense, it doesn't work with $effect.pending

Another approach could be to use abort signals (#15845 (reply in thread))

I'm hopeful for the integration of abort signals, I believe it may be the right abstraction

I tried to make my own integration, but it seems that the proposal is not yet prepared for rejected promises (the app simply crashes and the boundary does not capture any errors)

Edit: The issue was not the rejected promise, but an infinite loop for some reason
I fixed it, but $effect.pending is still broken (in a different way this time)

Thiagolino8 May 4, 2025

Here's an example of ignoring stale promises

@Rich-Harris, It looks like you saved this example over the default example provided at the beginning of the discussion.

Rich-Harris May 4, 2025
Maintainer Author

Ah whoops! Fixed. Also made the devbox public.

I also added a getAbortSignal function that you can use inside effects and deriveds. It means you can do this sort of thing:

import { getAbortSignal } from 'svelte';

const response = $derived(await fetch(`/blah/${foo}`, {
  signal: getAbortSignal()
}));

const data = $derived(await response.json());

Thiagolino8 May 4, 2025

Ah whoops! Fixed

Now it is a broken version of the getAbortSignal demo 😁
I loved the working version tho

Rich-Harris May 5, 2025
Maintainer Author

dammit! fixed again. not sure why branch-async doesn't include getAbortSignal

NullVoxPopuli · 2025-04-29T03:18:26Z

NullVoxPopuli
Apr 29, 2025

Not sure if I missed something, but -- there is some error handling in this demo: https://svelte.dev/playground/24eec2a85770402eae633d06aec412a6?version=pr-15844

but, how do you do error handling generically for any await'd thing?

for example, in this parallel-promise template:

<li>apples {await getPrice('apple')} each</li>
<li>bananas {await getPrice('banana')} each</li>
<li>canteloupes {await getPrice('canteloupe')} each</li>

what do I do if I want to render errors if getPrice fails for apple and banana?

3 replies

JReinhold Apr 29, 2025

I would assume that you should wrap apples and bananas in a <svelte:boundary> with a failed snippet. https://svelte.dev/docs/svelte/svelte-boundary#Properties-failed

<svelte:bondary>
	<li>apples {await getPrice('apple')} each</li>
	<li>bananas {await getPrice('banana')} each</li>

	{#snippet failed(error, reset)}
		whoops, apples or bananas failed.
	{/snippet}
</svelte:boundary>
<li>canteloupes {await getPrice('canteloupe')} each</li>

Rich-Harris Apr 29, 2025
Maintainer Author

Exactly — just the same as if there was no await and getPrice was a synchronous function that threw an error

NullVoxPopuli Apr 29, 2025

thanks!

madaxen86 · 2025-04-29T04:52:30Z

madaxen86
Apr 29, 2025

Solid user here. Never used createResource with startTransition/useTransition.
I am using the ✨createAsync✨primitive which handles transitions under the hood automatically refetches when args passed to the async callback change, parallel fetching (no waterfalls) etc.
Async was never easier.

const data = createAsync(() =>  promiseFn(args));

5 replies

Rich-Harris Apr 29, 2025
Maintainer Author

Ok. But createAsync isn't part of Solid, it's part of Solid Router; the Solid docs and tutorials steer people towards createResource so that's what we're talking about here, regardless of how things may look in 2.0.

The approach has its merits though I'm not personally sold on the programming model

Malix-Labs Apr 29, 2025

I'm not personally sold on the programming model

What is "programming model" in that case?

jer3m01 Apr 29, 2025

Nothing in the current createAsync is tied to the Router or 2.0.

It's not in core as we're focusing on the next major.
The import path/package really isn't relevant here.

More features will be included once 2.0 lands, but these aren't implemented nor restrict the current createAsync.

ryansolid Apr 29, 2025

@madaxen86 Currently Solid's createAsync(current version)/createResource aren't noticeably different from each other.. Same non-blocking, parallel fetching, auto-serializing, auto-streaming, async SSR etc... createAsync was introduced to streamline the API to make it more composable (useful for interacting with Solid Router's query and action APIs), but createResource has had those capabilities for the past 6 years.

There are 2 shortcomings of the approach. Neither of them related to performance or architecture but to ergonomics.

First, our async isn't completely colorless in the sense that async values can be null, so people need to null check stuff is there until it is even with mechanisms like Suspense. So while you don't have to worry about passing promises around or the whole "where you fetch" dilemma client (non-RSC) uses of data-loading with Suspense have with React you introduce nullability into the tree.

The second is Suspense being too eager to bail out. It is really easy to trigger Suspense on some small async update on the page causing return to fallback. Using Transitions is one way to avoid this, but most of the time people would probably rather just tear. This has lead to stuff like useDeferredValue in React and .latest on our resources. The truth is 99% of people will never knowingly use Transitions. They are mostly there for things like Routing. The cases that Rich refers to in the forking section. So they aren't generally part of the experience of developing. However aggressive Suspense bailout can get people there much earlier than they intend.

Of course, sitting with these issues over the years these are things we are already working on remedying in the next major version. But it is worth noting the proposal above for Svelte doesn't have these issues. The async holding along the graph + $effect.pending() removes the need for aggressive Suspense(boundary) bailout, and the compiled use of await plus the same holding removes the non-nullability. With this foundation the other async adjacent features should layer on quite nicely. This is very exciting progress in this area.

Rich-Harris Apr 29, 2025
Maintainer Author

@ryansolid happy to see you here! Thanks for reading the proposal.

What is "programming model" in that case?

Just the fact that I'm not dealing with promises in a way that feels JavaScript-native, but rather via a framework's abstraction. I totally understand why it is the way it is, and it's very much a matter of taste, but I don't think it would be the right design for Svelte. I do like how aggressively createAsync/createResource discourage waterfalls; in the worst case our design trades off a little performance for ergonomics here (though on the flip side it means that people are encouraged to learn patterns and techniques for avoiding waterfalls that apply to all their code, not just their components).

The 'JavaScript-native' thing is obviously a minefield. Svelte is transforming your async code and doing all sorts of behind-the-scenes scheduling, but React and (IIUC) Solid are throwing to trigger Suspense; to me these feel equivalently magical. YMMV!

hmans · 2025-04-29T05:58:26Z

hmans
Apr 29, 2025

Unless we want to create server endpoints for everything we want to fetch inside a component, we'll need tools for interacting with the server. Those tools will need to consider security, HTTP caching, mutations and invalidation, optimistic UI, batching, streaming, custom serialization, type safety and lots of other things.

We have a neat little super-lightweight RPC (lighter than tRPC) setup that

takes an "API object" consisting of functions to call (only requirement is that the functions have a single object argument)
wraps this object in a server-side API endpoint that translates URL paths into a path into this object, calls the function with the given query parameters, and returns its serialized response
and, for the client, provides a nested proxy object that has the same type as the original API object. No code generation/compilation necessary!

This basically turns anything that we put into the API object into an async function callable from the client, with the same signature as the original server-side function. Also, since we're working with plain functions, things can be trivially wrapped with HOF et al both on the server and the client to implement concerns like authentication, validation, caching, etc.

This has been really fun to use, and I'm happy to share more if there's interest in this.

13 replies

gterras May 4, 2025

return await db.user.create(user);

Is the await ideal here?

Rich-Harris May 4, 2025
Maintainer Author

It's an unnecessary extra microtask but I find it conceptually clearer. YMMV

t1u1 May 5, 2025

@hmans we're exploring the RPC space (@dummdidumm in particular is deep in this rabbit hole at present)

Anywhere we could follow along? Would be an immense timesaver to have an integrated RPC in sveltekit.

weepy May 6, 2025

I LOVE THIS - is there a branch or place for discussion ?

chanmathew May 13, 2025

THIS IS SO CLEAN! Taking it one step further to have Tanstack query-like destructuring of the data, loading, error, would be chef's kiss.

mary-ext · 2025-04-29T06:25:37Z

mary-ext
Apr 29, 2025

If unrelated state changes while an update is pending, it will be visible immediately (assuming it doesn't separately cause asynchronous updates).

Ah, so no freezing states in child components too, I suppose? I was hoping this was the case, it would certainly help with something like mobile stack navigations, carousels, accordions or drawers where you do want a portion of your component tree to be frozen (see svelte-freeze for the general idea, and svelte-stakkr for a router building on that idea)

The entirety of svelte-freeze could be simplified into this single component, and most importantly removes the need for willing packages to opt-in to the freezing functionality.

<script lang="ts">
	import { untrack, type Snippet } from 'svelte';

	interface Props {
		frozen: boolean;
		children: Snippet;
	}

	const { frozen, children }: Props = $props();

	const PROMISE = new Promise(() => {});
</script>

<svelte:boundary>
	{#if frozen}
		{await PROMISE}
	{/if}

	{@render children()}

	{#snippet pending()}
		<!-- empty -->
	{/snippet}
</svelte:boundary>

I would admit that it's going to be a lot more complicated behind the scenes though, since now you need to have a way to have a derivation that runs outside of that suspension, so that you can check for $effect.pending() (I personally need this to ignore events from mutation/resize observers as elements are being frozen/unfrozen, maybe it can be an $effect.pre thing)

It's certainly something that can be better handled by a different mechanism for sure, just like how React's <Activity>/<Offscreen> is separate from <Suspense>, but that certainly hasn't stopped React (Native) apps from toying with <Suspense> to get this exact functionality.

3 replies

Rich-Harris Apr 29, 2025
Maintainer Author

Right, so if e.g. page.url and page.params etc change, then everything derived from them (await loadStuff(page.params.stuff)) will update at the same time, wherever they appear in the app. But if you have something that doesn't depend on those things (like {time.now} or {mouse.x}x{mouse.y}) then it will update immediately. I assume that's the desired behaviour?

mary-ext Apr 29, 2025

Yeah, I had hoped that time.now wouldn't change so long as await loadStuff() is still pending

Rich-Harris Apr 29, 2025
Maintainer Author

Why?

Hugos68 · 2025-04-29T07:23:05Z

Hugos68
Apr 29, 2025

There's no sensible place to put the await that would result in x not being a Promise.

I don't understand this, I personally dislike $derived and $derived.by not working identically. Maybe someone could explain to me like I'm a 5 year old?

12 replies

jjones315 Apr 29, 2025

100% agree, i think the fact that $derived() accepts an expression should be leveraged. I was just giving concrete examples of some alternatives since that tends to help me when looking at decisions like this. i hadn't actually though through the pitfalls of $derived.async(...);. Then having to statically analyze const output = await $derived.by(…) has some very clear pitfalls. like what does

const fooPromise = $derived.by(…)
//.. several lines of code
const foo = await fooPromise;

do, this would be very easy for someone to do as a refracting and completely break how something works without being clear why it broke.

Should of included the pitfalls directly in the initial message i was pre-coffee :)

Looking forward to this shipping, if this works as promised its going to be amazing.

GauBen Apr 29, 2025

wait, am I supposed to do let x = await $derived(...) or let x = $derived(await ...)?

Could the compiler allow both? Even await $derived(await ...), while useless, could be valid async svelte code

gterras May 1, 2025

Even await $derived(await ...), while useless

useless AND nightmarish

rChaoz May 15, 2025

Exactly this. You can't use await outside an async function, but if you pass an async function to $derived.by then the value will be a promise

@Rich-Harris I still don't understand this. Why wouldn't something like this work:

declare function $derivedBy<T>(func: () => T): Awaited<T>

// the type of this is number, not Promise<number>
let num = $derivedBy(async () => await 5)

...and the compiler can just treat it as if it were written like this instead:

async function derivedTemp() {
    return await 5
}

let num = $derived(await derivedTemp())

And, to avoid a breaking change, a new name (e.g. $derived.byAsync or $derived.byAwait) can be used.

Update: I just realised this can also be implemented in user-land, using an IIFE:

let num = $derived(await (async () => { await 5 })())

But, IMO this is not ideal. And, if it, or the workaround using regular functions, defeat the purpose of $derived.byAsync, then the purpose of $derived.by is also defeated by the same concepts (without async), yet it exists.

Rich-Harris May 15, 2025
Maintainer Author

I explained it above #15845 (reply in thread)

Tc-001 · 2025-04-29T10:26:53Z

Tc-001
Apr 29, 2025

I wonder if it could be possible to somehow abort promises that are no longer needed, so that there aren't unneeded in-flight requests due to network lag

As I understand, once "Overlapping updates that touch the same state must be applied in linear order" is implemented the following would happen:

There is an app with a drpdown to check produce price, user quickly clicks on bananas, apples, mangos. There are now 3 getPrice() requests in the air.
The apple request hangs, maybe not cached.
In the background the mango price resolves, but the user needs to wait until apples resolves before being able to see the mango price.

So instead by aborting the older fetches the developer explicitly says "I don't care about this anymore, just give the user the latest value"

Something like this maybe?

export function getPrice(produce) {
  return await fetch("/api/price/"+produce, {
    signal: $effect.abortSignal()
  })
}

2 replies

Rich-Harris Apr 29, 2025
Maintainer Author

We actually implemented this exact thing a while back (as an import rather than a rune, but same semantics) but decided not to land it because your console quickly fills up with DOMExceptions that you can't really get rid of (unless you store a reference to the promise returned from fetch and attach a floating noop catch handler).

But with async stuff it does potentially become more valuable, so it might be worth revisiting

JonathonRP Apr 30, 2025

I wanted to up vote revisit the abort signal, I watched that PR and was really looking forward to it.

HugeLetters · 2025-04-29T12:58:57Z

HugeLetters
Apr 29, 2025

Regarding async derived dependencies effects to be blocked until async derived resolves - you mention inputs being the exception. What about cases like a custom inputs or search bar with a clear button - pressing clear should clear that input and initiate an async search with empty value(it returns unfiltered entries then). There would be no focused input here so input will be cleared only after search resolves?

4 replies

Rich-Harris Apr 29, 2025
Maintainer Author

Great question. The short answer is yes, if you press 'clear' then the input won't clear until the results have come in. In that case you would need to express that intent ('clear the input as well as resetting the value') programmatically:

<button onclick={() => name = input.value = ''}>clear</button>

As for custom inputs, it works by checking if the current element is document.activeElement. It's entirely possible that this will break for web components, because there is no limit to how much sadness they can cause.

Azarattum Apr 30, 2025

There are many use cases where we want to respond instantly to user input and fetch something in background. So, we definitely need a way to control that since both behaviors are useful.

Maybe for opt in:

let text = $state.deferred("");
let results = $derived(await search(text));

Other options .lazy.

Or for opt out:

let text = $state.eager("");
let results = $derived(await search(text));

Other options .immediate, .instant.

santiagocezar May 1, 2025

Another idea, syncing only between the parts of the UI that have the same closest parent boundary (or possibly another special element), for example:

<script>
	import { delayed } from './utils.js';

	let x = $state(0);
</script>

<svelte:boundary>
	<input type="range" bind:value={x} /> 
	<span>{x}</span>
	<svelte:boundary>
		<input type="range" value={await delayed(x)} disabled />
	        <span>{x}</span>
		{#snippet pending()}
			<p>loading...</p>
		{/snippet}
	</svelte:boundary>
</svelte:boundary>

The outside input and span would get updated immediately after the user interacts, while the inner ones update only after delayed resolves. On the surface, the way it works feels kinda intuitive, but I'm not sure if it's the best solution.

Rich-Harris May 1, 2025
Maintainer Author

That was one of our first designs. Long story short it leads you into impossible-to-resolve situations

peterreeves · 2025-04-29T13:34:27Z

peterreeves
Apr 29, 2025

https://svelte.dev/playground/767e0bfd75614664a41ba73f28cc424c?version=pr-15844

Is this a case of 'Overlapping updates' stuff that is yet to be resolved? Or is this a different bug? I'm confused why doubled can de-sync, but the count state variable updates correctly. In my understanding, count, doubled, and doubledAsync are all part of the same "batch" and should never de-sync from each other?

4 replies

Rich-Harris Apr 29, 2025
Maintainer Author

Looks like a new bug, will investigate

bennymi Apr 30, 2025

Is this another bug? Seems like $effect.pending() isn't changing to false: https://svelte.dev/playground/5c76337c47a1413f8b86f148bb97a553?version=pr-15844

Rich-Harris May 1, 2025
Maintainer Author

Yeah there are bugs around $effect.pending()

rChaoz May 15, 2025

https://svelte.dev/playground/767e0bfd75614664a41ba73f28cc424c?version=pr-15844

For me, simply double-clicking on count desyncs it.

jjones315 · 2025-04-29T16:41:29Z

jjones315
Apr 29, 2025

I know async SSR was mentions as a possible future development. In its current state are the component level await started on the server? or do they begin after hydration on the client? i suppose hydration will likely be much faster if it hits a pending early enough, but it still seems like a pretty big gotcha if request don't begin until after hydration.

1 reply

Rich-Harris Apr 29, 2025
Maintainer Author

If you look at the JS Output tab of the playground and switch to server mode you'll see what happens — we literally ignore everything except the pending snippet:

In other words for now everything starts in the browser. Obviously that's not tenable in the long term; we want to be able to pass promises from the server to the client.

It's not straightforward though. Consider a case like this:

<script>
  if (browser) {
    const x = $derived(await foo());
    const y = $derived(await foo());
    // ...
  } else {
    const z = $derived(await baz());
  }
</script>

Where does the serialized data 'go'? If we somehow bake the values into a comment that the component reads as it hydrates, then it will expect two payloads but we've only baked in one. And it's not even one that we want to use!

Or this:

<script>
  import { blah } from './stuff';
  import Child from './Child.svelte';
</script>

<Child blah={await blah} />

<script>
  import { blah } from './stuff';

  let props = $props();
</script>

<p>{props.blah === await blah}</p>

This needs to render <p>true</p> regardless of what type of value blah resolves to, so we can't just serialize the data in isolation for each component; we would need to have some central registry that every component can refer to. Something like this, perhaps:

const { head, body, data } = await renderAsync(App, {...});

return `<!doctype html>
<html>
  <head>
    <meta charset="utf-8">
    {head}
  </head>

  <body>
    <div id="target">${body}</div>
    <script type="module">
      import { hydrate } from 'svelte';
      import App from './App.svelte';

      hydrate(App, {
        target: document.querySelector('#target'),
        data: ${serialize(data)}
      });
    </script>
  </body>
</html>
`;

(I'm glossing over a lot of stuff but you get the idea.)

Alternatively, Svelte could delegate it to frameworks like SvelteKit which could provide their own abstractions (fetch caching, RPC utilities etc) and if a given expression doesn't have pre-rendered data ready to hydrate, hydrate could simply wait until the client can fix the gaps before returning.

Shorter version: there's a lot of stuff to figure out here and we don't yet know what it'll look like, but it's very much on the radar.

lukeed · 2025-04-29T17:42:43Z

lukeed
Apr 29, 2025
Maintainer

This is great 💪

0 replies

rossrobino · 2025-04-29T19:34:45Z

rossrobino
Apr 29, 2025

More of an SSR question: has there been any more research or thought into how streamed components with errors will be handled?

I remember reading another thread that was talking about including a meta tag if a component had an error so the page wouldn't get indexed. Interested to see where Svelte ends up.

4 replies

Rich-Harris Apr 30, 2025
Maintainer Author

I'm enough of a purist that I struggle a bit with the idea of handling errors by shoving a <meta> tag that indicates an error inside a 200 response. It's probably fine, but I don't feel confident that it will work reliably everywhere (like, what if the page has a cache header like s-maxage — can you stop your CDN from caching it?)

Instead, I quite like the idea of separating critical stuff (status code, <head>, some of the <body>) from non-critical stuff — perhaps something like this:

response.write(`<!doctype html><html><head>`);

try {
  // `stream` returns `Promise<{ head: string, body: AsyncIterator<string> }>`
  const { head, body } = await stream(App, {...});

  const response = new StreamedResponse(200);

  response.write(head);
  response.write(`</head><body><div id="root">`);

  async function next() {
    const { value, done } = await body.next();

    if (done) {
      response.write(`</div><script>${HYDRATE}</script></body></html`);
    } else {
      response.write(value);
      next();
    }
  }

  next();

  return response;
} catch (error) {
  return new Response(getStatusCode(error), renderErrorPage(error));
}

We could demarcate non-critical content with an attribute on <svelte:boundary>:

<script>
  import { page } from '$app/state';
  import { getPost } from '$lib/api';

  const post = $derived(await getPost(page.params.slug));
</script>

<!-- critical -->
<svelte:head>
  <title>{post.title}</title>
</svelte:head>

<h1>{post.title}</h1>
<div class="post">{@html post.content}</div>

<!-- non-critical -->
<svelte:boundary streamable>
  <Comments />

  {#snippet failed())
    <!-- if an error occurs while rendering comments, this snippet gets
         included in the server-rendered HTML -->
  {/snippet}
</svelte:boundary>

Inside a streamable boundary, certain restrictions could apply, like no <svelte:head>. Anyway, just spitballing at this stage. (Not pictured: a way of capturing the error during SSR so that you can log it, or fail if prerendering.)

rossrobino Apr 30, 2025

Yeah I like it! I can't think of a better way. If you want to stream something critical it just comes with the caveat that it might error and still send a 200. So best practice remains to only stream non-critical content.

For a client side navigation this wouldn't matter as much right? Everything could just be streamed as it resolves?

Rich-Harris Apr 30, 2025
Maintainer Author

Ah yep, the example was meant to show immediate writing of critical content but I wrote it wrong 😆

For client-side nav yeah, I think you could stream everything

rossrobino Apr 30, 2025

Awesome! This is going to be great

brenelz · 2025-04-30T03:27:17Z

brenelz
Apr 30, 2025

It would be cool if awaiting in the parent component didn't block the children as in this example. Just some food for thought. The <Component> elements themselves fetch in parallel which is great!

https://svelte.dev/playground/e3b0c1aecc4442a293b8c501b7b4ac90?version=pr-15844#H4sIAAAAAAAAE6VUy47TMBT9FcsgJRFRUgbNJk0LiB9ggcQCs3CTm47Bubbsm3aiKP-O8uiTaRmJVZxzj-_jHNsdR1kDz_hn32LBrJbt1pkGSx7zSmnwPPvRcWrtwBkAHh93WJv4HWgasI308BJeGCRA8jzjuS-csrQWKEjV1jhi3520FhyrnKmZ4Ek6A_N-wZdn5C-mtgYBaaIHSXpEZn6wFJinpzKYT3i2GSaSrh1r53OR8UdQfsqrypXg7wVn6Y3Yw53Yh2MsTy8qoKDujUdlLRCzgKXCbRj1cxa71kYOUJIkeWrHLV060_txnqsZeMwJnoln5Bro4xvuXGtz6dEL0ftOdSVo2ULZn7xqSGmf_PKCD7zCoCdmnbGerdjbcRFGy0PIaEi02YZBBVQ8Kdwyhaw4dBGciMQcDBnkXipic9UwIPAUvBuzJqqM2cNisYiu7e4c-D7fOJa-UqTDCJfinKFnosDzKETVYEHK4LG1ndQNxKwemn5cLCLWDaM4oMYhQ9izr87UykMYVhFbraewIA_0TdVgGgrDEa-mTNGQapKjHz796ya5vDiX8_wV-w-rl4cjrYFYx4onpUsHyPor02_aPjfzb8cPb8OoSnDP8fGml2rHPLUaVoJvZPF7esWyrZOt4GuB3ScHWII7tvwxGS9hnpZqd3VcfsacpNJ7hSXPKqk99H8AHL49AigFAAA=

3 replies

Rich-Harris Apr 30, 2025
Maintainer Author

The challenge here is that App.svelte doesn't know whether or not children will be rendered, and if so how many times. It can assume, but assumption is the mother of all fuckups.

What we probably can do is start rendering parts of the component before the component has finished initializing:

<script>
  let thing = $derived(await promise);
</script>

<!-- we need to wait for `thing` before populating the `<p>` -->
<p>{thing}</p>

<!-- but we can start rendering this immediately! -->
<Stuff />

That includes things like {@render children?.()}, which means the outcome — we start doing work inside <Component> before <Wrapper> has finished initializing — is the same.

This feels totally achievable (and is another vindication of the compiler-centric approach) but I didn't want to add it to the current PR since it's already quite a lot. Instead I imagine this will be a follow-up optimisation that magically makes apps faster without any changes.

brenelz Apr 30, 2025

makes sense thank you

Rich-Harris May 6, 2025
Maintainer Author

Had a realisation here: this wouldn't work if a parent component set context after the component was initialized:

<script>
  import { setContext } from 'svelte';
  import ChildThatUsesContext from './ChildThatUsesContext.svelte';

  await something;

  // this would happen after the `await` and therefore after the child has been rendered
  setContext('foo', 'bar');
</script>

<ChildThatUsesContext />

Conclusion: we need to ensure that setContext can only be called during component initialisation, so that we're able to implement this optimisation non-breakingly

adriablancafort · 2025-04-30T19:02:35Z

adriablancafort
Apr 30, 2025

I'm excited!

0 replies

gterras · 2025-05-01T15:34:01Z

gterras
May 1, 2025

This may be a highly addictive feature, congrats to the team.

The examples in the post are unbelievably clean, hard to picture how front-end code can get any cleaner. I still don't know if $effect.pending() is just a nice helper or something you can't live without.

Unless we want to create server endpoints for everything we want to fetch inside a component, we'll need tools for interacting with the server. Those tools will need to consider security, HTTP caching, mutations and invalidation, optimistic UI, batching, streaming, custom serialization, type safety and lots of other things.

Finding the right design for this seems very challenging, as the best design seems to be no design at all. Telefunc looks like a great basis anyway. I suppose this also means better-class support for GraphQL, would love to hear @AlecAivazis thoughts on this.

Does this mean the Loading data part of sveltekit is meant to go away at some point? Looking at it, will the majority of SvelteKit Core concepts be altered? Loading data, Form actions, State management get replaced, Routing and Page options become less relevant in this state?

Deeply excited about the direction of this project

8 replies

gterras May 2, 2025

Considering the scale of this new realm I agree the non-rushed process is the right approach.

if we had await and didn't have load, would we invent load?

Similarly I can't help but think If we didn't have load, would we implement file-based routing? (note that I really like file-based routing as it stands).

Anyway there's a great future ahead for Svelte.

Rich-Harris May 2, 2025
Maintainer Author

I believe it's the least worst option and so we would, to address the problems created by other approaches. But the thing that makes it necessary is the need to express a coupling between +page.svelte and +page.server.ts/+page.ts without import (because it's a relationship that crosses environments and therefore bundles).

If load went away then the only reason for that coupling would be the page options, which does feel like a less compelling reason. So if we could imagine a different way to express those then we suddenly find more adjacent possibles. Maybe that's enough to prompt a re-evaluation? I don't know, just thinking aloud

Ocean-OS May 2, 2025
Collaborator

The main reason I use load is for stuff that I want to specifically run on the server (such as accessing a database), would I have to create an API endpoint with GET and POST methods to be able to do this if load were to go away?

Rich-Harris May 3, 2025
Maintainer Author

No, there would be an alternative, with type safety and all the trimmings. We're still exploring what it looks like

AlecAivazis May 5, 2025

thanks for the ping @gterras and sorry for the delay in replying - i wanted to take some time to look through the proposal before replying. that being said, I really like this direction in general. It brings my favorite part of react's model in the form of the boundary with just the right svelte magic to avoid the reallly hacky things we have to do in the react world to get suspense to work (the need for an out-of-render cache of promises is incredibly hard to get right). All in all, it'll be a great step forward for the community.

that being said, i think it does slightly increase the challenge when it comes time for a library like houdini to seamlessly integrate in the way we currently do. i think rich is totally right that if this were in place first load wouldn't need to exist but one thing load did well for us was provide an integration point that did not require aggressively modifying the user's code - we could just worry about transforming a single function and the rest of users' code couldn't tell the difference. i suspect that with this move houdini will be pushed to do less magic which is probably ultimately for the best. Although if my experience with React's suspense maps well-enough onto this world, the generation of fallback UIs can be challenging in practice and it's not clear just yet to me how we would best wire up our @loading directive into this world. But even if users just have to do a little more wiring up themselves to get boundary fallbacks to use our infrastructure it'll still be worth it and regardless of the Houdini-specific hurdles this creates a really nice orchestration layer for data-fetching libraries so we can avoid worrying about managing loading state which can get really annoying.

targetlucked69 · 2025-05-02T21:09:59Z

targetlucked69
May 2, 2025

Love this so much except async derives. It would be nice to keep the goal of derive to just compute values based on other states, without side-effects etc

1 reply

levibassey May 4, 2025

Not sure what you're on about, this is still a derivation, except it's async. Also, what side-effects?

Thiagolino8 · 2025-05-03T11:38:18Z

Thiagolino8
May 3, 2025

Why the decision to allow async only at a boundary with a pending snippet?
Neither the {#await} block nor other framework implementations require fallback

1 reply

Rich-Harris May 3, 2025
Maintainer Author

To encourage good practices

weepy · 2025-05-04T11:59:20Z

weepy
May 4, 2025

I assume it’s the allure of an API along the lines of Telefunc. The dream being just able to call a remote function without really even knowing or fiddling about with designing an api etc.

…

On Sun, 4 May 2025 at 12:52, Julius Berger ***@***.***> wrote: @hmans <https://github.com/hmans> we're exploring the RPC space ( @dummdidumm <https://github.com/dummdidumm> in particular is deep in this rabbit hole at present), would love to see what you've cooked up. I'm not personally a fan of the tRPC approach, we've been more inspired by Telefunc <https://telefunc.com/>, though it doesn't fully meet our needs Could you maybe share why you're not a fan of tRPC here? — Reply to this email directly, view it on GitHub <#15845 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAAAGNFLGQXVFFYHIVPQRAD24XWOZAVCNFSM6AAAAAB4BQKD3CVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTGMBSHE2DQNY> . You are receiving this because you commented.Message ID: ***@***.***>

0 replies

weepy · 2025-05-09T09:39:23Z

weepy
May 9, 2025

I added a delay into the worker in the prime checker

https://svelte.dev/playground/5d6aae8c30f24ef2aea5cfa445305768?version=pr-15844

why does the the label update get delayed too ?

4 replies

Rich-Harris May 9, 2025
Maintainer Author

Because otherwise you'd have an inconsistent UI. This is called 'tearing' and avoiding it is the raison d'être of this work

weepy May 9, 2025

OK - makes sense - I get the motivation - but what is the API surface here ? Is it relative to the svelte:boundary ? I.e. all async "svelte" stuff will get batched and the UI will only update when all is resolved (inside the nearest boundary) ?

Ocean-OS May 9, 2025
Collaborator

AFAICT, the boundary is only used on the initial load to display a fallback while the async stuff is pending. After that, the delays are only from:

Currently pending async state
Anything that is a dependency of said async state

jjones315 May 9, 2025

from what i gather, if there is async work in a signals dependency graph that entire dependency graph will wait until the async work
finishes then the entire graph will write.
so if foo triggers async bar and baz is derived from async bar, foo, the result of bar, and baz will all be rendered when bar resolves.

but if qux does not depend on bar and bar does not depend on bar qux will be rendered immediately.

i updates your demo slightly. new demo

i increase the delay to 5 seconds to make the effect a little more obvious and added a slider bound to other. when you enter a number for n while the isPrime check is running you can slide the range input and {other} will be updates immediately even though its in the component as the async work. Additionally i added the result of n * other and it will also update based on the last resolved n and the current value of other.

sina-salahshour · 2025-05-19T09:45:17Z

sina-salahshour
May 19, 2025

$effect.pending() is changing to true also outside of boundary. is this intended? even when there are nested boundaries, $effect.pending() is true when the inner one is suspended.

demo

9 replies

sina-salahshour May 19, 2025

I think option 4 would be nice but also with option 2, there are ways to move the value to a top level state/global state, or even render required pending state in a portal.
but again option 4 would be a lot nicer.
something like $effect.root.pending() for global and $effect.pending for local scope..

also thank you you for your time and for answering🙏

GauBen May 19, 2025

Adding my two cents because I often build said global loading indicators: instead of a boolean it could be interesting to know the number of pending effects. When the page is loading, $effect.pendings (to bikeshed) starts at say 4, and as it decreases to 0, the global loading indicator progresses linearly based on this number.

rmunn May 20, 2025

Re @GauBen's idea, could still keep the name $effect.pending() and have it return a number rather than a boolean. 0 counts as falsy so {#if $effect.pending()} would still work with no changes needed.

And while I'm commenting anyway, let me cast a bikeshed vote for $effect.pendingLocally() or $effect.pendingLocal(). I also briefly considered $effect.pending.local() but decided that looks bad once I actually saw it on-screen.

Thiagolino8 May 20, 2025

Geez, I had the preconception that $effect.pending was locally scoped

Maybe a solution is to not bubble by default and have the boundary have a prop to allow bubbling
<svelte:boundary bubblePending>

Or a read-only state to allow binding
<svetle:boundary bind:pending>

That way the user can decide how far the event goes

dummdidumm May 20, 2025
Maintainer

That could make it tough for people integrating libraries where they don't have control to turn bubbling on/off

Thiagolino8 · 2025-05-20T15:50:06Z

Thiagolino8
May 20, 2025

I know the team isn't a big fan of the TRPC implementation, but if there's one thing I ask you to consider (not necessarily implement) it's the batch of requests

2 replies

Rich-Harris May 20, 2025
Maintainer Author

That is a completely separate conversation, it's nothing to do with await and entirely about what you're awaiting

Thiagolino8 May 20, 2025

The comment was regarding the mention of a future RPC implementation

TigerWest · 2025-05-25T14:21:41Z

TigerWest
May 25, 2025

As someone coming from the Vue 3 ecosystem, I wanted to share some thoughts based on patterns that have worked well for us in production.

I commonly use onServerPrefetch alongside @tanstack/vue-query to manage asynchronous data loading during server-side rendering. Here’s an example pattern:

const { data, suspense } = useQuery({
  queryKey: contentKeys.list(),
  queryFn: () => api.content.getContents()
})


// Wait for the suspense query to resolve or fail during SSR.
// If it fails, the page is rendered with the error result.
// If it succeeds, the page is rendered with the fetched data.
// On CSR navigation, no prefetch is triggered — the UI will show a loading state and fetch data on the client.
onServerPrefetch(async () => {
  await suspense().catch(() => {})
})

This setup allows us to wait for data during SSR without requiring a separate load() function, while still showing fallback UI (e.g., skeletons) on the client navigation. It offers a clean, maintainable developer experience with minimal framework-specific overhead.

⸻

🔍 Observations

From this perspective, I had a few reflections on the current async proposal:

Top-level await in components, especially for client-side rendering, may not always be ideal
In many real-world cases, developers prefer rendering to proceed immediately with a fallback UI (like a skeleton), rather than awaiting data before any content appears. This often results in better perceived interactivity.
The ergonomics of onServerPrefetch-style hooks already solve many SSR concerns
The explicit lifecycle makes it easier to understand and debug async behavior, without relying on implicit coordination between reactive and async expressions.
The proposal’s compiler-level async tracking is innovative, but may introduce complexity
While the fine-grained control is impressive, it could add mental overhead for developers who are used to manually managing loading/error states or prefer a simpler fetch/render lifecycle separation.

6 replies

Rich-Harris May 25, 2025
Maintainer Author

What you're describing are convoluted workarounds for a fundamental limitation of the framework. We would rather address the limitation directly

TigerWest May 26, 2025

Thanks again for this exciting proposal. I wanted to raise a question from the perspective of someone coming from Vue 3 with common SSR/CSR data loading patterns.

In Vue, when using onServerPrefetch, we can explicitly block only during SSR, allowing data to be awaited before rendering HTML on the server. On the client side, no blocking occurs — the component renders immediately, and the query runs in the background. This gives us fine control and a great user experience.

My question is:

With the current async proposal in Svelte, if I write something like {await fetchSomething()} or let x = $derived(await getData()), will this introduce blocking behavior on the client as well?

If so, that seems like a fundamental difference:
• In onServerPrefetch, we block only during SSR, while
• With this proposal, await applies at both server and client runtime, and I’m unsure how we would opt out of client-side blocking without additional control.

From what I understand, rendering would be suspended until the awaited expression resolves — even during client-side navigation — unless a <svelte:boundary pending> is explicitly used. If no such boundary is present, would this result in the entire component being paused or delayed?

This makes me wonder whether this proposal might introduce unexpected latency or interactivity delays on the client, especially for cases where we’d prefer to render immediately and show a loading state instead.

I fully recognize the power and ambition of this compiler-driven async model, and I appreciate the vision. Just wanted to better understand how CSR blocking is handled — and whether developers will have explicit control over when and where async pauses occur.

dummdidumm May 26, 2025
Maintainer

We might add a property for <svelte:boundary> that would control this, e.g. <svelte:boundary block="server">

Thiagolino8 May 26, 2025

During the summit @Rich-Harris mentioned that awaited queries will be serialized during SSR to avoid calling them again during hydration
It wasn't clear if this is just for kit rpc queries or any awaited data

Rich-Harris May 26, 2025
Maintainer Author

Probably just remote functions. But unclear. Figuring that out will be part of phase 2 (async SSR), while phase 1 is await

Thiagolino8 · 2025-05-25T14:42:58Z

Thiagolino8
May 25, 2025

1 reply

Rich-Harris May 25, 2025
Maintainer Author

That's included in 'top level of a component' - it means anything that isn't inside an async function, including if blocks, for loops and try-catch etc

Gin-Quin · 2025-05-26T12:36:47Z

Gin-Quin
May 26, 2025

An awesome feature that will be unlocked when async SSR is ready is handling internationalization the right way.

Today, it's impossible to make a SvelteKit internationalization library that:

Works with SSR and CSR
Lazy load one locale only
With translations bound to a component rather than one global file per locale (which is easy to start with, but a mess to manage when the project grows)

This "graal" of internationalization would be achieved in the most elegant manner with an await syntax that works both for CSR and SSR.

2 replies

Stadly May 26, 2025

Interesting. Will this open new possibilities for Paraglide JS, @samuelstroschein?

samuelstroschein May 26, 2025

Hm, I don't think so. Paraglide JS fulfills all points @Gin-Quin lists already without the complexity of async stuff.

The only point that needs work is the "lazy loads one locale only." Paraglide JS has an experimental split locale in the middleware, which leads to great benchmark results source. However, the demand to make this feature prod-ready is not high, given how well Paraglide JS already performs due to tree-shaking.

I also suspect that we will be able to move the splitting logic entirely into the bundler with Vite envs, for example, or JS itself with deferred exports. All with a sync API and, most importantly, approach that works in any framework, not only Svelte.

uniho · 2025-05-27T00:09:45Z

uniho
May 27, 2025

It is well known that JavaScript has a concept of Microtasks (though I only recently learned about them). There are three (strictly speaking, four, but one is irrelevant to this discussion) key ways to schedule a Microtask:

(p) Promise.resolve().then()

(q) queueMicrotask()

(a) await fn()

It is also known (again, something I only learned recently) that (a) is scheduled after (p) and (q).
Because of this, it can occasionally lead to behavior that, while technically correct, may appear confusing or unintuitive to developers.

In the context of React, this knowledge is generally unnecessary as long as we follow the "pure" rule.

In your excellent proposal, can we also continue working without needing to understand the details of Microtasks?
Or, do we need to follow some specific rules, like the "pure" rule?
Or, must we work in fear of Microtasks lurking in the background, making things harder to reason about?

1 reply

Rich-Harris May 27, 2025
Maintainer Author

What sort of confusion are you concerned about, concretely? If the answer is 'I don't know', then it means you have nothing to worry about

brillout · 2025-05-27T13:12:13Z

brillout
May 27, 2025

I'm the author of Telefunc which was mentioned by Svelte Summit.

I'm glad to see Telefunc inspired SvelteKit to re-create Telefunc's design!

Currently, Telefunc doesn't have that many features and re-creating Telefunc is relatively easy.

That said, Telefunc's goal is to support a lot more features (including some features mentioned in the conference) while enabling frameworks such as SvelteKit to deeply integrate Telefunc.

For example, real-time (two way communication) is very tricky to get right. I've some ideas and it would be great to design it together with the SvelteKit team — in case there is interest.

Another example is error handling, which is an interesting topic as well. (The combination tRPC + TanStack Query is one example, but I believe there are much better ways to do it.)

RPC's renaissance (it's actually an old technology — older than REST!) is just at its beginnings and I see an opportunity to create a common RPC infrastructure shared between frameworks.

RPC has a bright future (full of promises). The door is open on my side to collaborate.

2 replies

Rich-Harris May 28, 2025
Maintainer Author

Hey! In principle the door is open on our side too. In practice it may prove tricky, because the proposal we're about to share (this week or next) integrates with the rest of SvelteKit in a way that might be difficult to do in a less opinionated library. For example a query in our design isn't just a wrapper around an HTTP transport mechanism, it also works with our reactivity system to manage a local cache, and has a mechanism for optimistic updates. (Meanwhile a command causes currently active queries to clear their cache and re-run, unless you explicitly refresh queries in a more granular fashion.)

We also have form functions that are very specific to Svelte, and prerender functions that are very specific to SvelteKit. All of this works with SvelteKit's (de)serialization mechanism which allows everything devalue allows, plus anything you've defined in your own transport hooks, plus nested Promises, plus (soon, hopefully) streams and async iterables. And we'll likely have some opinionated handling of version skew.

So there are likely too many implementation details that can't really be outsourced — the coupling of the different pieces within the framework is the real value. What's left is the transport mechanism, which as you say is relatively straightforward (though it admittedly becomes slightly less so when you factor in batching and real-time).

I think what probably makes sense is for us to build this within SvelteKit to begin with, and then once we ship something we can start to get a sense of which pieces could become part of a common base.

brillout May 28, 2025

Seems like a good plan! And I agree: I also ain't sure whether/how a full-fledged RFC infrastructure can be made agnostic. Looking forward to your RFC!

coldino · 2025-05-29T11:30:26Z

coldino
May 29, 2025

I'd like to bring up the behaviour of delayed synchronous results and what I found to be surprising behaviour.

Experimenting with the PR, I extended the simple example so that there are two variables a and b, keeping the existing delay on a inside the boundary but making b plain. Then I set up buttons to increment either a, b, or both a and b at the same time.

<script>
	import { delayed } from './utils.js';
	let a = $state(0);
	let b = $state(0);
</script>

increment:
<button onclick={() => a += 1}>a</button>
<button onclick={() => b += 1}>b</button>
<button onclick={() => {a += 1;b += 1}}>both</button>

<p>a = {a}</p>
<p>b = {b}</p>
<h2>Boundary</h2>
<svelte:boundary>
	<p>a * 2 = {a} * 2 = {await delayed(a * 2, 1000)} (delayed)</p>
	<p>b * 2 = {b} * 2 = {b * 2}</p>
	{#snippet pending()}<p>...loading...</p>{/snippet}
</svelte:boundary>

(https://svelte.dev/playground/7173ec0d84ed42bc85d6c8dc8c926fe2?version=pr-15844)

Behaviour:

"a" button causes a delayed async update to a as expected
"b" button causes an instant sync update to b as expected
"both" button updates both, resulting in a delay updating b until a is complete
clicking "a" then "b" allows b to complete immediately while a is still running
clicking "both" then "b" causes a mixture of delayed and instant updates to b overlapped

So the link that causes sync updates to be delayed appears to be if they are altered in the same tick as an async one?

I don't know if this behaviour is technically considered right or wrong, but it sure is surprising, and surprising behaviour is always a worry. In particular the mixuture of delayed and instant updates to b overlapping is bound to be a very unhappy surprise.

That said, I don't currently have any constructive suggestions to improve the situation :(

0 replies

Uh oh!

Asynchronous Svelte #15845

Uh oh!

Uh oh!

Rich-Harris Apr 28, 2025 Maintainer

tl;dr

Background

Requirements

Design

Use cases

Avoiding waterfalls

Future work

Async SSR

Forking

Client-server utilities

Improving SvelteKit

Nuances

No startTransition/useTransition

Overlapping updates that touch the same state must be applied in linear order

Async deriveds are eager

Context is preserved in expressions

No async $derived.by

Focused inputs are not overridden

Breaking changes

Ok so

Replies: 31 comments · 118 replies

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Ocean-OS Apr 29, 2025 Collaborator

Uh oh!

Uh oh!

Ocean-OS Apr 29, 2025 Collaborator

Uh oh!

Uh oh!

Rich-Harris Apr 29, 2025 Maintainer Author

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Rich-Harris May 4, 2025 Maintainer Author

Uh oh!

Uh oh!

Rich-Harris May 5, 2025 Maintainer Author

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Rich-Harris Apr 29, 2025 Maintainer Author

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Rich-Harris Apr 29, 2025 Maintainer Author

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Rich-Harris
Apr 28, 2025
Maintainer

No `startTransition`/`useTransition`

No async `$derived.by`

Replies: 31 comments 118 replies

Ocean-OS
Apr 29, 2025
Collaborator

Ocean-OS Apr 29, 2025
Collaborator

Rich-Harris Apr 29, 2025
Maintainer Author

Rich-Harris May 4, 2025
Maintainer Author

Rich-Harris May 5, 2025
Maintainer Author

Rich-Harris Apr 29, 2025
Maintainer Author

Rich-Harris Apr 29, 2025
Maintainer Author