Both had huge issues UX wise, specially desktop, but performance and stability was never a issue.

Developers should always test their system on the minimum system requirement that they allow the system to be installed...

I remember I complained about WinUI performance years ago, and they told me at the time that "performance" was not the focus...

No one dog-fooded that thing.

I booted up an OLD imac stuck on 10.something, with an - I can't remember which gen - i5 and only 8gb of ram and I was blown away by how much it FLIES on that ancient hardware - even compared to my M1 Max Mac Studio

Apple Silicon is great. Everything else sucks.

I think another way to get to the same effect is to say “A company needs good leaders”.

But it's been long gone that time where Windows had a minimum cohesive guideline.

At my day job, I choose Windows Forms with Blazor mixed in. That's old reliable Win32 tech + modern web tech, without any modern Windows tech mixed in.

With egui, it's an immediate mode GUI rather than retained mode and that has trade-offs: https://github.com/emilk/egui#why-immediate-mode. It's going to use more CPU (and battery power), there can be jitter and things shifting after the initial rendering, and other stuff. I think egui is very different from most cross-platform and platform-specific libraries.

With .NET MAUI, you're getting native controls, but you're now using a layer that's trying to use native controls on the underlying systems that don't always align completely. A lot of things act mostly the same across systems, but some things don't totally.

With Flutter, your app is going to be larger in part because you're shipping a rendering engine, runtime, widgets, etc. Does it have the look and feel you want? Maybe. That's a bit subjective. Does it handle all the little things correctly? When I'm using an app, I want it to scroll like how I'm used to scrolling working on my system. If you have differently styled buttons, I don't care, but if the scrolling feels wrong, it's going to annoy me. And there's so many little things.

Frankly, one of the reasons why Electron often does well is that a lot of the little things "feel right" because the UI is essentially a Chromium-rendered web page which users are used to interacting with. But that has downsides too - shipping a web browser with your app and the memory usage.

Heck, Qt apps in Gnome or GTK+ apps in KDE can look/feel "off".

And it'll all depend on your ecosystem. Often cross-platform solutions are lacking in accessibility - sometimes completely missing, sometimes half-baked and it works in some parts and not in others or just is janky. Memory usage is often higher. Many little things that make an app feel right might not be there. Many have slower startup times since they're loading a bunch of stuff that native apps don't need to. And it really depends on what approach the cross-platform library is taking to determine what is going to cause pain.

So you kinda have to pick your poison and what's acceptable to you will vary depending on your goals and tastes. Maybe React Native is the way to go for you with lots of native controls available and the feel that provides and the performance and size is acceptable.

If you create a Flutter or Kotlin Compose Multiplatform or AvaloniaUI app and put it on the web, it's not going to feel right as something like HN does. Right-click, text selection, etc. are all going to be different or missing. If you're creating a solitaire game, maybe that doesn't matter - you get desktop and web in one go and it's not a big deal.

But you have to know what you're building to know if the trade-offs being made are good ones. This isn't meant to sound anti-cross-platform, but as someone who has suffered some pain in this area, I guess I just wanted to impart that it isn't all sunshine and rainbows. Some times it can still be worth it, but just go in with your eyes open.

But it is used to implement various parts of Windows, such as the File Explorer, so any improvements are helpful for general system performance.

Did you not read the thread? That's literally stated as an explicit goal.

With WinRT on top of Win32, the .NET Native runtime support now lives in CsWinRT, where they also only have C# into account, not even VB as it used to be on UWP side.

The only people that still buy into this are folks that never developed anything with WinUI, aka WinUI 3.0.

Since Windows 8, they messed up the development experience so bad, that they managed to turn many advocates like myself into vocal critics.

We avoid anything WinRT unless there is no way to do the same with Win32, classical COM (WinRT is an evolution of COM), or regular .NET (Forms/WPF).

And also post regularly about the actual state of the tooling unlike Microsoft's marketing posts.

Example, they keep mentioning about WinUI being supported in C++, but never mention how bad C++/WinRT dev experience has become, or that the framework is in maintenance, and has been superseded by WIL.