Avalonia GUI app, FuncUI vs ReactiveUI (with F#)

Hi,

I’m writing a small System tray + GUI app for the first time, and I selected Avalonia + FuncUI for the GUI. FuncUI is great, and my application is fairly simple, so I created a couple of simple views (e.g. input, button, and response viewer, response type depends on the result of the query).

Out of curiosity and because there were cases (involving using Avalonia extensions) where FuncUI was less helpful, I asked Claude to generate a project using Avalonia + ReactiveUI + FSharp and copy the functionality of the current FuncUI project. After going through several fixes (e.g. I insisted of making it impossible to represent invalid state - as it is so common in OO), I reached a result that is slightly more verbose, but one that I could certainly live with. This is of-course, not enough to make me think about migrating to ReactiveUI :slightly_smiling_face:.

Then I asked Claude to compare the testability of both implementations. This is where I was really surprised. I have no experience in desktop apps, (or any UI other then terminal), and almost no experience in OO programming. According to the comparison, it seems that the MVVM pattern, indeed makes the app much more testable without having to resort to headless UI testing.

Since I don’t want to spam the list with long code, I uploaded the sample files (both FuncUI and ViewModel - but without the context of the entire project) and the generated testability report to this gist.

I certainly don’t blindly trust Claude, so I was wondering if someone has any experience with Avalonia / FuncUI / ReactiveUI and can share his experience both in terms of testability and other things that I might overlook.

Thanks in advance

Haim

MVVM simply mess that you control.

Best way focus to domain specific problem and ignore details of implements.

Thanks.

Eventually, after going even deeper and trying C# and ReactiveUI, I stayed with FuncUI. I am going to investigate switching to RX architecture though. Passing around agents (MailboxProcessors) and having to always monitor their status adds a lot of boilerplate and complexity.