Gestern Abend war es wieder so weit. Nunmehr zum vierten Mal fand der DevDusk in der Brotfabrik Frankfurt statt.

Es war wieder ein toller Abend, vielleicht sogar der beste in der Serie. Bilder zum Treffen gibt es hier.

An die 40 Teilnehmer fanden sich ein um um zuerst Mihai Corlan, seines Zeichens Adobe Platform Evangelist für Europa, zu folgen. Neben einer kurzen Einführung und Vorstellung von künftigen Adobe Entwicklungen im RIA Bereich (Flex 4 Gumbo, Flash Catalyst) zeigte Mihai wie Rich Internet Applications einfach mit Flex und PHP erstellt werden können. Eindrucksvoll war das Frontend- und Backenddebugging in einer Session und die Performancevorteile bei Verwendung von AMF3 als Tramsferprotokoll zwischen Backend und Flex-Client.

In einem zweiten, sehr gelungenen, Vortrag, stellte Matthias Schmidt von Sun Microsystems Groovy, Grails und die Unterstützung dessen in der Netbeans IDE vor. Sehr schön wurden die positiven Eigenschaften von Groovy und seinem Webframework dargestellt und die Coder-Unterstützung durch die IDE. Da viele PHP-Entwickler anwesend waren zeigte Matthias anschließend noch das PHP-Plugin für Netbeans, was zum einen durch seine Features zum anderen durch seine Offenheit und Kostenfreiheit begeisterte. Es wäre mehr als zu bedauern, wenn diese tolle IDE, die immer mehr an Fahrt gewinnt im Rahmen einer Übernahme Suns durch IBM von der Bildfläche verschwinden würde (wir erinnern uns IBM ist der geistige Vater von Eclipse).

Insgesamt ein sehr schöner und unterhaltsamer Abend mit vielen guten Gesprächen auch am Rande. Als ich um 1 Uhr dann zu Hause war, war ich auch gut müde.

Ein Novum gab es noch: Der DevDusk fand das erstemal parallel in München statt, wo sich an die 30 Techies und Nerds zu einem ebenso unterhaltsamen Abend trafen. Den Nachbericht zu München findet man hier.

Der nächste DevDusk in Frankfurt wird etwas außerhalb des Rhythmus’ am 19. Mai wieder im 19.30 Uhr in der Brotfabrik stattfinden. Thema wird unter anderem “Testing untestable Code” anhand von PHP sein. Alle sind eingeladen zu diesem Treffen. Wer es weitersagen will, der findet hier Flyer zum weitergeben.

Zur Erinnerung an alle Leser: Der nächste DevDusk steht in den Startlöchern und wird am kommenden Donnerstag, den 19.3.2009 um 20 Uhr in der Brotfabrik Frankfurt stattfinden.

Diesmal haben wir zwei profilierte Sprecher gewonnen, beim DevDusk zu sprechen:

Der erste Vortrag stammt von Mihai Corlan, seines Zeichens Adobe Platform Evangelist und er wird uns in die gelungene Kombination von Flex und PHP (unter anderem mit dem neuen Zend_AMF aus dem Zend Framework) für Rich Internet Applications einführen.

Der zweite Vortrag dreht sich um die Entwicklung von Groovy und Grails mit der Netbeans IDE – es muss nicht immer Eclipse sein. Den Vortrag hält Matthias Schmidt von Sun Microsystems, ein Senior Entwickler aus dem dem Sun Open Source Engineering Team.

Wie immer gibt es neben den Vorträgen Getränke, lecker Essen, die eine oder andere Zeitschrift zum mitnehmen und Bücher zur Ansicht.

Weitere Infos sowie Anfahrt etc. finden sich hier.

Es ist noch nicht lange her, da erschien die Version 1.1 von JavaFX, der Rich Internet Application (RIA) Technologie von Sun Microsystems. Neben der neuen Laufzeitumgebung “mobile” waren hunderte von Bugfixes für die Desktopversion in dem Release enthalten – so kann man von einer jungen aber stabilen Technologie reden.

Sun bringt eine ganze Menge an Tutorials, Demos und Dokumentationen mit, so dass der Einstieg via der Projektseite leicht fällt. Die Sprache JavaFX Script ist leicht erlernbar und bringt viele Features und syntaktische Ausdrucksmöglichkeiten moderner Sprachen mit. JavaFX Script erinnert nicht unbedingt an Java, wenn auch ihre Kompilate in der Java Virtual Machine laufen.

Neben allem, was eine Programmiersprache so braucht ist eine besondere Eigenschaft von JavaFX Script, dass es eine Sprache ist, die von Grund auf designed wurde, um grafische Oberflächen zu programmieren. Dies erfolgt nicht via XML, wie etwa bei Flex oder Silverlight, sondern in dieser objektliteralen Notation, die ein wenig wie JSON aussieht. So lassen sich auch schnell die ersten Gehversuche in Sachen grafischer Programmierung unternehmen, was sehr leicht fällt, weil der Code vornehmlich deskriptiv ist und sich leicht “mit”lesen lässt.

Schnell findet man sich in die Systematik ein, wobei ich persönlich den Ansatz über XML sympathischer empfinde. Durch die nicht XML Syntax ist der Quellcode aber deutlich lichter und bei entsprechender Einrückung fast ebenso leicht zu lesen.

Selbst komplexeste Layouts sind mit JavaFX machbar. Wer dies bezweifelt, der erstelle mit Photoshop oder Illustrator eine entsprechend aufwändige Grafik und exportiere diese nach JavaFX. Der generierte Quellcode und das Resultat im JavaFX Viewer entsprechen der Vorlage 1:1.

Von der Programmierung von Grafiken und Oberflächen ist man weiter als die Konkurrenz von Adobe – ein Vorsprung, der nur durch zusätzliche Frameworks wie Degrafa oder dem neuen Flex 4 Gumbo kompensiert werden kann. Und selbst da scheint JavaFX Script ein Schnippchen vorne zu sein. Was bei JavaFX jedoch sehr negativ ist, dass es keine ausgereiften Komponenten, wie man sie etwa von Flex her kennt, gibt. Man kann zwar einige Swing Komponenten in die RIAs einbauen, jedoch sind diese Swing Komponenten nicht leicht skinbar und erweiterbar. Hier muss Sun spätestens in der Version 2 sehr deutlich nachlegen, sonst gerät JavaFX zu sehr ins Hintertreffen. Komponentenbasierte Frameworks wie Flex leben einfach von der Stärke ihrer Komponenten und die meisten GUI Entwickler aus der Javawelt, werden eben solche Komponenten in JavaFX vermissen.

Das Tooling mit der Production Suite (Photoshop- und Illustrator-Plugin samt JavaFX Viewer) ist gut gelungen. Die Exporte nach JavaFX entsprechen der Vorlage und sind leicht im Editor veränderbar. Mit dem Netbeans-Plugin wird auch der Programmierer zufrieden gestellt, bietet die IDE jedoch annehmbaren Komfort beim Programmieren. Von einer Unterstützung wie etwa für Java ist man jedoch noch Welten entfernt. Es gibt für Eclipse auch ein JavaFX-Plugin, was jedoch in der Entwicklung der Netbeansversion hinterher hinkt – hier bevorzugt Sun eindeutig die IDE aus dem eigenen Haus. Insgesamt ist das Tooling für eine 1.1 Version in Ordnung und es macht zuversichtlich für die Zukunft.

Summa summarum ist es kein großer aber ein gelungener Wurf, der Sun mit der Veröffentlichung von JavaFX geglückt ist. Man ist schnell in der Programmierung drinnen und die ersten Tools stellen geeignete Werkzeuge zur Verfügung. In Sachen Grafikprogrammierung ist JavaFX Script sehr mächtig und übertrifft die aktuelle Version von Flex in diesem Punkt deutlich. Jedoch macht es das Fehlen von leicht programmierbaren Komponenten fast unmöglich mit JavaFX RIAs zu entwickeln, die im Geschäftsumfeld anzusiedeln sind. Ein gewichtiger Punkt an dem Sun schnell nachbessern muss, um JavaFX den Durchbruch zu verschaffen. Solange sich da nichts ändert bleiben Swing/SWT die Mittel der Wahl um Geschäftsanwendungen im RIA-Space auf Basis von Javatechnologie zu entwickeln. Da kann das Versprechen von Sun, für eine Technologie zu entwickeln, die auf mobilen Geräten, PCs und Geräten wie Fernsehern läuft, auch nichts daran ändern.

Erinnert sich noch jemand an SVG, jenes XML Format des W3C um skalierbare Vektorgrafiken zu beschreiben? Natürlich, noch ist es nicht ganz vergessen und einige Browser unterstützen dieses Format auch. Jedoch, man sieht es selten in der freien Wildbahn und die Einsätze sind nicht gerade zahlreich wenn man mal von etwas exotischeren Programmen wie Inkscape absieht.

Dabei ist die Idee hinter SVG nicht schlecht, sie ist sogar so gut, dass sie heute im RIA-Bereich eine maßgebliche Rolle spielt, wenn auch nicht in der Gestalt von SVG, sondern in moderneren, teilweise proprietären Formaten. Die Idee hinter SVG ist eine Grafik so zu beschreiben, dass die Beschreibung (mittels XML) für Maschinen wie für Menschen gleichermaßen lesbar ist. Hinzu kommt, dass man die Grafiken verändern kann, indem man zur Laufzeit Änderungen an der Beschreibung vornimmt.

Ich will jetzt gar nicht drauf eingehen warum SVG nicht der Flashnachfolger geworden ist, wie es sich die Open Standards Fraktion erhoffte. Vielmehr ist es interessant, dass die Grundidee der deklarativen Grafikbeschreibung im RIA Umfeld mittlerweile eine große Rolle spielt.

Für Flex gibt es mit dem Degrafaprojekt einen Ansatz, Grafiken deklarativ zu beschreiben. Mit der Creative Suite 4 und im Vorgriff auf das kommende Flex 4 (Codename Gumbo) setzt Adobe aber selbst ein deklaratives Grafikformat ein: FXG. FXG erlaubt den leichten Austausch von Grafiken in Textform. Flex 4 kann FXG-Elemente zur Laufzeit transformieren und bietet so einen neuen völlig neuen Ansatz zur Echtzeit-Grafikmanipulation und Animation. Die Ähnlichkeit von SVG und FXG reicht über XML als gemeinsame Basis hinaus – die Gründe warum sich Adobe jedoch für eine eigene Sprache entschieden hat, werden hier dargelegt.

Auch Microsofts Silverlight kann mittels XAML auch Grafiken beschreiben dazu kann ich jedoch mangels Erfahrung nicht mehr schreiben – auch hier ist wieder XML der gemeinsame Nenner.

Selbst der Nachzügler im RIA-Bereich Suns JavaFX verfügt über eine Methode um grafische Assets zu beschreiben und somit austauschbar zu machen. JavaFX nennt diese Dateien FXD (reine Beschreibung eines Vektorassets) oder auch FXZ (komplettes Archiv von grafischen Assets). Die JavaFX Production Suite erlaubt es mittels Plugins Photoshop- und Illustrator-Dateien in FXD/FXZ Dateien zu exportieren und direkt in JavaFX zu einzusetzen und zu verändern. Analog des Sprachdesigns von JavaFX sind die die FXD Dateien kein XML sondern eher etwas JSON ähnliches, Sun spricht von objektliteral und entspricht JavaFX Script selbst. Ob sich der Alleingang von Sun auf XML zu verzichten durchsetzt wird die Zukunft zeigen. Der Vorteil vom XML ist die Verbreitung von Tools und Know-how darüber, bei JavaFX muss von Neuem begonnen werden.

Es ist interessant zu sehen, wie sich die relativ neue Technologie der Rich Internet Applications dem Thema der deklarativen Grafikbeschreibung erneut annimmt. Auf der anderen Seite ist es bedauerlich, dass dem offenen Standard SVG keine rechte Chance gegeben wurde, seine Stärken in dem neuen Kontext auszuspielen.