Sui Gn

Ha, I didn't even know that was a thing, thanks. That's actually why .me doesn't have that problem: there's no separate step for the total. When you write the quantity, the total is already updated, so nothing ever reads the old one in between.

Thanks, and agreed on selector equality. The Object.is contract is invisible until it bites. On the worker: I haven't measured a throughput ceiling, so I won't guess a number. The demos sidestep the 60 Hz case rather than survive it. Cursor-like data never goes through the kernel; it stays in refs. In the Fan-Out demo the page doesn't stream values to the worker at all: a write is a tiny command, normal writes wait for the reply before the next one is sent, and the stress loop runs entirely inside the worker. Replies are counts plus transferable Uint32Arrays, and the page paints at most 4 times a second, only while visible. Coalescing writes per frame is the next step if a page ever needs to stream values in. Where it starts to cost more: frequent writes that each touch only a few values. There the cloning overhead can outweigh the re-renders it saves, and the kernel belongs on the main thread. I'll benchmark that crossover and add it to the post.