Post

Jason Miller
@developit.dev

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.

Dominic Gannaway
@trueadm.dev

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.

Dominic Gannaway
@trueadm.dev

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.

0 reposts5 likes

Jovi 🐨
@jovidecroock.com

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.

Gautier
@gautier.dev

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

Dominic Gannaway
@trueadm.dev

So instead you need to get around this by breaking up scheduling based off the type of event, a "continuous" event and a "discrete" event. mousemove or pointermove is a continuous event, whilst click is a discrete event.