Donnerstag, 24. Mai 2012


Kolumne

Dienstag, 23. Juni 2009 | Kolumne

Revierkämpfe: Java, Flex und Silverlight

(Link zum Artikel: http://www.entwickler.de/cod//049499)
  • Teilen
  • kommentieren
  • empfehlen
  • Bookmark and Share

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).

Abb. 1: Aktuelle Clientverbreitung
Abb. 1: Aktuelle Clientverbreitung

Die Rote Laterne: Silverlight

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.

An der Pole Position: Flex

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.

Der Pacemaker: Java

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.

Fazit

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.

(rw)

Kommentare

Gravatar BOXHead 23.06.2009
um 13:54 Uhr
*klugscheiß* Zeile 4 -> Adobe Flash *klugscheiß*

;)
#zitieren
Gravatar Rookee 23.06.2009
um 15:05 Uhr
Auf der Grafik wird von Java 1.8 gesprochen. Hab ich nen Release verpasst? Eignetlich ist 1.6.14 aktuell... oder? #zitieren
Gravatar Inkvine 23.06.2009
um 21:17 Uhr
Leider kann ich es nicht nachvollziehen, dass man "schon nach der zweiten Woche Entwicklung ein "prozedurales Clientmonster" erschaffen hat, das nur schwer von einem selbst (ganz zu schweigen von anderen Entwicklern.) verstanden werden kann". Das ist wohl bei jeder Sprache so, wenn unerfahrene Entwickler sich an eine Programmiersprache wagen. Denn in ihrem Fazit haben sie es ja schon erwähnt:
Spätestens wenn es darum geht, eine Flex-Anwendung zu Stande zu bringen, die mehr als ein Widget auf dem Screen beinhaltet, sollte man gängige Design Patterns verwenden und sich von plumpem MXML-Gescripte lösen. Mittlerweile gibt es neben dem schon lange vorhandenen Cairngorm-Framework auch genügend Alternativen, die das strukturelle Entwickeln einer Applikation erleichtern und auch die Erweiterbarkeit und Wartung erheblich vereinfachen. Ich nenne hier nur PureMVC, Mate, Swiz, Actionscript Spring, ... Ein guter Einstieg, um einen Überblick über die Frameworks zu erhalten, findet man auf http://www.insideria.com/2008/12/frameworkquest-2008-introducti.html Wenn es darum geht, der Flex Anwendung noch Leben einzuhauchen mit einem geeigneten Backend, dann muss ich Ihnen voll und ganz zustimmen. Die Umstellung von Actionscript auf Clientseite und (womöglich) Java auf Serverseite ist mühsam. Zusätzlich gesellen sich dann noch Grundsatzfragen, ob man nun AMF (BlazeDS), SOAP oder REST verwenden solle, dazu.
Aber es gibt mittlerweile durch Grails/Rails doch sehr gute Alternativen, wenn es darum geht, ein flexibles, unkompliziertes Backend zu erzeugen (ich tendiere aus Hang zu Java doch aber eher zu Grails ;) ), dass dann auch jederzeit durch Ändern von ein paar Zeilen, die Übertragungsart zum Client ändern kann.

Nichtsdestotrotz ist heutzutage eine ansprechende GUI oftmals auch für Kunden und Konsumenten DAS Kaufargument und die Möglichkeiten, die mir mit der Flash API geboten werden, sind immens. Zusätzlich kommen dann noch Aspekte wie Integration mit Fireworks und Photoshop hinzu, die gerade den Prozess vom Mockup zum endgültigen Produkt sehr erleichtern.

Just my two cents, Inkvine

www.twitter.com/inkvine
#zitieren
Gravatar Florian Müller 24.06.2009
um 09:58 Uhr
Nachdem ich festgestellt habe dass der Artikel diverse Reaktionen hervor gerufen hat, möchte ganz kurz Stellung zu den einzelnen Kommentaren nehmen - grundsätzlich muss ich vorweg schicken: wenn ein Artikel solche "heftigen" Reaktionen hervor ruft dann hat man meistens einen wunden Punkt erwischt, der unterschiedliche subjektive Sichtweisen zulässt die dann vehement vertreten werden ;-)

@BOXHead: dass Adobe Flash/Flex an dieser Stelle nicht genant wird liegt daran, dass die Verbreitung von Flex in Unternehmen bei weitem noch nicht so verbreitet ist wie die Silverlight Durchflutung; Hintergrund: jedes Unternehmen hat in irgendeiner Form Microsoft Produkte am Laufen, entsprechend liegt der Griff zu einer weiteren MS Lösung wie z.B. Silverlight näher als der Griff zum Adobe Regal...ganz einfach vor dem Hintergrund einer homogenen Infrastruktur!

@Rookee: Java 1.8 ist definitiv ein Typo/Bug von den Jungs die die Anwendung gebaut haben - ich habe gerade mal eine Mail an die Jungs raus gelassen und werde die Antwort was sich genau hinter der 1.8 verbergen soll noch hier in den Thread posten...

@Inkvine: prinzipiell geht es mir mit der Aussage des "prozeduralen Clientmonsters" ganz einfach darum eine gewissen Sensibilität dafür zu schaffen, dass eine Flex Anwendung > 2 Seiten definitiv nicht ohne Design Patterns bzw. entsprechende Frameworks im Frontend auskommt; ganz egal ob Flex Anfänger oder alter Flex-Hase, es gibt etliche Situationen in denen sich Entwickler durch die Einfachheit von Flex haben blenden lassen nach dem Motto: "toll, ich habe ne super coole App auf meinem localhost gebaut also funktioniert das auch mit den 100fach größeren Anforderungen meines Kunden...";

Genau das ist ein wenig das Problem mit Flex - es wird einfach eingesetzt und um GUI Frameworks/Patterns wird gerne ein weiter Bogen gemacht. Meiner Meinung nach müsste Adobe die Entwickler viel mehr darauf einschwören dass von ANfang an Patterns eingesetzt werden - denn ohne Artikel wie den vorliegenden laufen noch viele weitere Entwickler in die prozedurale Client Monster Falle... ;-)

Dementsprechend ist der Tenor des Artikels viel mehr: Achtung, mit geschärften Sinnen an die Anforderungen heran gehen und dem Bewusstsein: auch Flex ist nicht der heilige Gral der UI ENtwicklung, mit entsprechender Vorbereitung/Zusatzframeworks kann es jedoch sehr nah an diesen heran kommen!
#zitieren
Gravatar Inkvine 24.06.2009
um 10:54 Uhr
@florian:

Yep. Jetzt stimme ich vollkommen mit Dir überein. Die Einfachheit von Flex ist es, die Entwicklern spätestens wenn es um das Thema Skalierbarkeit und Performance in einem Unternehmen geht, dann das Genick bricht.
Nur weil ich mit ein wenig Coding schnell was "hinbiegen" kann, darf ich mich leider noch nicht "Flex-Entwickler" schimpfen, was viele doch tun. Da gehört doch schon einiges mehr dazu. Die meisten "echten" Flex-Entwickler nutzen nur sehr wenig MXML (höchstens für den Aufbau der View) und implementieren sowohl Komponenten als auch die Anwendungslogik getrennt in AS. Die gängigen Frameworks verlangen dies ja auch. Und ja. Adobe vermittelt sogar selbst durch ihre doch sehr "idiotischen" Tutorials den Eindruck, dass man es mit Flex eher mit einer schnellen Spielerei als mit einer richtigen Programmiersprache zu tun hat (mit dem Begriff Programmiersprache bin ich dennoch vorsichtig ;) ). Womöglich ist das Tooling um Adobe Flex einfach zu gut. :P Btw. dein Buch werde ich mir mal anschauen und Feedback geben. Dann noch frohes (Er)Schaffen an alle.

Bye,
Inkvine
#zitieren
Gravatar M. Dürk 24.06.2009
um 11:00 Uhr
In diesem Artikel wird mit vielen Fachbegriffen dermaßen ungenau umgegangen, dass er wohl nur für Designer und nicht für Leser mit technischem Hintergrund / Studium gedacht ist? Leider ist das symptomatisch für die ganze Seite. #zitieren
Gravatar Florian Müller 24.06.2009
um 11:10 Uhr
@M.Dürk

Hallo Herr Dürk,

bitte nennen Sie doch genau welche Begrifflichkeiten aus Ihrer Sicht ungenau beschrieben sind - dann kann man damit umgehen und dies ggf. tiefer ausführen, weitere Leser können so von Ihrem Feedback profitieren;

allerdings sind pauschale Kommentare a la "ist mir zu schwammig..." nicht gerade zielführend und lassen gleichfalls nicht gerade auf technischen Hintergrund/Studium schließen - also bitte einfach nochmal genau ausführen wo der Schuh drückt; Gruß Florian Müller!
#zitieren

Folgende Links könnten Sie auch interessieren