Post

lol optimizing bluesky feed perf reminds me how misleading so much js framework benchmarking is; all the cost i’m trying to fix now is either about avoiding layout shifts, or about doing stuff as lazily as possible. very little is related to update cost

in fact i would happily trade update cost for better init cost. i need to cut down on what each of these things is doing *the first time*, none of this "reactivity" "signals" etc stuff helps here. it’s just about moving more calculation to interaction time

one easy way to reduce component initialization cost is to move the logic out of the component and into lazily-computed state. In your linked example, you have multiple O(n^2) lookups happening on first render, and much of that computation could be precomputed+reused if hoisted.

also, part of the reason these patterns are so prevalent in react is hooks requiring constant invocation order. it leads to components that do a decently large amount of up-front computation despite only some of it being used.

that's one thing folks don't really grok with Signals until they've used them a fair bit: even in the most basic case with no rendering optimizations, useComputed works like a lazy useMemo. Executing useComputed(fn) is effectively free, you only pay the cost of fn() if+when you _read_ its value.

to illustrate, here is the original code (prior to your changes) minimally refactored to use signals. It has the same performance characteristics as your improved version without requiring split components. (that said, I'd still 100% split the components as you did) carbon.now.sh?bg=rgba%2816...

ahh yeah that’s fair!

a gentleman and a scholar