[niam]

Calling hooks "traditional" in relation to signals seems fine, lest that word be relegated in time to whatever you in particular care about at this juncture.

I'm sure some 80 year olds before us thought the same of us using that term.

[troupo]

> Calling hooks "traditional" in relation to signals seems fine, lest that word be relegated in time to whatever you in particular care about at this juncture.

"Traditional" hooks are 6 years old. I think it's to early to call it traditional. Given that literally everyone else looked at this "tradition" and chose differently. Namely, signals.

Signals were popularized by SolidJS, but SolidJS's Ryan Carniato will keep telling you that what everyone calls signals now has its roots in libs like KnockoutJS from 2010. And everyone has been busy using signals for the past three years.

Given the amount of frameworks that implement signals today (including monsters like Angular), it's React who's not following tradition.

[niam]

> I think it's to early to call it traditional.

I guess the bigger point is that we could offer the same charity to the OP that I'm lending you here in your use of the wrong "to".

There are meaningful critiques elsewhere in the comments about the piece with some semblance of charitable interpretation. We've elected instead to manufacture a snide, pedestrian haughtiness about wording.

[naasking]

First-class signals came from functional reactive programming back in 1997. Even JS implementations of signals existed before React's hooks.

[kragen]

These "signals" don't seem like FRP signals (which are time-varying values, like a "signal" to an EE but not limited to real numbers) but more like Qt signals or MVC "model has updated" notifications.

[naasking]

Original FRP was "behaviours" (continuous time-varying values) and "events" (discrete events, which map to current signals).

[kragen]

Yes, you're right. I think I read some later FRP papers that used the term "signal" instead of "behavior", and I thought that was what you were talking about. FRP "events" are kind of like the kind of signals being discussed here, but there are still big differences.

[naasking]

> FRP "events" are kind of like the kind of signals being discussed here, but there are still big differences.

I don't think the differences are that significant, JS signals are basically `latch(frp-event-stream)`, eg. FRP events yield edge-triggered systems and JS signals yield level-triggered systems, and latches transform edge-triggered to level triggered.

I understand why people can see JS signals as FRP behaviours though, as both have defined values at all times t, but the evaluation model is more like FRP events (push-based reactivity), so I think edge vs. level triggered is the real difference, and these are interconvertible without loss of information.

IIRC, the FRP literature calls both of them "signals" as a general category, just two different types.