Hacker News

Glitch-freedom is one of those things that does not bite you until it does, and then you spend a day debugging a UI that renders an impossible intermediate state for a single frame. I hit this in a dashboard project where two derived signals depended on the same source, and without batched updates the downstream computation ran with one stale and one fresh value. The result was a brief negative number in a percentage display, which was only visible if you knew to look for it.

The push-pull approach described here actually sidesteps the worst glitches because the dirty-flag propagation is just marking, not computing. But the article glosses over what happens during the pull phase when the dependency graph has diamonds. Topological sorting during pull is the standard fix -- Preact Signals and SolidJS both do this -- but it adds complexity that matters if you are rolling your own.

Flapjax was doing a lot of this right in 2008. It is wild that the JS ecosystem took another 15 years to converge on essentially the same core ideas with better ergonomics.

I didn't know about Flapjax, thanks I'll check it out. Glitch-freedom is indeed a gap in this article. I focused on the signal algorithm exclusively without some implementation optimisation like batching updates; there is so much more to cover! Maybe in a next one, Thanks!

I wrote a whole screed here about how glitches are evil and Rx is evil for teaching people they’re normal, but then I thought about it a bit more—

The system as described isn’t actually glitchy, is it? It doesn’t eagerly run any user computations, just dirtying, and that is idempotent so the order is irrelevant. It’s also a bit useless because it only allows you to pull out values of your own initiative, not subscribe to them, but that’s fixable by notifying all subscribers after the dirtying is done, which can’t cause glitches (unless the subscribers violate the rules of the game by triggering more signals).

So now I’m confused whether all the fiddly priority-queue needlepoint is actually needed for anything but the ability to avoid recomputation when an intermediate node decides it doesn’t want to change its output despite a change in one of its inputs. I remember the priority queue being one of the biggest performance killers in Sodium, so that can’t be it, right?..

I’m also confused about whether push-pull as TFA understands it has much to do with Conal Elliott’s definition. I don’t think it does? I feel like I need to reread the paper again.

Also also, some mention of weak references would probably be warranted.

After wondering what the heck glitch-freedom is and learning about it, I agree with you. It seems like it deserves at least a brief explanation in an article about how signals work.

I've gone with the universal `alien-signals` package for my project (which doesn't use a frontend framework that includes signals). They show benchmarks of being by far the fastest and have strict limits on code complexity. Those limits are also supposed to avoid glitches by design, and now at least some of that is tested[1].

[1]: https://github.com/stackblitz/alien-signals/pull/39

I searched for the "right way" to explain this algorithm, and ultimately parsing the code was the clearest for me. This isn't always true; sometimes a graph or an interactive module has more impact; it really depends on the topic. Thanks for the feedback.

Writing technical articles without adding a graphic and playful touch would indeed interest me less. I find that it's the intersection of these two worlds that makes reading enjoyable. Thanks for your kind words!

Thanks a lot! The left column containing the text is sticky, The right column is absolute and translate on Y and depend on an intersection observer triggered by each scroll section from the left.

I create a new copy of the Set because the functions called during the loop might modify it by removing elements via cleanup functions. Without a copy, iterating directly on the Set could cause unpredictable behavior.

But as the article points out, this is a naive implementation. It could be discussed and greatly improved.

Result<T> should work

try-catch

Also in https://svelte.dev/blog/runes