The software biz in general has a major "out with the old, in with the new" attitude, which paired with the attitude of, "We're going to build what we know, instead of learning the old stuff which is new to us".

I've seen time and again, things like apps rewritten from scratch because nobody knew C++, and they only had C# devs. Or a massive runaround because the last guy on the team who knew C++ wrote a bunch of stuff and left a couple years back, and now nobody really knew how any of that stuff worked.

> React has had tremendous success in the web world, so why not try and get those developers more comfortable producing apps for your platform?

IMO - this is worth talking about. Zune, Windows Phone, and some others died when they did not, in fact, suck, and were pretty good products which while late to the game, could have competed if there had just been a decent app ecosystem.

The decisions reg UI frameworks are largely due to internal political conflicts, mostly between DevDiv and Windows.

> the result of Ballmer's "Developers, developers, developers!" attitude

I think Microsoft’s framework chasing has been a betrayal of that philosophy. Internal divisional politics have been major drivers behind fracturing and refusing to unify the stack and its UI approach, and without clear guidance from the Office team the direction of the entire platforms UI is opaque. Short term resume and divisional wins at the expense of the whole ecosystem.

A developer centric platform would let developers easily create platform specific UIs that look modern and normal. As-is the answer to how to ‘hello world’ a windows desktop app is a five hour “well, akshully…” debate that can reasonably resolve to using Meta’s stack. “VB6 for the buttons, C++ for the hard stuff” is a short conversation, at least.

I think the reason they keep trying new UI frameworks is that no one really adopts them. Developers know that Microsoft won’t kill off backward compatibility and break all the enterprise apps, so why rewrite? When one framework fails, they start working on the next one. I question if they understand the corner they’ve painted themselves into.

I think it's more of result of "okay we made it and it works, how we now can excuse still being employed in same head-count" development. And the answer is of course "rewrite, rewrite, rewrite". UI works well, no major bugs ? TIME TO CHANGE IT TO BE "MODERN"

Operating systems should always use C/C++ UI frameworks, and as little costly abstraction as possible, period. Anything else is wasting resources.

Changing UI framework all the times is fine, so is not changing anything for decades. Different strategies that both have value. Reasonably you want to be somewhere in the middle, depending on the use case. In an industrial setting, production infrastructure, etc... you generally want to change as little as possible "if it isn't broken, don't fix it". On emerging, consumer-facing technology such as mobile in the 2000s, "move fast and break things" makes sense.

But anyways, it is not the problem. The problem is just that Microsoft today is doing a terrible job.

The best example, I think, is the control panel. Starting from Windows 8, they changed it. Ok fine, you may like it or hate it, but to be honest, it is not a big deal. The problem is that they never finished their job, more than a decade later! Not all options are available in the new UI, so sometimes the old control panel pops up in a completely different style with many overlaps in features. And every now and then, they shuffle things around in hope that one day, the old control panel won't be needed anymore.

If you make a change, commit to it! If you decide to replace the old control panel, I don't want to see it anymore. It is certainly easier said than done, but if you are a many-billion dollar company and that's your flagship product, you can afford to do hard things!

Using a web engine to build UIs is fine too. As an OS-wide component, a web engine is not that big in terms of resource use, if properly optimized. The problem with Electron is that every app ships with its own engine, so if you have 10 apps, you have 10 engines loaded. But everything uses the same engine, and apps don't abuse it, then the overhead is, I think, almost negligible. It is rare not to have a browser loaded nowadays, so system components can take advantage of this. But again, you need to do it right and it takes skills, effort and resources.

> React has had tremendous success in the web world, so why not try and get those developers more comfortable producing apps for your platform?

Because web stuff utterly sucks for making UIs on the desktop. Microsoft either doesn't know this (bad sign), or is choosing to use the trendy thing even though it'll make their software worse for customers (a worse sign). Either way it's a very bad look from MS.

Blaming this on Ballmer is a serious stretch, I can't see how you would come to that conclusion. Developers Developers Developers was for the launch of .NET and it brought us a platform that is still considered cutting edge 25 years later.

UX was fine in the Windows Forms days, and WPF was a large step forward (responsive layouts, etc...). The problem was after that it all fell apart with Windows 8 and the attempt to switch to Metro, followed by the Windows Store fiasco and attempting to move to a sandboxed application model.

It all comes down to Microsoft's failure to adapt to mobile/tablets in so many ways. Which is kind of hilarious, because they had some really cool tech for the time (the PocketPCs were pretty fun back in the day, before touch came along).

Remember when Silverlight was _the_ future?

How long did it last. Ironically it still gives me the shits because you can't select text on Netflix's front end.

Problem with SwiftUI is that it only works well on macOS 26, maybe one version prior. AppKit works well on all macOS versions.

Building a macOS 26 only app in SwiftUI today is a great UX, just as fast as AppKit.

But it takes quite some effort to turn an iOS SwiftUI app into a real macOS experience. Though most macOS optimizations help for iPadOS as well.

When I was a developer I was not amused at all with constantly changing APIs to be honest. And UWP was really sucky. Way too aligned with mobile and tablet which nobody actually uses on windows. Even as a user I'm glad it didn't take off.

>Tangentially, see also the mixed reaction to Mac native apps switching from AppKit to SwiftUI

I'll take AppKit -> SwiftUI over Win32-> windowsx.h -> VB6 -> MFC -> ATL -> WTL -> WFC -> WinForms -> WPF -> WinRT -> UWP -> WinUI3 -> MAUI.

Even with all that Microsoft still went outside and used React Native for the start menu and Electron for the Visual Studio installer and Visual Studio Code.