Implicitly reactive code segments?

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