There's an important issue with async iterables: what's the initial value of derived "signals"?
In the Dart/Flutter world, async iterables are known as streams. The biggest problem is that they are asynchronous so if you derive new streams from existing streams, you won't have a value immediately for those streams available, you'll have to wait a frame for values to propagate. That's not a problem if you're just processing data, but if you're using them in a UI framework and your UI framework is coupled to the event loop, then you have a problem.
This doesn't happen with the ReactiveX approach because things are evaluated immediately, one doesn't have to wait for the event loop to tick. (A fun historical artifact is that ReactiveX has not caught on in the Dart/Flutter community around 2019-ish because it was eventually migrated to use Streams and the initial-value-problem was a real problem that made the benefits of ReactiveX not carry its weight nobody noticed that but I was heavily involved and I am still using a custom framework derived from my observations back then).
If we zoom out a bit, the problem is actually that we are trying to define a computation graph and then need a strategy for evaluation it. I think Elm has actually made the biggest progress on that front (here's THE talk on that topic that shows how complicated working out all the kinks can be: https://www.youtube.com/watch?v=Agu6jipKfYw)
I still think that functional reactive programming solves most of the problems we have in UI-land, but the complexity that we have to deal with when we use traditional methods of state mutation, that complexity becomes enormous when trying to define a reactive programming framework, especially in languages that are not purely functional.
I think in 10 or 20 years there will be somebody that solves this problem, I don't see it happening anytime soon, sadly. It's just too complicated and we need programming languages that are built around those ideas for them to become comfortable enough to be usable in practice.
> The biggest problem is that they are asynchronous so if you derive new streams from existing streams, you won't have a value immediately for those streams available
I tested that using `myAsyncIterable.map`, which is part of the stage 2 async iterator helpers proposal, and it works fine. Maybe I miss a specific case you have in mind?
How did Dart (or you) fix the initial-value problem?
> If we zoom out a bit, the problem is actually that we are trying to define a computation graph
I agree with that considering the comfort it brings, and since you mentioned Elm I will also mention lustre (a Gleam lib) which has the exact same approach. But both those tools/languages are niche functional languages, which JS is definitely not. I'd love to discuss why but it's another debate.
Elm's and Lustre's approach imply some trade-offs too, delegating a lot of work to the rendering engine.
This idea does not aim at replacing approaches like Elm's or Lustre's, the idea is to integrate with non-functional Web APIs – DOM nodes are definitely not immutable – following the exact opposite approach like SolidJS's about putting evaluation at the lowest level (ie: DOM node) rather than highest level (app).
If your team has the skills to build web apps in another language (Elm, Gleam, OCaml, …), you should probably do that. If you are all-in on JS, I'd better have something as close as possible to the Web platform.
I don't really see that this actually implements it's proposal. The State class is still a custom thing and you could implement that however you want (Indeed a working signal implementation can be made in under a hundred lines)
Sorry if I was unclear, the main point is not about the implementation detail nor size, although it's always a nice to have.
The State class is just one piece of it, you are free to not use it at all: for instance in the todo-fetcher, the State class does not even need to be used.
That's the point I tried to make: the rendering deals with a built-in API, not a special library's reactivity system.
Every time a new reactivity system appears, you need to learn how to compose states together.
Here since it's a built-in API, learning state composition is literally learning about async iterables, learnings which are also applicable in other fields than frontend reactivity.
There's an important issue with async iterables: what's the initial value of derived "signals"?
In the Dart/Flutter world, async iterables are known as streams. The biggest problem is that they are asynchronous so if you derive new streams from existing streams, you won't have a value immediately for those streams available, you'll have to wait a frame for values to propagate. That's not a problem if you're just processing data, but if you're using them in a UI framework and your UI framework is coupled to the event loop, then you have a problem.
This doesn't happen with the ReactiveX approach because things are evaluated immediately, one doesn't have to wait for the event loop to tick. (A fun historical artifact is that ReactiveX has not caught on in the Dart/Flutter community around 2019-ish because it was eventually migrated to use Streams and the initial-value-problem was a real problem that made the benefits of ReactiveX not carry its weight nobody noticed that but I was heavily involved and I am still using a custom framework derived from my observations back then).
If we zoom out a bit, the problem is actually that we are trying to define a computation graph and then need a strategy for evaluation it. I think Elm has actually made the biggest progress on that front (here's THE talk on that topic that shows how complicated working out all the kinks can be: https://www.youtube.com/watch?v=Agu6jipKfYw)
I still think that functional reactive programming solves most of the problems we have in UI-land, but the complexity that we have to deal with when we use traditional methods of state mutation, that complexity becomes enormous when trying to define a reactive programming framework, especially in languages that are not purely functional.
I think in 10 or 20 years there will be somebody that solves this problem, I don't see it happening anytime soon, sadly. It's just too complicated and we need programming languages that are built around those ideas for them to become comfortable enough to be usable in practice.
Thanks for your feedback!
> The biggest problem is that they are asynchronous so if you derive new streams from existing streams, you won't have a value immediately for those streams available
I tested that using `myAsyncIterable.map`, which is part of the stage 2 async iterator helpers proposal, and it works fine. Maybe I miss a specific case you have in mind?
How did Dart (or you) fix the initial-value problem?
> If we zoom out a bit, the problem is actually that we are trying to define a computation graph
I agree with that considering the comfort it brings, and since you mentioned Elm I will also mention lustre (a Gleam lib) which has the exact same approach. But both those tools/languages are niche functional languages, which JS is definitely not. I'd love to discuss why but it's another debate.
Elm's and Lustre's approach imply some trade-offs too, delegating a lot of work to the rendering engine.
This idea does not aim at replacing approaches like Elm's or Lustre's, the idea is to integrate with non-functional Web APIs – DOM nodes are definitely not immutable – following the exact opposite approach like SolidJS's about putting evaluation at the lowest level (ie: DOM node) rather than highest level (app).
If your team has the skills to build web apps in another language (Elm, Gleam, OCaml, …), you should probably do that. If you are all-in on JS, I'd better have something as close as possible to the Web platform.
I don't really see that this actually implements it's proposal. The State class is still a custom thing and you could implement that however you want (Indeed a working signal implementation can be made in under a hundred lines)
Thanks for your feedback!
Sorry if I was unclear, the main point is not about the implementation detail nor size, although it's always a nice to have.
The State class is just one piece of it, you are free to not use it at all: for instance in the todo-fetcher, the State class does not even need to be used.
That's the point I tried to make: the rendering deals with a built-in API, not a special library's reactivity system.
Every time a new reactivity system appears, you need to learn how to compose states together.
Here since it's a built-in API, learning state composition is literally learning about async iterables, learnings which are also applicable in other fields than frontend reactivity.
[dead]