Preact Signals just got a huge perf 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 jovi 🐨 for making this happen.

In the vid, a signal for the mouse coords is used to compute 1000's of positions that are applied to 1000's of elements as CSS in an Effect. In 1.x, when the rate of input exceeds screen refresh, computations run more often than their results can be painted. In 2.x, they don't.

The awesome thing is, this effectively brings the value of scheduling to signals without any of the headaches normally associated with it. Because it's not possible to bog the graph down by computing state for outdated frames, it can begin computing on every frame instantly.

This is possible because Preact Signals uses a two-phase design: changing a signal notifies its deps that they need to recompute (top-down), but computation is only performed when a dep's value is accessed (bottom-up). All we have to do is intelligently schedule the leaf reads!

🚀 Wallaby.js v2 is here! 🎉 ▪️New unified UX ▪️Works with ALL editors (NeoVim, Zed, Vim, etc.) ▪️Interactive test timeline ▪️and much more! Ready to take your testing to the next level? 💻🔍

@JoviDeC neat

At what rate is the browser triggering events? 🤔 Presumably in some cases it has to trigger events faster than the screen's refresh rate, but shouldn't that be pretty rare? One can kinda force an fps cap on portions if the UI with some kind of fully controllable Suspense, but it seems better if an optimization like that is implemented deeper in the framework.

@JoviDeC Looking good in as usual!

@JoviDeC Nice one @JoviDeC