Die reiche Qual der Wahl

RIA-Technologien im Kurzvergleich
Kommentare

Rich Internet Applications (RIA) sind in – aber womit soll man diese dynamischen, webbasierten Anwendungen erstellen? Es gibt viele verschiedene Technologien, über deren Vor- und Nachteile man fantastische und fanatische Diskussionen führen kann. Wir stellen die wichtigsten Möglichkeiten vor.

Der Begriff Rich Internet Applications wird ursprünglich Macromedia und damit heutzutage Adobe zugeschrieben. Hintergedanke war seinerzeit, dass Websites mit integrierter Flash-Applikation mehr sind als nur die bekannten statischen Websites, sondern eben „reich“: Reich an Features, reich an Möglichkeiten.

Nach und nach haben auch andere vergleichbare Technologien den Anspruch erhoben, mit ihnen könne man RIAs implementieren. Der Begriff RIA wird aktuell unabhängig von bestimmten Techniken oder Firmen verwendet und ist eine allgemeine Bezeichnung für moderne Anwendungen, die im Webbrowser laufen. Das „Moderne“ einer Anwendung ist ein relativ schwammiger Begriff; meist wird damit in Verbindung gebracht, dass die Anwendung selbst gar nicht mehr wie eine herkömmliche Website aussieht, sondern sehr nahe an etwaigen Desktop-Pendants ausgerichtet ist. Aktuelle Webmail-Dienste wie die von Google, Microsoft und Yahoo! zeigen sehr gut, was eine RIA sein kann: Teilweise werden Features wie Tastatursteuerung und Drag-and-Drop unterstützt, was herkömmliche Websites nicht bieten können. Übrigens, auch die aktuelle Wikipedia-Definition von RIAs ist nicht besser: „Der Begriff beschreibt eine Anwendung, die Internet-Techniken benutzt und eine intuitive Benutzeroberfläche bietet“ – äh ja, genau.

Der Sinn und Zweck dieses Artikels soll nicht sein, eine eindeutige Präferenz für oder wider eine Technologie darzustellen. Auch ist es nicht unser Ansinnen, eine komplette Liste von Techniken, inklusive aller Exoten, aufzuführen. Stattdessen werfen wir einen Blick auf diejenigen Möglichkeiten, die wir selber in den letzten Jahren in Praxisprojekten einsetzen konnten. Dabei halten wir natürlich mit unserer eigenen Meinung nicht hinterm Berg, möchten aber dennoch den verschiedenen Technologien jeweils ihren Platz einräumen und fair die jeweiligen Hintergründe und Eigenheiten vorstellen.

AJAX

Als Microsoft ungefähr 1998 ein neues ActiveX-Objekt für den Internet Explorer implementierte, das es ermöglichte, HTTP-Anfragen an einen Server zu schicken (das war bereits vorher mit JavaScript möglich) und die Rückgaben auszuwerten (das war mehr oder minder neu), hatten die Redmonder Entwickler keine RIAs im Sinn. Stattdessen ging es eher darum, eine Feature-Anfrage des Teams von OWA (Outlook Web Access) zu erfüllen, dem Web-Frontend von Outlook. Damit auf ActiveX zu setzen war natürlich nicht die beste Entscheidung, aber der prinzipielle Ansatz war sehr gut – so gut, dass auch die Entwickler der anderen Browser die Funktionalität nachgerüstet haben, natürlich ohne ActiveX. Mittlerweile unterstützen alle modernen Browser dieses XMLHttpRequest getaufte JavaScript-Objekt, der Internet Explorer 7 übrigens auch ganz ohne ActiveX.

Das alleine wäre wohl immer noch nicht sonderlich berichtenswert, aber ein Artikel des kalifornischen Usability-Beraters Jesse J. Garrett führte ganz überraschend zu bahnbrechenden Auswirkungen. Im Artikel nämlich schafft Garrett den Begriff AJAX, als Akronym für „Asynchronous JavaScript + XML“. Seitdem hat er häufig Kritik für den Begriff eingesteckt („and“ wird nicht abgekürzt, XML wird praktisch gar nicht für diese Art von Anwendungen eingesetzt), aber gleichzeitig dafür gesorgt, dass sich technisch affine und nicht affine Personen gut über moderne Webanwendungen unterhalten können – AJAX-Anwendungen eben. Und von AJAX zu RIA ist es kein großer Schritt.

Abb. 1: Anfang 2005 fing alles an: Jesse J. Garrett erfindet den Begriff AJAX

AJAX ist keine Technologie an sich, sondern ein Mix aus vorhandenen Technologien: XHTML, CSS, DOM und natürlich JavaScript (inklusive XMLHttpRequest). Der Ansatz ist der folgende: JavaScript-Code kann mit dem Server Daten austauschen, ohne dass die Seite komplett neu geladen wird – XMLHttpRequest macht es möglich. Dank DOM (Document Object Model) kann JavaScript weiterhin auf jedes Element auf der Seite zugreifen und es verändern, beispielsweise Daten vom Server anzeigen. Spinnt man den Faden etwas weiter, dann sieht man, dass sich so im Browser tatsächlich Anwendungen realisieren lassen: Die Seite wird nicht komplett neu geladen, trotzdem ändert sich etwas. Eine solche Art von Benutzeroberfläche war bis dato primär Desktopanwendungen vorbehalten.

Flash

Schon Jahre bevor XMLHttpRequest salonfähig wurde, gab es bereits eine andere Möglichkeit, „reiche“ Anwendungen innerhalb eines Webbrowsers ablaufen zu lassen. Ende 1996 erschien die erste Version von Flash, damals frisch aufgekauft von der Firma Macromedia. Zahlreiche weitere Versionen folgten, wobei der Fokus ursprünglich auf den Design- und Animationsmöglichkeiten lag. Eine Programmierung war zwar durchaus möglich, jedoch auf eine etwas mühsame Art und Weise. Mit Flash-Version 5 (2001) änderte sich die Situation, denn die Skriptsprache ActionScript (angelehnt an ECMAScript und damit sehr ähnlich zu JavaScript) ermöglichte es, mit einer einigermaßen vernünftigen Sprache zu programmieren und Flash-Filmen so mehr Dynamik zu verleihen. Flash MX (interne Versionsnummer: 6) erschien im darauffolgenden Jahr und unterstützte unter anderem Videodaten. Das wurde seinerzeit nicht sonderlich beachtet, ist aber heutzutage einer der Hauptgründe dafür, wieso Flash auf so vielen Seiten eingesetzt wird.

In den folgenden Flash-Versionen wurden immer abwechselnd Designer und Entwickler besonders gut bedient: Flash MX 2004 führte ActionScript 2.0 ein, das deutlich mehr OOP-Features aufwies als die Vorgängerversion. Flash 8 wiederum bot Entwicklern kaum Neues, lockte aber dafür Designer mit neuen Möglichkeiten wie etwa Filtern. Flash 9 glänzt mit ActionScript 3.0 und einem komplett veränderten, aber dafür deutlich stimmigeren Entwicklungsmodell.

In seinem vierteljährlichen Flash Player Census lässt Macromedia-Aufkäufer Adobe ermitteln, auf wie vielen Clients das Flash Plug-in installiert ist – im Gegensatz zu AJAX, das „nur“ JavaScript benötigt, ist für die Anzeige von Flash-Inhalten Zusatzsoftware notwendig. Die Werte des Flash-Plug-ins sind allerdings phänomenal: Zählt man auch ältere Plug-in-Versionen mit, sind in manchen Regionen um die 99% der Clients mit Flash ausgestattet, was höher sein dürfte als die Anzahl der Clients, die JavaScript ausgeschaltet haben. Aber auch neue Flash-Player-Versionen werden schnell adaptiert und erreichen nach nur wenigen Monaten Werte von über 80%. Etablierte Alternativen zum Flash-Player von Adobe gibt es nicht, denn das Flash-Format ist nicht komplett offen. Zwar gibt es Spezifikationen, deren Einsatz jedoch unter rigiden Einschränkungen stehen und es unter anderem verbieten, Software herzustellen, um Flash-Anwendungen darzustellen.

Abb. 2: Marktführer: Das Flash-Plug-in hat eine enorme Verbreitung

Parallel dazu hat Macromedia/Adobe an der Technologie Flex gearbeitet. Auch sie arbeitet mit Flash-Filmen (SWF-Dateien), allerdings werden die von einem Compiler erzeugt. Die eigentliche Anwendung wird mittels XML-Markup gestaltet und mit ActionScript-Code programmiert. Dazu gibt es auch eine IDE, den Flex Builder, der auf Eclipse basiert – eine Wohltat für alle Entwickler, die mit der Flash-IDE von Adobe nicht so gut zurechtkommen (man merkt die Vergangenheit als Designertool an vielen Ecken). Die ersten Flex-Versionen waren ein kompletter Reinfall, weil sich kaum Anwender fanden, die die teils horrenden Lizenzgebühren zahlen wollten. Mit einer zunehmenden Vergünstigung der Preise, in Verbindung mit kostenlosen Lizenzen für Entwickler, hat sich die Situation jedoch verbessert, sodass die aktuelle Flex-Version 3 deutlich mehr Erfolg hat als die früheren Versuche.

Silverlight

Den Ansatz, auf XML-Basis eine Anwendungsoberfläche zu schaffen und separat dazu die Anwendungslogik und -steuerung zu implementieren, wird auch von anderen Projekten und Firmen eingesetzt – schließlich ist eine mehr oder weniger saubere Trennung von Code und Inhalt ab einer gewissen Projektgröße ein Muss. Auch Microsoft ist schon vor einiger Zeit auf diesen Zug aufgesprungen. Eine der dazugehörigen Technologien heißt WPF – Windows Presentation Foundation. Das gibt es für Windows Vista (dort automatisch dabei) und für Windows XP (hier ein Zusatz-Download) und ist ein vektorbasiertes Grafik-Subsystem. Technologischer Hintergrund ist XAML, ein XML-Dialekt, der ein wenig an das Adobe-Pendant MXML (sowie an den technologischen Vorreiter SVG, Scalable Vector Graphics, vom W3C) erinnert. WPF wird vergleichsweise zögerlich adaptiert, aber eine Spezialvariante davon erzeugt großes Interesse. Diese hieß ursprünglich WPF/E, Windows Presentation Foundation Everywhere, aber wurde schließlich in Silverlight umbenannt. Die technische Grundlage bleibt fast die gleiche, denn Silverlight verwendet eine Untermenge des XAML-Sprachschatzes. Für die Anzeige der Daten im Browser ist dann wie gehabt ein Plug-in zuständig.

Obwohl Silverlight vergleichsweise neu ist, gibt es bereits zwei Versionen. Version 1.0 erschien im September 2007 und klinkte sich in Hinblick auf die Programmierung der Anwendung in die JavaScript-Engine des Browsers ein. Version 2.0, die voraussichtlich im Sommer 2008 in finaler Version erscheinen wird, geht einen Schritt weiter: Hier stehen diverse .NET-Sprachen zur Verfügung, inklusive C#, Visual Basic, IronPython und IronRuby. Bei der Programmierung können Entwickler auf auf Teile des .NET-Frameworks zurückgreifen. Abschließend wird der Code in eine DLL kompiliert und die Anwendung samt XAML-Markup online gestellt. Das Plug-in wiederum kann XAML interpretieren und auch die DLL verarbeiten – selbst wenn kein .NET-Framework auf dem Client installiert ist.

Liest man die Liste der unterstützten Plattformen, ist das auch ein Muss: Neben Windows wird auch Mac OS X (und dort Safari und Firefox) unterstützt; eine Gruppe innerhalb des Mono-Projekts arbeitet derweil an einer Open-Source-Portierung, Codename „Moonlight“.

In Hinblick auf die Features orientiert sich Silverlight ein wenig an Flash & Co., wobei einschränkend gesagt werden muss, dass sich Silverlight 1.0 aufgrund des reduzierten Funktionsumfangs primär für die Multimedia-Wiedergabe eignet, während Version 2.0 – sobald sie final erschienen ist – deutlich mehr Möglichkeiten vorweisen können wird.

Bewertung

Gilt es eine Technologieentscheidung zu treffen, so gibt es mehrere Ansätze. Zum einen kann man sich an den Features orientieren – erfordert eine Aufgabenstellung bestimmte Funktionalitäten, die in der einen oder anderen Technologie besonders gut (oder schlecht) funktionieren? Ein weiterer Ansatz besteht darin, den Aufwand bei der Entwicklung zu schätzen (wie lange dauert es, die Anwendung mit einer Technologie zu implementieren?) und das dann gegen eventuelle Hindernisse auf Client-Seite (Plug-in-Zwang, JavaScript-Zwang) abzuwägen. Ein dritter Ansatz versucht, in die Zukunft zu sehen: Wie wird sich der Markt entwickeln, wie verschieben sich die Marktanteile von Plug-ins und die Weiterentwicklung der Browser, in welchem Gebiet erscheint ein strategisches Investment sinnvoll? Eine ausführliche Analyse zahlreicher Aspekte und Kriterien gab es beispielsweise auf der Ajax in Action 2007.

In Hinblick auf die Features hat Flash aktuell die Nase vorn: Multimedia-Unterstützung bietet von den drei Kontrahenten sonst nur noch Silverlight, das aber in Version 1.0 funktionell sehr eingeschränkt ist. Mit Version 2.0 wird sich das ändern, doch hierbei ist wiederum fraglich, wie schnell das Silverlight-Plug-in Verbreitung findet. Am amerikanischen Markt ist Microsoft sehr engagiert, das voranzutreiben – beispielsweise wird bei den Olympischen Spielen 2008 in Peking die Online-Berichterstattung des US-Senders NBC auf Silverlight setzen. Im europäischen Markt dagegen gibt es solche Initiativen noch nicht, doch es ist abzuwarten, ob auch in hiesigen Gefilden prominente Kooperationspartner gefunden werden.

Der Vorteil von JavaScript und AJAX liegt darin, dass überhaupt keine Abhängigkeit von externen Komponenten besteht und somit noch mehr Betriebssysteme unterstützt werden (zum Vergleich: das Silverlight-/Moonlight-Plug-in für Linux steht noch am Anfang, das Flash-Plug-in für Linux war lange Zeit ein Wackelkandidat). Auf der anderen Seite ist immer noch aktiviertes JavaScript erforderlich.

Doch nicht nur ist die Zufriedenheit auf Client-Seite ein wichtiger Faktor, sondern auch die des Entwicklungsteams. Hier gibt es für AJAX Licht und Schatten: HTML, CSS und JavaScript sind etablierte Technologien, doch gerade JavaScript wurde vor dem AJAX-Hype lange Zeit belächelt (eine Auswirkung des desaströsen Browserkriegs vor etwa zehn Jahren), was auch dazu geführt hat, dass die Hersteller von Editoren und anderen Tools nur zögernd Scripting-Unterstützung eingebaut haben. Wer mit einer modernen IDE „normale“ Anwendungen programmiert hat, ist teilweise schockiert über den aktuellen Zustand der großen Webeditoren. Da Microsoft mit Visual Studio 2008 eine sehr gute JavaScript-Unterstützung in die IDE eingebaut hat, ist aber abzusehen, dass auch Konkurrenten wie Dreamweaver und GoLive an entsprechender Stelle nachbessern werden (letzteres hat Adobe allerdings zum 28. April 2008 zu Gunsten von Dreamweaver eingestellt).

Trotzdem, JavaScript-Entwicklung kann mühsam und teilweise auch frustrierend sein, denn obwohl es viele Bemühungen in Richtung Vereinheitlichung gibt, kochen die Browser hin und wieder weiterhin ihr eigenes Süppchen.

Die Flash-IDE ist heftig umstritten. Designer kommen meist gut mir ihr zurecht, aber Programmierer (vor allem diejenigen mit viel Programmier- und kaum Design-Erfahrung) rümpfen verächtlich die Nase: nur eingeschränkte Codevervollständigung und IntelliSense wird meist an erster Stelle genannt. Immerhin gibt es externe, teilweise auf Eclipse basierende Tools, die ActionScript-Entwicklern professionellere Mittel zur Verfügung stellen – aber auch Eclipse hat nicht nur Freunde. Mit Flex und dem Flex Builder (wiederum auf Basis von Eclipse) gibt es deutlich bessere Möglichkeiten, wobei es hier erfahrungsgemäß Designer wieder etwas schwieriger haben.

Silverlight verfolgt einen sehr interessanten Ansatz: Der technische ist vergleichbar zu dem von Flex und erfordert eine recht strikte Trennung von Präsentation und Logik. Für alle Bereiche gibt es spezialisierte Tools: Expression Design für die Erstellung des Layouts, Expression Blend 2 für Animationen und Transformationen, und Visual Studio für Code und Logik. Die Integration der Tools ist zurzeit sehr gering, was aber zumindest ab mittelgroßen Projekten gar nicht schlecht ist, da dann eh jede der Einzeldisziplinen von einem Spezialisten bearbeitet wird. Und da Silverlight auf XML basiert und man dieses per Skript fast beliebig zur Laufzeit ändern kann, hat man auch das (subjektive) Gefühl, die Anwendung unter Kontrolle zu haben – ein Gefühl, das uns (wiederum subjektiv) bei Flash teilweise verlässt.

Jedoch steht Silverlight noch ganz am Anfang, und die Verbreitungsgeschwindigkeit des Plug-ins wird zu einem entscheidenden Faktor werden. Microsoft hat in den letzten Jahren immer wieder Entwickler glücklich machen können, aber bei einer Webtechnologie muss der Client erfreut werden, damit das Plug-in installiert wird. Und auch wenn uns der Entwicklungsansatz sehr gefällt, ist das nebenrangig, solange Silverlight kaum Client-Features aufweist, die Flash nicht beherrscht. Erste Nischen gibt es schon: Beim Abspielen mehrerer Videos gleichzeitig ist in unseren Tests das Silverlight-Plug-in schneller als das Adobe-Plug-in. Dafür ist ersteres auch etwas (Windows) beziehungsweise deutlich (Mac) größer. Es wird also noch ein langer Weg für Microsoft, doch Konkurrenz belebt bekanntlich das Geschäft, und es ist zu erwarten und zu hoffen, dass auch Adobe kontinuierlich nachlegt.

Fazit

Es gilt das Sprichwort: Die Wahl zu haben ist gut, zu viel Wahl zu haben ist schlecht. Im Web gibt es zurzeit nur eine Handvoll Technologien, die entweder weit verbreitet sind oder die zumindest großes Potenzial haben, deutlich an Marktanteil zu gewinnen. Vollständig ist unsere Aufzählung noch nicht, denn den Traum, Desktopanwendungen ins Web zu bringen, verfolgen viele – beispielsweise seien noch Adobe AIR, Sun JavaFX und Mozilla Prism genannt. Es bleibt also auch 2008 spannend im Frontend. Bei all der verständlichen Begeisterung für die modernen Technologien darf Eines nicht vergessen werden: Nicht nur die Usability ist entscheidend, auch der Inhalt. Und ansprechende Inhalte sind auch auf Websites ohne zu viel Effekthascherei gut untergebracht.

Christian Wenz und Tobias Hauser sind seit über zehn Jahren als Autoren, Trainer und Berater im Web-Umfeld tätig. Als Teilhaber der Agentur Arrabiata Solutions GmbH implementieren Sie Web-Lösungen und beraten Firmen im In- und Ausland bei der Wahl der richtigen Web-Technologie.

Unsere Redaktion empfiehlt:

Relevante Beiträge

Meinungen zu diesem Beitrag

X
- Gib Deinen Standort ein -
- or -