> 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.
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.
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’d argue they started doing that a bit earlier. My hard drive from 2011 made using Windows a miserable experience any time the search indexing or windows defender scans kicked on, no later than 2016-2017.
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.
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.
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.
I don’t believe it’s Limiting factor in UI frameworks. I’ve profiled a lot of c++ and a lot of UI code. UI problems tend to come from too much churn and object creation, or doing too much work in the UI thread so it gets laggy, not just doing some reference counting.
While I agree that shared pointer are problematic (I almost never use them in C++), I don't think they're ever really the reason for performance issues in GUI apps. I've been doing GUI programming for more than a decade now and the overwhelming majority GUI performance issues come down to issues like poor use of concurrency (blocking GUI thread), unoptimised algorithms (e.g. for layouts), overdrawing, GPU/CPU sync issues or inefficient input handling.
I have never encountered a performance issue that was to due to reference counting (in fact I'm a big user of the CoW idiom when it comes to UI).
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 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.
>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.
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
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.
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 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.
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.
.. 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.
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.
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
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”.
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.
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.
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!
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 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.
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.
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".
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.
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.
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.
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 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.
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.
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
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
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.
"aside from the start menu" is one hell of a caveat. When you screw up one of the main UI elements as badly as they did, it really drags the whole experience down.
Well most people just press the Windows key and type to open a program which works exactly the same on Win8. And personally I loved the start screen. And how often do you really need the start menu?
That's the most brain dead take I've seen in a while. Yes, forget about start menu and lets just search everything or use giant pictorials designed for 'blind' people.
exactly! I don't understand why people hated it so much.
It was snappy, clean OS. I've always thought it was better than Win7.
Of course, absent of start menu was terrible choice. And I meant 8.1, not 8.
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
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.
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
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."
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.
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.
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
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.
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.
> 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.
If I recall right, Windows 8 and Windows Phone 7/8 during the 2010's were all developed on low end devices.
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...
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.
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.
> UX of 8 and 8.1 was awful
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.
[0]: https://news.ycombinator.com/item?id=45743066
It’s after the 2019 release, they started optimising for ssds.
I’d argue they started doing that a bit earlier. My hard drive from 2011 made using Windows a miserable experience any time the search indexing or windows defender scans kicked on, no later than 2016-2017.
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.
It is quite easy to know why.
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.
I don't believe it.
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.
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.
Can I see the profiler data that shows AddRef/Release being a performance bottleneck?
Yes, learn to use one and point it to a C++ Github project full of shared pointers.
I don’t believe it’s Limiting factor in UI frameworks. I’ve profiled a lot of c++ and a lot of UI code. UI problems tend to come from too much churn and object creation, or doing too much work in the UI thread so it gets laggy, not just doing some reference counting.
embarrassing
While I agree that shared pointer are problematic (I almost never use them in C++), I don't think they're ever really the reason for performance issues in GUI apps. I've been doing GUI programming for more than a decade now and the overwhelming majority GUI performance issues come down to issues like poor use of concurrency (blocking GUI thread), unoptimised algorithms (e.g. for layouts), overdrawing, GPU/CPU sync issues or inefficient input handling.
I have never encountered a performance issue that was to due to reference counting (in fact I'm a big user of the CoW idiom when it comes to UI).
For that matter, AppKit was first released on a NeXT with a 25 MHz 68030 and 8MB of RAM.
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.
> WinRT is the Windows team final response to Longhorn, but lets do it with COM and C++, which started in Vista.
Not sure what you mean, I was using COM and C++ for Windows development in the late 90s.
> So there is no elision, it is AddRef/Release all over the place.
...and constructing an object is an insanely complex (and expensive) operation.
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.
https://learn.microsoft.com/en-us/previous-versions/msdn10/f...
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.
https://arstechnica.com/features/2012/10/windows-8-and-winrt...
https://web.archive.org/web/20190111203733/https://blogs.msd...
Eh... not exactly.
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.
>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.
I run macOS every day, and while I find Apple Silicon shockingly fast - I'm surprised at how shockingly slow Finder seems to be.
This might be off topic, but wish Apple would focused on Finder performance (app loading, window refresh, etc) like this blog post by Microsoft.
And in case you're curious, my disk is only using 250GB in use (50GB for Apps, 150GB for System Data, 50GB for macOS)
macos itself is sluggish af
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.
Well, they could have had BeOS instead of NeXTStep.
Jobs would have been lost with that move...
I am skeptical.
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..
No one dog-fooded that thing.
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.
It’s incredible that “Search the Current Folder” is not the default, nor, as far as I’m aware, can it be made the default.
> nor, as far as I’m aware, can it be made the default
Huh? You absolutely can, the post you're replying to says as much.
Spotlight search is completely broken.
If I type "sa" the first result is Safari but if I type "safa" I get "Adguard for Safari.app".
In what world does this make sense?
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.
explorer opens instantly on my windows desktop. i cannot replicate this on any mac.
I switched to xplorer2 about twenty years ago and never looked back
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.
Finder is one of the worst pieces of software I've used and I have no confidence in Apple ever fixing it, or even being able to in theory.
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.
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.
> Users expect much more from today's UIs
.. 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.
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.
> Users expect much more from today's UI
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.
> Users expect much more from today's UIs
Are these users in the room with us. If anything, today's UIs are dumbed down, mobile first abominations.
> much more
Specifically?
> look and feel
Oh right so.
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
I have BEEN WAITING FOR the calculator (calc.exe) to launch in Windows 11. In my view Microsoft (again) lost its way with 11.
Ironic how in supposedly tech company nobody gives a shit about doing great technical work unless it aligns with some VPs goals.
A company is a company. For some weird reason techies used to think that they were special, but that time came to an end
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”.
Not ironic at all. VP didn't become VP by doing great technical work. They made the VP before them look nice.
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.
Capitalism cannot produce good software, just like it cannot produce good art, or children.
I seriously hope Microsoft consolidates all their Windows app dev on WinUI and invests heavily in making it great.
I also wish that they’d make WinUI work on macOS as well similar to Avalonia, but I think they probably won’t.
There's now an Avalonia back-end for .NET MAUI in preview, so they are making an effort on that cross-platform front too. Link: https://avaloniaui.net/blog/maui-avalonia-preview-1
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.
Windows can now load 2x Ads 100% quicker!
As someone who builds desktop apps:
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!
Not really. At least not directly.
But it is used to implement various parts of Windows, such as the File Explorer, so any improvements are helpful for general system performance.
Support for accessibility.
egui might not be great for it, but Slint and Iced have decent accessibility support (via AccessKit).
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.
Win32 is absolutely the best GUI system, you get the most clean, performant and easy-to-use results.
I wish Microsoft just sticked to Win32 instead of reinventing the wheel with worse solutions.
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.
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.
Well, from egui's own page:
> If you want a GUI that looks native, egui is not for you. If you want something that doesn't break when you upgrade it, egui isn't for you (yet).
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.
> Will any of this translate to Windows programs like File Manager?
Did you not read the thread? That's literally stated as an explicit goal.
>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".
https://news.ycombinator.com/newsguidelines.html
Ok fair enough, thanks for letting me know.
The photos app also uses webview so yes hopefully
Nice to see. I wonder how feasible it would be to build a plain C interface… would be nice for building bindings to other languages.
It will need a flashy name, "WinAPI" or something. Just a suggestion
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.
If you enjoy calling COM vtables, and doing the reference counting by hand, by all means.
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.
And better not touch C++/WinRT, it makes that experience a few notches up.
WinRT isn't the most awful in the world to use from, say, Rust because there are auto-generated bindings, but I agree that C++ can be awful.
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.
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.
Because the idea is to use the designer, not write it by hand.
Well, until they killed the designer for WinUI 3.0, yet another flaw they don't talk about.
At least still around for Forms, WPF.
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.
WinUI apps are unbearably laggy when you resize them.
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.
How about F# support? Until then, happy to support Avalonia.
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.
Wow, they are actually starting to care about quality. Color me surprised.
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
Microsoft has long had a tick tock cycle for Windows.
98: great. ME: bad. XP: great. Vista: bad. 7: great. 8: bad. 10: great. 11: bad
Maybe “great” is going a bit far for some of those. “Not bad” vs “bad” seems more realistic.
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
still leaps better than windows 8
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.
"aside from the start menu" is one hell of a caveat. When you screw up one of the main UI elements as badly as they did, it really drags the whole experience down.
Well most people just press the Windows key and type to open a program which works exactly the same on Win8. And personally I loved the start screen. And how often do you really need the start menu?
That's the most brain dead take I've seen in a while. Yes, forget about start menu and lets just search everything or use giant pictorials designed for 'blind' people.
Not what I said.
exactly! I don't understand why people hated it so much. It was snappy, clean OS. I've always thought it was better than Win7. Of course, absent of start menu was terrible choice. And I meant 8.1, not 8.
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
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.
Idk, I literally skipped Windows 8.
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
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."
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.
You can always really on the MBAs
I can't downvote this comment, because I've observed exactly this practice happen, again and again, over the past three decades.
I still remain naively hopeful and cheer them on, however.
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.
> we are in 2026 and WPF is still the way to go IMHO.
Why not Avalonia? It's not Microsoft but it is a spiritual successor to WPF, cross-platform, and open source.
Sure, Avalonia is fine. I meant specifically Microsoft offering
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
I was specifically talking about my frustration with Microsoft. MAUI was indeed pretty much on arrival, what a waste of the Xamarin name…
That's the one I use now. But it still feels laggy to me.
Yep, it's 2026 and I'm still 8 hours a day in win32.
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.
May I ask what kind of work you do at what sounds like a dream job to me?
Their recent post about explorer performance was “we raise clocks when you launch explorer” rather than an actual fix
Nah, mostly marketing.
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.
"We need a new standard!" :p
Not sure how much will this idea fly in today's time. I would love to be proven wrong though.