Comment by AceJohnny2
6 days ago
Microsoft has a history of creating new UI frameworks. IMHO it's the result of Ballmer's "Developers, developers, developers!" attitude, which I think is a good thing at core (court the developers that add value to your platform!)
But this results in chasing a new paradigm every few years to elicit new excitement from the developers. It'll always be more newsworthy to bring in a new framework than add incremental fixes to the old one.
React has had tremendous success in the web world, so why not try and get those developers more comfortable producing apps for your platform?
(Tangentially, see also the mixed reaction to Mac native apps switching from AppKit to SwiftUI)
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.
Out with the old, in with the new, doesn't have to be bad, but it depends on what your old and new are. I'd be a lot less skeptical about migrating OS-level sttuff from C to Rust than from C to React.
If the motivation is "Because I refuse to learn C", then both approaches will be bad. You can't avoid understanding what you're migrating, but seemingly Microsoft thinks they're above that. Fits with the average mindset of developers within the Windows ecosystem, at least from my experience.
1 reply →
I maintain to this day that the Zune was one of the best designed hardware and software platforms I've ever used. Probably the only truly design forward product that MS ever produced.
The Zune hardware was slick, particularly the solid state players. The music store worked great and their music licensing was so much better than Apple - $10 a month for unlimited streaming, unlimited downloads (rentals) to Zune devices and 10 free mo3 downloads to own.
Their only misstep was making one of their colorways poop brown! That and being too late to market with a phone that used the same design language
6 replies →
The Zune software 2.0 remains the pinnacle of Microsoft design
Windows Phone was actually doing well and adoption was taking off when Nadella came in and killed it. It didn't help that they changed the app framework and then blamed lack of apps. Such a brain-dead decision.
Windows Phone was dead in the water because many services did not have first party support, and the third party clients kept getting killed / people banned from said services.
Google was extremely aggressive in muscling Microsoft out. They refused to release a Gmail, YouTube or Maps client for Windows Phone but made sure those services did not work (properly).
And indeed on top of that, Microsoft switched UI frameworks 3 or 4 times. And they left phones behind on the old OS releases repeatedly, that then couldn't run the new frameworks.
Still, Windows Phone its UI concept was really great, and I sorely miss the durability of polycarbonate bodies versus the glass, metal and standard plastic bodies of today.
3 replies →
Windows Phone 7 was doing well; for some reason they did a breaking change with Windows Phone 8 and broke app compatibility. I will never understand that, they kneecapped themselves despite being multiple laps behind Apple and Google already…
2 replies →
The decisions reg UI frameworks are largely due to internal political conflicts, mostly between DevDiv and Windows.
They have a lot of staff turnover too, and each generation of new SDE has less of a clue how the old stuff worked. So when they're tasked with replacing the old stuff, they don't understand what it does, and the rewrite ends up doing less.
That was my impression of one of the major problems when I worked there 2008-2011. But I don't think it's just one problem.
I think that because their total compensation is lower than FAANG, especially at senior levels, and they are seen as uncool, they sometimes have issues retaining top-notch talent. It's paradoxical, because MS Research is probably the best PLT organization in the world. But they have failed to move a lot of that know-how into production.
Besides, because it's an older company, it might have more organizational entropy, i.e. dysfunctional middle-management. As you say it's probably several other causes too. But still, hard to understand how they can create F#, F*, and Dafny, just to name a few, and fail with their mainstream products.
23 replies →
I can confirm, the guys still around for WinUI team and related frameworks, always appear clueless when posed questions about Windows features they were supposed to know about.
Just go watch a few recordings on their YouTube channel.
Raymond Chen tries to document it, but he's just one person.
https://devblogs.microsoft.com/oldnewthing
From the outside looking in one wonders why this is allowed to continue. Microsoft’s old school “developer tools for money” business is slowly dying (because Visual Studio proper is less popular than its ever been since so much is targeting web), you would think they’d reorganize and move .net and GitHub and stuff into their cloud team and yeet whatever toxic leadership is preventing Windows from using Microsoft’s own frameworks.
IIRC .NET was banned from core Windows components after longhorn died, but its been 20 years. .NET is fast now, and C++ is faster still. Externally developed web frameworks shouldn’t be required for Windows.
It’s a largely dysfunctional org creating largely dysfunctional software, I.e. Conway law. Dysfunctional orgs tend not to be capable of fixing themselves, especially without external threat. Satya Nadella, like many CEOs, seems mostly interested in impressing his peers and these days that means fancy AI, before that it was Quantum chips.
Microsoft has produced some great technology and when I was last there I was definitely focusing on getting as much of the good stuff out into open source as possible.
Back in the early V8 days the execs imagined JavaScript would keep getting exponentially faster, I tired to explain with a similar investment anything V8 could do dotnet could do better as we had more information available for optimization.
2 replies →
Longhorn was politics, then Google ate their lunch on mobile with Java and JavaScript userspace, across two platforms.
DevDiv is a "here C++ rules!" silo, even the Rust adoption is being widely embraced at Azure, less so on Windows team.
Yeah, as far as I understand it, that politics is: Sinofsky entrenched NIH on every team that he touched.
Just curious what is DevDiv? Tools division?
As I understand it, .NET, developer tools, and VS.
Basically you have tight OS integration vs developer friendly cross platform.
3 replies →
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 stopped writing Windows applications back in the early 00s
my Windows API knowledge (essentially: just Win32) is still exactly as useful as it was then, having missed the 7 or 8 different UI frameworks in the interim
Win32 is basically frozen on Windows XP.
Since Vista most newer APIs are done in COM, or WinRT nowadays.
7 replies →
Me too, back then I wrote applications either using the raw Win32 API (GetMessage, TranslateMessage, DispatchMessage, etc), or using MFC.
I think MFC is now long-time dead and buried, but at the time I liked it despite the ugly macros.
1 reply →
> 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 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.
It’s not so much about wasting resources as it is about the added latency, jankiness, and inconsistency in look & feel hurting usability.
And how about reliability? Having to start a web browser and a web framework to display core OS functionality adds a lot of moving parts that can break.
Latency is literally wasting resources
4 replies →
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.
probably trying to repro the crazy success of vscode, surely electron is the magic sauce and not the dream team of devs. azure data studio should've proved that you can't just sprinkle electron dust and get a winner.
sadly I loved azure data studio despite its being afflicted with electron, but it became so bug infested they had to completely abandon it.
vscode is successful despite electron, not thanks to electron. The electron part is the worst of it.
No, it does not suck.
I attempted to use WinUI 3, and could not even get PNGs to render the colors correctly, no matter what setting I tried.
Then I gave Tauri a try, and everything worked out of the box, with the PNGs rendering even better than in the Windows Photos app.
Building the UI was much easier, it looked better, and you get to build the "backend" in Rust.
Nothing about this sucked.
WinUI 3 is basically utterly pathetic bul_sh_t attempting to pretend that it is a UI framework. A wet paper plane passing itself off as a passenger aircraft. Please compare with a real desktop UI framework like GTK or Qt. Or just a more modern one like Rust Iced or gpui/slint
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.