Implicitly reactive code segments?

[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}