Donnerstag, 24. Mai 2012 |
| |
Lässt man Ajax, HTML und Co außen vor und fokussiert lediglich den Bereich Rich-Client-Technologien, so stößt man auf drei große Player, die momentan die Rolle der Platzhirsche (mit zugehörigen Revierkämpfen) übernehmen: Adobe Flex, Microsoft Silverlight und natürlich Java. Die Verbreitung der im Client benötigten Plug-ins beim Hersteller zu erfragen ist überflüssig, selbstverständlich hat laut Adobe der Flash Player die Nase vorne, Microsoft behauptet Selbiges über Silverlight und auch Sun geizt nicht mit optimistischen Statistiken.
Für alle, die jedoch einen objektiven Blick auf die aktuelle Situation werfen wollen, zeigt Abbildung 1 (für größere Version anklicken) einen Zwischenstand, wie stark und vor allen Dingen in welcher Version die aktuellen Plug-ins momentan verbreitet sind (Quelle: Riastats.com, ca. 1,5 Millionen Clients als Datengrundlage).
Die "rote Laterne" (langsamster Fahrer im Feld der Tour de France) geht dabei ganz klar an Silverlight, zu dessen Schutz muss jedoch erwähnt werden: Würde ein entsprechender Vergleich auf reiner Intranetbasis durchgeführt werden, so würde Silverlight weiter vorne mitmischen. Nach wie vor zählt zu den Hauptvorteilen von Silverlight die einfache Anbindung bestehender Microsoft Environments (Sharepoint etc.), die in nahezu jedem Unternehmen auftauchen.
Die Pole Position hinsichtlich Plug-in-Verbreitung geht momentan klar an Adobe Flex, der Flash Player 10 ist auf mehr als 65 % aller Clients installiert, knapp weitere 30 % haben immerhin Version 9. Nur 3 % der Clients sind mangels Flash Player nicht in der Lage Flash/Flex-Inhalte darzustellen. Java ist im Client nicht so stark vertreten wie der Flash Player, ca. 25 % der Clients können gar nichts mit Java-Inhalten anfangen – die größte Gruppe, auf die gesetzt werden kann, ist mit knapp 50 % Java 1.6, die verbleibenden 25 % werden durch niedrigere bzw. höhere Java-Versionen repräsentiert.
Jetzt könnte leicht die Schlussfolgerung gezogen werden "am besten auf Flex im Client setzen, damit ist eine hohe Erreichbarkeit gewährleistet". Dieser Schlussfolgerung sollten jedoch einige Überlegungen vorausgehen, die sich nicht nur am Endresultat orientieren, sondern viel mehr den Entwicklungsprozess gleichfalls in die Waagschale legen. Für eine kleine Anwendung a la "Baum-Produkte-Detailansicht" hat Flex nach wie vor die Nase vorne, schnell und einfach kann mit dem Flex Builder eine entsprechende Oberfläche erstellt und die zugehörige Logik mit ActionScript implementiert werden.
Mit steigendem Umfang bzw. steigender Komplexität der Anwendung, wird jeder Entwickler feststellen: Die Wurzeln von Flex liegen ganz klar im Scripting-Bereich und das Programmiermodell verleitet zum Aufblähen des Clients, und schon nach der zweiten Woche Entwicklung hat man ein "prozedurales Clientmonster" erschaffen, das nur schwer von einem selbst (ganz zu schweigen von anderen Entwicklern.) verstanden werden kann – es funktioniert zwar, aber wehe wenn Änderungen bzw. Erweiterungen nach einem Jahr gemacht werden müssen. Genau an dieser Stelle liegt der große Vorteil von Java gegenüber Flex.
Das Java-Programmierkonzept ist weit ausgereifter und vor allen Dingen verbreiteter als ActionScript/Flex, auch gibt es bei einem Java-Client kein Delta zwischen Client- und Serversprache, auf beiden Seiten wird ganz einfach Java eingesetzt. Ein weiterer großer Vorteil kommt gerade bei komplexen Screens mit vielen Controls zur Geltung: Zwar blinken und rotieren die Java Controls im Client nur halb so schön wie die einer Flex-Anwendung, dafür werden die Java Controls jedoch wesentlich schneller gerendert als Controls einer Flex-Anwendung – große Tabellen mit darin enthaltenen Subcontrols sind ein Paradebeispiel, um diesen Vergleich nachzuvollziehen.
Zusammenfassend kann gesagt werden, dass Flex gegenüber Java, gerade im Web, einen starken Verbreitungsvorteil aufweist. Dafür schlägt Java mit dem jahrelang ausgefeilten und optimierten Programmierkonzept um Längen, was sich gerade bei komplexen Anwendungen zur Entwicklungszeit bemerkbar macht. Und was heißt das für Sie? Ganz einfach, seien Sie sich dieser Vor- und Nachteile bewusst! Auch eine große Flex-Anwendung kann durchaus "sauber" implementiert werden, wenn nicht ganz einfach los gecodet wird und stattdessen einige Tage Zeit dafür verwendet werden, eine gute Architektur zu definieren, um die hier genannten Pain Points zu umschiffen.
Florian Müller arbeitet für Comit Schweiz und betreut dort den Bereich User-Interface-Technologien. Darüber hinaus betreibt Florian die Plattform richability.com, wo regelmäßig über neuste Erkenntnisse aus dem Bereich Frontend-Technologien und -Entwicklung informiert wird. Kontakt: Florian.Mueller (at) richability.com.