Modern Silverlight = Totgeburt?

Silverlight empfand ich als eine produktive Plattform für anspruchsvolle Anwendungen und mit etwas Geschick konnte man viel Code mit einer WPF-Anwendung teilen. Leider ist Silverlight an sich tot und wird von Microsoft nicht mehr weiterentwickelt. Interessanterweise gibt es Frameworks/Plattformen, welche die Silverlight-Experience auf technischer Basis von HTML5 aufleben lassen. Ich nenne dies einmal Modern Silverlight:

C#/XAML for HTML5

http://www.cshtml5.com

Fayde

http://fayde.io

Granular

https://github.com/yuvaltz/Granular

Auf Basis von HTML5 lassen sich als Hybrid-Lösungen dann natürlich auch Mobile Apps damit entwickeln – etwas wozu Silverlight nicht fähig war.  Grund genug sich diese Nachfolger einmal genauer anzuschauen.

Sehr interessant zu diesem Thema ist auch ein Beschwerde-Blog, der doch tatsächlich versucht Microsoft davon zu überzeugen, dass sie bitte ein Cross-Plattform-Programmiermodell anbieten sollen.

Die große Enttäuschung

Auf den ersten Blick sehen diese 3 Tools extrem vielversprechend aus. Klar war von Anfang an, dass sie nicht den gesamten Funktionsumfang von WPF bzw. dem alten Silverlight liefern werden, aber der aktuelle Stand war doch eine große Enttäuschung.

Das Grundprinzip der Tools ist ähnlich. Zwei der Tools, namentlich C#/XAML for HTML 5 und Granular, arbeiten mit einem C#-to-JavaScript Transpiler, der C#-Code nach JavaScript konvertiert. Auf dieser Ebene sieht es eigentlich schon ganz gut aus. Granular benutzt z.B. Saltarelle, C#/XAML for HTML 5 benutzt JSIL. Die Transpiler sind nicht perfekt, aber laufen meiner Ansicht nach robust und zuverlässig. Auch kann man erkennen, wie dynamisch da die Entwicklung aktuell ist. Nebenbei: die JavaScript-Engine als eine Art neue JVM zu sehen, die nur noch als Host-Runtime für diverse Sprachen und Plattformen dient, ist nicht mehr ganz so neu.

Auf der Basis der 3rd-Party-Transpiler laufen nun die eigentlichen XAML Engines. Im Falle von Fayde schreibt man seinen Client Code mit TypeScript, was ich persönlich keine große Einschränkung finde. Aber bei den eigentlichen “XAML Engines” hakt es noch gewaltig.

C#/XAML for HTML5

Von der Developer Experience ist C#/XAML for HTML5 schon einmal sehr gut. Nach der Installation ist eine Integration in Visual Studio inkl. eines Projekttemplates und sogar ein rudimentärer Designer/Live-Preview vorhanden. Man merkt schnell: hinter diesem Produkt steht eine Firma, die ein kommerzielles Produkt entwickeln will. Absolut positiv!

Doch positive Gefühle sind beim ersten coden primitivster GUIs schnell verflogen. Elementarste WPF-Features wie Trigger und DataTrigger werden nicht unterstützt und die ComboBox-Klasse wird einfach in ein HTML-<select> Element konvertiert. Dass dieses in allen Browsern anders gestellt wird, wird vom Hersteller wohl ignoriert.

Nun ja, es handelt sich um eine Beta und einige der WPF-Funktionen werden vielleicht später noch nachgerüstet. Aber meine Kritik geht noch weiter. Ich habe schon ein fundamentales Problem mit der XAML-Engine an sich. Die Engine übersetzt XAML in DOM-Knoten.
Ich kann mir einfach nicht vorstellen, dass man auf diesem Weg zum Ziel kommt. Selbst wenn die Engine prinzipiell funktioniert und in allen Browsern unterstützt wird – was eine große Herausforderung für den Hersteller wird – wenn irgendwo ein Problem auftritt (und jeder, der ernsthafte Anwendungen entwickelt, weiß: es werden Probleme auftreten!), muss man sich plötzlich mit zwei komplexen Stacks auskennen: XAML und HTML.

Ein weiteres Problem daran XAML in DOM-Elemente zu konvertieren, liegt im Bereich der Performance. Große DOMs performant zu programmieren ist eine enorme Herausforderung. Jetzt kann man zwar sagen: kein Problem, dafür gibt es ja GUI-Virtualisierung! Aber zum einen hat C#/XAML for HTML5 aktuell da keine Unterstützung, zum anderen ist eine GUI-Virtualiserung alles andere als trivial. Anwendungen wie Excel Online zeigen, dass dies möglich ist, aber wenn man sieht, wie viele Frameworks sich um Themen wie Virtual DOM kümmern: da ist viel Bedarf, aber höchste Komplexität vorhanden. Dass es dem Hersteller gelingt diese Komplexität vor dem Entwickler zu verstecken, das bezweifle ich.

Schon zum aktuellen Zeitpunkt lege ich mich für dieses Produkt fest: C#/XAML for HTML5 ist eine Totgeburt. Zwar ermöglicht es eine vielen Entwicklern lieb gewonnene Syntax und einige bekannte Konzepte im Browser zu benutzen, aber für ernsthafte Anwendungen stellt die Erlernung einer Syntax und Programmiersprache (sprich: JavaScript/TypeScript+Frameworks) das absolut kleinste Hemmnis dar. Fazit: nicht konkurrenzfähig mit state-of-the-art JavaScript Frameworks wie AngularJS oder Knockout.js.

Fayde

Fayde verfolgt einen etwas anderen Ansatz und verzichtet auf den Einsatz von C#. Stattdessen muss im Client mit TypeScript gearbeitet werden. Mir gefällt daran schon einmal, dass es nicht darauf setzt, ein Produkt zu schaffen, was mit reiner Vertrautheit punktet, sondern was gute Konzepte von WPF/Silverlight verwendet und es in die Welt des Web überträgt.

Was mich am Anfang als altergedienter User von Visual Studio etwas irritiert hat, aber dann durchaus positiv überzeugt hat, ist der Fakt, dass Fayde vom gesamten Programmierworkflow auf Web-Tools wie NPM, Bower, Grunt und Yeoman setzt. Wenn man die Tools noch nicht kennt, dann ist das Handling via Kommandozeile doch sehr ungewohnt, aber die Tools sind robust und mit etwas Eingewöhnung sogar cool.

Fayde könnte aus einem Grund funktionieren: Es versucht nicht XAML und Controls in DOM-Elemente zu konvertieren. Stattdessen enthält es eine Rendering-Engine, die final auf eine HTML5-Canvas zeichnet. Hier ist die Cross-Browser-Umsetzung kein Problem. Maximal das Rendering von Fonts könnte Browser-abhängig in Härtefällen abweichen.

Leider ist Fayde ebenso nicht wirklich produktiv einsetzbar, denn es hat noch einige Bugs. Zwar gibt es eine sehr imposante Demo-Anwendung, die demonstriert, dass die Vektor-Rendering-Engine prinzipiell auch für komplexe GUIs funktioniert – aber anderseits zeigt ein primitiver Button noch ein völlig falsches Layoutverhalten, wenn nur die Fenstergröße verändert wird.

Und auch Trigger und DataTrigger werden hier – ebenso wie in C#/XAML for HTML –  nicht unterstützt. Das MVVM-Konzept ist schon stark in Fayde eingebacken, daher überrascht mich die fehlende Unterstützung schon. Mir ist schlicht nicht klar, wie man komplexe GUIs in MVVM ohne  dieses Konzept programmieren soll. Als WPF-Anfänger habe ich einige Zeit mit Konvertern gearbeitet – diese werden unterstützt – aber außer für einfache Aufgaben, wie das Ausblenden via des BooleanToVisibilityConverters, taugen diese meiner Ansicht nach nichts. In WPF war das vielleicht eine Philosphiefrage. Da ich nicht weiß, ob DataTrigger die führende Philosophie darstellen, nehmen wir dies vielleicht einmal aus der Bewertung der Silverlight-Nachfolger heraus. Mich persönlich schmerzt das Fehlen dieser Features aber stark.

Da ich denke, dass Fayde einen besseren Ansatz als C#/XAML for HTML verfolgt, ist es tragisch, dass es als Open-Source Projekt aktuell im Kern von einem Entwickler abhängt. Das Projekt war um 2014/2015 offenbar schon einmal aktiver als aktuell. Open-Source Communities funktionieren nach ihren eigenen Regeln. Hier ist leider bisher noch nichts extrem Fruchtbares entstanden.

Granular

Granular habe ich nicht erfolgreich getestet, daher rührt meine Meinung nur aus einer fehlgeschlagenen Nutzung und einer Live-Demo. Anhand der Live-Demo kann man aber sehen, dass die XAML-Engine als Resultat DOM-Knoten erzeugt, d.h. der Ansatz von C#/XAML for HTML5 genutzt wird. Nur dass hier eine lächerlich komplexe Installation/Einrichtung notwendig ist, an der ich selbst gescheitert bin. Also werden hier die schlechten Eigenschaften von C#/XAML for HTML5 und von Fayde kombiniert.

Warum überhaupt Modern Silverlight?

Das Programmiermodell von Silverlight und WPF war schon gut, aber ist dies alleine ein Grund dafür eine Nachfolgetechnologie zu fordern? Heutzutage gibt es v.a. eine Herausforderung: man muss viele Plattformen bespielen. Man muss mindestens eine App für iOS und Android liefern. Vielleicht muss man im Web und vielleicht sogar auf dem Desktop laufen. Zu Zeiten von Silverlight konnte man den Desktop (via WPF) und den Browser (via Silverlight) abdecken. Das stand doch gar nicht in der Einleitung des Blogs, worum geht es also? Aber mal ganz ehrlich: es geht doch nicht darum ein Programmiermodell vom Desktop (WPF) ins Web zu übertragen. Wir wollen heutzutage die genannten Plattformen von einer Quellcodebasis aus bespielen. Zwei der vorgestellten Lösungen taugen meiner Meinung nach nicht, um wirklich alle Plattformen und Devices abzudecken. XAML  ist eine tolle Abstraktion und wenn ich mir Knockout.js oder Angular ansehe, dann sehe ich dort viele Konzepte von XAML verwirklicht und weiterentwickelt.

Was einen Silverlight-Nachfolger v.a. attraktiv macht, das ist XAML. Mit XAML kann man WPF-Anwendungen, Anwendungen auf Basis der Windows Runtime, Windows Universal Apps, mit Hilfe von Xamarin (Forms) Apps für iOS und Android bauen. Nur den Webbrowser konnte man mit XAML bisher nur via Silverlight abdecken. Insofern schmerzt dessen Aussterben schon. Aber das Teilen von Code über Xamarin Forms und WPF ist auch nicht trivial. UWP ist etwas komplett anderes als WPF. Ein wirkliches Cross-Plattform-Modell wird bisher durch nichts geboten – außer durch HTML5. Mittels Cordova kann man alle mobilen Plattformen unterstützen und mittels Node.js und Tools wie nw.js sogar den Desktop.

HTML5 in Kombination mit diversen Framworks wie z.B. Angular JS, Cordova, Ionic und nw.js bietet ein mächtiges Ökosystem. XAML hat durchaus Stärken, aber die Silverlight-Nachfolger sind mir aktuell viel zu unausgereift, um da nur ansatzweise mitzuhalten.

Auch wenn mir XAML ein stückweit ans Herz gewachsen ist, am Ende zählt die Plattform-Abdeckung, Qualität und Produktivität. HTML5 hat da aktuell die Nase meilenweit vorne. Modern Silverlight ist eine Totgeburt.