DEV Community

Avalonia UI and MAUI - Something for everyone

Mike James on March 29, 2023

In the world of cross-platform .NET development, two popular frameworks have emerged as strong contenders: Avalonia UI and .NET MAUI (Multi-platfor...
Collapse
 
panditapan profile image
Pandita

I really like that this article highlights the good in both frameworks to draw the comparisons rather than put the other one down to prop the other one up.

I love this positive approach <3

Collapse
 
ant_f_dev profile image
Anthony Fung

This is a really good comparison between the frameworks.

A while ago, I started on a personal project. I wanted to build a (primarily) Windows desktop app, but wasn't sure of which UI framework to use. I could have gone for WPF, but it seems like it isn't (truly) in active development anymore.

After looking around a bit, I came across a few options which included MAUI and Avalonia. MAUI didn't really seem the perfect fit for what I wanted to do, and I already knew WPF pretty well. I decided to go with Avalonia, and I have to say it's a nice framework to work with!

In the spirit of being fair, I'm sure MAUI is great too; I just haven't tried it yet.

Collapse
 
thewerewolf profile image
The Werewolf

WPF isn't dead. If it was, they wouldn't have taken the time to port it from framework 4.x to Core 3.5. It's more that it works and it's flexible enough that you can make it do pretty much anything now so there's not much left to do...

Well, other than make it cross platform, which Avalonia does - without turning it into .Net Forms, which MAUI and Xamarin Forms does.

Collapse
 
ant_f_dev profile image
Anthony Fung

I just had a quick look at the WPF GitHub repository. You're right - it's not dead, and there is a vision for it.

For the most part, I agree that it's mature and flexible. That said, it's been around for a long time time. I understood the initial vision to be a modern replacement for Windows Forms, but it still doesn't have colour picker or tray icon controls - unless I'm mistaken (which could be the case as I haven't done much WPF recently).

Thread Thread
 
thewerewolf profile image
The Werewolf • Edited

Ah... well, you're actually sort of right in that Microsoft is a little like a herd of cats.

Forms tried to 'modernise' VB. WPF modernised Forms (and made it platform independent - but at a time when Microsoft wanted all platforms to be Windows). That led to Silverlight - which was 'WPF Everywhere' - and ran in all browsers.

Then they decided they wanted to replace Win32 with a modern platform and cater to webdevs and so created WinRT and tossed desktop apps for UWP/WinRT and HTLM/Js/Visual C++ (original Surface and Win8). Seriously, .Net/C#/VB/F# wasn't even mentioned in the original presentations., When the dev community collectively said "WTAF Microsoft???" they reluctantly added .NET back into the mix and kind leaned back into WPF but secretly still wanted everyone to use UWP - which was a variant of WPF anyway. This would become a trend.

Then they bought Xamarin and bam, back to Forms again AND cross-platform (sort of, because relying on native controls means 'least common denominator' development rather than WPF's 'do anything anywhere' approach). They also promised XAML 2 - a the one formal consistent XAML to rule them all.

It kind of vanished.

Then they introduced WinUI - which was (wait for it) UWP on Win32 that could live side by side with regular WPF and was itself WPF-like.

Then they announced MAUI (Multiplatform Application User Interface) which was...mmm... Xamarin.Forms but with a few webby things glued into it and a hint that they might remove the coupling to native controls (or make it optional) which was ALSO WPF-like.

At the same time, we got Uno Platform ('let's make Xamarin.Forms use WinUI syntax - a good idea but...), CHTML or OpenSilver (which brought back Silverlight, so WPF but ONLY in browsers) and AvaloniaUI (basically real WPF with a few syntactic changes AND genuinely cross platform - most of the others support macOS through MacCatalyst which is really just a way to run iOS/iPadOS apps in macOS - but not a real macOS app).

And that's where we are today. Microsoft doesn't like WPF but it's so flexible, powerful and easy to learn that even their own engineers prefer to use it, so they can't get rid of it. It's why when .Net Core came out they were trying to ride the webdev bandwagon and targetted it at ASP.Net on Linux, there was NO UI tech in it at all.

It took until .Net Core 3.1 (I think) before they added WPF and Forms when they realised that all the app devs were ignoring Core because, well, they couldn't use it. :) Then Microsoft open sourced .Net, so WPF is here for the long haul.

As for colour pickers and tray icons, yeah - there are weird gaps, but you can host Forms controls or Interop to the platform for those. There are quite a few open source control kits (some by Microsoft in fact) to fill in the missing pieces. More to the point, it's really easy to fill them in.

Why Microsoft chose to skip some basic control (Open File, Save File and Folder Browser are another set) is that cat herd problem again.

PS: When they did open sourced WPF and brought it to .Net Core, I remember Scott Hanselman hinting that they could make WPF genuinely crossplatform and that that might be coming. Sure, sure. :)

Thread Thread
 
ant_f_dev profile image
Anthony Fung

Thanks for the history lesson (I really do mean it).

I did the bulk of my WPF coding starting circa 2005, and remembered feeling disappointed that there were no tray icons, etc. But you’re your right that they can be relatively easily patched, and I remember following some guides to do platform interop code for tray icons, etc.

I then transitioned to Silverlight until its sunset approximately 10 years later. I remember the fanfare around .Net Core being cross platform, and that WPF was coming to it. And then the disappointment of learning that it would be there, but only for Windows (rather than being cross platform like the rest of .Net Core).

After Silverlight was dropped, I transitioned to HTML/JS/CSS, so didn’t follow the Microsoft UI frameworks as closely until around a year ago when I wanted to do a desktop app. I admit I found it really confusing choosing a UI framework, as there were so many different options. I think I tried WinUI3, but it didn’t feel right for my project and so tried Avalonia. It was still slightly confusing – it was my first real contact with Observables and Reactive UI – but nice to use once I got the hang of things.

It's good to know WPF is here to stay – at least for now. Thanks for the insight.

Collapse
 
thewerewolf profile image
The Werewolf

The biggest difference is that MAUI/Xamarin.Forms uses a highly incompatible XAML syntax which means having rewrite most of your UI while AvaloniaUI is about 95% compatible with standard WPF.

I just ported two WPF apps to macOS using Avalonia in two weeks after literally trying to do this with Uno Platform and MAUI and Xamarin.Form for years.

Collapse
 
jemh profile image
Jem • Edited

I don't understand why in MAUI Performance you say:

It should be noted that on some platforms, objects will exist in both the .NET memory space and the platform UI toolkits memory. This can have a noticeable effect on performance compared to an app developed purely with the native technology. 
Enter fullscreen mode Exit fullscreen mode

It doesn't make sense to me. Since Avalonia is built on top of .NET Mobile/Xamarin too, isn't this the same for Avalonia too?

Collapse
 
xtuzy profile image
xtuzy

maybe it means when you create a control in maui on android, it also will use java create this control, althoug memory that c# use is little, but it is exist.

Collapse
 
jemh profile image
Jem

Yes, but Avalonia is also based on .NET Mobile/Xamarin. It uses SkiaSharp to draw the controls, which means, on Android, there's two objects in memory, one in .NET and another one in Java.

Thread Thread
 
mikecodesdotnet profile image
Mike James

the SkiaSharp control would be referenced on both sides but thats it. With Xamarin.Android, it's every single control, which is a huge performance problem.

We also have a version of Avalonia that can run without any Xamarin / .NET Mobile and the performance is incredible.

Thread Thread
 
nicolasklaas profile image
Nicolas Mousserin

While the version without Xamarin/.NET Mobile looks fine and extreme fast in the video, it is still a preview? and as far as I know there is no real commitment date planned for it? So it could be years? And even then, there will probably be still more than enough bugs or limitations.

Thread Thread
 
mikecodesdotnet profile image
Mike James

It's a proof-of-concept to demonstrate that we don't require Xamarin to run Avalonia. We havn't got a release date for it, because it's not a big priority for us right now. When we do release it, we'll have worked hard to make sure it doesn't have "more than enough bugs"....

Collapse
 
danardelean profile image
Dan Ardelean

Really nice comparison

Collapse
 
wolfandrealbrecht profile image
WolfAndreAlbrecht • Edited

Very good contribution and a comprehensive comparison of the two frameworks. As an experienced .Net and wpf developer, I think the decision on which framework to use depends on context and requirements.

For example, if a cross-platform business application is to be developed, then the usability and user experience are critical. So that the user experiences the same behavior of the application on each platform. So that the decision for Avalonia UI is made

For example, if an app is developed for mobile devices, where there is no business process in the background, it is more about performance and a native platform experience. So that the decision for MAUI is made.

But lastly, such a decision is difficult, because it must be sustainable in the long run.

Thanks and best regards.

Collapse
 
qws profile image
Qws

There is also Uno, which use the UWP/WinUI XAML dialect.