Kommentar: So kann Microsoft die Abwanderung von .NET-Entwicklern nicht stoppen
Microsoft ist über die letzten Jahre beim Thema Cross-Plattform-Entwicklung lediglich wenige Millimeter weitergekommen, so Dotnet-Doktor Holger Schwichtenberg.
(Bild: zeevveez CC-BY 2.0 (bearbeitet))
- Dr. Holger Schwichtenberg
Mein Kommentar vom 12. Mai 2017 hatte die Überschrift "Kann Microsoft mit XAML Standard die Abwanderung von Entwicklern stoppen?" Darin hatte ich eine der Neuankündigungen der Build 2017 diskutiert, die eine Vereinheitlichung der XAML-Dialekte von WPF, UWP und Xamarin.Forms bringen sollte und damit echte Cross-Plattform-Oberflächen mit der Extensible Application Markup Language (XAML) ermöglichen würde. Nun gebe ich – etwas frustriert – die Antwort auf die damalige Frage: "So kann Microsoft die Abwanderung von .NET-Entwicklern nicht stoppen!"
MAUI ist nicht viel mehr als Xamarin Forms
Die gestern auf der Build angekündigte .NET Multi-Platform App UI (MAUI) hat zwar einen vielversprechenden Namen, wird dem aber nicht gerecht. Denn sie läuft keineswegs auf allen wichtigen Betriebssystemen, sondern "nur" auf Android, iOS, macOS und Windows. Das Thema Linux überlässt Microsoft der Community. Dass Scott Hunter gestern in seinem Vortrag "The Journey to One .NET" in seiner Antwort auf die Frage nach dem Pinguin-Betriebssystem eine spätere Implementierung für Linux als "zu prüfen" deklariert hat, ist viel zu vage, um darauf irgendetwas zu bauen.
Jetzt können wir vortrefflich darüber streiten, wie wichtig GUI-Anwendungen auf Linux sind. Aber wenn Microsoft jetzt schon Linux-GUIs im Rahmen des "Windows Subsystem for Linux" (WSL) in Windows zum Laufen bringen will, wäre es doch nur konsequent gewesen, wenn man Linux-GUIs auch selbst unterstützen würde.
Zumal ja Xamarin.Forms heute schon Cross-Plattform-Entwicklung für Android, iOS und Windows (WinRT) bietet, mit Community-Unterstützung auch für Windows-Desktop, macOS und Linux-Desktop. Mit Ausnahme von Nebenschauplätzen wie dem vereinfachten Projektmodell und der Vereinheitlichung der Klassenbibliothek: Was ist eigentlich nun wirklich neu bei MAUI? Laut Vergleichstabelle auf GitHub nur, dass auch macOS und der Windows-Desktop direkt von Microsoft unterstützt werden, wobei letzteres ein Abfallprodukt davon ist, dass der UWP-Nachfolger "Windows UI Library 3" (WinUI 3) sowieso auch auf dem Win32-Desktop von Windows läuft. So betrachtet ist MAUI mehr alter Xamarin.Forms-Wein in neuen Schläuchen als eine echte Innovation in Richtung Cross-Plattform-Entwicklung.
Kein XAML Standard
Aber ich habe da noch mehr Mankos von MAUI identifiziert:
- MAUI soll erst im November 2021 erscheinen. Das wären dann viereinhalb (vergeudete) Jahre nach der Ankündigung von XAML Standard. Den für Dezember 2020 geplanten Erscheinungstermin der ersten MAUI-Version fasst direkt der erste Leser-Kommentar zu meiner Nachricht sehr gut zusammen: "Erst Ende nächsten Jahres ist sehr spät, wirklich schade."
- MAUI kocht (trotz einiger angekündigter Ergänzungen) syntaktisch weiterhin das Süppchen von Xamarin.Forms und macht die Migration bestehender WPF-Oberflächen zur größeren Aufgabe. Womit wir auch bei der Frage sind, was eigentlich aus dem groß angekündigten XAML Standard geworden ist? Leider gar nichts. Das Projekt ist seit November 2017 nicht mehr angerührt worden. Ich hatte im Mai 2017 schon von einem "Feigenblättchen vor Microsofts Blöße an der Cross-Plattform-UI-Front" gesprochen. Zu meinem größten Bedauern lag ich mit dieser Formulierung sehr richtig. Warum aus XAML Standard nichts geworden ist? Ich habe eine Antwort erhalten, die ich hier aber leider nicht wiedergeben darf.
Abschied in Richtung HTML
Die .NET-Entwicklergemeinde wartet seit Jahren auf eine vollumfassende XAML-basierte Cross-Plattform-Lösung für native Anwendungen von Microsoft, denn sehr viele Unternehmen haben Windows-Anwendungen auf Basis von WPF entwickelt, von denen einige aber nun unter dem Druck der (internen oder externen) Kunden stehen, die Software auch auf iOS- und Android-Smartphones und Tablets anzubieten. Gerade in dieser Gruppe war die Enttäuschung groß, als Microsoft im September 2019 zwar WPF für das plattformneutrale .NET Core veröffentlicht, aber als Basis für den Betrieb von WPF-Anwendungen nur Windows implementiert hatte.
Viele .NET-Entwickler haben aufgrund der fehlenden Cross-Plattform-Lösung inzwischen bei der Client-Entwicklung der .NET-Plattform den Rücken gekehrt und setzen stattdessen auf HTML und CSS mit JavaScript/TypeScript. .NET kommt oft noch auf dem Server zum Einsatz, in einigen Fällen wurde auch dieser auf Node.js umgestellt, um die Vorteile einer einheitlichen Programmiersprache auf Client und Server zu genießen. Wir haben in den letzten Jahren einige Dutzend Kunden im deutschsprachigen Raum beim Umstieg auf Webtechniken begleitet. Wer aber eigentlich von .NET aufgrund seiner Werkzeuge und Klassenbibliotheken begeistert ist, kann nur noch ein "wirklich schade" bringen.
Ich kann und will an dieser Stelle niemandem mehr raten, auf ein "plattformneutrales WPF" oder eine einfache Migrierbarkeit von WPF auf ein syntaktisch weitgehend kompatibles, anderes XAML-basiertes Benutzerschnittstellen-Framework zu warten. Ich persönlich habe das Warten mit dieser Build-Konferenz aufgegeben.
Wenn MAUI erscheint, wird der Aufwand der Migration von WPF groß sein, weil die Tags eben anders sind und es keinen XAML Standard geben wird. Dann kann man neue Cross-Plattform-Anwendungen mit MAUI schreiben, aber sicherlich nicht die großen WPF-Anwendungen umstellen.
Im Hier und Jetzt gibt es drei Optionen, wenn man aus der klassischen .NET-Welt kommend Cross-Plattform entwickeln will:
- Jetzt umsteigen auf Xamarin-Forms und dann migrieren auf MAUI (was wieder etwas, aber hoffentlich nicht so viel Arbeit machen wird)
- Auf Open-Source-Projekte außerhalb von Microsoft setzen wie Uno oder Avalonia
- Doch die Anwendung neu schreiben mit HTML und CSS mit JavaScript/TypeScript
Mit Option 1 bleibt man in der komfortablen .NET-Welt von Microsoft, erreicht aber dann eben bis auf Weiteres wieder nicht alle Plattformen. Option 2 kann ich unseren Unternehmenskunden nicht mit Überzeugung vermitteln, denn die meisten Geldgeber sind keine jung-agilen Start-ups, die sowieso alle paar Monate die Software über den Haufen werfen und auf der grünen Wiese mit dem aktuellsten Zeug neu starten, sondern mittlere und große, alteingesessene Unternehmen, die sich eine langfristige Stabilität und Unterstützung einer Lösung wünschen – ohne selbst die Ressourcen zu haben, gegebenenfalls die eigenen Hände an die Pflege eines GUI-Frameworks zu legen, wenn der Anbieter nicht mehr da ist und ihnen nur noch den Quellcode hinterlässt.
Blazor als Ausweg?
Wenn wir also bei Option 3 (HTML) angekommen sind, stellt sich noch die Frage, was ist mit den Blazor-Ankündigungen? Blazor ist ein Webframework zur Programmierung von Single-Page-Web-Applications (SPAs), die erste stabile Version von Blazor WebAssembly ist gerade erschienen. Auf der .NET Conf im September 2019 hatte Microsoft eine Ausweitung des Konzepts auf hybride und native Anwendungen angekündigt. Mittlerweile gibt es Projekte für Blazor Electron und Blazor WebWindows, um eine auf Linux, macOS und Windows hybride Desktop-App zu schreiben. Auch in Cordova kriegt man Blazor für iOS- und Android-Apps zum Laufen. Das offizielle Microsoft-Projekt "Blazor Mobile Bindings" verwendet allerdings XAML statt HTML.
(Bild: .NET Conf, 14. Januar 2020)
Hier nun XAML statt HTML einzusetzen, löst nicht das Cross-Plattform-Problem. Wenn wir schon kein Cross-Plattform-WPF-XAML bekommen, dann hätten wir wenigstens gerne ein Blazor mit HTML (Cross-Plattform-Web-UI) für wirklich alle Plattformen, also auch für die Mobilplattformen. Blazor innerhalb von MAUI zu hosten, wäre da nun eine naheliegende Option – wenn MAUI denn auch auf Linux laufen würde.
Dann können unsere Kunden zwar immer noch nicht die bestehenden WPF-Oberflächen in einer Cross-Plattform-App wiederverwenden, aber wenigstens die in C#-Code bestehenden Geschäftslogikimplementierungen frei auf Client und Server verteilen.
Mal schauen, wie viele Jahre das noch dauert. (ane)
