You're absolutely right that the issue is the coordination cost. It's not about the number of resources but just the fact that you need those resources to coordinate, slowing everything down.
Not a problem in waterfall, since you can set the targets beforehand and just have the teams work in parallel. In an "Agile" setting though (not the manifesto version, the current practice version)? It's a huge mess.
So then the question becomes, is this coordination cost worth it and how much are we willing to "spend". It seems the cost is worth it for Android and iOS since the native app experience on those platforms is so much better.
The macOS app is just a tweaked iOS app so it's also easy to justify.
But what about Windows? The Microsoft provided APIs are a disaster that keeps getting rewritten every half decade, and even Microsoft barely uses them. Windows users don't have a "feel" for a native app the way macOS and mobile users do, since there hasn't been a "native app experience" on Windows for a very long time.
Just look at the 2 context menus on Windows Explorer, they can't even get the sizes and colors between them right.
Meta would have been better off doing like Telegram and just using Qt.
> Microsoft provided APIs are a disaster that keeps getting rewritten every half decade
What a wrong and misleading statement.
Not they aren't. Otherwise Winamp 2.95 from 2003 wouldn't flawlessly work on my Windows 11 install 23 years later. Same with my Unreal Tournament 99 installation that I just copied over via a CD left from my Windows 98 PC.
As long as you haven't used any undocumented APIs or made your app hack its way into the OS via hooks like some games did back then for performance optimizations or some anti-piracy SW did, then most Windows apps from over 20+ years ago will still work today and it's also why WINE works so well to get Windows app working on Linux, is precisely because Microsoft HASN'T changed the APIs.
They're half-right. Microsoft do keep supporting the OS APIs, but it's the UI frameworks that get half-assed and abandoned. Which is why so many people recommend Avalonia these days. Microsoft don't even reliably use their own frameworks - go through Win11 and see how many Windows Forms dialogs are still present in things like settings and Explorer.
(WinUI is also a hybrid: since it uses the DirectX APIs rather than the old GDI model, most of it is in a userspace package that's delivered as an .appx)
Of course it does, those APIs don't work well together. It's a pain in the ass to use the features only available in the new APIs on old applications. Microsoft has put some effort into making it work but it's still hugely hit and miss. You can mix WPF and WinUI2, but not WinUI3.
Amazing. I thought they fixed that years ago with "XAML islands", but apparently [1] they un-fixed it again with WinUI 3 and still haven't re-fixed it?
Yup, though I wouldn't even say they "fixed it" with XAML islands since they lock you into .NET core 3...
They also keep doing boneheaded decisions like the new DWriteCore, which is a reimplementation of DirectWrite, and some features are only available in DWriteCore, but DWriteCore is not a strict superset and doesn't even interoperate directly with Direct2D like DirectWrite did.
So once again, either stay on the "stable" as people like to call it version, which is effectively frozen, or use the new one and rewrite half you app!
And then people wonder why nobody uses Microsoft APIs if they can avoid it.
It doesn't directly, but the fact that these old APIs are abandoned still matters. It's not like you'll get bug fixes for Win32 (non-CVE) issues, it's just that it will keep working as is.
You can't get a competitive UX by using Win32, even basics like resizable windows and proper hidpi support is missing. And the number of people who know this API is probably sub-1% these days. There are dozens of us left, dozens!
It's not wrong nor misleading at all. Win32 doesn't even support dark mode properly because it's effectively "deprecated" like all the others in the graveyard.
Who cares if they keep working if the only way to get dark mode is to custom render the whole UI yourself? Might as well do something non-native at that point.
Microsoft does not provide a serious UI library for applications to use. It provides 10 half broken and deprecated ones.
>if the only way to get dark mode is to custom render the whole UI yourself
Most the apps I use support dark mode: Chrome, FF, Notepad++, Jellyfin, Qbittorrent, SumatraPDF, Signal, Wiztree, WinSCP, and others I'm forgetting. Seems like it's not an impossible task for the developers.
And on Github you can find FOSS apps[1] that have implemented light/dark mode switching for their UI, so you can just copy what they're doing if you don't know where to start.
Are you speaking as a user? I'm speaking as a dev. Of the applications you mentioned only a couple actually use the Win32 controls (like Notepad++) and they custom render them to get dark mode. That's a lot of extra work they had to do, essentially draw the whole look themselves.
Chrome is not native. FF is not native. Qbitorrent is not native (it uses Qt, right there in the name). Signal is not native, it's a web page bundled with Chromium (aka, an Electron app). WinSCP only this year actually started using the right font! But at least that one is native I'll give you that.
The GitHub you sent doesn't really have anything to do with the discussion.
> Win32 doesn't even support dark mode properly because it's effectively "deprecated" like all the others in the graveyard.
Remember when you used to be able to make custom Windows color schemes? Where you could color each widget type independently? I miss that.
Assuming that your report is true, if Microsoft gave a shit, they'd come up with four color schemes (high-contrast light/dark mode and regular-contrast light/dark mode) for Win32 programs and sync them with the relevant "modern" settings. Alas.
What do you do if you're a Win32 program who refuses to use the system color scheme? Well, I guess you'll stand out no less than you would have been in the Windows 95/98/ME days... stubbornly refusing to conform to the user's commanded colors and all that.
I like to joke that we already had dark mode on Window 95. It didn't work super well with black colored icons but you could always just tone down how dark you made it.
We also had pseudo-dark mode themes for Windows XP. But the new dark mode stuff in explorer doesn't use uxtheme anymore.
> I like to joke that we already had dark mode on Window 95.
When I say it, it's not a joke! :D
> But the new dark mode stuff in explorer doesn't use uxtheme anymore.
I'm only familiar with Windows 10, and in that version Windows Explorer seemed to conform to the system color scheme just fine. Did Microsoft break that at some point in the past three, four months, [0] or did they royally fuck the dog in Windows 11?
For me, the *maddening* color-scheme-nonconformance was Task Manager. No matter what I did, it was *white*. It made it substantially unpleasant when you wanted to check a performance something-or-other in a dark room.
[0] Ever since I learned just how well video games work on Linux (via Steam), I've not booted into Windows. It's so nice. Folks report that there are launchers to run games in the Epic Game Store, but I've not yet bothered, so I can't provide first-hand info.
Windows Explorer still respects the color-scheme preference but the problem is the way it does it.
When you as a dev use a Windows provided control (be it a button, a toolbar, a context menu, etc.) the system grabs the theme information from something called uxtheme. This is how it worked in Windows XP and why you had like 3 different themes you could pick from and switch between at any time, and most apps would respect the selection.
But dark mode doesn't work like that, there's no uxtheme for dark mode. Windows Explorer is given special treatment by Windows with undocumented APIs. Other apps are not so lucky. If they want dark mode, they need to effectively draw the whole UI themselves. Even apps like Notepad++ have to do that these days.
> Windows Explorer is given special treatment by Windows with undocumented APIs.
Microsoft: "We offer GREAT backwards compatibility! The best in the business!"
Also Microsoft: "Man, doing things the old way is so hard. What if we had a clean break with the past?!?!"
Microsoft, some time later: "Man, making a clean break from the past is so hard. Let's just ship what we've done so far and think about finishing up the rest later. What? Windows Explorer is broken, and you refuse to let us ship!? *Fine*, we'll hack something in and not tell anyone."
I think few people are using the Win32 APIs directly and Microsoft has been shifting their stuff a bunch.
WPF (Windows Presentation Foundation ) had been the recommendation a while back, but then Microsoft started pushing UWP (Universal Windows Platform). Both of those have been succeeded by WinUI 3. UWP has been deprecated. WPF is alive, but more in a maintenance mode while WinUI 3 takes over the future. Oh, and WinForms were popular, but now not.
There's definitely been a lot of shifting and I think that's caused a lot of annoyance in the developer community - especially as Microsoft ships JS/WebView2 based apps instead of dogfooding their own stuff. If you hang out in the dotnet subreddit enough, you'll definitely see Windows devs annoyed at Microsoft's mercurial attitude toward their desktop frameworks and seeming lack of direction/interest - as their big new things are JS/WebView2.
They are talking about UI. Winforms (abandoned), WPF (abandoned), UWP (abandoned), MAUI.
Windows itself was always using their own custom stuff and not any of those. The closest thing to an established framework in Windows is react native that is sprinkled here and there. And QT that OneDrive uses
> Meta would have been better off doing like Telegram and just using Qt.
Qt would certainly be the better choice. However, since Meta already has a web version of the WhatsApp client, the WebView2 path was an easy and inexpensive option. After all, MS itself paved the way with Teams, Visual Studio Code, and Outlook.
Not a problem in waterfall, since you can set the targets beforehand and just have the teams work in parallel. In an "Agile" setting though (not the manifesto version, the current practice version)? It's a huge mess.
So then the question becomes, is this coordination cost worth it and how much are we willing to "spend". It seems the cost is worth it for Android and iOS since the native app experience on those platforms is so much better.
The macOS app is just a tweaked iOS app so it's also easy to justify.
But what about Windows? The Microsoft provided APIs are a disaster that keeps getting rewritten every half decade, and even Microsoft barely uses them. Windows users don't have a "feel" for a native app the way macOS and mobile users do, since there hasn't been a "native app experience" on Windows for a very long time.
Just look at the 2 context menus on Windows Explorer, they can't even get the sizes and colors between them right.
Meta would have been better off doing like Telegram and just using Qt.