Caliburn.Micro VS async_ui

It works with ActivateItemAsync but I don´t know if there is a difference that I should be aware of ? They seem to be a bit slow with updating the documentation so I´m a bit nervous about what else might not be updated yet.

The programming model reminds me of Rob Eisenberg's older attempts at building UI toolkits ([0]). I don't recall if that was fully async or 'just' using a coroutine/generator-style approach, but it feels similar.

I'm not sure the complexity of doing everything using async constructs is worth it, though. Large-scale UI's built in Qt or Javascript are mostly single threaded anyway, but it's still worthwhile to explore so kudos for that. Looking forward to seeing how far you get.

[0] https://github.com/Caliburn-Micro/Caliburn.Micro

Vanilla WPF has a lot of boilerplate and verbose binding expressions. I'd check out an MVVM library like https://caliburnmicro.com/ which has tons of convention-based features and helps maintain the "screens" in your app.

Your UI needs to bind to something that can programmatically notify it about changes, we call these things View-Models. Usually View-Models implement INotifyPropertyChanged interface (another key interface is INotifyCollectionChanged that is responsible for notifying collection views that number of items is changed and they need to update the UI accordingly). You can do that (the implementation of the interface) manually or use some library to do that for you just to cut some boilerplate code (e.g. ReactiveUI + Fody or Microsoft.Toolkit.MVVM or maybe even this or this).

I haven't done WPF/XAML stuff in years but I really liked Caliburn Micro, largely because of the convention-based auto-binding.

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