> benchmarks (like this one: https://github.com/Noemata/XamlBenchmark), WinUI 3 is currently measurably slower than both WPF and UWP. WPF is 20+ years old and even it is not native!!!.
Older stuff is generally faster because it had to be built in a more resource poor time. Maybe the WinUI devs should be forced to work on systems with the Minimum System Requirements. Heck, maybe all Microsoft development should be done like that, so that some focus on performance is there from the start, instead of as an afterthought.
I am sure this was posted so many times before but someone should reverse engineer the windows 8 era windows phones. Those were ridiculously smooth compared to android and ios with just 512mb of ram.
WP was incredibly smooth and they were willing to reinvent UX from first principles in ways that'll to this day make me reach for Sailfish OS if I didn't need physical buttons, but I must bring up the desktop version of Windows from that day.
I'll never forget the Asus Netbook proudly boasting about its 1024MB of memory via a colorful sticker that'd be considered excessively large on a 17.3" workstation, somehow running Gimp with multiple layers on Windows 8 alongside a few Chrome tabs without a care in the world. UX of 8 and 8.1 was awful, but it was optimized and stable in ways that made me hopeful for what MSFT would deliver in the future. 1gig of memory, a spinning hard drive and a single low powered x86 core were enough to get some image editing for a then school course done with some wiki pages in the background. I'd hardly believe it, had I not lived it. 10 and 11 have been regressions in my book.
The UX of Windows 8 was amazing on tablets, to the point where it's still my favourite touchscreen UI. The keyboard+mouse UX wasn't very good though, which is all that >99% of users ever used.
> 1gig of memory, a spinning hard drive and a single low powered x86 core were enough to get some image editing for a then school course done with some wiki pages in the background. I'd hardly believe it, had I not lived it. 10 and 11 have been regressions in my book.
I had a similar experience with the earlier releases of Windows 10 also [0]. I'm not really sure when Windows's performance got worse, but it was definitely some time after that.
I never used 8 because I hate the UI. But I used 7 for a long time. I recall that 7 was blazingly fast on a 2GB notebook back in the early 2010x. But then that was already way beyond its minimum system requirement.
Contrary to Windows Phones, Android was still mostly JIT compiling, with Dalvik.
Windows Phone 8, used technology from Singularity, .NET Native apps were compiled on the cloud and what was downloaded was MDIL (Machine Dependent IL), on device only linking was performed.
Starting with Windows 10, everything was done on cloud and you got a binary targeted to device.
Android had to go through AOT compiler in version 5, 6, reintroduction of JIT with AOT on idle on 7, staring of PGO data across devices on 8, until it got into a similar kind of performance.
And to this day, NDK sucks compared with Windows Phone 8 C++/CX experience.
Windows 8 Inbox apps a lot of them where WinJS actually. But on Windows 8 even web tech was fine (speed-wise).
And WP 8.0 < didn't offer AOT for .NET apps. AoT only came as experimental on WP 8.1 with WinRT apps if I recall right. And on W10 and W10 Mobile, it comes as default for all UWP .NET apps.
I think android apps bundle pretty heavy batteries, so it's like Electron, but in java, windows can make it faster by just pushing the GUI into the system as it always did.
>WinUI 3 is currently measurably slower than both WPF and UWP. WPF is 20+ years old and even it is not native!!!.
It is similar everywhere, they put out figures, like Teams rewritten from Electron to using native browser or something. claims to have 50% speed up. But 50% of what?
We used to have bundler on web and many vocals devs were suggesting 10 min was fast enough. Atom was fast enough, Electron was fast enough. Node.js was fast enough. It wasn't until things like Zed, ( or some other editor before that ), Bun and other Bundler showing them they were 10 - 50x slower before people realise.
WinRT is the Windows team final response to Longhorn, but lets do it with COM and C++, which started in Vista.
This is why all major new APIs since Vista are COM based.
So you get an UI framework with reference counting all over the place, and application identity, which is a kind of sandboxing, for the capabilities like in mobile OSes or macOS.
On the UWP subsystem, you get .NET Native and C++/CX, whose runtimes are WinRT aware and can elide those RC calls.
Whereas using WinRT on Win32, means regular .NET and C++, via interop frameworks CsWinRT and C++/WinRT, plain libraries.
So there is no elision, it is AddRef/Release all over the place.
Reference counting is a virtual function call + an integer operation. It doesn't happen that often either because objects in UI frameworks are very long lived. C++'s shared_ptr, Rust's Rc, and Swift, don't typically cause performance problems either.
I'm not disagreeing, but I will point out that COM reference counting is an atomic integer operation. That's expensive. boost::local_shared_ptr exists because std::shared_ptr does sometimes cause performance problems. std::shared_ptr must be used sparingly. It's unlikely to matter in a UI scenario with long-lived objects because it, indeed, does use reference counting sparingly.
Of course they cause problems as well, you not believing it doesn't change profiler facts.
I can also easily point you on CppCon, C++Now and WWDC talks, where presenters spend valuable time of their lifes speaking about matters you don't believe.
Of course you were it predates all the way back to OLE in Windows 3.x, but not the extent it is pervasive in modern Windows past Vista.
After Longhorn's failure, Windows team vouched to replicate all the .NET based ideas for Longhorn, as COM in Vista, followed by the Hilo code sample in Windows 7, how modern Windows applications should look like.
Best quote from Hilo, to show how Windows team sees .NET,
> So overall C++ is a good choice for writing Windows 7-based applications. It has the correct balance of the raw power and flexibility of C, and the sophisticated language features of C#. C++ as a compiled language produces executable code that is as close to the Windows API as is possible and, indeed, the C++ compiler optimizer will make the code as efficient as possible. The C++ compiler has many of options to allow the developer to choose the best optimization, and Microsoft’s C++ compiler is one the best ways to produce small, fast code.
WinRT was the next step, coming back to the ideas that predated .NET as the COM evolution, before Microsoft got distracted with J++ and the project pivoted.
MinWin was the response to Longhorn. When most of the major goals of Longhorn failed to ship and those that did resulted in Vista, Microsoft did a reset. The MinWin project was a massive cleanup effort that promoted cleaner API boundaries and layer separation that defined a minimal bootable NT core at the bottom with reduced overall dependencies.
WinRT was introduced as an alternative API/runtime layer alongside Win32. Both WinRT and Win32 used COM concepts and ran ontop of the NT executive. WinRT was a modern async first object oriented natively sandboxed capability-based runtime that supported built-in projections over manual COM.
Microsoft tried to encourage everyone to adopt WinRT and the new sandboxed App Model on Windows 8, Windows RT, and Windows Phone. It used modern concepts and was more secure than the uncontrolled legacy surface area that Win32 exposed. They shipped those devices with Metro, a new "desktop" interface and didn't allow Win32 Apps. Unfortunately they shot themselves in the foot by shipping full Win32 based Office on Windows RT. This demonstrated that yes Win32 could run on ARM. After that, things fell apart and Microsoft decoupled many WinRT features from the WinRT/UWP model.
WinUI is an interesting UI framework that sits on top of this stack and is decoupled from it. This allows it to be updated independent of the operating system.
The “Apps” app is so bad on macOS too (seems built off of Spotlight?). I’ll type the exact app name and it’ll suggest the one on my phone, an installer in Downloads, etc..
Someone has realized the search results are insane, as there's at least one obvious fix buried in settings:
I open Finder, click on Applications, search "Google Chrome". Top results? MarketingAnalytics.yaml, aria-proptypes.md, and so on, from some project I cloned off of Github into my home directory at some point. I guess the file contents include "Google Chrome"?
Clearly insane, but under the "Advanced" finder settings, it's easy to find "Search the Current Folder". Suddenly, you get the result you'd expect.
I had to use MacOS recently and wasn't impressed by Finder. I am convinced that the best file manager on the market bar none is Dolphin from KDE software suite.
Agreed. KDE apps are slowly getting feature parity between crossplatform builds, Kate's nearly there but Dolphin is still missing some features on macOS.
Hope there's a day I can just use Dolphin on any system
I've turned into a bit of a data hoarder lately, I have a folder with over 43k images. Finder and File Explorer both struggle to even open the folder and load all the thumbnails, but XnView MP can load the folder without much issues.
It's a shame the system file managers feel so ignored, I would love to manage collections of files and folders rather than putting all my data into dedicated black holes with better viewing features such as Raindrop.io, Apple Photos, and Eagle 4.
If you're keeping them in just one directory on a drive I think you might run into filesystem limitations because it's just too many files in one directory, you'll have the same issue on Windows and Linux too. You potentially need to look into directory sharding, splitting it up a bit :)
Explorer.exe is far slower. It was one of the reasons I switched to macos after being a hardcore microsoft fan for many years. explorer would be so slow with fodlers that has a large number of files it would darastically impede my workflow. Macos is far superior IMO than windows when it comes to daily use efficiency.
I decided to tryout W11 in vm to see how it works in comparison to W10 and damn, current Explorer not only is slow but feels like taped together with at least 3 different UIs.
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
I'm stilll shocked that we're reinventining the wheel of things that were solved 20+ years ago, like UIs, and somehow making them massively more resource intensive
It's tempting to look at it that way; but that's being over-reductive. UIs of today are not the UIs of 20 years ago. Users expect much more from today's UIs, and UI toolkits necessarily get more complex as a result in order to deliver on those increased expectations.
And if you don't agree, this is Windows we're talking about. Nothing's stopping you from creating your application with Win32 except for the fact that it's going to look and feel like an application from 20+ years ago.
What do they expect that WinUI provides that classic WinAPI UIs don't?
This is not a rhetorical question. I do see some things, like antialiased drawing, etc (GDI is outdated, but I'm not convinced newer drawing could not be added.) But in general the classic ones work, including with accessibility, and are highly functional and batle-tested.
This is funny. You know, users also want games to be ridden of DRM but I don’t think the big companies cared about that for a long time. Users also want a lot of things that they never got, like a visible scroll bar sometimes.
And since Windows is primarily OEM or enterprise, I don’t know what users are going to do if Microsoft sticks to say Windows 7 UI? Like, uninstalling Windows and switching to Linux? Oh yeah, they are doing that right now.
Sure users want A or B, but that’s not important. What’s important is some idiot VP saw something and decided to push on, and other managers jumped in to grab the pie.
20 years ago was 2006. Back in those days the vast majority of UI paradigms have already been explored for decades and the standard window pane UI has existed since the 80s. The biggest difference between back then and today is the eye candy and the fact that browser based UIs took over.
Do they really though? I understand wanting to be able to use a common layout between mobile and PC devices, but even when you factor those things in there's no reason that we should've gone from something snappy at a few 100MHz to sluggish on multicore GHz processors
> it's going to look and feel like an application from 20+ years ago.
This is simply not true. You can built completely modern apps in WPF if you want. There is nothing about the framework that says your app is going to look 'old' except if you are just using default styles, and if that's the metric here then... we got bigger problems.
.. and get much less. Especially in accessibility. We've lost things like ubiquitous accelerator keys and even basics like "being able to tell where the edges of controls are or which is the active window".
The only real advantage WinUI has over WinForms is "responsive" resizing and display scaling.
The user experience of WinUI 3 isn't the worst I've seen but the developer experience is absolutely awful. I tried to make a simple app with it and the number of hacks I needed to get it to look and feel the way I almost wanted was horrible. And the documentation sucks. I had to read the system level implementations of controls in order to figure most of it out. It's great those implementations are available to read, at least, but OH MY GOD
Also seeing stuff like text fields re-implemented from scratch in XML scares me. I don't like to see that.
WinRT was great, back when using it via .NET Native and C++/CX.
It was like Delphi and C++ Builder kind of experience, then they killed the whole experience.
Rust with windows-rs is hardly any better, and coming from the same folks that killed C++/CX, with false promises at CppCon 2017, I don't have great hopes for it. They will jump ship again after a new shiny.
Speaking of Delphi - they should just buy Embarcadero and make Delphi and CppBuilder available for small money. That way they might get more and better apps for their platform again.
The thing is, at least compiled programming languages are statically typed. XAML is... well I don't think they even have a language server for it. My experience in Visual Studio (non-Code) was pretty bad.
At the end of the day, they find a way to get rid of you if you don’t, even if the VP would endorse your efforts. I understand what you’re saying and hope you understand why it happens, it took me years, and pain.
I mean… that’s kind of the goal really. If you are a leader, you want the people under you to go along with your priorities. That’s a feature, not irony.
I think another way to get to the same effect is to say “A company needs good leaders”.
Out of sheer curiosity I gave it a quick "search" how one goes from client code instrumenting WinUI to then pixels appearing on the screen, and it seems like quite the indirection-ridden and generalized journey, which I fundamentally can't imagine being particularly cheap. Maybe it's just my unfamiliarity with this world though, never wrote a graphics application end-to-end (i.e. rasterization included) on my own.
Will any of this translate to Windows programs like File Manager? Whatever their Image viewer is even called? For some ungodly reason, on my last remaining Windows Device, which is a Surface Book 2 (a Microsoft made laptop!) with very vanilla configurations, everything slows to a crawl in the file manager and if I try to view images on a directory and do the "right arrow" for next or "left arrow" key for previous. It baffles me how something that never had so much slowness can be completely FUBAR'd I miss when Windows had standard apps that were very optimal and didn't slow and ruin my experience. I find myself opening that laptop less and less, and one of these days I might just slap Linux over it.
>Please don't comment on whether someone read an article. "Did you even read the article? It mentions that" can be shortened to "The article mentions that".
I always laugh when some inexperienced developer, or an academic who has never built software for real customers, claims that “performance doesn’t matter.”
I spend a significant amount of time improving performance for our paying customers because performance absolutely matters to them. They might use a single simple feature hundreds of times during a normal workday. When we make that experience even 10% faster or smoother, they notice immediately and are genuinely delighted by it. That creates an enormous amount of goodwill.
And sometimes we can go even further and completely automate tedious workflows they hate doing manually. That’s even more valuable.
Developers with experience from the games industry understand this instinctively. Even when the software has nothing to do with games, they tend to have a deep appreciation for responsiveness, efficiency, and user experience. That’s why I’m always excited to hire people with that background.
When we worked on a SaaS HR platform, simplicity of use and the speed of getting an actual result from a workflow were some of the biggest contract renewal factors.
Even relatively small improvements strongly changed how customers perceived the product.
A lot of developers still underestimate how much “fast and simple” translates into trust, reliability, and user experience.
Is there any reason I would use this over something cross-platform like EGUI? I am kind of over software being OS-specific; this is one of the biggest compatibility mistakes we've made. Along with the related process of making drawing pixels on a display a complicated process!
WinUI made sense when windows actually had a proper design guideline, and touch was also the focus. So using WinUI was just easier as the controls were all following the guidelines, and if you wanted to offer a native experience, that was the best choice.
But it's been long gone that time where Windows had a minimum cohesive guideline.
Even if I wanted a Windows-specific UI, I still wouldn't choose WinUI 3. You can ignore it.
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.
I agree. If the OS vendors want application developers to target their native UI framework, they have to put in that work to make it seamless. As of right now, every OS vendor has an incentive to make their UI toolkits incompatible with each other to ensure vendor lock-in.
I too don't want to write OS-specific stuff, but here's some counter arguments.
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.
Yeah I remember doing that in one project. And then at least I found c++ and ATL back when it came out. I never went back to doing COM in C after that.
Painful. A lot of the Microsoft interfaces these days are asynchronous and are built around the dev experience of c#/c++ with libraries/runtimes that do a lot of the heavy lifting. So you end up calling functions with ridiculously long names and they aren't like good old win32 calls where you pass in some parameters and you get a result back. Instead you create objects to pass function pointers and data around and who knows when you'll get your result values back.
It won't happen, already on UWP you had to avoid specific F# code idioms that could generate MSIL that the .NET Native compiler wasn't happy with.
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 user experience is the way it is because they want it to be. This is at best optimizing one small component which as we all know can be done infinitely well and still have a negligible effect on the use of the system.
Don't worry, once enough people come back, they'll roll back in the ads and the intrusive performance-killing features and the cycle will repeat all over again
A fundamental problem with this is that "8" is two different releases (8.0 and 8.1), "10" is about 9 different releases, and "11" is three different releases so far (21H2, 22H2, and 24H2). It doesn't make much sense to lump all of them together because they share the same marketing name; technically there's no difference between going from 8.0 to 8.1 or from 22H2 to 24H2 and going from Vista to 7 or 10 20H1 to 11 21H2
10 was bad 11 is a little better but no enough.
With win10 they started with more annoying ads and the start menu with apps and the click bait news in the start menu
It was, eventually. In the beginning 10 was literally just Windows 8.1 (it even ran the same NT6 kernel) but with the classic UI slapped back on. They called it 10 to get away from the Windows 8 branding that everyone hated.
I recall it being pretty mediocre at release, just a reskinned 8.1. 10 started to come into its own much later after NT10
Aside from the start menu no, not really. Windows 8 is the most performant operating system. No laggy animations (thanks to DirectUI), fast boot time, especially fast on older systems. Windows 10 started the whole lagfest.
Windows 8 was ultra stable. I've seen uptime well over multiple years on it. The original UX was beyond awful and 8.1 made it ok but the core of the OS was solid.
I mean, apart from killing the start button and all the touch first applications, windows 8 felt really satisfying to me by eliminating transparency effects and having simpler, clearer window decorations. I hate the transparency effects in windows 7, and performance was improved in Win 8.
Maybe Windows 12 will be the promised "last Windows" which 10 was supposed to be.
I'd love to know the exec who ordered Windows 11. It stinks of "I need a product on my resume that I launched because being Windows 10 "maintainer" sounds so pathetic on a resume."
Anyone who tried to do serious native windows dev has been burnt so often by Microsoft. I really wanted to give them the benefit of the doubt with WinUI 3 but I really cannot anymore. Until proven otherwise I expect absolutely nothing to improve meaningfully. It’s extremely sad for those of us who were dumb enough to think Microsoft take on modern GUI would be interesting to follow closely, we are in 2026 and WPF is still the way to go IMHO.
What kind of thing do you write? I'm still amazed at how much functionality is packed into tiny binaries like the sysinternals tools, and depressed at how acceptable 50MB todo apps have become.
Why limit yourself to Microsoft's offerings? They've dropped the ball on all of their UI frameworks I don't see why anyone would trust them to build software on. Give it a few more years and MAUI will join the list of abandoned UI frameworks and another one will pop up
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.
Older stuff is generally faster because it had to be built in a more resource poor time. Maybe the WinUI devs should be forced to work on systems with the Minimum System Requirements. Heck, maybe all Microsoft development should be done like that, so that some focus on performance is there from the start, instead of as an afterthought.