Eine simple Frage in einem Entwickler-Meeting brachte es auf den Punkt: „Welches Framework soll ich für eine neue Windows-Desktop-App verwenden?" Die Antwort war betäubendes Schweigen. Ein Entwickler schlug WPF vor, ein anderer WinUI 3, ein dritter fragte halbherzig, ob Electron nicht die einfachere Wahl sei. Eine Entscheidung fiel nicht. Diese Szene, die sich so oder ähnlich in zahllosen Teams weltweit wiederholt hat, beschreibt ein fundamentales Problem, das Microsoft seit über drei Jahrzehnten mit sich schleppt: das vollständige Fehlen einer kohärenten GUI-Strategie für Windows.
Als Windows noch eine klare Sprache sprach
Der Vergleich mit der Vergangenheit macht das Ausmaß des Problems erst greifbar. Im Jahr 1988 veröffentlichte Charles Petzold sein legendäres Buch über Windows-Programmierung – 852 Seiten, Win16-API in C, und dennoch eine kristallklare, autoritative Antwort auf die Frage, wie Windows-Anwendungen zu schreiben sind. Das war Strategie. Eine Plattform, eine Antwort, ein Weg. Entwickler wussten, woran sie waren.
Was folgte, war eine jahrzehntelange Abfolge von Frameworks, die einander ablösten, überlappten oder schlicht im Nichts verschwanden: Win32, MFC, COM, ActiveX, Windows Forms, WPF, Silverlight, WinRT, UWP und schließlich WinUI 3. Jede Generation brachte neue Versprechen mit sich – und neue Inkompatibilitäten. Entwickler, die in eine Technologie investierten, sahen sich regelmäßig von Microsoft im Stich gelassen, wenn die nächste „zukunftssichere" Lösung ausgerufen wurde.
Die Konsequenzen für den Markt
Die Auswirkungen dieses Strategieversagens sind weitreichend. Electron, das auf Chromium und Node.js basierende Framework, hat sich trotz seiner bekannten Performance-Probleme und des hohen Speicherverbrauchs zur De-facto-Lösung für viele Desktop-Applikationen entwickelt – nicht weil es technisch überlegen wäre, sondern weil es plattformübergreifend funktioniert und Entwickler nicht auf Microsofts nächsten Strategieschwenk warten müssen. Apps wie Visual Studio Code, Slack oder Discord basieren auf Electron. Das ist ein stilles Urteil über den Zustand des nativen Windows-Ökosystems.
Für Unternehmen bedeutet die Unklarheit konkrete Kosten: Fehlentscheidungen bei der Framework-Wahl binden Ressourcen, erzwingen spätere Migrationen und erhöhen die technische Schuld. Startups meiden native Windows-Entwicklung oft gänzlich und setzen von Anfang an auf Web-Technologien oder plattformübergreifende Lösungen wie Flutter oder .NET MAUI – wobei letzteres selbst wieder ein Zeichen dafür ist, dass Microsoft versucht, das Ruder herumzureißen, ohne dabei eine klare Richtung vorzugeben.
WinUI 3 und die Hoffnung auf Konsolidierung
Mit WinUI 3 und dem Windows App SDK unternimmt Microsoft seit einigen Jahren einen neuen Versuch, die Fragmentierung zu beenden. Der Ansatz ist technisch solide: WinUI 3 entkoppelt die UI-Schicht vom Betriebssystem und ermöglicht unabhängige Updates. Doch das Vertrauen der Entwickler-Community ist nachhaltig beschädigt. Zu oft wurden neue Frameworks als die endgültige Lösung angepriesen, nur um Jahre später stillschweigend in die zweite Reihe zu treten.
Solange Microsoft nicht in der Lage ist, die Frage „Wie baue ich eine Windows-App?" in unter zehn Sekunden eindeutig zu beantworten, bleibt das Ökosystem gespalten – und Entwickler werden weiterhin pragmatisch auf plattformunabhängige Alternativen setzen, egal wie elegant die native Lösung auf dem Papier aussehen mag.
Quellen: Hacker News