Avalonia Redux
Published at 08:30 on 27 May 2026
After using Avalonia for one project, I can say that it is basically what I thought it was, with one exception.
My previous deadline for the wxPython web site coming back up to something approaching full health blew by, so Avalonia it was. As I knew going in, it’s a little more clumsy and boilerplate-y than I like. The resulting apps don’t look as slick and polished as native ones (because they don’t use native widgets). But it works well enough, and it’s popular enough I don’t have big worries about it turning into abandonware.
The exception was multithreading. Avalonia supports async/await, or as Microsoft calls it task-based asynchronous programming. Because of course it does. Async/await got its start with .NET languages. So it’s been part of C# for a long time, and that feature has been fully absorbed into frameworks developed for that programming environment.
This ends up making Avalonia a clear winner over Qt and its quirky signals and slots and its poorly-implemented memory management. It even makes it a clear winner over the callback-based multithreading that wxPython offers. Async/await effectively compiles under the hood to callbacks, but it lets the programmer write code much more as if it were traditional blocking code, which makes coding far easier.
Signals and slots were a significant step backwards over Swing’s callbacks. Async/await is a significant step forward. What seemed to be a narrow win now looks like a clear win.
The things that make Avalonia suck still suck. All GUI frameworks suck. Avalonia simply sucks less than the alternatives for my purposes, significantly less.
And yeah, I know: the wxPython web site now seems to be back up. Well, so what? It took most of a fortnight to come back to full health. That speaks loudly as to how little momentum there currently is behind that platform.