Em 1988, um programador chamado Charles Petzold publicou um livro de 852 páginas chamado Programming Windows. Era grosso, denso e — por mais estranho que pareça — reconfortante. Porque se você queria criar uma aplicação com interface gráfica no Windows, a resposta era uma só: Win16 API, C, e aquele livro. Ponto final.

Quase quatro décadas depois, se você perguntar a cinco desenvolvedores Microsoft qual framework usar para criar um app desktop no Windows, vai receber seis respostas diferentes. E pelo menos duas delas vão incluir a frase “depende do que você precisa”.

Jeffrey Snover — o cara que inventou o PowerShell e passou décadas dentro da Microsoft — publicou um post no seu blog que explodiu na comunidade dev: “Microsoft Hasn’t Had a Coherent GUI Strategy Since Petzold”. Com mais de 340 comentários no Hacker News, o texto tocou numa ferida que todo desenvolvedor Windows conhece bem.

Eu já vi projetos inteiros serem reescritos três vezes por causa de pivôs de framework da Microsoft. Então vamos entender como chegamos nesse ponto — e por que a situação provavelmente não vai melhorar tão cedo.

A Era Dourada: Quando Existia Uma Resposta

O modelo Petzold funcionava por um motivo simples: existia um flywheel perfeito. A Microsoft lançava uma nova versão do Windows com novas APIs. Desenvolvedores aprendiam essas APIs e criavam apps que só rodavam no Windows novo. Usuários compravam hardware novo pra rodar esses apps. Fabricantes de hardware pagavam licenças de Windows. E o dinheiro voltava pra Microsoft investir na próxima versão.

Nova versão do Windows
    → Novas APIs para devs
        → Apps que exigem o novo Windows
            → Vendas de hardware novo
                → Receita de licença para Microsoft
                    → Investimento na próxima versão

Todo mundo ganhava. O desenvolvedor sabia exatamente o que estudar. O livro do Petzold vendia milhões de cópias. A resposta era clara: Win32 API. Primeiro em C, depois em C++ com MFC (Microsoft Foundation Classes).

Sim, era verboso. Sim, criar uma janela exigia 50 linhas de código onde hoje bastam 5. Mas era uma resposta. E isso tem um valor enorme que a Microsoft subestimou por décadas.

WinForms: O Primeiro Divórcio

Em 2002, o .NET Framework chegou trazendo o Windows Forms — ou WinForms, pra quem frequentava os fóruns da época. A proposta era sedutora: arrastar componentes num designer visual, escrever C# em vez de C++, e ter uma aplicação rodando em minutos.

WinForms era basicamente um wrapper gerenciado sobre o Win32. Por baixo dos panos, seus botões e textboxes ainda eram controles nativos do Windows. Mas a produtividade era incomparável com MFC.

O problema? A Microsoft não substituiu Win32/MFC. Ela adicionou uma opção. Agora existiam duas respostas pra mesma pergunta. Mas tudo bem — WinForms era claramente o futuro, e Win32/MFC era legado. Pelo menos era o que todo mundo pensava.

WPF e XAML: A Revolução que Quase Foi

2006\. A Microsoft apresenta o Windows Presentation Foundation — WPF — junto com o Windows Vista. E a proposta era ambiciosa demais: uma engine de renderização totalmente nova, baseada em DirectX, com uma linguagem declarativa chamada XAML para definir interfaces.

WPF era lindo. Data binding bidirecional, templates de controle, animações suaves, resolução independente. Parecia o futuro. E em muitos aspectos, era o futuro — boa parte dos conceitos de UI que usamos hoje (binding, MVVM, layout declarativo) nasceram ali.

Mas aí veio a facada: o próprio Windows Vista não usava WPF. O shell, o Explorer, o Painel de Controle — tudo continuava em Win32 nativo. A Microsoft pediu pros desenvolvedores adotarem WPF, mas internamente recusou fazer o mesmo.

Snover explica esse ponto com precisão cirúrgica no blog dele. Existia uma guerra interna entre o time do Windows (que preferia C++ nativo) e o time do .NET (que empurrava código gerenciado). O resultado: WPF ganhou investimento inicial, mas nunca o comprometimento real da empresa.

Três respostas agora. WinForms pros pragmáticos. WPF pros visionários. Win32 pros que não confiavam em nenhum dos dois.

Silverlight: A Primeira Traição

Se existe um momento que marcou a quebra de confiança entre Microsoft e desenvolvedores, foi o Silverlight.

Lançado em 2007, o Silverlight era essencialmente WPF rodando no browser via plugin — a resposta da Microsoft ao Flash. A Microsoft investiu pesado em evangelismo. Conferências inteiras foram dedicadas ao Silverlight. Empresas migraram aplicações web complexas pra plataforma. O Netflix usava Silverlight. A NBC usava pra streaming das Olimpíadas.

E aí, em 2010, Steve Ballmer subiu num palco e disse que o futuro era HTML5.

Sem transição. Sem plano de migração. Sem aviso. Milhares de desenvolvedores e empresas que tinham investido meses ou anos em Silverlight ficaram com código que estava marcado pra morrer. O suporte oficial acabou em 2021, mas na prática morreu em 2012.

“The big problem was Silverlight was abandoned in a way that damaged developer trust irreparably. It wasn’t just deprecated — it was betrayed.” — Comentário com 200+ upvotes no Hacker News

Eu lembro de colegas que tinham feito certificação em Silverlight. Compraram livros, fizeram cursos, convenceram seus chefes a adotar a tecnologia. Foram todos deixados no vácuo.

Metro, Modern UI e o Desastre do UWP

O Windows 8 trouxe o Metro — aquela interface de tiles coloridos que ninguém pediu e que matou o menu Iniciar. Junto veio a WinRT, uma nova API que prometia unificar apps desktop e mobile (Windows Phone, alguém lembra?).

O problema do UWP (Universal Windows Platform) era ideológico: a Microsoft queria um ecossistema de apps estilo iOS/Android, com Store obrigatória, sandboxing restritivo e permissões granulares. Parece bom na teoria. Na prática, significava que seu app desktop perdia acesso ao sistema de arquivos, ao registro do Windows, a APIs COM — basicamente tudo que tornava uma aplicação Windows útil pra empresas.

// UWP: quer acessar um arquivo? Boa sorte.
var picker = new FileOpenPicker();
picker.SuggestedStartLocation = PickerLocationId.DocumentsLibrary;
picker.FileTypeFilter.Add(".txt");
var file = await picker.PickSingleFileAsync();
// O usuário tem que escolher manualmente. Sempre.
// Não, você não pode simplesmente File.ReadAllText("C:\\dados\\config.txt")

Desenvolvedores enterprise olharam pra isso, riram nervosamente, e voltaram pro WPF. Ou pro WinForms. Ou — e essa é a parte triste — pro Electron. Sim, apps em JavaScript empacotados com um Chromium inteiro ficaram mais atraentes que a plataforma nativa da Microsoft.

O Windows Phone morreu. A Windows Store nunca decolou. E o UWP ficou ali, como um monumento ao excesso de ambição sem execução.

WinUI 3: A Promessa Que Ninguém Acredita

Em 2021, a Microsoft anunciou o WinUI 3 como parte do Windows App SDK. A ideia: pegar a camada de UI moderna do UWP, remover o sandboxing e as restrições da Store, e oferecer como framework desktop “normal”.

Na teoria, WinUI 3 deveria ser a resposta definitiva. Na prática? O desenvolvimento é dolorosamente lento. Issues críticas no GitHub ficam abertas por anos. Features básicas que existiam no WPF há 18 anos ainda estão faltando.

A real é que o time de WinUI dentro da Microsoft é pequeno. Os recursos estão todos em AI, Azure, e Copilot. Interfaces gráficas desktop não geram a receita que um serviço cloud de $80 bilhões por ano gera.

E os desenvolvedores percebem isso. A discussão no repositório do WinUI no GitHub é brutal. Devs reportam bugs que ficam meses sem resposta. Features pedidas em 2022 continuam no backlog sem prazo.

.NET MAUI: O Xamarin que Não Deu Certo

Se WinUI é pra desktop, MAUI é a aposta multiplataforma — o sucessor do Xamarin.Forms. Um framework, um código, apps rodando em Windows, macOS, iOS e Android. O sonho “write once, run anywhere” que assombra a indústria desde os anos 90.

MAUI lançou em 2022 e, honestamente, parecia um beta público. Bugs por todo lado. Performance questionável. O hot reload — que era o recurso mais aguardado — travava mais do que funcionava. A cada novo .NET release, alguma coisa quebrava.

Um comparativo recente feito pelo time da Avalonia mostrou números constrangedores: em benchmarks de renderização no macOS, o Avalonia atingiu mais de 1.8 milhão de operações por segundo. O MAUI? 212 mil. Uma diferença de quase 9 vezes.

Benchmark de renderização (macOS):
┌─────────────┬──────────────────┐
│ Framework   │ Operações/seg    │
├─────────────┼──────────────────┤
│ Avalonia    │ 1,800,000+       │
│ MAUI        │ 212,000          │
│ WPF*        │ ~900,000         │
└─────────────┴──────────────────┘
* WPF só roda no Windows

O pior? A própria Microsoft quase não usa MAUI internamente. O Teams? Electron (agora parcialmente Edge WebView2). O Visual Studio? WPF. O Windows Terminal? WinUI. O Office? Win32 nativo com algumas partes em web. Nenhum produto principal da Microsoft usa o framework que eles dizem ser o futuro.

Avalonia: A Resposta que Veio de Fora

Diante do caos, a comunidade fez o que comunidades fazem: resolveu o problema sozinha. O Avalonia UI emergiu como a alternativa que a Microsoft deveria ter criado.

Avalonia é um framework .NET com XAML (parecido com WPF), mas que roda em tudo: Windows, macOS, Linux, iOS, Android, WebAssembly e até embedded. Tem o modelo de programação que desenvolvedores WPF já conhecem, mas sem a bagagem política da Microsoft.

O JetBrains adotou Avalonia pro Rider. O AvaloniaEdit é usado em dezenas de IDEs. E em março de 2026, a Avalonia anunciou suporte a MAUI backends, basicamente permitindo rodar apps MAUI com o renderizador do Avalonia — consertando os problemas de performance que a Microsoft não consertou.

A ironia é brutal: um projeto open source mantido por uma empresa relativamente pequena está entregando o que a Microsoft, com seus $3 trilhões de market cap, não consegue.

As 3 Causas-Raiz (Segundo Snover)

Jeffrey Snover, que viveu tudo isso por dentro, aponta três causas que se repetem em cada framework abandonado:

1. Política interna — O time do Windows e o time do .NET operavam como feudos rivais. Quando o time do .NET criava algo inovador (WPF), o time do Windows sabotava internamente ao não adotar a tecnologia nos próprios produtos do Windows. Quando o time do Windows tentava algo (UWP/WinRT), ignorava feedback dos desenvolvedores .NET que sabiam o que funcionava na prática.

2. Anúncios prematuros em conferências — A Microsoft tem um histórico terrível de anunciar tecnologias em keynotes antes de validar se elas fazem sentido. Metro, UWP, Silverlight para web — todas foram apresentadas com pompa máxima e morreram com um comunicado discreto.

3. Pivôs de negócio que abandonam devs — Cada vez que a estratégia de negócio muda — e na Microsoft muda a cada novo CEO ou reorganização — os frameworks que serviam a estratégia anterior são largados. Silverlight morreu quando mobile virou prioridade. UWP morreu quando a Windows Store falhou. MAUI sofre porque tudo agora é AI e cloud.

O Custo Real: Devs Migrando pra Web

O resultado mais concreto de tudo isso? Desenvolvedores pararam de confiar na Microsoft pra desktop.

Olha o que aconteceu nos últimos anos:

• Slack — Electron
• VS Code — Electron
• Discord — Electron (agora com partes em React Native)
• Figma — WebGL + web
• Notion — Electron
• 1Password — Electron (depois migrou pra Rust + web)
• Teams — Electron (depois Edge WebView2)

Apps que poderiam ser nativos, com performance nativa, usando APIs nativas, estão rodando dentro de um browser empacotado. E a culpa não é do Electron — é da Microsoft, que nunca deu uma resposta estável para “como eu faço um app desktop”.

Cada app Electron no Windows é um atestado de fracasso da estratégia de GUI da Microsoft. O desenvolvedor do Slack não escolheu Electron porque queria gastar 500MB de RAM num chat. Escolheu porque não queria reescrever o app de novo daqui a 3 anos quando a Microsoft pivotar.

E Agora? O Futuro Não é Promissor

Hoje, em abril de 2026, a documentação oficial da Microsoft reconhece seis frameworks como opções válidas para apps Windows: Win32, WinForms, WPF, UWP (sim, ainda listado), WinUI 3 e MAUI. Se você contar variações como React Native for Windows, WebView2 e Blazor Hybrid, o número passa de dez.

Snover é pessimista — e com razão. O flywheel que sustentava a era Petzold não existe mais. A receita da Microsoft hoje vem do Azure ($80B+/ano), não de licenças Windows. Desktop é custo, não receita. E nenhum VP vai investir pesado num framework de GUI quando poderia colocar esse dinheiro em AI e dobrar a receita do Copilot.

A aposta mais segura hoje, se você me perguntar? Depende do cenário:

Não existe resposta certa. E esse é exatamente o problema que Snover denuncia.

A Lição que a Microsoft Não Aprendeu

O que torna a análise do Snover tão dolorosa é que ele não está falando de incompetência técnica. A Microsoft tem — e sempre teve — engenheiros brilhantes. O WPF era tecnicamente excepcional. O UWP tinha ideias sólidas. Até o MAUI, debaixo dos bugs, tem uma arquitetura interessante.

O problema nunca foi técnico. Foi organizacional. É uma empresa gigante onde times competem entre si, onde estratégias mudam a cada ciclo orçamentário, e onde ninguém tem autoridade (ou incentivo) para dizer “esse é o framework, ponto final, pelos próximos 10 anos”.

Charles Petzold parou de escrever Programming Windows depois da sexta edição, em 2012. O livro que definia como criar apps no Windows simplesmente… parou. Porque o autor não sabia mais qual Windows cobrir.

Se isso não resume o problema, nada resume.

Fonte de inspiração: Microsoft Hasn’t Had a Coherent GUI Strategy Since Petzold — Jeffrey Snover