Many things are possible that weren't possible before. For example, I was able to compile the Dart VM (the compiler + analyzer + VM) to wasm and run it on the web: https://github.com/modulovalue/dart-live it supports hot reload and many other cool features. It runs essentially everywhere and it's a very bare proof of concept for a fully integrated programming development system.
The problem is that things just take time if you have to coordinate across a bunch of languages and teams while trying to make everyone happy.
To give you a sense of what else is coming: the wasm ecosystem is moving towards supporting a component model. Eventually you'll be able to import any piece of code from any programming language that supports it. Wasm interface types will make that possible.
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.
Very interesting, I always believed we should have more declarative frameworks in other domains and not just UI. My experience shows me this gives LLMs a much smaller space to explore which leads to better results.
Many things are possible that weren't possible before. For example, I was able to compile the Dart VM (the compiler + analyzer + VM) to wasm and run it on the web: https://github.com/modulovalue/dart-live it supports hot reload and many other cool features. It runs essentially everywhere and it's a very bare proof of concept for a fully integrated programming development system.
The problem is that things just take time if you have to coordinate across a bunch of languages and teams while trying to make everyone happy.
To give you a sense of what else is coming: the wasm ecosystem is moving towards supporting a component model. Eventually you'll be able to import any piece of code from any programming language that supports it. Wasm interface types will make that possible.