Eight month ago I posted this entry in german. After a comment that this post is needed in English, I will translate it and rethink if I would confirm my pro and con.

Could you compare Ajax and Flex? Sure! Both are technologies in the web frontend, which cover the same domain.

Should you compare Ajax and Flex? Sure! To learn more about the strengths and weaknesses and pull the right technology for the use case out of the hat.

What are the pros of Ajax?

• HTML, CSS and Javascript are widely known and there are a lot of people who have programmed with this languages
• The end user is very familiar with it. He knows the browser very well and knows how things are working, what buttons look like and where he could click, …
• There is no need for a plugin, because everything is supported natively in the browser (plugins could be a huge problem in controlled enterprise environments)
• Client and server side patterns are very mature and you get clobbered over the head with frameworks (in a positive way). Webwork, Struts (1 and 2), Spring, Turbine, Tapestry, JavaServer Faces, … in the Java world, YUI, Prototype, JQuery, Dojo, Ext, … in the Javascript world (to name just a few).

What are the cons of Ajax?

• It still is HTML with all its weaknesses. Rounded corners, small effects, browser incompatibilities, … … nearly everything is possible, but it is often laborious and not really straightforward
• Ajax is based on Javascript. At the beginning everything seams to be great. But then you realize, that you are just scratching on the surface and you are falling in a deep hole. When you are back at the top, you can see the strengths of the language
• The Javascript/Ajax frameworks are getting better and better. Two years ago there also exist a lot of frameworks, but they weren’t very mature or well documented in some parts
• The performance can suffer a lot of from the use of DOM manipulations. Sortable tables or other complex operations are working at limit of the practiable
• Browser and their technologies have evolved in the last years, but HTML wasn’t created to be dynamic.

What are the pros of Flex?

• Steep learning cureve at the beginning. After a few days you can create applications, which would take longer with HTML, CSS, and Javascript even after some years of training
• Sexy interfaces. A Flex application looks better at the first sight. Rounded and transparent layers, gradients just as you like them without complex scaling background images. Small effects just working after two lines of code and doesn’t have an impact at the browser performance
• Integration of multimedia data. A video player or a control to play MP3s, just a few lines of code. Clean and straightforward

What are the cons of Flex

• A Flex application looks like a Flex application. Not a big downside, but a designer needs to learn how to style it. Else you just got a 08/15 application, what can be a problem when Flex is spread wider
• Small application can be developed really fast, but if an application gets larger, you are loosing yourself in Flex. Frameworks like Cairngorm solving the problem but the learning curve is getting flatter and flatter
• I18N, automatic builds and code generation are possible but a lot of enterprise features are hidden very well. The community around Flex is growing but in a lot of areas you are alone with just a hand full of google hits
• Flex is generating Flash and the language MXML is in the opposite to pure Actionscript the strength, to get faster to your goals. But Flex is just on top of Flash and the separation of MXML and Actionscript is often to fluent, to be very homogeneous
• The FlexBuilder is no IntelliJ and the tools are still very unpolished. The development of applications is possible but it could be a lot better in some parts

Conclusion:

If you need a multimedia application with some content which should look very nice, then Flex fits very well. But if you want to manage data and you want a wide support for your application, then Ajax is still the better choice. Flash still feels like a foreign object in the web. Deep links, copy of content, loading time and the existing knowlege and usability of HTML are arguments against Flex. But if the web application should feel as close as possible like a desktop application, then Flex is a good way and maybe the AIR technology is the goal. When developing a touchscreen application we also had the decision between Flex and HTML. I think it was a good choise to try Flex because of the interface speed (no page rendering) and the missing page reloads. It feels more natural for this kind of product.

We have written the application as a demo in the first place and now wanting to test it in the wild. Because we use Cairngorm the application is well structured and contains as view layer only minimal parts of logic. Yes, we could include unit tests, but integration tests are far more interesting (from my point of view). In a large code base it could happen, that because of refactoring some things are broken. No deal, if you have tests and a CI system. But in the Flex app there are just tiny parts which I could test in a normal unit test.

Okay, so it should be integration test. Sounds good and not too complicated. There should exist a lot of frameworks because a lot of people start to use BlazeDS and other stuff in Java environments. Just something to start the app, run some tests and get the result back in the CI system.

I started to search on google and was surprised. Most of the blog posts I have found on that topic are just two month old. And there are not so many posts about that topic. With the combination of those posts I figured out, how to solve that problem. What problem?

• Integration tests of our Flex app
• Integrated in Maven
• Should work together with Cairngorm (would be more complicated with some unit tests frameworks)
• Could be Selenium (to start the app and run tests)
• Should be integrated in our continuous integration server TeamCity
• Could be written in Java

First thanks to the blog post of Julia at Blackpepper. She opened my eyes how to work with Java and Flex in combination. It is the combination of the SeleniumFlexAPI, which integrates as Flex to Javascript bridge in your Flex application and FlashSelenium.

SeleniumFlexApi is in one part a Flex library which needs to be included in your app and on the other part an extension to the Selenium IDE. I like the Flex part, because it makes it easy to dive over Javascript into the details of your Flex app. What I don’t really like is the Javascript extension. Yes, it is not only a Selenium IDE part and you can include it into the start of the Selenium Server, but it is far away from Java and Maven.

FlashSelenium is a piece of code which let’s you talk from Java over Selenium with your Flex app. The Java part is very handy, but you need to code into Flex, which methods you could call over your bridge. So I need to write special code, which opens the bridge. The SeleniumFlexAPI is much better in this part.

I liked the solution of the blog post and started to implement it.

First the pom.xml where you need to include the SeleniumFlexAPI (the scope cost me some time):

<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd">

   <parent>
        <groupId>agimatec</groupId>
        <artifactId>assessor</artifactId>
        <version>1.0-SNAPSHOT</version>
        <relativePath>../pom.xml</relativePath>
    </parent>

  <modelVersion>4.0.0</modelVersion>
  <groupId>agimatec</groupId>
  <artifactId>assessor-flexapp</artifactId>
  <packaging>swf</packaging>
  <version>${agimatec-assessor-version}</version>
  <name>Assessor Flex Application</name>
  <url>http://www.agimatec.de</url>

  <dependencies>
    		 <!--Flex SDK dependencies-->
		<dependency>
			<groupId>com.adobe.flex.sdk</groupId>
			<artifactId>playerglobal</artifactId>
			<version>3.0.0.477</version>
			<type>swc</type>
		</dependency>
		<dependency>
			<groupId>com.adobe.flex.sdk</groupId>
			<artifactId>flex</artifactId>
			<version>3.0.0.477</version>
			<type>swc</type>
		</dependency>
		<dependency>
			<groupId>com.adobe.flex.sdk</groupId>
			<artifactId>framework</artifactId>
			<version>3.0.0.477</version>
			<type>swc</type>
		</dependency>
		<dependency>
			<groupId>com.adobe.flex.sdk</groupId>
			<artifactId>framework</artifactId>
			<version>3.0.0.477</version>
			<type>resource-bundle</type>
			<classifier>en_US</classifier>
		</dependency>
		<dependency>
			<groupId>com.adobe.flex.sdk</groupId>
			<artifactId>rpc</artifactId>
			<version>3.0.0.477</version>
			<type>swc</type>
		</dependency>
		<dependency>
			<groupId>com.adobe.flex.sdk</groupId>
			<artifactId>rpc</artifactId>
			<version>3.0.0.477</version>
			<type>resource-bundle</type>
			<classifier>en_US</classifier>
		</dependency>
		<dependency>
			<groupId>com.adobe.flex.sdk</groupId>
			<artifactId>utilities</artifactId>
			<version>3.0.0.477</version>
			<type>swc</type>
		</dependency>
    <dependency>
      <groupId>com.adobe.cairngorm</groupId>
      <artifactId>cairngorm-bin</artifactId>
      <version>2.2.1</version>
      <type>swc</type>
    </dependency>

      <dependency>
        <groupId>org.openqa.selenium</groupId>
        <artifactId>flex-api</artifactId>
        <version>0.22</version>
        <type>swc</type>
          <scope>internal</scope>
      </dependency>

		 <!--FlexUnit dependencies-->
		<dependency>
			<groupId>flexunit</groupId>
			<artifactId>flexunit</artifactId>
			<version>0.85</version>
			<type>swc</type>
			<scope>test</scope>
		</dependency>
		<dependency>
			<groupId>flexunit.junit</groupId>
			<artifactId>flexunit-optional</artifactId>
			<version>0.85</version>
			<type>swc</type>
			<scope>test</scope>
		</dependency>
  </dependencies>

  <build>
    <sourceDirectory>src/main/flex</sourceDirectory>
    <plugins>
      <plugin>
        <groupId>info.rvin.mojo</groupId>
        <artifactId>flex-compiler-mojo</artifactId>
        <extensions>true</extensions>
        <configuration>
          <includeSources>
            <param>${project.build.sourceDirectory}</param>
          </includeSources>
          <locales>
            <param>en_US</param>
            <param>de_DE</param>
          </locales>
          <debug>true</debug>
        </configuration>
      </plugin>
      <plugin>
        <groupId>info.rvin.mojo</groupId>
        <artifactId>asdoc</artifactId>
      </plugin>
    </plugins>
  </build>
</project>

To get the Flex application compile with Maven you need to download the SeleniumFlexAPI and include the swc-file into your Maven repository, because it is (not yet) available on public repositories.

After compiling you can start the Selenium IDE and load the extension or go directly to FireBug and try to call the methods. Be aware, that the args-parameter is normally optional, but needs to be filled for the Javascript-Flex bridge (also cost me some time).

To call a method of your running application in Firefox fire up in FireBug’s console:

window.document['AppName'].getFlexExists('NameOfAnElement','');

To test your application you need to know, what the name of your application is (can be found in the HTML calling the Flash file) and you need to give ids to your elements, because there is just an id locator at the moment.

If you are at this point we can now switch to the Java part with Selenium. Selenium is just Javascript when you are in the browser. So all you do is to call the Javascript function which you called before over Firebug. FlashSelenium is a good wrapper for that call which means that you don’t have to write normal strings into your Selenium commands. I like a little bit more comfort and wanted to wrap the SeleniumFlexAPI a little bit closer. Also there are some methods in the FlashSelenium you don’t need with this solution. So I started to implement my own little wrapper. Maybe it is also interesting for the SeleniumFlexAPI (if completed with all methods).

Here is the beginning of the code:

package com.agimatec.assessor.selenium;

import com.thoughtworks.selenium.DefaultSelenium;
import com.thoughtworks.selenium.Selenium;

public class FlexSelenium {
    Selenium selenium;
    String flexApp;

    public FlexSelenium(String ip, int port, String browser, String url, String flexApp) {
        selenium = new DefaultSelenium(ip, port, browser, url);
        this.flexApp = flexApp;
    }

    public void start() {
        selenium.start();
    }

    public void open(String url) {
        selenium.open(url);
    }

    public void stop() {
        selenium.stop();
    }

    public String doFlexClick(String id) {
        return callFlexBridge("doFlexClick",id);
    }

    public boolean getFlexExists(String id) {
        return callFlexBridge("getFlexExists",id).equals("true");
    }

    private String callFlexBridge(String method, String id) {
        return callFlexBridge(method, id, null);
    }

    private String callFlexBridge(String method, String id, String args) {
        if(args == null || args.trim().equals("")) {
            args = "''";
        }
        return selenium.getEval("window.document['"+flexApp+"']."+method+"('"+id+"',"+args+");");
    }
}

And now the test case is the only thing which is missing. I used TestNG because it can be easier configured in a Selenium environment (when it started to become more complicated with several browsers, plattforms, test suites, test groups …):

package com.agimatec.assessor.selenium;

import org.testng.annotations.Test;

public class AssessorTest {
    private final static String URL = "http://192.168.1.175:8080/assessor-webapp";
    FlexSelenium selenium;

    @Test
    public void setUp() throws InterruptedException {
        selenium = new FlexSelenium("192.168.1.254", 4444, "*firefox", URL, "Terminal");
        selenium.start();
        selenium.open(URL);
        while(!selenium.getFlexExists("videoPlayer")) {
            Thread.sleep(1000);
        }

        selenium.doFlexClick("videoPlayer");
        Thread.sleep(300);
        selenium.doFlexClick("enterUserModeButton");
        selenium.stop();
    }
}

Installation:

1. Download and install BlazeDS (bundles with Tomcat): blazeds_turnkey from http://opensource.adobe.com/wiki/display/blazeds/Release+Builds

2. Download and install ActiveMQ (4.1.1) from: http://activemq.apache.org/download.html

3. Download the extended example blazetest-extended and extract into your BlazeDS-Turnkey directory.

The interesting BlazeDS configuration files are services-config.xml and messaging-config.xml in tomcat/webapps/BlazeTest/WEB-INF/flex.  Also look into the tomcat JNDI resource file BlazeTest.xml in tomcat/conf/Cataline/localhost and in the flex-app itself (test.mxml or test2.mxml, whose only difference is the value of the message selector)

Run example:

1. Start ActiveMQ

2. Start BlazeDS-Tomcat

3. Browse to http://localhost:8400/BlazeTest/

[]
Screen shot of the example application running in Firefox

What it shows:

It is a simple chat-application that consists of one HTML-page and two Flex-applications. The first Flex-app in the upper part of the window is added twice to the page. The second Flex-app in the lower part also appears twice.

You see, that the browser (tested with FireFox3) does not allow enough HTTP-connections to be opened simoultanously so that most of the Flex-apps need to poll instead of streaming.

A single JMS topic is used to distinguish the chat-messages for both Flex-apps. Message filtering is done with JMS-Message Selectors, a String-property named “RType” in the example, with the value “one” or “two”.

test.mxml

To send a message with a message selector from flex, refer to function sendMessage() in test.mxml (or test2.mxml):

private function sendMessage():void {
var message:AsyncMessage = new AsyncMessage();
message.body = sendTextArea.text;
message.headers = new Array();
message.headers["RType"] = “one”;
producer.send(message);
sendTextArea.text=”";
}

To filter messages received with a message selector, set “selector” attribute in the <mx:Consumer> element:

<mx:Consumer id=”consumer”
destination=”message-destination”
message=”messageHandler(event)”
selector=”RType=’one’”
acknowledge=”acknowledgeHandler(event);”
fault=” faultHandler(event)”/>

Java application using JMS

A Java application (e.g. servlet or EJB) can easily communicate with the same JMS Topic, so that you can send messages to the client applications or listen to messages. The Java application does not need any Blaze-DS library, just plain JMS (and the activemq-libs). There a two simple Java-main() apps: JMSTopicSender and JMSTopicListener.

JMSTopicListener.java

It prints all messages and their properties to the console, that you send to the JMS topic.

JMSTopicSender.java

It sends 100 messages in 200 seconds to the JMS Topic with the message selector set to “one” or “two”. You can see the messages appear in the open flex-apps.

I hope, this example helps you with your own BlazeDS experiments.

TO DO: Tomcat resource for JMS Topic with SonicMQ instead of ActiveMQ

I did not find a way to configure the tomcat JMS-resource (file tomcat/conf/Catalina/localhost/BlazeTest.xml) so that the same example runs with SonicMQ (7.6) instead of ActiveMQ (4.11).

Something alike is included in the BlazeTest.xml file, but it does not work yet. If you have a hint, please send me…

Die Adobe Flex 3 Roadshow machte heute Halt in Köln, was ich mir nicht entgehen lassen wollte. Immerhin liegt es fast um die Ecke und Informationen und Fragen aus erster Hand können Stunden in Google ersetzen. Veranstaltet wurde das Event von Adobe und Herrlich & Ramuschkat. Der Tagesplan sah wie folgt aus:

• Kunden-Engagement durch Flex
• Vorstellung von Kundenlösungen basierend auf Flex
• Adobe Flexbuilder 3
• Adobe AIR
• Serverseite mit BlazeDS und Lifecycle Data Services

Kunden-Engagement durch Flex

Andreas Helios stellte aus Sicht von Adobe dar, warum es sinnvoll ist auf Adobe (Flex) Produkte zu setzen. Eigentlich eine gelungene Einleitung, wäre das Wort PDF nicht so oft gefallen. Warum sollte man Flex einsetzen? Weil es ein deutlich besseres Benutzerinterface bei kürzerer Entwicklungszeit bietet. Das kann man je nach Einsatzzweck voll unterschreiben und es war sehr positiv anzumerken, dass Adobe sich selber auch auf Einsatzzwecke beschränkt. Es ist eben nicht immer sinnvoll auf Flash zu setzen. Aber Anwendungsfälle wie Produktfinder, wo es um den Eindruck beim Kunden geht oder komplexe Webanwendungen sind damit sehr gut zu realisieren. Webseiten mit Flash sind möglich, aber unterbrechen die Surfgewohnheiten des Nutzers und sind mittlerweile als Spielerei von Grafikern geächtet.

Vorstellung von Kundenlösungen basierend auf Flex

Vorgestellt wurden verschiedene Projekte die den Einsatzzweck von Flex sehr gut umrissen. Eine Anwendung für Köche, die komplex war, aber wohl ohne Schulung und Fachkenntnisse keine Glücksgefühle bei mir hervor rief. Ein weiteres Projekt war ein internes Addressbuch einer niederländischen Firma, die sehr viel Wert auf das Benutzerinterface legte, was der Anwendung wirklich zugute kam. Hinzu kam Adobe Photoshop Express, welches auch auf Flex beruht und zeigt, dass Adobe seine eigenen Produkte nutzt.

Adobe Flexbuilder 3

Mit dem Flexbuilder 3 ging es einmal durch die Basics von Flex, wobei man nicht sehr viel Neues sah, wenn man sich schon einmal mit Flex beschäftigt hatte. Hello World, Komponenten und Container hat wohl jeder schon mal gesehen, der sein erstes Tutorial durchgearbeitet hat. Mit dem Styling per CSS hatte ich mich bisher selber nicht beschäftigt und somit konnte ich in diesem Punkt auch dem ersten Abschnitt des Vortrags etwas entnehmen. Flexbuilder 3 soll gegenüber der 2er Version einige Verbesserungen mit sich bringen. Bitter nötig meiner Meinung nach, denn die vorherige Version war definitiv nicht so rund, wie man es sich wünschen würde. Ich selber habe zwar Flexbuilder 3 schon heruntergeladen, ihn aber noch nicht ausprobiert. Meine letzten Arbeiten an Flex habe ich mit IntelliJ 7.0.3 vollzogen, welches eine heute ungenannte Alternative zum Flexbuilder bietet. Mit der Version 8 wird dann auch Debugging integriert, was im Moment neben dem visuellen Editor am meisten fehlt. Für Syntaxhighlighting und Vervollständigung in MXML und Actionscript aber vollkommen ausreichend.

Im zweiten Teil des Vortrags ging es dann um den Zugriff über Services, wobei gezeigt wurde, wie schön einfach es ist, strukturierte Daten die als XML reinkommen in Anzeigeelemente zu verwandeln. Über Databindings kann man wirklich sehr einfach und zielgerichtet programmieren. Auch ein Punkt, den ich bisher an Flex schätze, es funktioniert so, wie man denkt, dass es funktionieren sollte. Schwer konkret zu beschreiben, aber man kommt schnell vorwärts.

Dann wurde noch eine eigene Komponente erstellt, wobei der Datenaustausch zwischen Komponenten wohlwissend ausgelassen wurde. Da wird es nämlich erst interessant: Wie erstellt man entkoppelte und wiederverwendbare Komponenten mit Flex. Der Hinweis auf das Caingorm-Framework hat nicht gefehlt und ist meiner Meinung nach auch sehr nötig. Denn der einfache Einstieg wird schnell zu Spaghetti-Code, wenn man nicht aufpasst. Eigene Pattern zu entwickeln, während man Flex noch lernt ist schwer und somit ist Cairngorm bei größeren Anwendungen eine gute Wahl (bei kleineren nicht wirklich).

Adobe AIR

Nach der Mittagspause gab es dann eine Einführung in Adobe AIR, der Adobe Integrated Runtime. Adobe Air wird auf dem Rechner installiert und bietet ein Framework für Webanwendungen auf dem Desktop. Es ermöglicht leichtgewichtige Desktop Applikationen, die im Gegensatz zu reinen Web-Anwendungen auf Resourcen des Client-Rechners zugreifen dürfen. Dazu zählt das Dateisystem, das Clipboard und eine mitgelieferte SQLite Datenbank wodurch auch Offline-Anwendungen möglich sind. Vorgestellt wurde hier eine Flexanwendung innerhalb der AIR-Umgebung. In AIR ist aber auch ein Webkit-Browser integriert, weswegen auch eine Programmierung in HTML und Javascript/AJAX möglich ist. Eine AIR-Applikation verhält sich dabei wie ein gewöhnliches Programm auf dem Rechner. Man lädt eine .air-Datei herunter, wonach sich AIR meldet und fragt, ob wir diese wirklich installieren wollen. Danach wird diese z.B. unter C:/Programme abgelegt und ist über das Startmenü zu erreichen, sowie laufend in der Start-Leiste zu finden. Ein sicherlich interessanter Ansatz, wobei zu oft die Offline-Fähigkeit erwähnt wird. Sicherlich ist diese Interessant, wenn man eine Adreßapplikation auf einem Notebook hat, aber der normale Desktop-Nutzer ist dauerhaft online. Ich selber nutze Mozilla Prism, wodurch meine Google Apps auch sehr nativ ins System integriert sind. Prism basiert auf dem Firefox und hinterlegt Desktopicons, Startmenüeinträge und lässt die Webanwendung dann in einem eigenen Container laufen. Somit wird der Firefox nach 8h Google Mail nicht noch zusätzlich ausgebremst.

Was aber ist dann der Kick? Ich denke es ist die schnelle Erstellung von Desktop-Applikationen und die Realisierung mit bekannten Technologien wie Flex, HTML und AJAX. Hinzu kommt die Nähe zum Internet, wodurch Videos, und Informationen eher den Weg in Desktop-Anwendungen finden. Die These, dass Adobe AIR in einem Jahr genauso verbreitet ist, wie der Flashplayer halte ich dagegen genauso falsch, wie die enorme Verbreitung von Silverlight in kurzer Zeit. Es sind sicherlich interessante Technologien, werden aber ihre Zeit benötigen, um ihre Position zu finden.

Serverseite mit BlazeDS und Lifecycle Data Services

Auch wenn man Flex mit simplen Webservices sehr einfach füttern kann, so bietet Adobe mit BlazeDS und Lifecycle Data Services noch eigene Lösungen an. Interessant sind hierbei die Konnektoren zu Java-Objekten, JMS, Hibernate und Co.

BlazeDS ist das neueste Open-Source Produkt von Adobe und deckt einen weiten Bereich der gewünschten Serverfunktionalität hin zu Java ab. Wir werden wohl in den nächsten Googledays das Messaging über JMS weiter unter die Lupe nehmen, da dies eine andere Art der Anwendungssteuerung ermöglicht (Push anstatt Polling).

Lifecycle Data Services sind die kostenpflichtigen Produkte von Adobe, die mehr Performance versprechen und eine ganze Menge zusätzlicher Features mit sich bringen (ein Vergleich). Der Vortrag zielte dabei etwas an BlazeDS vorbei und hob den Mehrwert der Lösung hervor. Über ein eigenes Messaging-System werden die Daten bis hin zum Client synchronisiert. Eine Änderung der Daten in einem Browser, kann sofort auch bei anderen Anwendern erscheinen. Konflikte beim gleichzeitigen Bearbeiten von Daten können aufgelöst werden und das alles transparent bis hin zur Datenbank. Klingt gut und viele Probleme haben wir in unserer AJAX-Entwicklung auch schon gehabt. Es wirkt aber so, als würde man sich mit einem Schwenk in diese Richtung sehr in die weichen Betten von Adobe fallen lassen. Probleme gibt es keine und die Realisierung ist in 5min fertig. Nur die Geldbörse muss für die Lösung entsprechend dimensioniert sein. Klingt zu schön um wahr zu sein und hält wohl noch viele Probleme in den Details und fehlenden Schichten versteckt.

Fazit:

Für Einsteiger, die bisher nur den Namen Flex gelesen haben, wäre die Veranstaltung Gold wert gewesen. Für jeden der sich schon etwas mit Flex beschäftigt hatte, blieb zumindest etwas hängen und die Veranstaltung war insgesamt professionell gemacht und organisiert. Aufgrund der mangelnden Informationsflut für Semi-Anfänger hat mich Fabian dann ab der Mittagspause alleine zurück gelassen, mit der Aufgabe über die ausstehenden Dinge zu berichten. Das werde ich dann zusätzlich zum Blogeintrag morgen noch einmal in der Stand-Up-Runde tun.

Irgendwie ist der Eintrag länger geworden als gedacht, aber so war der Termin heute trotz der eigentlich wenigen Stunden auch. Das lag aber primär an der Luft im Raum.

Kann man Ajax und Flex vergleichen? Klar, beides sind Technologien im Web-Frontend, die den gleichen Bereich abdecken.

Sollte man Ajax und Flex vergleichen? Klar, um die Stärken und Schwächen kennen zu lernen und für jeden Anwendungsfall die richtige Technologie aus dem Hut zu zaubern.

Was sind die Vorteile von Ajax?

• HTML, CSS und Javascript sind weit bekannt und viele Leute haben schon damit programmiert
• Der Endnutzer fühlt sich heimisch. Er kennt den Browser, weiß wie die Dinge funktionieren, wie die Buttons aussehen, wo er hinklicken kann, …
• Es wird kein Plugin benötigt, denn alles ist nativ im Browser (Plugins können in kontrollierten Firmenumgebungen ein Problem darstellen)
• Client- und serverseitige Pattern sind weit entwickelt und man wird von der Menge Frameworks (positiv) erschlagen. Webwork, Struts (1 und 2), Spring, Turbine, Tapestry, JavaServer Faces, um nur ein paar zu nennen

Was sind die Nachteile von Ajax?

• Es ist und bleibt HTML mit all seinen Schwächen. Runde Ecken, kleine Effekte, Browserinkompatibilitäten, … … alles machbar, aber es ist aufwendig und nicht straightforward
• Ajax beruht auf Javascript. Zuerst wirkt es toll. Dann merkt man, dass man nur an der Oberfläche kratzt und fällt in ein tiefes Loch. Ist man wieder oben, erkennt man die Stärken der Sprache.
• So langsam haben die verfügbaren Javascript-/Ajax-Frameworks einen Reifegrad erreicht, der einem Arbeit abnimmt. Dies war nicht immer so.
• Die Performance im Browser kann unter den DOM-Manipulationen leiden. Sortierbare Tabellen oder andere aufwendige Operationen arbeiten an der Grenze des Machbaren
• Browser und deren Technologien haben sich in den letzten Jahren weiterentwickelt, aber HTML wurde nicht dafür geschaffen, dynamisch zu sein.

Was sind die Vorteile von Flex?

• Schnelle Einarbeitung. Schon nach wenigen Tagen hat man Anwendungen erstellt, die selbst nach mehrjähriger Erfahrung mit HTML, CSS und Javascript länger gedauert hätten
• Sexy Oberflächen. Eine Flex-Anwendung macht auf den ersten Blick einfach mehr her. Abgerundete und transparente Layer, Gradienten nach Wunsch ohne kompliziert skalierende Hintergrundgrafiken. Kleine Effekte, die mit zwei Zeilen Code eingefügt sind und nicht auf die Performance des Browsers drücken
• Integration von Multimediainhalten. Ein Videoplayer, Musik gesteuert abspielen, alles eine Frage von wenigen Zeilen Code. Sauber und einfach klar in der Denkweise

Was sind die Nachteile von Flex?

• Eine Flexanwendung sieht aus wie eine Flexanwendung. Kein echter Nachteil, aber ein Grafiker muss sich auch erst mal in das Skinning einarbeiten. Ansonsten hat man eine 08/15-Anwendung, was bei weiterer Verbreitung von Flex negativ ins Auge fallen wird
• Kleine Anwendungen sind schnell realisiert, aber wird es etwas größer, so verliert man sich erst einmal wieder in Flex. Frameworks wie Cairngorm lösen diese Probleme, aber die Lernkurve ist plötzlich doch steiler als angenommen
• Internationalisierung, automatisierte Builds und Codegenerierung sind möglich, aber viele Enterprise-Features verstecken sich doch sehr gut. Es macht oft den Anschein, als wäre manches zu kurz gesprungen
• Flex generiert Flash und die Sprache MXML ist im Gegensatz zu purem Actionscript die Stärke, um schnell an ein Ziel zu kommen. Allerdings ist Flex ein Aufsatz auf Flash und die Trennung von MXML und Actionscript ist zu fließend, als das alles homogen wirkt.
• Der Flexbuilder ist nunmal kein IntelliJ und die Tools wirken alle noch sehr roh. Die Erstellung von Anwendungen ist möglich, aber an vielen Enden könnte es besser laufen. Auch der Flex-Support in IntelliJ ist sehr weit von Java entfernt

Fazit:

Benötigt man eine Multimedia-Anwendung, die viel Inhalte darstellt und schick herüberkommen soll, ist Flex sehr gut geeignet. Will man dagegen Daten pflegen und möglichst breiten Support für die Anwendung haben, so ist Ajax immer noch die bessere Wahl. Flash wirkt in der Welt des Webs immer noch als Fremdkörper. Deeplinks, kopieren von Inhalten, Ladezeit und die schon erlernte HTML-Usability sind Punkte, die gegen Flash sprechen. Wenn es aber darum geht, möglichst nah an Desktop-Anwendungen zu kommen, so ist Flex ein guter Weg und Air schon ein Ziel. Bei der Umsetzung einer Touchscreen-Anwendung standen wir auch vor der Überlegung auf Ajax zu setzen. Zum Glück haben wir an dieser Stelle auf Flex gesetzt, da seine Reaktionsgeschwindkeit ohne Page Reloads wesentlich natürlicher bei dem Anwendungsfall ist.

Alles was mit Flex geht, ist auch mit Ajax möglich. Aber der Aufwand kann enorm werden.

a) ich sollte mir ein vernünftiges Hobby suchen

b) Flex ist schon cool

Was habe ich bisher: einen Kalender mit Detailansicht und der Möglichkeit, per Drag&Drop über Terminvorschläge abzustimmen. Jetzt muss ich nur noch mit Grails einen Server dahinter packen und fertig.

Tja, wenn ich’s nicht hassen würde, mich selbst zu korrigieren, dann könnte ich noch zu einem Flex-Fan werden.