[bbor]

A) I agree with many of the comments here arguing that this is not necessarily a new technique, and

B) you’re gonna go far in this life, I’d bet! I know nothing about you but this whole README just reeks of a bright young thinker who’s not afraid to question existing paradigms and can follow through on their conceptual vision. Plus it helps that you’re a very dramatic and effective writer. I encourage you not to let any of this feedback get you down!

Will sit down with the repo myself later, just for me it’s not an angle of HCI I’ve examined explicitly, at least for very long.

[grayrest]

> it’s not an angle of HCI I’ve examined explicitly, at least for very long

If you're looking for additional reading then it's arguable that Reacts matches this viewpoint but any web framework from the past few years using signals (re-popularized by Solid) is explicitly this approach. Most frameworks don't opt for graphical node editors and I've never liked the approach but I've seen a number of those as well.

More generally this falls into dataflow programming which has had a number of published papers starting in the late 80s I believe.

If you're looking for a similar computer sciency approach to UI structure you can look up statecharts which is an older idea that formed the conceptual basis for Ember Router and, in turn, most js framework routers in the past decade.

[bbsimonbb]

No. Signals work with a weak map of references, not a graph. So in my Pizza example, when pizza changes, totalPrice would recalculate twice: once on a signal from pizza, once on a signal from tip. Explicitly constructing the graph dramatically reduces needless recalculation in bigger systems.

[AndrewKemendo]

This is exactly my take. I love anything that makes it easier to track state and transitions. Especially so if it’s a framework for generalizable applications.