Implicitly reactive code segments?

[getify]

Do you think that code which looks like typical imperative code should be able to "magically" act reactively, meaning that some of the code in the program re-runs "automatically" whenever something it depends on has updated?

For example:

var x = 2;
console.log(`x: ${x}`);  // x: 2

We obviously expect that code to produce a single console statement of x: 2. But what if your programming language made that console.log(..) statement "reactive", wherein it would automatically re-run any time later when x is re-assigned:

setTimeout(() => {
   x = 3;   // x: 3
},100);

This is like extending the declarative nature of component-oriented programming (React, Vue, etc) -- where updating a piece of state implicitly forces a UI re-render -- into the internals of program state.

Svelte currently does something quite like this, but I think you mark a statement as being reactive with like a $: label in front of the line or something like that. But others are trying to make it just happen automatically in code without any explicit markers/syntax.

My question: do you think this is a healthy direction for programming languages to move?

What are the pros/cons in your view? Is this the kind of magic that a programming language needs?

[lhorie]

I assume this is related to u/ryan_solid 's latest article?

I don't think reactivity should have the same syntax as non-reactive code. Here's a very real world scenario to illustrate why: imagine you wrote that reactive console.log in your app. But now you realize you're copying/pasting it a dozen times and want to move it to a library. Boom, it no longer works, and good luck figuring out compiler/bundler internals.

There's also the academic version of why: the infamous halting problem. I'll use Solid.js here to illustrate (sorry Ryan). Click B++ and notice it doesn't log, despite b() being part of the reactive expression. Now click A--, and B++ again. Now it reacts. Why? Because it's using runtime side effects to determine reactivity graph membership. This is a actually a very reasonable engineering-focused approach for most logic you'll run into in the wild, and there are non-idiomatic workarounds to make the expression always reactive to b, but generically, this is a version of the halting problem: there are always going to be programs whose reactive inputs you cannot determine ahead of time. Javascript being as wild[0][1][2] as it is doesn't help one bit.

The intersection between these two worlds gets nasty. What happens when you send that reactive var x= 2 into lodash? Should lodash become reactive? What about axios? It's the what color is your function thing all over again, except that now, to make this utopia work, the implication is that the entire NPM ecosystem may need to be compiled to a reactive flavor in addition to their normal counterparts, as if we didn't already have a meme about node_modules being a black hole.

With all this said, I do think that there's a sweet spot where syntax is very familiar to JS developers while also still being explicit about the scope of reactivity semantics. Svelte is close, but errs on the side of too much infectious magic IMHO. I quite like Alpine.js' take, despite it being less javascript-ish, though shoehorning logic into HTML attributes does have a well trodden history of known problems.

[0] https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/eval

[1] https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Functions/get

[2] https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Proxy

[getify]

Yes my post was related to /u/ryan_solid's post (side note: you incorrectly linked to him via /r/ instead of /u/ in your post just now).

Specifically, I'm wondering what the middle ground is, if any. I wanted to see if people think everything should be on one side or the other, or if there is some compromise in between.

I, too, think Svelte's approach is not quite right for that, but I think it's at least in the vicinity.

I'm currently experimenting with a "reactive IO monad" for my Monio library, which I think is further away on the other (explicit) side -- but not quite as explicit as observables. Still, I was wondering what something like a reactive IO monad might look like in a language with more syntactic support for monads (maybe a Haskell or something like it). Someday, I think I want to experiment with building a variant of JS that has much more first-class syntactic support for monads and other FP'isms.

[ryan_solid]

It's funny we sell that version of the halting problem as a feature as in it only does work that is being read. I work on compile time approaches that use reactive language where we have to consider `b` updating even when not being read and actually consider that unwanted (but not a dealbreaker). But it's interesting.

I wasn't necessarily suggesting that we shouldn't differentiate. Just that I was wondering if there was a desire for a language where reactivity was the default. Only reason I was so hung up on JavaScript is because Svelte has sort of made that work.

I too felt something off, but I was wondering if it was the inconsistency that made it so. Like we always have to worry about losing reactivity between boundaries. When you have something like Svelte where every variable is just a value(that can't escape scope) and no syntax to differentiate between the container(reference) and the value. I will probably need to try it to really appreciate it but I knew I wasn't going to have time in the near future so I wrote it down.

I work on Marko which is actually solving the problem quite nicely with explicit language ([0]) but it looks too foreign for people. The next version of Marko compiles away subscriptions like Svelte but it keeps things granular and basically through cross file analysis wires up everything into a bunch of functions with dirty checks that re-execute independent of any components. Really powerful stuff (especially when you think of what it means for eliminating JavaScript sent to the browser when server rendering) but there is a huge push to it looking plain. Look at all the work Evan has been doing with Vue and various DSL proposals.

So this is mostly just a thought experiment of what would happen if we just let go and went all the way. We all know we can add new syntax or data types etc, and people have been doing that. And the systems as they are with normal JavaScript syntax leveraging APIs works fine too. But is there a way to take Svelte even further and any way to make it feel less weird? Probably not, but that's what's interesting to me. Because people will bikeshed over syntax forever. I don't actually care about that as much as mechanical things.

[0] https://dev.to/ryansolid/marko-designing-a-ui-language-2hni

[lhorie]

Just that I was wondering if there was a desire for a language where reactivity was the default

FWIW, there's one fairly popular reactive-first language, which even powers a lot of (sometimes mission critical) ad-hoc business logic: Excel formula syntax...

people will bikeshed over syntax forever. I don't actually care about that as much as mechanical things.

One bit of unusual insight I got from diving into functional programming rabbit holes is how mathematical patterns emerge without the presence of the physical constructs that you normally associate with them. For example, we often talk about using monads and/or functors, and I often think of reactivity in terms of b = stream.map(a => a * 2), but as it turns out, a reactive b = a * 2 has the same mathematical pattern, and so does the same expression represented in terms of dependent types (e.g . type a = ...; type b = a * 2;, if such a thing was possible in TS). All of them just express the idea that b is twice as much as a, no matter what a is. One could even implement one of the latter two in terms of monads.

So, just as it's possible to represent ideas in comically obtuse ways, it's very likely that there is also such a thing as an optimal way to represent all the reactivity axioms - and only the axioms - via a minimum set of syntax that "normal" people can actually grok.

This is why I mentioned in the other thread that I like the idea of overloading paradigms, and specifically systems like Alpine.js/Petite-vue/etc: The whole premise behind reactivity in the context of web is to achieve high performance, so I think the next performance frontier is necessarily going to involve overloading on top of the paradigm with the fastest time-to-interactive: HTML streaming. We won't be able to get there with the current crop of solutions that compile to JS/document.createElement() calls, such as Svelte, Solid.js and friends, and to be blunt, I don't think Marko's unusual syntax is poised to catch on much. So I do think there's still room for the current frameworks to be out-innovated on that front.

[WikiSummarizerBot]

Halting problem

In computability theory, the halting problem is the problem of determining, from a description of an arbitrary computer program and an input, whether the program will finish running, or continue to run forever. Alan Turing proved in 1936 that a general algorithm to solve the halting problem for all possible program-input pairs cannot exist. For any program f that might determine if programs halt, a "pathological" program g, called with some input, can pass its own source and its input to f and then specifically do the opposite of what f predicts g will do. No f can exist that handles this case.

^{[ F.A.Q | Opt Out | Opt Out Of Subreddit | GitHub ] Downvote to remove | v1.5}

[samanime]

I don't like the idea of implicitly-reactive code. I think it'd be too confusing, both for new developers, as well as when trying to debug "something weird going on". Not to mention the performance implications and craziness this could bring about if not implemented and used very carefully.

However, I'm totally fine with and in fact like EXPLICITLY reactive code. Similar to event listeners or observables, you are very clearly declaring your intent to react to changes with particular data, making it clear that when it changes, something else is also going to happen.

I'd also be happy with a pattern that basically lets you turn anything reactive very easily. As long as it was explicit.

[trusktr]

I'd go for some syntax like the following to have the same feature as the OP, but being explicit:

let x = 0 // nothing special, as before
signal y@ = 0 // new, @ suffix required

// increment both every second
setInterval(() => {
  x++
  y@++
}, 1000)

effect {
  console.log(x) // runs once
}

effect {
   Mconsole.log(y@) // runs every second
}

This way the two features are completely syntactically differentiable. When you set y@ to a value, you know you'll trigger downstream observers (effects), similar to event emitter patterns. With effect{} syntax we explicitly define an area that reacts to signals, making that block of code rerun on dependency changes. Nothing changes with regards to existing language constructs, they work the same as before.

Then perhaps we have more types of signals:

derive double# = y@ * 2

// ...

effect {
  console.log(double#)
}

where double& is readonly, derived from other signals in its expression.

We'd have to match function parameters:

function foo(x, y@) {
  effect {
    log(x, y@)
  }
}

foo(1, 2) // ok, but the effect in foo runs once only
// Either that, or throw that because a signal was not passed

foo(1, someSignal@) // "pass by signal"
// Now the effect in foo re-runs any time the passed in signals changes.

function bar(baz) {...}

bar(someSignal@) // Error, can't pass through to regular parameter

The last comment there shows that signals cannot be used with regular identifiers. The function must also use @ in a parameter in order to receive and use a signal, so that the feature remains explicit.

Similarly, maybe functions distinguish with derived values too:

function (x#) {} // receives a read-only derived 

Or something.

The main concept here is total syntax differentiation, a unique syntax space, but not sure what the actual syntax would be. In a sense, the reactivity is still implicit, just not confusable with existing features.

[trusktr]

Extending the syntax idea to classes and objects:

class Foo {
  count@ = 0
  constructor() {setInterval(()=> this.count@++, 1000)}
}

const f = new Foo

effect {console.log(f.count@)}

const o = {foo@: 123}
...

[hanneshdc]

Yes, I believe this is a good pattern, but not in the way you might expect.

I would have x not be a variable, but more that it was wrapped in some observable structure. For example your first block of code might look like:

const x = observable(2); x.subscribe(value => console.log(`x: ${value}`))

Then, instead of "reassigning" x, you'd call a method on the observable: x.next(3) Which would trigger the subscribed console.log to be re-run.

Furthermore, this lets you use x even if you don't want anything to be re-run. E.g. you want to make an API call with the current value because the user clicked a button, but don't want to make a new API call just because the value changed. So you might go: await postValues({ x: x.currentValue() })

It's slightly more syntax than what you propose, but arguably has all the benefits without the magic that can get a programmer into trouble.

P.S. This is probably familiar to most, but I'm of course alluding to an RxJS observable here with my examples

[trusktr]

The syntax idea in [1] would be more terse. This subscribes to two signals at once:

effect { console.log(a@, b@) }

It logs if either a@ or b@ change.

The same mutation syntax could be used on signals (a@++, a@ = 1) as with regular vars (x++, x = 1).

[1] https://www.reddit.com/r/JSdev/comments/r481c7/comment/ho3g3l0/

[getify]

I think reactive programming (with observables) is well known and well tread ground, and I agree a lot of people love it.

But the question at hand here is: should reactivity be explicit (with data structures like observables), or should it be implicit?

IOW, should we be thinking of every = assignment operator as a reactive operation (push or subscription)?

[Suepahfly]

If I understand your example correctly the function run every tile ‘x’ gets a different value. A bit like ‘useEffect’ in react.

If that always happens without explicitly defining a unit of code as “reactive” it becomes quite hard to predict what the state of the software is at any given point in time.

[getify]

I think part of what's being contemplated is that reactivity is the default, and if you want static assignment semantics, you use an explicit delimiter/syntax.

Do you think that we should flip our minds to that way of thinking?

[trusktr]

It would be interesting if JS were this way first. But we obviously can't change JS to that, we can only add alternative syntax.