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