Jeffrey Snover, the former Microsoft Distinguished Engineer who created PowerShell, just published a scathing indictment of Microsoft’s Windows GUI strategy. His blog post, which hit Hacker News today with 455 points and 282 comments, asks a devastating question: Can Microsoft answer “How should I build a Windows desktop app?” in ten seconds? The answer is no. That’s a fundamental platform failure.
In the past 14 years, Microsoft has pivoted its GUI framework recommendations 14 times. Windows now ships with 17 competing GUI technologies across five programming languages, and even Microsoft’s own developers can’t agree on which to use. When a developer meeting asked “What framework for a new Windows app?” the responses included WPF, WinUI 3, and Electron—but the meeting “went sideways and the question was never answered.” This isn’t technical debt. It’s organizational dysfunction.
The Petzold Standard: What Microsoft Lost
Charles Petzold’s “Programming Windows” represented the last time Windows development had absolute clarity. His 852-page guide, first published in 1988, provided a single coherent mental model: Win32 API in C. Every Windows developer used the same book. Snover calls this “Physics not Chemistry”—universal rules, not context-dependent exceptions. That clarity lasted until 2012.
Petzold stopped after the 6th edition covering WinRT for Windows 8. The fragmentation had become so severe that maintaining a single authoritative guide was impossible. “Petzold’s book represented not just good documentation but a trust signal—one API, one answer, one commitment,” Snover writes. “Everything after it broke that commitment incrementally.” The year 2012 marks the symbolic endpoint of coherent Windows development.
The Thirteen-Year Civil War That Killed Windows Development
Snover traces a “thirteen-year institutional civil war between the Windows team and the .NET team” as the root cause. Frameworks died from internal politics, not technical merit. WPF shipped with Vista in 2006, but the Windows Shell refused to use it—a rejection signal that doomed the framework from the start.
Silverlight was killed in 2010 when an executive announced at a conference Q&A (not through official channels) that HTML5 was policy. Developers learned their framework was dead by attending MIX 2010, not from Microsoft developer communications. UWP deliberately excluded .NET to reflect “team bitterness.” A former Microsoft DevDiv employee confirmed on Hacker News: “Windows just hated .NET that much.”
Three major frameworks became casualties of internal warfare. WPF is now open source with “no new Microsoft investment”—maintenance mode for a framework that should have been Windows’ future. Silverlight died not from technical failure but from a business pivot that blindsided developers. UWP was dead on arrival because Microsoft’s flagship apps—Office, Visual Studio, Windows Shell—never used it. Internal non-confidence killed it before developers could build ecosystems.
These weren’t technical decisions. They were the collateral damage of corporate infighting. Microsoft’s Windows and .NET teams destroyed more developer value than Apple or Google ever could.
Related: Microsoft Copilot Branding Chaos: How Many Products?
Electron Won Because Microsoft Failed
Electron is now “the most widely deployed desktop GUI technology on Windows—and Microsoft had nothing to do with it,” according to Snover. The ultimate irony: Microsoft’s flagship developer tool, VS Code, uses Electron instead of WPF, WinUI, or UWP. Actions speak louder than keynotes.
On March 17, 2026, Microsoft promoted Electron for Windows 11 AI apps, explicitly stating “no need of native code, despite RAM concerns.” This is an implicit admission that native Windows frameworks failed so completely that Microsoft itself recommends a third-party web framework over its own technologies. When your platform vendor promotes competitors, the platform has failed.
Popular Electron apps dominate Windows desktops: Discord, Slack, Figma, Notion, Spotify. Developers didn’t choose Electron because it’s technically superior—it’s not. RAM usage is higher, performance overhead exists. They chose it because it works, it’s cross-platform, and it won’t get deprecated every 2-3 years. Electron won by default because Microsoft created a vacuum through 14 years of pivots and broken trust.
14 Pivots, 17 Technologies, Zero Trust
One developer on Hacker News catalogued Microsoft’s “14 pivots” across 14 years: UAP, UWP, C++/CX replaced by C++/WinRT without tool support, XAML Islands, XAML Direct, Project Reunion, Windows App SDK restart, chaotic switch between WinUI 2.0 and 3.0. Each pivot orphaned developers who had invested months or years building apps.
Windows currently ships with 17 GUI technologies spanning five programming languages: Win32 (1985, still in Windows Shell), MFC (1992, maintenance mode), WinForms (2002, discouraged), WPF (2006, no investment), Silverlight (killed 2010), WinRT/Metro (Windows 8 disaster), UWP (abandoned 2020), WinUI 3 (2021, uncertain roadmap), MAUI (2022, .NET team’s bet), plus third-party dominants like Electron, Qt, and Avalonia.
Microsoft’s own documentation includes feature comparison tables for all these frameworks. That’s not a platform—that’s an admission that developers need a map just to choose a starting point. Snover describes this as “six teams fighting for your attention” in a “Hunger Games stage,” not a coherent strategy but internal competition. Each framework taught developers the same lesson: Don’t bet on Microsoft GUI technologies.
WinUI 3: Too Little, Too Late
Microsoft’s latest “answer,” WinUI 3 (launched 2021, part of Windows App SDK), might technically work. Developer trust is shattered anyway. Hacker News commenters express universal skepticism: “I have no idea where I’d begin now,” “so much friction,” “once bitten, twice shy.” The 14 years of pivots taught developers that Microsoft GUI frameworks have a 3-5 year lifespan before the next abandonment.
WinUI 3 faces a trust death spiral. Developers won’t invest until Microsoft proves commitment—but Microsoft can’t prove commitment until developers invest. Snover’s conclusion cuts to the core: “You either have a Plausible Theory of Success that covers the full lifecycle—adoption, investment, maintenance, and migration—or you have a developer conference keynote.” WinUI 3 is the latter.
Until Microsoft’s own flagship apps adopt WinUI 3, it’s just another keynote announcement waiting to be abandoned. VS Code still uses Electron. Office still uses custom Win32. Windows Shell is still a mix of old and new. The signals are clear: Microsoft’s developers don’t trust Microsoft’s frameworks. If they won’t use it, why should anyone else?
Key Takeaways
- Microsoft’s GUI chaos is organizational dysfunction, not technical failure. Internal team conflicts between Windows and .NET groups destroyed frameworks through politics, not merit. WPF, Silverlight, and UWP died because of corporate infighting, not technology limitations.
- The 14 pivots in 14 years systematically destroyed developer trust. Each abandoned framework—from Silverlight (2010) to UWP (2020)—taught developers the same lesson: Don’t bet your product on Microsoft GUI technologies. That trust takes decades to rebuild.
- Electron won because Microsoft failed to provide a stable alternative. Developers chose web tech not because it’s superior (it’s not) but because it’s reliable and cross-platform. When Microsoft itself uses Electron for VS Code and promotes it for Windows 11 apps, the platform has failed.
- WinUI 3 arrived too late to save the Windows native app ecosystem. No amount of “this time is different” messaging will restore trust. Until Microsoft’s flagship apps (Office, VS, Windows Shell) adopt WinUI 3, it’s just another developer conference announcement.
- If Petzold can’t write a book about Windows development anymore, maybe developers shouldn’t bet their products on it either. The symbolic endpoint was 2012 when fragmentation made a single coherent guide impossible. From one answer (1988-2012) to 17 competing technologies (2026)—that’s not evolution, that’s collapse.
Microsoft’s Windows GUI strategy is dead, and the company killed it. The damage is done, and WinUI 3 won’t fix it. Developers have moved on.
