async_ui VS rust-signals

I'm very interested in seeing if using the commonly implemented forms of compiler support for async programming can also be well used for GUI programming. One wishawa[0] is also perusing this approach in Rust but I first came upon this idea from the crank-js[1] authors. It wasn't clear to me why that one never went anywhere. Was it failure with the approach or was React just a good solution in the space? I can say this though, there's something strikingly elegant about those initial samples of using JavaScript generators for components.

[0]: https://github.com/wishawa/async_ui

[1]: https://github.com/bikeshaving/crank

Not OP, but... I'd argue that async style event handling is even more readable then the traditional way of using callbacks. Take a look at this counter example in Async UI (a project I've been working on that's very similar to what OP purposes); my event handlers are all in the same place, and my state (the value variable) is a regular variable; no reactivity primitive needed.

If you are doing ui events, then you can have a look at wishawa/async_ui.

Only in small examples. This doesn't look that much like SwiftUI to me: https://github.com/wishawa/async_ui/blob/main/examples/web-t...

What is the relation and differences between this approach and rust-signals?

Signals is a fantastic and stable library for reactive programming https://github.com/Pauan/rust-signals

How does this approach differ from rust-signals? https://github.com/Pauan/rust-signals

You might want to check out dominator and the rust-signals it is based on, seems like a similar technique to avalanche.

Maybe try futures-signal? I think its API looks quite nice and it even has a tutorial.

Both are signal-based, which seems like the way to go to me. The latter seems more mature in terms of code, but also lacking in good documentation. The rust-signal crate it uses though has a nice tutorial from which a lot of concepts seem to transfer.