[spacechild1]

> a concept that is increasingly used in UI development

For a desktop app developer that's a pretty funny statement, given that the Qt framework introduced signals and slots in the mid 90s.

I am curious how many web devs think that signals are a new concept. (I don't necessarily mean the parent poster.)

[MrJohz]

While they share the same name, and are both reactive primitives, there are some fairly key differences between these signals and the QT signals and slots mechanism.

The main one is that QT signals are, as far as I understand, a fairly static construct - as you construct the various components of the application, you also construct the reactive graph. This graph might be updated over time, but usually when components are mounted and unmounted. JS signals, however, are built fresh every time they are executed, which makes them much more dynamic.

In addition, dependencies in JS signals are automatic rather than needing to be explicitly defined. There's no need to call a function like connect, addEventListener, or subscribe, you just call the original signal within the context of a computation, and the computation will subscribe to that signal.

Thirdly, in JS signals, you don't necessarily need to have a signal object to be able to subscribe to that signal. You can build an abstraction that doesn't necessarily expose the signal value itself, and instead provides getter functions that may call the underlying signal getter. And this same abstraction can be used both inside and outside of other reactive computations.

So on the one hand, yes, JS signals are just another reactivity tool and therefore will share features with many existing tools like signals and slots, observables, event emitters, and so on. But within that space, they are also a meaningful difference in how that reactivity occurs and is used.

[spacechild1]

Thanks for the great reply! I definitely need to take a closer look.

[MzHN]

This is an interesting topic so I tried to dive in a bit.

From my reading I understood that Qt signals & slots (and Qt events) are much more closely related to JavaScript events (native and custom).

In both you can explicitly emit, handle, listen to events/signals. JavaScript events seem to combine both Qt signals & slots and Qt events. Of course without the type safety.

For example, taken from https://doc.qt.io/qt-6/signalsandslots.html

"Signals are emitted by objects when they change their state in a way that may be interesting to other objects."

However what I think they are proposing in the article is a much more complex abstraction: they want to automate it so that whenever any part of a complex graph of states changes, every piece of code depending on that specific state gets notified, without the programmer explicitly writing code to notify other pieces of code, or doing connect() or addEventListener() etc.

What are your thoughts on that? I'd be interested to hear since I'm sure you have more experience than me.

[spacechild1]

This sounds interesting. The code examples reminded me of Qt signals but all the answers to my post suggest that JS signals would be much more powerful. Honestly, I'd need to take a closer look.

[naasking]

JS signals come from functional reactive programming, which is a generalization of synchronous reactive programming from the Lustre and Esterel programming languages from the 80s and 90s. I believe the first version was FrTime published in 2004.

You can think of reactive signals as combining an underlying event system with value construction, ultimately defining an object graph that updates itself whenever any of the parameters used to construct it change. You can think of this graph like an electronic circuit with multiple inputs and outputs, and like a circuit, the outputs update whenever inputs change.