Waarom de GUI-strategie van Windows zo’n chaos

Voormalig CTO van Microsoft onthult hoe decennia aan GUI-wijzigingen verwarring en fragmentatie hebben veroorzaakt voor Windows-ontwikkelaars.

We hebben eerder besproken waarom de Windows 11 GUI inconsistent is: sommige verouderde interfaces maken nog gebruik van legacy-elementen. Maar er is een groter probleem: de verwarrende GUI-strategie van Microsoft voor ontwikkelaars heeft geleid tot een zeer gefragmenteerde technologie-stack.

Uit een recente blogpost van voormalig CTO Jeffrey Snover krijgen we meer inzicht in hoe de GUI-strategie van Microsoft de afgelopen decennia ontspoord is. Snover neemt ons mee terug naar de jaren ’80, naar de tijd van Win16 en Win32 API’s, geschreven in C, die op een uniforme manier door alle Windows-ontwikkelaars gebruikt konden worden. Hij verwijst ook naar het 852 pagina’s tellende boek Programming Windows van Charles Petzold, dat gold als hét handboek voor desktopapplicatie-ontwikkeling.

In de jaren ’90 probeerde Microsoft de beperkingen van Win32 te omzeilen met MFC, COM, OLE en ActiveX. Hoewel dit geen GUI-frameworks zijn, waren het componentarchitecturen die volgens Snover “elke hoek van Windows-ontwikkeling besmetten en een grote cognitieve complexiteit introduceerden”. Deze versnippering zorgde ook voor grote verwarring tijdens belangrijke Microsoft-presentaties. In plaats van een helder verhaal over technologieën te vertellen, probeerde het bedrijf indruk te maken op het management tijdens evenementen die Snover omschrijft als een “keynote-chaos”.

In 2003 toonde Microsoft Windows Longhorn, met een indrukwekkende technische visie en Avalon (later WPF genoemd), een GPU-versnelde, vectorgebaseerde UI-subsystem genaamd XAML. Maar in augustus 2004 maakte Microsoft een draai en kondigde aan dat alle nieuwe ontwikkeling in C++ moest gebeuren. WPF verscheen wel in Windows Vista, maar de Windows-shell gebruikte het zelf niet. Dit leidde tot onenigheid tussen de Windows- en .NET-teams, wat intern tot conflicten leidde en uiteindelijk resulteerde in het “verlaten” van WPF, het afsterven van Silverlight en de mislukking van het Universal Windows Platform (UWP).

In 2006 was duidelijk dat WPF een krachtige technologie was. Toch koos Microsoft opnieuw een andere weg en lanceerde Silverlight in 2007. In 2010 raakten Silverlight-ontwikkelaars onaangenaam verrast toen Microsoft aankondigde dat Silverlight niet bedoeld was voor cross-platform toepassingen en dat HTML5 de toekomst was in dat gebied. Silverlight werd daarmee gereduceerd tot alleen Windows Phone-ontwikkeling.

In 2012 werd Windows 8 aangekondigd, met een native C++ runtime in WinRT. De persoonlijke wrok van het Windows-team tegenover .NET zorgde ervoor dat een decennium aan investeringen in die technologie ineens stopgezet werd. Snover vat de situatie treffend samen:

“Binnen Microsoft werden tegelijkertijd twee verhalen verteld. Het Windows-team bouwde WinRT, het .NET-team bleef WPF promoten. Verschillende gebouwen, verschillende vice-presidenten, verschillende roadmaps.

Wat ontwikkelaars hoorden op //Build 2012: de toekomst is WinRT, HTML+JS is ook belangrijk, .NET werkt nog steeds, C++ is terug, je moet Metro-apps schrijven, en je WPF-code werkt nog prima. Dat is geen strategie. Het is een Hunger Games waarbij zes teams vechten om jouw aandacht.

Enterprise-ontwikkelaars zagen UWP’s sandboxing, verplichtingen via de Store, en ontbrekende Win32 API’s en lieten het links liggen. Het framework dat hen moest moderniseren, was geoptimaliseerd voor een tablet-appstore die nooit kwam.”

Nu, in het huidige tijdperk dat volgens Snover in 2015 startte, heeft UWP een sterke visie, maar maakt Microsoft’s eigen producten er nauwelijks gebruik van. De communicatie uit Redmond blijft onduidelijk en springt heen en weer tussen WPF, UWP, Project Reunion, WinUI 2, WinUI 3 en meer. De afgelopen 14 jaar heeft Microsoft 14 keer van koers veranderd wat betreft aanbevolen GUI-frameworks en technologieën voor Windows-ontwikkeling.

Als gevolg daarvan bevat Windows nu 17 GUI-technologieën die draaien op vijf verschillende programmeertalen:

• Microsoft native frameworks:
  • Win32 (1985) – Nog altijd in gebruik. Petzold’s boek blijft relevant.
  • MFC (1992) – C++ wrapper voor Win32. In onderhoudsmodus. Wordt vooral gebruikt in enterprise en CAD.
  • WinForms (2002) – .NET-wrapper voor Win32. “Beschikbaar maar afgeraden.” Nog steeds snel voor data-invoerformulieren.
  • WPF (2006) – XAML, DirectX-rendering, open source. Er wordt niet meer door Microsoft geïnvesteerd.
  • WinUI 3 / Windows App SDK (2021) – Het ‘moderne’ antwoord. Toekomst onzeker.
  • MAUI (2022) – Cross-platform opvolger van Xamarin.Forms. De huidige inzet van het .NET-team.
• Microsoft web-hybrid:
  • Blazor Hybrid – .NET Razor-componenten in een native WebView.
  • WebView2 – Embed Chromium in Win32/WinForms/WPF-apps.
• Derden:
  • Electron – Chromium + Node.js. VS Code, Slack, Discord. De meest gebruikte desktop GUI-technologie op Windows, en Microsoft had er niets mee te maken.
  • Flutter (Google) – Dart, custom renderer, cross-platform.
  • Tauri – Rust-backend, lichte Electron-alternatief.
  • Qt – C++/Python/JavaScript. Serieuze cross-platform optie.
  • React Native for Windows – Microsoft-ondersteunde port van Facebook’s mobiele framework.
  • Avalonia – Open source spirituele opvolger van WPF. Gebruikt door JetBrains, GitHub, Unity – ontwikkelaars die geen geduld meer hebben met Microsoft.
  • Uno Platform – WinUI API’s op elk platform. Meer toegewijd aan WinUI dan Microsoft zelf.
  • Delphi / RAD Studio – Nog steeds in gebruik. Snel en populair in nichemarkten.
  • Java Swing / JavaFX – Ja, nog steeds in productie. Enterprises vergeten nooit.

Jeffrey Snover noemt de huidige situatie een “boof-a-rama” – een term die hij zelf bedacht om aan te geven dat “briljante mensen stomme dingen doen”. De voormalige topmanager benadrukt dat de technologieën die Microsoft promootte zelden slecht waren. Ze werden vaak vroegtijdig afgeschoten door interne politiek, onverwachte koerswijzigingen gepresenteerd op conferenties of verwarrende bedrijfsstrategieën die ontwikkelaars in de steek lieten.

Waarschijnlijk is deze onvoorspelbare fragmentatie de reden dat Petzold stopte met het schrijven van Programming Windows na de zesde editie, die Windows 8/WinRT besloeg in 2012.

Hoewel sommige anekdotes in Snover’s uitgebreide blogpost subjectief kunnen zijn, is zijn analyse zeer betrouwbaar door zijn grondige kennis van Microsoft’s interne werkwijze. Hij werkte 23 jaar bij Microsoft, klom op van Partner Architect tot Distinguished Engineer (2009), Technical Fellow en Chief Architect (2015) en CTO (2019). Hij verliet Microsoft in 2022 en werkte daarna bij Google tot 2025, waarna hij met pensioen ging.