killcoder

With the discussions surrounding Preact Signals and the React team's suggestion that perhaps the upcoming React Forget compiler would bridge much of the performance gap, I thought I'd write down some of my thoughts about potential optimisations that could be explored given the platform of an optimising compiler for React.

For context this is written by the creator of Glidesort:

https://github.com/orlp/glidesort

With all the recent talk around Preact Signals I decided to clean up and release some benchmarks I did a while ago, and talk about the conceptual differences between the various state management systems available.

Originally this post was much longer, but I've split it into two, and I'll release the second part once it's finished soon (hopefully in a couple of days).

This was sparked by Preact Signals monkey patching the renderer in their React package. I thought that such a high maintenance cost decision surely conferred huge performance benefits, when in fact it does not! Though I don't show it in this specific benchmark (it's in the next post), it's more performant to subscribe to the signal and update a regular useState hook in the component, no monkey patching required.

I think it's helpful to see that these text updates are taking on the order of <20 microseconds on 10 year old hardware, so upending your entire state management solution in pursuit of better performance might not be a sound compromise.