Silverlight versus HTML 5: Microsofts Strategie für Rich Clients

    SilverlightEin Interview mit Bob Muglia, President der Server and Tools Division bei Microsoft, sorgte für Aufregung, weil er eine neue Ausrichtung von Silverlight angekündigt und HTML 5 eine zentrale Position eingeräumt hatte. Die Aussage spiegelt insgesamt eine Neuorientierung bei der Entwicklung von Client-Anwendungen wider, die der neuen Heterogenität von Geräten und Betriebssystemen Rechnung trägt.

    Silverlight startete 2007 als Konkurrenz zu Flash und verfolgte daher einen plattformübergreifenden Ansatz zur Entwicklung von Rich Internet Applications (RIAs). Eine Laufzeitumgebung für mehrere Betriebssysteme und Plugins für die gängigsten Browser sollten sicherstellen, dass Silverlight-Anwendungen weite Verbreitung finden. Wie Flash war es vor allem für Programme gedacht, die sich nicht mit Web-Standards wie HTML, CSS und Javascript realisieren ließen.

    IE9 stellt die Weichen für HTML 5

    Die konsequente Unterstützung von HTML 5 im Internet Explorer 9 war bereits ein klares Indiz dafür, dass Microsoft seinen Standpunkt revidierte, wonach der Browser ein dummer Client sei und für anspruchsvollere Aufgaben proprietäre Techniken wie Silverlight nötig seien.

    Bob Muglia und Steve Ballmer im Interview mit Gartner-Analysten (ab 2:00) stellen nun klar, dass Microsoft den Cross-Plattform-Anspruch für Silverlight aufgibt und die Technologie neu positioniert. Für RIAs, die auf möglichst vielen Systemen laufen sollen, lassen sie HTML 5 den Vortritt und folgen damit dem Rest der Industrie, der ebenfalls diesen Kurs fährt.

    Entwickler befürchten Aus für Silverlight

    Die Stellungnahme von Bob Muglia wurde von vielen Entwicklern als Ende für Silverlight aufgefasst und führte zu teils heftigen Reaktionen, die den Microsoft-Manager zu einer Klärung seiner Position veranlasste. Sieht man vom üblichen Markting-Brimborium ab, dann lautet die Kernaussage, dass Silverlight künftig als Technologie zur Entwicklung von Client-Anwendungen unter Windows dient.

    Allerdings bleibt dabei weiterhin die Anforderung bestehen, dass Silverlight-Anwendungen auf verschiedenen Plattformen ablaufen sollen, auch wenn sie alle Windows heißen. Die Technik soll wie bisher nicht nur wie bisher den Desktop abdecken, sondern das bevorzugte Programmmodell für das Windows Phone 7 werden.

    Silverlight für Rich Clients auf allen Windows-Varianten

    Auch hier gilt weiter die alte Devise, dass Silverlight dort seine Plattform-spezifischen Fähigkeiten ausspielen soll, wo HTML an seine Grenzen stößt. Nachdem HTML 5 jedoch wesentlich leistungsfähiger ist als seine Vorgänger, stehen Entwickler in vielen Fällen vor der Wahl, entweder eine für Windows optimierte Anwendung mit Silverlight zu schreiben oder mit gewissen Abstrichen mittels HTML praktisch alle Arten von Clients zu erreichen.

    Allerdings heißt das noch lange nicht, dass die Entscheidung für Silverlight automatisch zu Anwendungen führt, die perfekt auf alle Varianten von Windows abgestimmt sind. Die Positionierung der Technik vom Desktop bis zum Smart Phone verlangt spezifische Ausprägungen von Silverlight für verschiedene Geräteklassen. So hat eine Reihe von APIs, die für den Desktop entwickelt wurden, auf dem Windows Phone 7 keinen Sinn und wird nicht unterstützt.

    Eingeschränkte Portabilität durch fragmentierte APIs

    Microsoft ist daher gezwungen, Silverlight zu segmentieren und einen ähnlichen Weg zu beschreiten, wie Sun vor Jahren mit der Java 2 Micro Edition (ME). Auch hier stellte sich das Problem, mit einer übergreifenden Programmiertechnik diverse Geräte mit unterschiedlichen Formaten und Funktionen abzudecken. Sun entschied sich für die Definition von Profilen für bestimmte Geräteklassen, die eine Teilmenge des Java-API umfassten.

    Das wichtigste davon war das Mobile Information Device Profile (MIDP), das Hersteller von Hardware jedoch bei Bedarf um zusätzliche Java-Schnittstellen erweitern konnten. Dies beeinträchtigte jedoch die Portabilität von J2ME-Anwendungen. Im Vergleich zu Java hat Microsoft jedoch den Vorteil, dass durch die Aufgabe des Cross-Plattform-Anspruchs die Zahl der potenziellen Endgeräte deutlich geringer ist.

    Microsoft definiert nun im Portable Library Project einen Kern von APIs, die zwischen den verschiedenen Silverlight-Implementierungen portabel sein sollen. Entwickler können dann innerhalb von Visual Studio die gewünschten Zielsysteme angeben und bekommen über die Type-ahead-Funktion der IDE nur jede Funktionen angezeigt, die zu den gewählten Plattformen passen.

    Optimale Benutzererfahrung fraglich

    Mit diesem Ansatz läuft Microsoft Gefahr, dass Silverlight genau wie HTML 5 zum kleinsten gemeinsamen Nenner wird, zumindest für jene Anwendungen, die am Desktop und am Windows Phone laufen sollen. Dann kann es gerade nicht die spezifischen Vorzüge des jeweiligen Windows ausspielen. Aber genau die reichhaltigste Benutzererfahrung soll laut Bob Muglia durch die Neupositionierung von Silverlight erreicht werden, weil ein umfassender Cross-Plattform-Support nicht mehr auf der Tagesordnung steht.

    Die Java-Welt ist übrigens gerade dabei, die Portabilitätsprobleme zwischen einer Vielzahl von Client-Geräten nochmal zu erfahren. Gleichzeitig mit Silverlight 1.0 kam JavaFX auf den Markt, das Client-Anwendungen für die JVM auf Basis einer Scriptsprache erstellen kann und ebenfalls für die Entwicklung von RIAs gedacht war. Auch wenn Oracle an JavaFX festhält, während es sonst die Java-Gemeinde nach Kräften verunsichert, ist längst die Debatte um die Zukunft von JavaFX entfacht. Microsoft kann sich darüber kaum freuen, denn es steht mit Silverlight als Cross-Windows-Technik vor ähnlichen Problemen.

    3 Kommentare

    Bild von Thomas Maierhofer
    9. Januar 2012 - 18:15

    Der Autor hat die Zeilsetzung der "Portable Class Library" nicht verstanden. In einem Typischen Multiplattform Projekt werden nur die gemeinsamen Teile in einer "Portable Class Library" zusammengefasst. Es gibt sehr wohl plattformspezifische Teile, die für jede Plattform getrennt entworfen werden. Von kleinstem Gemeinsamen Nenner kann also kaum die Rede sein. Die "Portable Class Library" bietet insbesondere die Möglichkeit Libraries zwischen .NET und Silverlight zu sharen. Z.B. WCF Conracts. Somit stellt die PCL eher eine Brücke zwischen Client und Server dar.

    Bild von Wolfgang Sommergut
    9. Januar 2012 - 21:34

    >In einem Typischen Multiplattform Projekt werden nur die
    >gemeinsamen Teile in einer "Portable Class Library"
    >zusammengefasst. Es gibt sehr wohl plattformspezifische
    >Teile, die für jede Plattform getrennt entworfen werden.

    Steht nicht genau das in meinem Text? Aber wahrscheinlich habe ich den Kommentar auch nicht verstanden...

    Bild von Thomas Maierhofer
    10. Januar 2012 - 4:25

    Sie sagen doch damit aus dass es ein Portable Library Projekt gibt und deshalb alles auf den kleinsten gemeinsamen Nenner gebracht wird. Oder hab ich Sie da missverstanden?

    In Ihrem Artikel wird nicht ausgedrückt dass die PCL nur ein Instrument zum Code Sharing zwischen den Plattformen ist und dass eine PCL gerade keine Code der Benutzeroberfläche teilt? Gerade die "reichhaltige Benutzererfahrung" bzw das Anwendererlebnis wird im derzeitigen Stand für jede Plattform getrennt implementiert.

    Vor kurzem wurde SL5 freigegeben. Wenn man sich die API Erweiterungen mal genauer anschaut erkennt man durchaus wo es zukünftig langgehen soll. "Trusted Out of the Browser Applications" ist hier das Stichwort. Im Detail wurde gerade auch bei der Datenbindung - Stichwort RelativeSource AncestorType und ICustomTypeProvider - die Lücke zur WPF geschlossen bzw mit dem kommenden .NET Framework 4.5 die Plattformen vereinheitlicht.

    Silverlight entwickelt sich zusehends zum universellen Client Frontend für .NET Applikationen und stellt immer mehr eine Alternative zum wenig erfolgreichen XBAP oder OneClick Deployment von z.B. WPF Applikationen dar.

    Auch der permanente Vergleich von HTML5 mit Silverlight (jetzt nicht nur speziell in diesem Artikel) ist hanebüchener Unsinn. HTML5 ist nach wie vor eine Markup Language mit dem ein Inhalt präsentiert wird. Mit HTML5 allein kann man keine Stand Alone Anwendung erstellen. Man benötigt immer ein Web Server Backend (ASP, PHP,...) um die Anwendungslogik zu fahren.

    Silverlight war von der ersten Sekunde an ein Application Framework mit dem man eine Anwendung programmiert. Silverliht Anwendungen sind echte Applikationen die natürlich völlig unabhängig von irgendwelchen Web Servern laufen. Eine Silverlight Applikation benötigt im Client/Server Umfeld überhaupt keinen Web Server. Ein Silverlight Client kann über WCF direkt auf einen im App-Server gehosteten Web Service zugreifen. Die Internetseite ist dann faktisch nur der Deployment Mechanismus für die Applikation. Und das macht Silverlight gerade im Intranet und Extranet spannend.

    Im Bezug auf die Plattformen kann von einem KLEINSTEN gemeinsamen Nenner kaum gesprochen werden. Es ist gerade andersherum Silverlight wird immer mehr zum GRÖSSTEN gemeinsamen Nenner und zusehends mit der WPF vereinigt.