They are both mentioned in the article. But I appreciate the extra experience and details, beyond what I got from browsing their landing pages and GitHub repos.
A lot of people complain about this, but there seemed to be a reasonable XAML designer when I was making my WinUI 3 app. I didn't really use it (my app was simple enough that hand-crafting the XAML felt worthwhile to ensure everything was nicely aligned and not full of any unnecessary designer gunk). So I suspect it does suck, since otherwise people would not complain as much. But one does exist.
From what I understand, Win32/MFC/WinForms inherently are stuck around Vista visuals, with no dark mode support. Win32/MFC also have no high-DPI support, so you get gross upscaling. (WinForms supposedly has some support for high DPI, but with many open issues. [1])
Now, I'm not 100% sure, since there are so many commenters in this thread saying "just use Win32/MFC like a real man". (Most of them ignoring the memory safety angle.) I might do a follow-up asking Claude to reproduce my UI in the various frameworks to test. But my strong guess is that we just have a bunch of HackerNews curmudgeons who are happy to foist pixelated Vista-era light-mode-only UIs on their users.
"Dark mode
Windows Forms has fully integrated dark mode support.
Windows Forms for .NET 9 introduced preliminary dark mode visual styling, but in an opt-in preview mode where you had to suppress Compiler Error WFO5001 to use the feature. This feature is no longer guarded behind this compiler error starting with .NET 10.
The Application.SetColorMode(SystemColorMode) API is no longer considered experimental."
I think that would be a great article! For your specific app, I can see how the "super modern" sparse UI fits nicely, since the controls are nice and simple. However, for a more involved app knowing what possibilities there are to get the Windows 10 look would be nice.
Id be interested in a source for both this and the parent's comment. How do we know which settings pages use which tech? Have people been decompiling them?
I was actually part of a team at Barnes & Noble.com which tried to use WinJS for a serious application. (We were previously using Chromium Embedded Framework, or our own hand-rolled WebKit integration, for the desktop e-reader.)
Maybe I grew up with Windows so the older uis don’t phase me, but I find these sort of complaints rich considering differences between gtk, qt, etc in Linux userland. The average Windows user might stumble on an aero dialog, which is arguably less jarring in win11 than og metro.
> but I find these sort of complaints rich considering differences between gtk, qt, etc in Linux userland
I've been around long enough to remember MS and their fans banging on about how bad other OSs were for their inconsistent interfaces, so I feel justified in getting a little riled at the hypocrisy of how much of a mess UIs are in Windows these days.
And I don't see it getting any better - they'd rather spend the time finding new places to slip in adverts. And this is far from the fault of app developers, while they often do have something to answer for wrt consistency, because the worst culprit is MS themselves both in their apps and the OS.
I shouldn't have to click to make sure the right thing has focus for instance, particularly after switching from another virtual desktop, I should be able to see this information easily but there is no consistency in titlebars and other window chrome any more.
Screenshots are made on Windows 8.1 box, the windows chrome comes from there.
Plus the whole thing is meant to work on ancient Windows versions (like, Vista and WS2008 ancient), so that ultimately defines the minimal common UI denominator.
> Turning them off will cause Windows to spasm for several seconds and throw all your current window positioning out of whack.