At the end of the day, they find a way to get rid of you if you don’t. I understand what you’re saying and hope you understand why it happens, it took me years and years and much 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”.
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..
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
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.
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 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.
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 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.
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
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.
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.
"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.
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.
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.
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. I understand what you’re saying and hope you understand why it happens, it took me years and years and much pain.
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”.
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)
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.
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.
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!
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.
Support for accessibility.
egui might not be great for it, but Slint and Iced have decent accessibility support (via AccessKit).
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.
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.
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.
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.
If you enjoy calling COM vtables, and doing the reference counting by hand, by all means.
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.
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
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.
Not sure how much will this idea fly in today's time. I would love to be proven wrong though.
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.
Wow, they are actually starting to care about quality. Color me surprised.
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.
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
You can always really on the MBAs
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.
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
still leaps better than windows 8
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.
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.
"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.
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
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