Discussion on: The Quest for ReactiveScript

[Joe Pea]

I love the concepts. For these new concepts to be adoptable into EcmaScript they'd have to play well with the existing imperative constructs, living along aside them, while reducing any chance for ambiguity.

Maybe the label idea isn't so bad if it propagates into every place it the feature is used, like

import { foo@ } from './foo'

signal count = 0

log(count@)

setInterval(() => foo@ * count@++, 1000)

function log(value@) {
  effect { console.log(value@) }
}

or something.

Now, I'm not sure this is the best syntax, or that it doesn't have any issues, or that @ is the best symbol, but the idea with signal names requiring to be postfixed with @ in the example is

• usage sites are clear and semantic: we know we're dealing with a signal
• receiving or passing sites (identifiers in import or export statements, function parameters, etc) have the same naming requirement and can only accept or receive signals (so passing "by ref" or "by value" is not relevant at these sites anymore, we just "receive a signal" or "pass a signal").

Another thing to consider is that, if dependency-tracking were applied to all of JavaScript's existing features, what would this imply for performance?

The performance characteristic of every variable, every property, every parameter, every usage site, would change (probably get slower) just so that reactivity works. With a parallel syntax to keep the imperative and declarative paradigms decoupled, we can limit any overhead strictly to those signal variables and their consumers, without affecting the engine implementation of the other features. This would reduce implementation complexity for people who write and maintain the JS engines.

I'm hoping this will spawn more discussion on the possibilities!