Post

Preact Signals just got a huge performance boost: Signals rendered as text/props & effects only "pull" as fast as needed for rendering. Since computeds run as-needed, they now only re-run as often as their downstream DOM output can be painted. H/t to @jovidecroock.com for making this happen.

@trueadm.dev Can Svelte ship this? Or does Svelte need this?

Svelte 5 already has this

To be clear, Svelte 5 used to have something like this with our scheduling but we had to back out of it due to some issues that surfaced due to the sequencing of some things not happening soon enough. However, we're going to look into re-enabling some form of it again in the future.

Looking at back why we reverted it, it was because of things like the `disabled` attribute. If you don't apply that in a microtask, then the next event coming in will read the stale value and do the incorrect thing. Flushing template effects on events just gets us back to where we started.

Yes, we had this as well. Effects are scheduled rAF debounced while DOM properties/Text nodes are scheduled in a double microtask so it can slot in with the normal Preact rendering cycle, this prevents the issue.

It is, it has been shot with the latest version. Just that effects and dom-updates have slightly different queueing mechanisms github.com/preactjs/sig...

Hey Jovi, I'm really intrigued by this double microtask and the necessity of two kinds of deferment. Do you have documentation about this?

In Preact we use a single microtask, so that any synchronous work can complete before we schedule a rerender github.com/preactjs/pre... We also use RAF for effects, as we allow the DOM to paint and then execute effects.

So the updates are happening inside a user effect rather than in template effect from JSX?

I have no idea what you're implying, sorry. I also don't have access to the code of Jason, I am just clarifying that <x disabled=someSignal /> updates differently from useSignalEffect(() => {})