Snover, a Microsoft Technical Fellow who invented PowerShell, argues that the last time Microsoft had a coherent answer to 'how do I build a Windows desktop app?' was the Win32/Petzold era. He describes the painfully familiar scene of developers unable to agree on a framework — not from lack of options, but from lack of a single clear strategy from Microsoft itself.
The editorial argues that WPF was genuinely innovative — XAML-based, hardware-accelerated, data-binding-first — and arguably the best desktop UI framework Microsoft ever built. Yet Microsoft spent a decade trying to replace it rather than completing it, with rough tooling and steep learning curves left unaddressed while attention shifted to the next shiny framework.
Snover's post walks through the graveyard — Win32, MFC, WinForms, WPF, Silverlight, and beyond — arguing that the timeline of successive replacements tells the story on its own. Each framework was positioned as the future, attracted developer investment, then was effectively abandoned for the next one, eroding trust in any single choice.
The editorial highlights that Win32/GDI code written in 1995 still compiles today, calling it verbose and painful but stable. This backward compatibility stands in stark contrast to every successor framework, suggesting that developers value a single dependable API over repeated attempts at modernization that never fully land.
Jeffrey Snover — the Microsoft Technical Fellow who invented PowerShell — published a blog post with a title that doubles as a diagnosis: "Microsoft Hasn't Had a Coherent GUI Strategy Since Petzold." The "Petzold" in question is Charles Petzold, whose book *Programming Windows* was the definitive reference for the Win32 API, the last time Microsoft had a single, clear answer to "how do I build a Windows desktop app?"
The post opens with a scene that will be painfully familiar to anyone who's worked in a Microsoft shop: a room full of developers, someone asks what framework to use for a new desktop app, and the room goes silent. Not because nobody has an opinion — because everybody has a *different* one, and none of them feel safe. The post landed on Hacker News with 422 points, which tells you how many nerves it hit.
Snover's authority here matters: this isn't a blogger dunking on Microsoft from the outside. This is someone who spent decades inside the machine, shipping one of its most successful developer tools, saying the quiet part out loud.
Let's walk the timeline, because the sheer volume is the argument:
Win32/GDI (1985–): The Petzold era. One API, one book, one way to do it. Verbose, painful, but *stable*. Code written in 1995 still compiles.
MFC (1992–): C++ wrappers around Win32. Microsoft's first attempt to make GUI development less brutal. Still works, still maintained, still nobody's first choice.
WinForms (2002–): .NET's first GUI framework. Drag-and-drop designer, rapid development, massive adoption. Then Microsoft told everyone to move to WPF.
WPF (2006–): XAML-based, hardware-accelerated, data-binding-first. Genuinely innovative. But the tooling was rough, the learning curve steep, and Microsoft's own teams barely used it. WPF is arguably the best desktop UI framework Microsoft ever built — and they spent a decade trying to replace it instead of finishing it.
Silverlight (2007–2012): The "Flash killer" that Microsoft killed instead. Developers who built line-of-business apps on Silverlight — and there were thousands — got a five-year deprecation notice and a shrug.
UWP (2015–): Universal Windows Platform. The promise: write once, run on desktop, tablet, phone, Xbox, HoloLens. The reality: a sandboxed, capability-restricted platform that couldn't access half the Win32 APIs enterprise apps needed. Windows Phone died; UWP lost its reason to exist.
WinUI 3 (2020–): The current "answer." Decoupled from UWP, ships with the Windows App SDK. In theory, it's the modern native framework. In practice, it's missing features WPF had a decade ago. The DataGrid shipped years late. The designer support is thin. The community is small.
MAUI (2022–): .NET Multi-platform App UI. Xamarin.Forms renamed and extended. Cross-platform (Windows, macOS, iOS, Android), but the Windows rendering path uses WinUI 3 under the hood — inheriting its gaps. MAUI has been GA for years and still has open issues that would be blocking for any serious production app.
That's eight frameworks in four decades, with at least three (Silverlight, UWP, WinForms-as-primary) explicitly abandoned after significant developer investment.
The technical damage is obvious: fragmented ecosystems, duplicated effort, abandoned codebases. But the real damage is to developer trust, and that's much harder to repair.
Every framework pivot followed the same pattern: Microsoft announces the new thing, evangelizes it hard, gets developers to invest, then quietly shifts resources to the *next* new thing before the current one is finished. The developers who built Silverlight LOB apps learned this lesson with their careers. The developers who went all-in on UWP learned it again. At some point, the rational response to "Microsoft's new GUI framework" is to wait three years and see if it's still alive — which is exactly what most teams do, and exactly why adoption never reaches critical mass.
The Hacker News discussion surfaced a pattern that Snover's post implies but doesn't fully spell out: Microsoft's GUI strategy has been driven by *platform strategy* (compete with Flash, unify phone and desktop, compete with React Native) rather than by *developer needs* (I need to build a desktop app that works, ships fast, and will still compile in five years). Every time the platform strategy shifted, the GUI framework got sacrificed.
Contrast this with Apple's approach. AppKit is ancient and cranky, but it *works* and it's *maintained*. SwiftUI is the new hotness, but Apple hasn't deprecated AppKit — they've layered SwiftUI on top and let developers adopt incrementally. The interop story is real. You can mix and match. Microsoft never figured out this "both/and" approach; every new framework was a "replace everything" proposition.
The web, meanwhile, solved the problem by not being a platform at all. Electron won the Windows desktop not because it's good — it's a resource hog that ships a whole browser per app — but because it's the only framework where developers are confident their investment won't be deprecated in three years. That's a damning indictment.
If you're starting a new Windows desktop project today, here's the honest assessment:
WPF remains the most capable native framework for complex desktop UIs. It's old, it's not getting major new features, but it's stable, well-documented, and has a massive ecosystem of third-party controls. If you need a rich desktop app and you're targeting Windows only, WPF is still the pragmatic choice — not because it's exciting, but because it's *finished*.
WinUI 3 / Windows App SDK is where Microsoft wants you to go, but evaluate it against your actual requirements, not Microsoft's roadmap promises. Check that every control and capability you need actually exists and works. Don't assume feature parity with WPF.
Electron / Tauri if you need cross-platform or your team already knows web tech. Tauri is worth serious consideration if you want native performance without Electron's resource overhead — it uses the OS webview instead of bundling Chromium.
Flutter if you're greenfield cross-platform and your team can learn Dart. Google's track record with developer tools isn't spotless either, but Flutter's desktop support has matured significantly.
The meta-advice: don't optimize for Microsoft's stated direction. Optimize for the framework that has the largest active community and the most real-world production apps today. Those frameworks survive regardless of what any vendor's strategy deck says.
Snover's post is notable not just for what it says, but for *when* it says it. Microsoft is in the middle of an AI pivot that's consuming enormous internal attention and resources. The GUI framework teams were already under-resourced; the AI gold rush is unlikely to improve that. If history is any guide, the next announcement will be an "AI-native UI framework" that makes WinUI 3 the new WPF — technically alive but strategically orphaned. The developers who've been paying attention will wait three years before adopting it. The ones who haven't been paying attention will read Snover's post and start.
Top 10 dev stories every morning at 8am UTC. AI-curated. Retro terminal HTML email.