Snover argues that the last time Microsoft had a single, clear answer to 'how do I build a Windows desktop application?' was the Win32/Petzold era of the 1990s. Drawing on over two decades of internal experience as a Distinguished Engineer, he contends that every subsequent framework was launched by competing teams chasing different organizational priorities, then quietly deprecated when those priorities shifted.
The editorial synthesis walks the full timeline — WinForms, WPF, Silverlight, and beyond — to argue that the sheer volume of abandoned frameworks is itself the evidence. Each was marketed as the definitive future, developers invested heavily in learning and building on it, and each was quietly deprecated, creating a 30-year pattern of broken promises that has eroded developer confidence in committing to any Microsoft GUI technology.
Snover frames the Win32/MFC era as the gold standard not because the technology was elegant — it was verbose and painful — but because it was coherent: one API, one book, one way to build apps. The implicit argument is that developer experience quality matters less than strategic clarity and long-term commitment.
The post garnered 297 points and 164 comments, with the community treating it as insider testimony rather than opinion. The resonance reflects that developers who lived through multiple framework transitions see Snover's internal context — knowing why each framework was created and abandoned — as validating what they experienced from the outside.
Jeffrey Snover — the Distinguished Engineer who created PowerShell and spent over two decades inside Microsoft — published a blunt assessment of the company's GUI strategy, or rather the absence of one. The post, titled *Microsoft Hasn't Had a Coherent GUI Strategy Since Petzold*, hit 297 points on Hacker News and resonated with a developer community that has lived through the consequences.
The "Petzold" in the title refers to Charles Petzold, whose book *Programming Windows* was the definitive guide to Win32 GUI development in the 1990s. Snover's argument is simple: that was the last time Microsoft had a single, clear, well-supported answer to the question "how do I build a Windows desktop application?" Everything since has been a series of competing bets launched by different teams, each marketed as the definitive future, each quietly deprecated when organizational priorities shifted.
The timing matters. This isn't a random blog post from an outsider. Snover has the internal context to know *why* each framework was created and *why* each was abandoned. When someone with his tenure says the strategy is incoherent, it's not opinion — it's testimony.
Let's walk the timeline, because the sheer volume is the argument:
Win32/MFC (1990s): The Petzold era. One API, one book, one way to build Windows apps. Painful, verbose, but *coherent*. Microsoft Foundation Classes (MFC) wrapped it in C++ and became the standard for a decade.
WinForms (2002): Arrived with .NET 1.0. Drag-and-drop GUI builder, rapid application development. Millions of line-of-business apps were built on it. Microsoft told developers this was the future.
WPF (2006): XAML-based, resolution-independent, data-binding-first. A genuine leap in capability. Microsoft told developers *this* was the future. WinForms investment quietly stopped.
Silverlight (2007-2012): Microsoft's Flash competitor. Ran in browsers and on Windows Phone. Developers built entire product lines on it. Microsoft killed Silverlight in 2012 with roughly 18 months of warning, stranding teams that had invested years of work.
UWP (2015): Universal Windows Platform. Sandboxed, Store-distributed, touch-first. Microsoft told developers this was the future and that Win32 was legacy. Adoption was anemic because the sandbox restrictions made it impractical for most real applications.
WinUI 3 (2020-present): The "modern" native UI framework. Decoupled from the OS, meant to replace UWP's UI layer. Years into development, it still has gaps that send developers back to Win32 interop.
MAUI (2022-present): .NET Multi-platform App UI. The successor to Xamarin.Forms, meant to be the cross-platform answer. Launched with significant stability issues. Microsoft recently moved the MAUI team under a different org, which developers have learned to read as a leading indicator.
Blazor Hybrid (2022-present): Write your UI in web technologies (HTML/CSS/Razor), host it in a native shell. The newest entrant, and already competing with MAUI for the same mindshare.
That's nine frameworks in roughly 30 years. No other platform vendor — not Apple, not Google, not the Linux desktop projects — has churned through GUI frameworks at this rate. Apple's AppKit shipped in 1989 and still works. SwiftUI (2019) supplements it rather than replacing it. Google's Android View system (2008) coexists with Jetpack Compose. The contrast is damning.
The surface-level cost is obvious: rewrite fatigue. Every framework transition means months or years of migration work that delivers zero new features to users. But Snover's deeper point is about something harder to quantify: developer trust is a non-renewable resource, and Microsoft has been spending it down for three decades.
When a platform vendor tells you "this is the future," you're making a multi-year bet. You're hiring developers with that skill set, building internal tooling, training your team, accumulating institutional knowledge. When the vendor abandons the framework five years later, you don't just lose the code — you lose the team's confidence that the next recommendation is worth following.
This explains the paradox of Windows desktop development in 2026: there are more framework options than ever, and developer confidence in choosing any of them is at an all-time low. The Hacker News discussion is full of developers saying they default to Electron or web apps not because those are better, but because at least the browser isn't going to deprecate HTML.
The organizational root cause is well-understood by Microsoft insiders: each framework was championed by a different VP or CVP, and each one's success was measured by adoption metrics that incentivized launching new things rather than sustaining existing ones. The GUI graveyard isn't a technical failure — it's an organizational one. Each framework was technically competent. The strategy was the casualty.
If you're choosing a Windows desktop GUI framework today, Snover's post is cold water on any hope that Microsoft will converge on an answer soon. The practical implications:
If you need native Windows desktop today, WinUI 3 is the "official" answer but has meaningful gaps. WPF remains the most capable and battle-tested XAML framework, and Microsoft continues to ship .NET updates for it. Betting on WPF in 2026 is unfashionable but defensible — it has 20 years of ecosystem depth and a larger installed base than anything newer.
If you're building cross-platform, the honest assessment is that Microsoft's own offerings (MAUI, Blazor Hybrid) are competing with each other and neither has achieved the stability or ecosystem depth of Flutter, Electron, or even Tauri. The community has largely voted with its feet.
If you're making an architectural decision for a 5+ year horizon, the meta-lesson from Snover's timeline is to minimize your coupling to any single framework's abstractions. Separate your business logic ruthlessly. The UI layer *will* change — the only question is when and to what. Teams that survived the WinForms→WPF→UWP transitions with the least pain were the ones that had kept their domain logic framework-agnostic.
This is also a useful framework for evaluating *any* platform vendor's GUI story. Apple and Google have churned less, but they've churned. The difference is degree, not kind. The developers who weather framework transitions best aren't the ones who picked the right framework — they're the ones who architected for the framework being wrong.
Snover doesn't just diagnose — he implies that the fix is organizational, not technical. Microsoft doesn't need a tenth framework. It needs a single empowered team with a 10-year mandate and the authority to say "no" to competing efforts. Whether the current leadership structure at Microsoft can produce that kind of sustained focus is an open question, especially as AI tooling (Copilot, the other kind) consumes an increasing share of the company's developer-facing attention. The GUI strategy problem isn't getting solved because, right now, nobody at Microsoft is being measured on solving it.
Top 10 dev stories every morning at 8am UTC. AI-curated. Retro terminal HTML email.