Avalonia.FuncUI VS Comet

For those interested in .NET languages with alternative compilation targets, Elmish (https://elmish.github.io/elmish/) is pretty unique.

We use F# on the front end (instead of TS), and thanks to the Fable compiler (which transpiles F# to JS, Python, Dart, PHP and Rust), most of the benefits of an Elm-style model in the UI can be ported to all sorts of different outputs languages. The rust target is in beta, but its promising because the WASM bundle size stands to be dramatically lower.

While the default is reactivity library for Elmish is React, you can swap in Avalonia/FuncUI (https://github.com/fsprojects/Avalonia.FuncUI) pretty easily as well.

The code to declare/build the widgets is quite nice. Modifying widgets by hand on certain signals or manually re-wiring all the signals seems a bit outdated to me.

Wonder if something like FuncUI [1] could be built on top of it.

[1] https://github.com/fsprojects/Avalonia.FuncUI

OTOH, if desktop really is the primary focus, and if you can drop the idea of reusable UI code, then Avalonia is a great choice for F# as you can use a Avalonia.FuncUI and/or Elmish.Avalonia.

And one more MVU for you https://github.com/fsprojects/Avalonia.FuncUI

You might want to check out Avalonia.FuncUI, which lets you use F# and the cross-platform Avalonia framework to build desktop applications with an Elm-like architecture: https://github.com/fsprojects/Avalonia.FuncUI#example-using-...

> the first, MVP-style, attempt will be using Electron.

Good choice.

If you want to stick to HTML...WebView2 is suppose to replace it, but it assumes your backend code is .NET or C++, instead of JS/Node.js. Microsoft Teams is using it.

If you want to use native Windows UI components from JS code, then React Native for Windows is recommended. Facebook Messenger is using it.

All approaches require C# or C++ modules to be used to interact with the Windows Platform. Or there is: https://github.com/tjanczuk/edge.

The recommended approach is WinUI 3 which would involve C#/C++ and XAML.

To SwiftUI/React/JetPack are called module-view-update (MVU). There is an MVU for C# called Comet. https://github.com/dotnet/Comet#key-concepts

The benefit at least with the approach instead of embedding Avalonia inside Maui is you could potentially use non xaml frameworks for ui as long as they support Maui as a target. Stuff like Comet or Blazor mobile bindings would be possible aside from xaml. Especially if they're coming from Blazor web or code based ui frameworks like flutter which makes it appealing.

That was using the experimental Comet extension and lib, based on .NET MAUI. You can find instructions here: https://github.com/dotnet/Comet

There are also experimental libraries for .NET MAUI, which let's you create UI only with C#: Comet, MauiReactor

The MVU library is called Comet. The lead developer recently left Microsoft but im still seeing commits on the repo which is a good sign!

Yeah the hybrid blazor stuff is interesting. So is https://github.com/dotnet/Comet.

The XAML API is definitely more compact overall which is unfortunate, mostly because a lot of the devs prefer XAML. I've always preferred code-based UI though. Theres some 2ndish/3rd party options with Comet, which changes the UI pattern to MVU and C# Markup, which might not be updated for MAUI yet.

All the C# parts for Hybrid (including the components themselves) are running natively. Only the UI part (e.g. html, css) under the Web View is running web tech (html, css) under a native webview of the platform. But you can also add native MAUI controls if you wanted to (either via XAML, or Comet) and mix and match as that webview control that Blazor uses is just a MAUI control.

There is an alternative using MAUI .Net Comet