MoonZoon VS async_ui

They are both async and made for GUI -- in case of rust-signals WebGUI, provided by dominator and MoonZoon.

Fullstack Framework: MoonZoon, Leptos

Dominator is more of a low-level framework for manipulating the DOM. There's also MoonZoon (https://github.com/MoonZoon/MoonZoon) which uses dominator but provides a more complete experience.

Alternative 2)thin client in browser and server in rust. If you really want to limit it to web client and web server, possibly try a newer approach with moonzoon. https://github.com/MoonZoon/MoonZoon/tree/main/examples/todomvc

I don't really know Rust so clearly I'm not the target audience, but this thing where you define all the styles using chains of methods seems kinda clumsy to me. And if it's all turning into CSS in the end you presumably still need to understand CSS concepts in order to make the layout you want using this syntax. So I'm not sure this is really saving you from learning HTML and CSS. That said it does appear to be compiling your Rust to web assembly (like Blazor does) which is pretty cool.

I've come across MoonZoon (https://github.com/MoonZoon/MoonZoon) which seems like an interesting full stack framework, but I'm wondering about a solution that would allow choosing both frontend and backend frameworks.

There’s also https://github.com/MoonZoon/MoonZoon which is built on dominator. It’s in fairly early stage development but offers a higher level interface than dominator.

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