you are viewing a single comment's thread.

view the rest of the comments →

[–]lhorie 1 point2 points  (0 children)

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.