Snover argues that the last time a developer could get a single, clear answer to 'how do I build a Windows app?' was the Petzold era of Win32/GDI. He catalogs at least 15 distinct GUI frameworks over 30 years — from MFC to WinForms to WPF to UWP to WinUI 3 to MAUI — as evidence of strategic incoherence at Microsoft.
Snover's framing isn't just that technologies changed — it's that each framework was positioned as 'the answer' before being sidelined by the next initiative. The critique carries unusual weight because Snover is one of Microsoft's highest-ranking individual contributors, someone who watched these decisions get made and unmade from inside the organization for decades.
Submitted the post to Hacker News where it reached 490 points and 318 comments, indicating strong resonance with the developer community. The high engagement suggests widespread agreement that Microsoft's framework churn is a systemic problem rather than an edge-case complaint.
Snover opens with a scene where someone asks the simplest possible platform question — what framework to use for a new desktop app — and is met with dead silence. His core argument is that for the world's most popular desktop OS, this question should have the simplest answer in all of platform development, yet in 2026 it still doesn't.
Jeffrey Snover — the Microsoft Technical Fellow who invented PowerShell — published a blog post titled "Microsoft Hasn't Had a Coherent GUI Strategy Since Petzold" that hit 490 points on Hacker News. The title references Charles Petzold, whose *Programming Windows* (first published 1988) was the canonical guide to building Windows applications. Snover's argument: the Petzold era was the last time a developer could ask "how do I build a Windows app?" and get a single, clear answer.
The post opens with a scene most Windows developers will recognize. Someone in a meeting asks what framework to use for a new desktop app. Dead silence. The question that should have the simplest answer in all of platform development — "how do I build an app for the world's most popular desktop OS?" — has no consensus response in 2026.
Snover's authority here matters. This isn't a frustrated indie dev venting on Reddit. He's one of the highest-ranking individual contributors Microsoft has ever had, someone who spent decades inside the machine watching these decisions get made and unmade.
To understand the argument, you need to see the timeline laid flat. Win32/GDI gave way to MFC, which coexisted with VB6 Forms. Then .NET arrived with WinForms (2002), followed by the genuinely ambitious WPF (2006) with its XAML-based, GPU-accelerated rendering. Silverlight (2007) tried to bring WPF to the browser. Windows Phone introduced yet another XAML variant. Windows 8 brought WinRT. UWP (2015) was supposed to unify everything under one platform for all Windows devices. Xamarin promised cross-platform mobile. WinUI 2 (2018) updated UWP's controls. WinUI 3 (2020) decoupled from UWP entirely. MAUI (2022) replaced Xamarin. Blazor Hybrid offered web-tech-in-a-native-shell. React Native for Windows got Microsoft investment.
That's at least 15 distinct GUI frameworks in roughly 30 years, and the count depends on how generously you define "distinct." Each was introduced with conference keynotes, documentation pushes, and implicit promises of long-term support. Each was deprioritized or abandoned within approximately five years of reaching developers' hands.
The pattern isn't just churn — it's a specific kind of organizational dysfunction. Each framework was championed by a different team, often a different division, sometimes reporting to a different VP. When leadership changed, priorities shifted, and the new team had every incentive to build something new rather than maintain their predecessor's code. The framework wasn't a platform commitment; it was a team's project.
WPF deserves special attention because it was genuinely good. Released in 2006, it introduced concepts — data binding, resolution independence, composable visual trees, MVVM architecture — that influenced every UI framework that followed, including ones on competing platforms. WPF was the last time Microsoft shipped a GUI framework that developers actually loved and that had the technical depth to be a decade-long foundation.
Instead, Microsoft got distracted by mobile. Silverlight was WPF-for-the-browser, designed to compete with Flash. When the iPhone killed both Flash and the browser-plugin model, Silverlight died too — but it took WPF's momentum with it. Resources that should have gone into making WPF the definitive desktop framework went into the Windows 8 bet, then UWP, then the slow walk-back to Win32 via WinUI 3.
Developers who went deep on WPF — learning XAML, building custom controls, mastering the visual tree — watched Microsoft repeatedly signal that their investment was yesterday's news. Many of those developers are now the most vocal skeptics of any new Microsoft framework announcement, and they have earned that skepticism.
The most corrosive detail in the entire GUI saga isn't the framework count. It's that Microsoft's own teams don't use the frameworks they recommend to everyone else.
Visual Studio Code is Electron. Teams was Electron (now a custom web wrapper). Office uses a proprietary internal toolkit that predates most of the frameworks on the public list. Windows Settings is a mishmash of UWP and Win32 controls. When the platform owner's own flagship applications won't commit to the platform's recommended UI stack, the message to external developers is unmistakable: we don't trust it either.
Contrast this with Apple. Cocoa has been the macOS framework for over 20 years. SwiftUI, introduced in 2019, is layered on top of it rather than replacing it. AppKit code from 2005 still compiles and runs. You can debate whether SwiftUI is ready for production — many developers say no for complex apps — but the migration path is clear: SwiftUI views embed in AppKit, AppKit views embed in SwiftUI, and Apple's own apps (Finder, Mail, Xcode) progressively adopt SwiftUI while keeping their AppKit foundations.
Apple has had roughly two GUI frameworks in 40 years. Microsoft has had 15+ in 30. The gap isn't about technical ambition — Microsoft's frameworks have often been more technically sophisticated. It's about organizational commitment.
If you're starting a new Windows desktop project in 2026, Snover's post doesn't give you a clean answer, and that's precisely the point. Here's the uncomfortable decision tree:
WinUI 3 is the closest thing to an "official" recommendation, but it's under-resourced, has a long bug tail, and its adoption outside Microsoft is thin. WPF is battle-tested and has the largest ecosystem of existing code, but Microsoft has made clear it's in maintenance mode — security patches, not new features. MAUI targets cross-platform but ships with enough rough edges that production teams report spending significant time on platform-specific workarounds. Electron/web-based approaches work — VS Code proves it — but come with memory and performance trade-offs that feel absurd for native desktop apps.
The pragmatic move for most teams is WPF for Windows-only apps that need to ship this year, and a web-based approach (Electron, Tauri, or Blazor Hybrid) for anything cross-platform. But that answer comes with an asterisk: you're choosing based on what works today, not on any confidence about where Microsoft is heading.
The deeper lesson applies beyond Windows. Platform stability is a feature. When you evaluate any framework — not just Microsoft's — look at what the platform owner builds with it. If their flagship products use something else, that's the strongest possible signal about the framework's real priority level inside the organization.
Snover's post landing at 490 points on Hacker News suggests this frustration has been quietly building for years. The question is whether Microsoft treats this as a wakeup call or as background noise. WinUI 3 is still in active development, and Microsoft's recent investments in AI-powered coding tools could theoretically drive a renewed interest in native desktop frameworks (local models need native performance). But if the last 30 years are any guide, the most likely outcome is a 16th framework announced at Build 2027, positioned as the one that finally unifies everything. Developers will applaud politely, check back in three years, and find it already in maintenance mode.
Top 10 dev stories every morning at 8am UTC. AI-curated. Retro terminal HTML email.