Microsoft has completely and utterly failed at creating a stable foundation upon which GUI applications can be built. Unlike every other operating system out there, there's no such thing as a "native" Windows UI anymore (even Linux has "native" UIs for Gnome and KDE respectively). Don't bother trying, package a webapp in an Electron shell or something, that's what Microsoft does too.
Seriously, what's a "native" Windows UI these days anyway? The old Windows API stuff? Sure, the Windows API has remained impressively stable, but nobody actually uses the User32 controls anymore (Microsoft included), and with good reason! They're ugly, hard to develop with, and can't be improved without a total rewrite that would break backwards compatibility. They don't even have official dark mode support!
The lack of official dark mode support is entirely Microsoft’s fault. User32 styles could easily support a separate dark mode.
The fancy new WinUI 3? You have to bundle it with your app meaning you don't get matching styles on newer (or older) Windows versions. Great.
Windows, despite its excellent backwards compatibility track record, has utterly failed to provide a stable base for native applications UI-wise.
Microsoft has made multiple attempts at replacing the User32 controls with a more modern alternative, each attempt unfortunately ending up "deprecated" (perhaps not officially, but for all intents and purposes), all the while various Microsoft teams (like the Office team) went their own way with the internal-only DirectUI, or with web-based user interfaces.
While it appears that Microsoft might be finally eating their own dogfood with WinUI 3 on Windows 11, at least to some extent, the WinUI 3 distribution model means any non-Microsoft application developed with it will become outdated as soon as Microsoft changes their Fluent style to something else.
Why bother then? To understand how things got to this point, it's important to look at the history of the Windows user interface APIs.
The Windows XP era and MSSTYLES
During the Windows 95-2000 era, Windows applications were highly consistent, with a few exceptions that intentionally had highly stylized looks and some old 16-bit Windows apps. In fact, you were able to change the UI colors to your liking and it would affect nearly every application. Wanted your apps to have bright pink backgrounds and comic sans as a font? No problem. Dark Mode? Just make the background black and the foreground white.
This changed with Windows XP. Windows XP introduced MSSTYLES and a skinning engine, giving User32 controls a much fancier look. Colors could no longer be changed arbitrarily, instead, there were a fixed set of styles you could pick from. While custom themes were not officially supported, a vibrant theme-development community developed around MSSTYLES anyway.
However, Microsoft caught themselves in a bit of a pickle. Because the Windows API was so limited, most apps rendered some custom-drawn controls alongside the native ones, which wasn't too hard to do in the Windows 95-2000 days since the existing controls had a simple look that could be easily replicated.
With XP you could have radically different looks depending on the chosen style. To avoid breaking apps with custom controls (which was most of them), new apps had to explicitly request the new styling with a manifest file. That meant that some apps still retained the old style, while others had the new one. This by itself would not be a big issue, but remember how a lot of apps had custom-drawn controls? To update those controls to the new styling, they would need to reprogram them from scratch, and use the uxtheme
API to get the right bitmaps and sizes and such, which was a lot harder than replicating the old Windows 95 look. To make matters worse, the User32 API wasn't the most complete thing in the world, with certain Windows apps just custom-drawing most things from scratch anyway, office in particular.
Microsoft at some point realized trying to build on top of User32 was not going to work. The API was just too lousy and could not be fixed. So when microsoft introduced the second major version of Windows Forms, the .NET wrapper over the Windows API UI stuff, it included new MenuStrip and ToolStrip controls that were entirely custom rendered:
The picture above is taken from a Stack Overflow question on how to get the same gradient on the MenuStrip and on the ToolStrip, two of the new custom rendered controls. The answer is to do a custom render of course. Note that both of these controls look completely out of place on any later windows version, their styles don't update. They're styled after Office 2003, whose UI was all custom of course. The older native MenuBar and ToolBar controls were deprecated.
This move towards heavy use of custom-drawn controls completely ignoring the system theme was the nail in the coffin for a "native" Windows UI. Things were about to get a lot worse.
The Windows Vista/7 era
In the Windows Vista/7 era, Microsoft basically gave up on "native UI". Windows Explorer was a pile of non-native controls:
Even amongst Microsoft's own apps, each "commandbar" or "searchbox" you saw was a different custom control, often made using entirely different APIs!
The new preferred way to make Windows UI apps was to use .NET only Windows Presentation Foundation (WPF) (though it wasn't used by any built-in Windows app AFAIK). WPF custom rendered everything over Direct 3D, it didn't use a single User32 control or even uxtheme. It had awful performance and blurry text rendering (at the time of release), but it became very popular because of how powerful, customizable, and easy to use it was. It is still used to render the modern Visual Studio user interface, a rare case of Microsoft eating their own dog food (and Visual Studio was instrumental in getting the awful text rendering fixed).
But bad performance and unreadable text weren't the only problems with WPF. While it included an "Aero" style that was meant to mimick the native Windows API look of the time, it didn't quite look right (good job there Microsoft...). With the release of Windows 7, the Aero style was unchanged from the Vista one, making it look even worse. Everyone and their mother ended up restyling everything anyway, to the point a whole industry of custom controls and control styles got built around WPF.
What could have been a renaissance of native Windows UI turned out to be the very opposite.
If you think all of this was a mess, I haven't even mentioned the Ribbon. You see, Microsoft was really proud of the Ribbon introduced in Office 2007, so proud in fact that they patented it (despite the existence of obvious prior art, good job patent office). You had to get a special license to have a Ribbon control in your own application.
On the other hand, the Ribbon was a complicated control and Microsoft (despite the patent) really wanted people to use it. So they provided their own implementation... or implementations I should say. One for MFC, which still looks like Office 2007. One for the native Windows API, which has a whole messy XAML compilation process unlike anything else on the Windows API. And, of course, a WPF Ribbon control still stuck on the Office 2010 style that somehow broke the window frame rendering on Windows 8:
Unfortunately, this was not rock bottom. Things were about to get even worse…
The Windows 8+ era
Windows 8 of course had its own contribution to the mess: WinRT. Microsoft decided that people really wanted to use their large desktop computers as tablets for some reason, so they created an entirely separate tablet-like environment within Windows with an entirely separate UI stack. Windows 8 wasn't very well received, and nobody cared about WinRT, so the next Windows version included its own entirely new UI stack, the Universal Windows Platform (UWP). While UWP was clearly based on WinRT, it was technically a different UI! Good lord Microsoft!
While Windows 10 was better received, UWP wasn't. Not only was it quite limited, new features were released on a 6 month basis alongside Windows 10 updates. That meant that you had to limit yourself to older UWP versions if you wanted to reach customers using older versions of Windows 10 (like large enterprises). Not only that, it didn't run on Windows 7 at all, which still had a huge market share at the time.
Meanwhile the old User32 controls were barely updated, with only some of them even getting dark mode support, and there wasn't even any official API to activate their dark mode! Absolute insanity. Software like Notepad++ had to custom draw their menubars for example. Meaning even the most "native"-looking (if User32 is considered native) apps like Notepad++ are actually custom rendering a lot of their UI these days.
Recently Microsoft has been trying to salvage UWP into WinUI, untying the UI components from Windows versions. There have been 3 versions of WinUI, all incompatible with each other, and the latter is constantly getting updated.
Even Microsoft has given up. Many of their newer apps are based on Electron, effectively web pages packaged alongside Google Chrome. If you're pissed at companies for using Electron, take some time to read the above again. Look at the mess Microsoft has made for themselves, what an absolute joke:
How many times has Microsoft reinvented the (context menu) wheel? A hundred? Other operating systems have fared a lot better, but even there the UI-story should have been a lot more stable. I'll leave that topic for another time.
Save your sanity
For all its faults, the web has remained a relatively trustworthy base. While frameworks of the month come and go, websites built with HTML, CSS and Javacript from the early days of the web still work fine today. Not only that, they can be incrementally upgraded without kicking the baby out with the bathwater, and there's a huge wealth of both free and commercial UI components available. If you are building a new application, the web route is a safe option. As awful as the web may be, it gets the job done.
The "bundled Google Chrome" side of Electron is more questionable. Every OS already comes with a browser, so why not use a native window, with a native browser component, and just render a web application with that? It should give much smaller and more efficient executables since the browser component is shared.
Unfortunately Microsoft dropped the ball here as well! First with Internet Explorer severely lagging behind, followed by Edge using an entirely different API that only worked with UWP, and now Chromium-based Edge using another entirely different API. This really made the creation of an Electron alternative based on native components a tall order.
Thankfully the situation is improving with projects like Tauri, Wails, and webview, which use the native browser control on each platform. Alternatively, projects like Sciter and Ultralight have their own HTML renderers with a much smaller footprint than an entire chromium instance per application.
You can of course forget all about the web and use APIs like Qt, Avalonia, Dear ImGui, etc.
Either way, be kind to developers using Electron. Maybe direct them to less resource-intensive alternatives. Your anger should be pointed entirely towards the operating system vendors that dropped the ball so badly people went for CSS and Javacript in desperation.
I'm pretty sure CSS and Javascript are used as a form of torture by the secret services, and yet people use them willingly to get away from the insanity that are the native UI APIs. Even Apple has dropped the ball with the deprecation of Carbon and now the move to SwiftUI, while Gnome and KDE's respective "native" APIs keep breaking backwards compatibility. The only exception I can think of is Haiku which is still somehow API (and even ABI) compatible with BeOS. Now that's the sort of stability operating systems should have!