Why build a product on MAUI when Microsoft aren't too sure about it.
I think it’s better on the server side with ASP.NET.
As far as I have heard MAUI is pretty buggy and has lost momentum. It will probably go on the long list of basically abandoned .NET UI frameworks
The point about them not using MAUI still stands though. From what I understand, the .NET world has either adopted different abstractions like Avalonia, or stuck with tried and tested solutions like WinForms with proprietary controls. After all, they've seen this before with WPF which was never fully adopted by MS either, or with the debacle around Metro/WinRT. You're never quite sure what Microsoft wants you to use or will support in the long term. They also make Blazor, which is a different (and likely more accessible) way to build web apps with .NET.
Since we're on the subject of companies not dogfooding their shiny tech, is Google really using Flutter for their own apps? I feel like the evolution of the Android ecosystem towards Kotlin and Jetpack Compose implies otherwise.
Microsoft Teams was released in March 2017. .NET MAUI was released in May 2022. In 2021, Microsoft replaced Angular with React and moved away from Electron to WebView2 (using the OS' built-in renderer rather than a bundled Chromium). So even the rewrite was a year before MAUI (and they probably started the rewrite before 2021). Plus, part of the point of using React there was that they could basically replace Angular bit by bit.
Microsoft Teams is just older than MAUI. It's like asking why Hadoop is written in Java and not Go or Rust or why Kafka is written in Scala and not Kotlin. Kafka was open sourced in January 2011 and Kotlin came out in July 2011. Kotlin wasn't an option given that they were developing it years before the language was released.
That's not to say that Microsoft's attitude toward MAUI doesn't leave concerns. There was some news a while back about a bunch of layoffs around MAUI. It's always concerning when there doesn't appear to be any dog-fooding going on - is this just some junk they're throwing at us that they don't want to use? I think some hesitation also comes from the Blazor side where it's looking like Microsoft doesn't really see Blazor as a React competitor so much as a way for internal company apps to be made quickly - in contrast to the Google IO presentations on WASM support for Dart/Flutter where they were emphasizing better-than-JS performance.
That said, Microsoft hasn't really released a lot of new (green field) stuff over the past 2-3 years. What product should they have made in MAUI, but didn't? You can't say Teams because that was a giant product way before MAUI even existed. Most of what Microsoft is doing is work on existing products - things they released before 2023/2024 and were in development before MAUI existed. Flutter had a 5 year head start on MAUI.
But there certainly is a feeling that Microsoft doesn't feel committed to it or at least not enough to put its weight behind it.
Qt also seems to be a good option, though there are licensing considerations for commercial applications.
I’m excited for various upcoming Rust options as well, but right now Electron is the battle tested option.
I am curious though about Avalonia. I’ve heard good things, but it’s definitely a smaller player compared to Electron. I’d most likely choose it over Microsoft’s first party frameworks.
Ive been using the same framework now for 10+yrs on apps in the stores, i wrote a small layer infront of the webviews and can swap out webkit, chrome, edge on demand. You really dont need much, just a constand way to boostrap logic and UI. 90% of code is shared across all platforms, there are def differences in WebView engines that you sometimes come across but those parts just get swapped out with browser specific JS. Ive found bugs and worked with browser teams at all vendors doing this and to see how simple this is with Dotnet these days compared to when i started is refreshing. Its easily the most stable cross-platform framework around, if you are stuck using something like flutter i pitty you, its just eletron with another skin. I can swap out and integrate directly with OS libs when i need to do stuff that the dotnet team hasnt gotten around to yet without re-writing. This has mean i really havnt used MAUI at all, but if i need to or could take advantage of it i can mix it on an Ui element by element basis. I prefer webUIs though, i have the chose to handle anything with either JS, WASM, or a combination. I can use traditional JS frameworks or traditional Native UI frameworks.
If i had started this process later, avalonia seemed to have the closest thing i required. It was just a bit a more complex /based on WinUI (which i dont really enjoy) but it supported all platforms and gave lower level api access. MS were smart, that canabalanised all these community effort and brought them into the fold. Every dotnet webview impl was a successfull community driven project before. They didnt write anything themselves from scratch.
Unfortunately Microsoft likes to jump into bandwagons and many engineers at the company seem to like to reinvent stuff rather than adopt. WPF, WinUI2 and WinUI3 all share the same Xaml based structure. So they could have adopted WPF.
It is not that Microsoft doesn't develop advanced UIs with their frameworks. WPF is still well-used by Windows and other Microsoft utilities like Windows Terminal. They are just stupidly abandoning their built up bases for silly industry fads.
They jumped into tablet / touchscreen / hybrid-mobile-desktop bandwagon in late-2010s and tried to force WinUI as an UWP-only feature. It resulted in low adoption. They didn't adopt WPF to have same theming.
When WinUI2 failed, they tried to make modern C++ a reality and tried to remove UWP restrictions which is a good decision. However they diverted quite a bit resources into AI slop generation now and WinUI3 just languishes.
Same for MAUI. They tried to get into multi-platform, multi-device framework as a way to generate leads into Microsoft ecosystem.
They try to use various frameworks and UI stuff to get people hooked into the ecosystem and find ways to upgrade them into Azure and M365 customers. It is meaningless and tiring. All of those could be only WPF.
It is like Google and its many Bazel-like build systems (but not full Bazel) for each of Chrome, Fuschia and Android.
It's also the option which gives your users by far the worst experience. Not worth it at all, imo.
Eventually dumped it and moved to Kotlin Compose/Multiplatform, which is just so much better at achieving a similar goal (though, obviously, without being part of the .NET ecosystem).
Plenty of category leading applications like Discord, VSCode, Slack, Figma, etc. use it quite successfully.
To be fair, there is no practical way to write native desktop applications using stylistically consistent UI elements AND have it be portable AND in a language that you enjoy using.
As far as I can tell, Windows 11 doesn't even have a toolkit with platform UI elements.
GTK on Gnome is pretty okay and GTK-rs is not dissimilar to React. Who know what MacOS uses but something something Swift XCode.
But I agree, just use web technologies. Write once, ship everywhere (and hum loudly when people complain about poor performance - joking, it's the vendors' fault we have to use web technologies).
Are there QT or GTK competitors crushing them?
I always hear how terrible electron apps are, but the companies picking electron seem to get traction QT or other apps don't and seem to have a good cross platform story as well.
I don't know much about it but it seems like a weird combination. If you want high performance and low memory usage, you don't want HTML, if you want fast code writing, you don't want Rust.
And most of the world is like that, very few of us (speaking globally) have $2k to drop on a new supercomputer every few years to run our chat applications.
And furthermore, if you want fast code writing, you write in the language you already know. For some people, that is Rust.
You are right that WinForms and MVC have been around forever. However, Microsoft has continuously told devs that they are the past. So, you would be forgiven for expecting them to go away.
WinUI is the current official desktop paradigm and it is basically UWP from an API point of view. So the idea that UWP went away is not 100% accurate either.
Microsoft does not really abandon their UI tech like people say they do. But look how many different frameworks they have.
All of the above is Windows desktop only. There are a completely different set of UI technologies for the web.
UNO Platform (Open Source) allows you to use the WinUI API to target almost anything.
.NET MAUI is the official "cross platform" UI tech from Microsoft. It is what you use to target iOS and Android. As a bonus, you can target macOS and Windows too. On Windows, it uses WinUI. You will notice that the Linux desktop is missing from that list.
Here comes Avalonia to build MAUI on top of the Avalonia framework. This adds Linux and WASM to the list of platforms that MAUI will run on. Adding Linux is awesome. A lot of people have wanted that and it really completes the MAUI cross-platform story.
Adding WASM is neat but MAUI was never meant to target the web. If you use it for that, it is literally just the modern version of Silverlight. But Microsoft did not design it for that at all. It is just a back-end that Avalonia supports.
It is history not the lack of will. At one point the windows division was in shambles (remember vista) and WPF pops up. At another point, the windows and dev division have no answers to the office group (because you know who uses non win tech) so they went react. And then external devs screamed: where is the .net cross platform story so Microsoft acquired xamarin and later form Maui out of it.
It is history not lack of trust. But the outcome is the same: lackluster support for all UI toolkits.
- HTML is the main way of designing interfaces (whether we like it or not)
- Rust is the main language promoted by intelligence agencies with multi-billion dollar budgets because it is laced with their backdoors (whether we like it or not)
Someone needs to remind those cats that they own the platform. Being able to sanely develop apps for and on that platform should be possible, and UI kinda-sorta matters for that. At a certain point with the MFC they had it dialled in, while pioneering asynchronous browser tech, with many best in class tools. Decades later with a cross-platform cloud-centric stack they have a shrug emoji as big and wide as the eyes can see, and no sense this basic question of development will ever get improved.
Ballmer chanting ‘developers, developers, developers …’ springs to mind.
Blender: frontend Python, backend C++.
Houdini: frontend Python(PyQt), backend C(presumably)
Sim City: frontend JavaScript, backend C++
The reason is very simple: frontend is more error tolerant, but less resistant to the product designer's whims (or the users' desire to customize.)
For Windows you're dealing with Edge (so Chromium), on macOS you have Safari, and on Linux you have WebKitGTK. WebKitGTK has honestly abysmal performance, and you're missing a lot of modern standards.
The Tauri devs are looking at bundling a Chromium browser with it to deal with that, but that's still some time off, and leads to the same issue Electron has, where you have large bloated applications.
Companies aren't picking Electron due to inherent shortcomings in other platforms, they're picking it because it's easier (and cheaper) to find JavaScript devs who can get up to speed with it quickly.
One that comes to mind that I use daily and noticed only recently that it was implemented in Qt is the telegram desktop app.
Windows for many years is just a pile of different browser engines stashed one atop another running broken javascript/xml with react native on top.
I think Qt really is 'just' missing more language bindings, and a better hot reload story for more people to use it. Lots of devs (specially Free Software devs) would prefer to use native toolkits, if the prototyping experience was similar to how Vite is for web frontend stuff, I think Qt would be used a lot more.
Your comment applies to Teams and I’m sure other electron apps. But the sweeping generalization that electron apps have terrible user experiences is pretty obviously incorrect.
I did, it was great. Very apple-esque in a way. As long as you stayed in Microsoft's garden, you had a good time. Microsoft had, at the time, one of if not the most productive stack to build GUI desktop line of business apps. If your whole org was Microsoft from top to bottom, even better. AD auth in your desktop app in a couple of lines.
It was an expensive stack for sure, but I'd argue there's still nothing that has come close to it if you want to build an enterprise desktop app.
blender's frontend is pretty much exclusively C++? https://github.com/blender/blender/tree/main/source/blender/...
> Houdini: frontend Python(PyQt),
I would be infinitely surprised if Houdini's frontend wasn't also a majority C++. Likewise consider large apps such as Ardour, Krita, etc.
> Qt also seems to be a good option, though there are licensing considerations for commercial applications.
you need to respect the LGPL with Qt. You also need to with Electron which uses Chromium which is LGPL.