Das nächste Treffen der Flex UG Rhein-Main nach der Sommerpause wird am 2. September um 19.30 Uhr stattfinden. Thema werden Tools sein. Neben Vorträgen von Euch werden wir IntelliJ Idea als Flex IDE vorstellen und wenn noch Zeit ist auf Flash Catalyst eingehen.

Wenn Ihr Ideen für einen Vortrag habt oder etwas zeigen wollt, dann habt Ihr die Gelegenheit dazu. Egal ob Flexneuling oder Profi, jeder ist willkommen!

Damit wir planen können, gebt bitte auf unserer Mailingliste Bescheid, ob Ihr kommen könnt. Für Teilnehmer, die das erste Mal kommen haben wir ein kleines Goodie. Außerdem verlosen wir diesmal bei ausreichender Teilnehmerzahl eine Lizenz von IntelliJ Idea.

Der Veranstaltungsort ist:

Coded Culture GmbH 
Luisenstr. 6 (wir sind im Haus im Hinterhof, dort im 2. Stock)
D-65185 Wiesbaden (für Navi-Nutzer bitte die PLZ mit eingeben)
Telefon: +49 (0)611 – 450 30 57 0
Telefax: +49 (0)611 – 450 30 57 9

Meine Kollegen von der Münchner Flex Usergruppe München veranstalten dieses Jahr den RIA Summer Jam.
Rich Internet Applications oder kurz RIA stehen für technisch anspruchsvolle, multimediale Anwendungen, die innovative Möglichkeiten bieten Ästhetik und Funktionalität miteinander zu verbinden.
In Kooperation zwischen der Adobe Flex User Group München und P//MOD ist die Idee entstanden den RIA Summer Jam ins Leben zu rufen. Dabei soll die RIA Technologie nicht ausschließlich unter den Aspekten Design und Technik fokussiert werden, sondern auch die Bedeutung und Herausforderung für Marken in den Vordergrund gestellt werden.
Auf dem RIA Summer Jam präsentieren Profis aus den Bereichen Technik, Design, Marketing und Projektmanagement das Thema Rich Internet Applications auf 2 Präsentations Tracks.
Im Anschluss an den Event gibt es dann die Möglichkeit beim BBQ auf der Dachterrasse die Eindrücke des Tages weiter zu vertiefen.
Der RIA Summer Jam 2009 findet am 12. September 2009 in München statt und ist kostenlos.
Weitere Infos und Anmeldung unter www.riasummerjam.de

Update vom 14. August 2009: Der RIA Summer Jam ist bereits ausgebucht. Es gibt aber eine Warteliste für Tickets, die nicht in Anspruch genommen werden.

Wenn man einige Jahre Usergruppen leitet und auch als Vortragsreisender für bestimmte Technologien unterwegs war, also klassisch als unabhängiger technologischer Evangelist (klingt komisch auf Deutsch, soll aber Technical Evangelist übersetzt sein) wirkt, kommt es immer wieder zu ähnlichen Beobachtungen, denen ich in diesem Blogeintrag einmal nachgehen will.

Wenn ich eine Technologie als Usergruppenleiter oder unabhängiger Evangelist vertrete, tue ich dies aus der Überzeugung heraus, dass die Technologie gut, interessant und viel versprechend ist. Wenn ich meine Zeit in eine Technologie investiere, muss mir klar sein, dass ich diese Technologie auch selber nutzen und in Kundenprojekten einsetzen will und werde. Ich bin auf Seiten der Entwickler, die meine Veranstaltungen besuchen, weil sie aus erster Hand eines Entwicklers hören wollen, wie es sich mit dieser oder jener Technologie verhält.

Entspringt die Technologie oder das Projekt aber einer Firma, kommen ganz andere Interessen mit dazu. Der Firma geht es weniger um die Coolness oder die für Entwickler interessanten Dinge dabei, sondern es geht ihr letztlich darum, mehr Technologie und mehr Produkte zu verkaufen. Die meisten Firmen haben ihre eigenen bezahlten Evangelisten, deren Erfolg wird aber in der Zahl der “bekehrten” Entwickler oder aber schlicht in Verkaufszahlen gemessen. Einer solchen Erfolgskontrolle unterliegen freie Evangelisten nicht – sie tun es aus Überzeugung. Diese Authentizität lässt sich nicht kaufen, sie muss aus Überzeugung entstehen – genau diese aber ist es, die den Unterschied zu Veranstaltungen macht, bei denen immer auch mehr oder weniger Produktmarketing betrieben wird.

Ein weiterer Konflikt ist an der Stelle auszumachen, wenn Firmen mehrere Technologien haben, die miteinander arbeiten. Hier gilt aus Firmenperspektive die Devise des Cross-Sellings, also jene Frontend-Technologie arbeitet am besten mit dieser Backend-Technologie aus dem selben Haus zusammen oder diese Software passt exzellent zu der Hardware des gleichen Herstellers. Natürlich gibt es Alternativen aber einem Corporate Evangelist wird es vorwiegend um das Promoten der eigenen Technologien gehen. Hier sind freie Evangelisten wieder im Vorteil, sie werden das propagieren, was aus ihrer Erfahrung und Praxis heraus am meisten Sinn macht.

Eine Ausnahme für das hier beschriebene bilden die Usergruppen oder Veranstaltungen, die aus Community Projekten hervorgegangen sind und zumeist unter die Klassifikation Free and Open Source Software (FOSS) fallen. Hier verhält es sich anders, da im Unterschied zu Technologien und Projekten hinter denen Unternehmen stehen, keine Drittinteressen im Spiel sind.

Christian Heilmann – seines Zeichens Web Developer Evangelist für das Yahoo Developer Network – führt in seinem neuen Buch-Projekt Developer Evangelism aus, wie sich Corporate Developer optimal geben sollten, um einen maximalen Impact zu erzielen. Für freie Evangelisten, die Technologien aus Überzeugung promoten bietet das Buch weniger als für Corporate Evangelists. Geht man die Kapitel durch wird deutlich, dass diese aus Überzeugung für die Technologie auftreten müssen und nicht um Produkte zu verkaufen. Die Firma, für die man arbeitet muss in den Hintergrund treten, die Technologie muss im Mittelpunkt stehen:

Yes, you work for a certain company that builds a lot of products, some of them cool – some of them terrible. The point of developer evangelism is not to get people excited about the brand or the company behind it though.

Instead it is about the products the company releases and even more specifically about getting developers excited about playing with them.

Diese uns andere Einsichten Heilmanns sind diejenigen, die einen Evangelisten erfolgreich machen sollen. Natürlich gehört dazu auch ein Management, was diese Art von Evangelisation unterstützt – es ist eben ein allumfassender Lernprozess.

Freie Evangelisten sind hier im Vorteil: Vieles, was sich bei Unternehmensevangelisten ändern muss, ist bei ihnen sozusagen naturgegeben schon vorhanden. Die oben angesprochene Authentizität muss sich durch Begeisterung und Überzeugung für die Technologien speisen und aus nichts anderem sonst.

Entwickler sind selten Entscheider, aber sie sind öfter als man denkt Entscheidungsvorbereiter. Und wenn Entwickler von Technologien angesprochen sind steigt die Chance, dass das Management sich auch dafür entscheidet. Das Ziel von Unternehmensevangelisten, mehr Produkte zu verkaufen und mehr Entwickler für sich zu gewinnen, stellt sich so auch indirekt ein – aber ohne peinliche Marketing- und verkappte Promotionaktionen für Produkte.

Hier sind wiederum die freien Redner im Vorteil. Ihre Unabhängigkeit erzeugt auch die angesprochene Authentizität. Sie ist aber auch für die Unternehmen eine unberechenbare Komponente, weil deren Technologien zwar authentisch demonstriert und erklärt werden, aber nicht unbedingt auf die Art und Weise, wie es die Marketingabteilungen der Firmen gerne hätten. Unternehmen sollten diese Unberechenbarkeit aber nutzen, sie ist oftmals mehr Wert als gestreamlinte Marketingshows.

Seit einiger Zeit ist nun die Beta von Flash Catalyst erschienen, dem neuen Tool von Adobe, welches die Brücke zwischen Kreation und Entwicklung bauen soll wenn es um Rich Internet Applications auf Basis von Adobe Flex geht.. Ziel soll sein, dass Designer in die Lage versetzt werden, Interaktivität in ihre Designs zu bringen, ohne dabei eine Zeile Programmcode schreiben zu müssen. Den Programmcode generiert Flash Catalyst nämlich selber. Es gibt eine Codeansicht in der Anwendung, die es einem erlaubt zu jeder Zeit in den aktuell zu generierenden Quellcode zu schauen.

Die Beta ist aktuell noch ziemlich lahm, wenn ich sie mit anderen Anwendungen auf meinem MBP vergleiche, aber es ist ja noch kein optimierter Code und Debugcode dürfte auch noch allenthalben enthalten sein. Dennoch kann man mit der Beta bereits gut arbeiten und auch Projekte damit erstellen, zumindest Testprojekte.

Flash Catalyst benötigt das Flex 4 SDK und am besten den Flashbuilder 4, die beide auch im Betastadium sind und Anfang 2010 final werden. Das erzeugte SWF basiert auf Flex 4 und benötigt zwingend den Flashplayer 10.

Flash Catalyst ist vom Produktmarketing her ein Tool für Designer, denn Ausgangsbasis sind idealerweise fertige Layouts und Designs in Adobe Photoshop oder Illustrator. Man erstellt einfach ein neues Catalyst Projekt auf der Basis eines Designs in einem der beiden Grafikformate und man hat ein bearbeitbares Projekt. Schnell werden Elemente aus Ebenen in interaktive Komponenten umgewandelt und bearbeitet. Man kommt so sehr schnell zu benutzbaren Click-Dummies und es macht einfach Spaß aus einer Grafik eine Anwendungen zusammen zu klicken.

Flash Catalyst kompiliert mittels Flex Gumbo aus einer solchen Projektdatei eine lauffähige Flexanwendung (SWF), die im Browser betrachtet und mit der interagiert werden kann. Soweit so gut, klingt erstmal nicht aufregend bis man es ausprobiert hat. Was Catalyst aber im Hintergrund leistet ist wirklich beeindruckend.

Aus der PSD / AI plus den Bearbeitungsschritten in Catalyst werden grafische Assets für die Flexanwendung erstellt, deren Informationen über die Ebenenstruktur gewonnen werden. Darüber hinaus wird Quellcode generiert, der dann im Flashbuilder 4 (oder einem anderen Editor) bearbeitet und wiederum kompiliert werden kann. Mit Flash Catalyst ist der Designer in der Lage der Entwicklung nicht nur Designs zu liefern, sondern bereits Interaktivität und Dummy-Daten. Dem Entwickler ist es dann überlassen, die echte Datenanbindung an ein Backend auszuprogrammieren und ggf. den generierten Quellcode aufzuräumen und zu optimieren. Aufgrund des Betastatus kann man noch nichts über die Qualität des generierten Quellcodes sagen, das wir sich erst mit der fertigen Version zeigen.

Die Arbeit mit Catalyst macht Spaß, und vor allem ist es interessant einmal den umgekehrten Weg zu beschreiten: Entwickelt man normalerweise anhand von Funktionalität und kümmert sich dann um Skinning etc., geht man hier sozusagen vom fertigen Skin hin zur Funktionalität. Mir als Entwickler war diese Zugangsweise erste fremd, sie ist aber durchaus interessant. Für den Designer umgekehrt dürfte es interessant sein, dass er auch Funktionalität gestalten kann, ein Weg, der ihm vorher versperrt war.

Ob Flash Catalyst der große Wurf wird, muss sich erst noch zeigen. Aber es weist sowohl für Entwickler als auch für Designer neue Perspektiven auf – ganz abgesehen davon, dass der Austausch der beiden Lager besser wird, sowohl hinsichtlich der Daten als auch der Kommunikation. Darüber hinaus ist Code- und Assetgenerierung ein sehr interessantes Feature, was Projekte deutlich beschleunigen kann.

Adobe lud zum ersten Mal die Usergroup Manager DACH der Flash Technology Platform zu sich nach Hamburg ein.

Es waren viele Flex UG Manager anwesend aber auch Vertreter von ColdFusion und Flashgruppen, sogar ein Vertreter der einzigen LiveCycle Usergruppe war da. Auch Vertreter aus der Schweiz und Österreich waren gekommen – Adobe übernahm großzügigerweise die Reisekosten.

Ziel war es, dass sich die UG Manager untereinander kennenlernten. Mir gefiel besonders, dass ich UG Manager wie Jens (Hamburg), Thomas (München) und Bettina (Berlin) auch einmal im Reallife treffen konnte – man kannte sich sonst nur oberflächlich über Netzwerke. Aber auch das Schliessen neuer Bekanntschaften war sehr positiv. Es war das erste mal in meinem Leben, dass in einem Raum mit weniger als 20 Leuten, neben mir ein zweiter Reto anwesend war – und das dann noch in Deutschland und nicht in der Schweiz…

Adobe berichtete über das Engagement für die Community, die Pläne für die Zukunft und stellte das Evangelistenteam vor. Der Austausch zwischen des Usergruppenvertretern und Adobe stand jedoch im Mittelpunkt. Es wurde offen besprochen was gut läuft und was verbessert werden sollte. Der konstruktive Austausch ging in ein sehr gelungen Abendprogramm über, bei dem dann weitere Diskussionen und Networking stattfand.

Insgesamt ein gelungener Tag und einen herzlichen Dank an Sven und Sabina, die alles organisiert und begleitet haben!

Das nächste Treffen der Flex Usergroup Rhein-Main nach der Sommerpause wird am 2. September um 19.30 Uhr stattfinden.
Thema werden Tools sein. Neben hoffentlich zahlreichen Vorträgen von Euch werden wir IntelliJ Idea als Flex IDE vorstellen und wenn noch Zeit ist auf Flash Catalyst eingehen.

Wenn Ihr Ideen für einen Vortrag habt oder etwas zeigen wollt, dann habt Ihr die Gelegenheit dazu. Egal ob Flexneuling oder Profi, jeder ist willkommen!

Damit wir planen können, gebt bitte auf unserer Mailingliste Bescheid, ob Ihr kommen könnt.

Der Veranstaltungsort ist:

Coded Culture GmbH (wir sind im Haus im Hinterhof, dort im 2. Stock)
Luisenstr. 6
D-65185 Wiesbaden (für Navi-Nutzer bitte die PLZ mit eingeben)
Telefon: +49 (0)611 – 450 30 57 0
Telefax: +49 (0)611 – 450 30 57 9

In letzter Zeit rückt die Webentwicklung (zumindest des Frontends) mit den typischen Web 2.0 Technologien wie standardkonformes HTML, CSS der neuesten Generation und Ajax / JavaScript immer mehr in meinen Blickwinkel. Das bedeutet nicht, dass in diesem Bereich tatsächlich mehr passiert als sonst, sondern kann auch lediglich bedeuten, dass mir das Augenfällige dann doch noch aufgefallen ist. Ich bin auch nicht mehr so der Frontendentwickler wie noch vor acht oder zehn Jahren und wenn dann eher in Adobe Flex.

Anyway, es tut sich was im Webbereich und gerade im Bereich der offenen Standards. Neue Technologien sprießen, Frameworks werden immer besser und leichter einzusetzen und Altbewährtem werden neue Aspekte abgewonnen. Wer wie ich schon etwas länger im Webapplication Developement dabei ist, kennt einen Teil der Bewegung, die jetzt aufgezogen ist unter dem Stichwort DHTML. Schon vor rund zehn Jahren war man durchaus in der Lage mittels JavaScript DOM Bäume zu manipulieren und einiges an Dynamik in statische Webseiten bringen. HTML und CSS aber auch JavaScript entwickelte sich fort und brachte immer neue Möglichkeiten.

Neu hinzugekommen (und an das ist das wirklich Neue) ist, dass man aus einer Webseite heraus, Daten nachladen kann, etwas, dass vorher nur proprietären Technologien wie Flash oder Applets möglich war. Ajax fand sich schnell als eingängiges Brand für asynchrone Requests die Daten mittels JSON oder XML von einem Backend holten und darstellten.

Mit Ajax kamen die Frameworks, die Animationen, völlig neue Widgets für HTML und Interaktivität auf Webseiten brachten und den Datenaustausch mit Backends vereinfachten. Mit ExtJS und bspw. jQuery UI stehen komponentenbasierte Frameworks zur Verfügung, die sonst eher im Bereich von Java und Flex zu suchen waren. Neue Browserversionen überbieten sich mit immer schnelleren JavaScript-Engines und ein Ende der Entwicklung ist noch nicht abzusehen.

Und ein Blick in die Glaskugel (wobei eigentlich schon alles bekannt ist) zeigt, dass mit Anwendungstypen wie Google Wave oder Google Docs, Calendar etc. der Browser als Applikationsträger immer wichtiger wird und das eigentliche Betriebssystem zurückgedrängt wird. Googles angekündigtes Betriebssystem Chrome OS scheint vorwiegend als Browserruntime zu dienen. HTML 5 und immer schnellere JavaScript Engines zeigen schon heute was mit Video und Animationen bis hin zum Raytracing im Browser möglich ist – von den neuen Gestaltungsmöglichkeiten mit CSS 3 ganz zu schweigen. Da wird selbst die Luft für Rich Internet Technologien wie Flash, JavaFX und Silverlight dünner.

Aber sollte die Zukunft der Anwendungsentwicklung wirklich in JavaScript liegen? Diese Sprache, die so unleserlich und unschön ist. die noch nicht einmal einen eigenständigen Namen von ihren Schöpfern bekam, sondern sich als Java Irgendwas bezeichnen lassen musste – ohne dabei irgendeine vorteilhafte Eigenschaft von Java zu haben? Ich will und kann es mir nicht recht vorstellen. Selbst wenn die Tools einmal ausgefeilter sind, wird es immer noch eine große Mühe sein, JavaScript zu entwickeln – und damit meine ich nicht nur das eine oder andere Framework zu benutzen, sondern richtig zu programmieren.

Gestandenen Anwendungsentwicklern ist noch nicht einmal ein einigermaßen ausgereiftes Framework wie Flex mit einer relativ elaborierten Sprache wie ActionScript 3 ausreichend, um komplexe Anwendungen zu schreiben. Wie soll das dann erst mit JavaScript vonstatten gehen, wenn wir mal den Umweg über Googles Web Toolkit beiseite lassen?

Auch wenn vieles danach aussieht als würden die Anwendungsoberflächen der Zukunft in JavaScript programmiert werden will es mir nicht wirklich in den Kopf. Trends und Hypes gehen und kommen im Internet schneller als sonst wo aber an den Grundfesten der Softwareentwicklung wird nicht so schnell gerüttelt, das braucht Zeit. Das Versprechen der Offenheit und Plattformunabhängigkeit der Webstandards ist da, aber das wird bspw. auch von Java gegeben. Und wenn sich Adobe entscheiden sollte den Flashplayer zu öffnen, wird wieder ein Konkurrent um die Technologie der Webanwendungen gleichberechtigte Ansprüche anmelden können.

Es ist verblüffend was heute mit Webstandards und Ajax möglich ist, aber das Entwicklungsmodell ist nicht überzeugend. Zu viele Einzeltechnologien mit Interdependenzen und kein so ausgereifter Toolsupport wie bspw. in Java, ganz zu schweigen von Browser-Inkompatibilitäten. Aber JavaScript als Entwicklungssprache muss nicht die Zukunft gehören. Über Google Wave, die vermutlich am weitestgehende Ajax Anwendung sagen die Entwickler selbst: Ohne das Google Web Toolkit (was Javacode in JavaScript/Ajax “kompiliert”), also direkt in JavaScript programmiert, wäre Google Wave nie möglich geworden.

Wie der geneigte Leser an den Posts in meinem Blog sehen kann, habe ich mich in der letzten Zeit mit verschiedenen IDEs im Zusammenhang mit verschiedenen Sprachen und Technologien beschäftigt. Auch wenn der Prozess der Sichtung noch nicht abgeschlossen ist, wage ich dennoch einmal den Vergleich zwischen den drei Major IDEs wenn es um die Entwicklung mit Java und anderen Sprachen geht. Ich werde nicht nach IDE sortieren sondern nach verwendeten Sprachen und Frameworks. Zur Verwendung kommen die aktuelle Eclipse 3.4 (mit Vorausschau auf 3.5), Netbeans 6.7 Beta und IntelliJ Idea 8.1.

PHP

Die PHP Unterstützung ist nur in Eclipse und in Netbeans gegeben. Das freie PDT in Eclipse ist gleichzeitig die Grundlage für das kommerzielle Zend Studio for Eclipse, die führende IDE im PHP Bereich. Von den Kosten kann man fairerweise nur PDT und das Netbeans-Plugin vergleichen. Beide haben einen großen Coding Comfort und die Debugger Unterstützung ist ausgereift. Beide bringen auch Standardfeatures ihrer jeweiligen Mutter IDE mit, also Code Folding, Zeilennummerierung, ausgefeilte Suchen & Ersetzen Funktionen, Filenavigator und eine Outlineansicht sowie Anzeigen über Probleme, Todos etc.

Das Zend Studio erweitert PDT in vielerlei Hinsicht, etwa um ausgefeiltes Codeformatting, Unittest-Unterstützung, Server-Debugging und vieles andere mehr. Das Zend Studio (und damit die Eclipse-Plattform) ist klarer Gewinner des Vergleichs es kostet aber auch an die 400 €. Bleibt man bei den kostenfreien Lösungen gewinnt meines Erachtens die Netbeans-Lösung vor Eclipse. Zum einen ist das Editieren von Code in vielerlei Hinsicht komfortabler, die IDE fühlt sich schneller an und vor allem sind mit Unittest-Unterstützung und Code-Coverage-Analyse bereits Pro-Features aus dem Zend Studio frei verfügbar.

Fazit: Auch für größere Projekte reicht die Netbeans-Lösung aus, in einem aktuellen Projekt spicht einzig das Code-Formatting noch unbedingt für Zend, alles andere könnte man vermutlich auch mit Netbeans erledigen.

Flex

Für Flex fällt Netbeans komplett aus, da es keinerlei Support bietet. Für Eclipse gibt es den großen Flex Builder von Adobe, der kostenpflichtig ist, es sei denn man ist Student oder grade durch die Wirtschaftskrise arbeitslos geworden. IntelliJ ist ja eine kommerzielle IDE, aber der Flex Support kostet keinen Aufpreis.

Der Flex Builder ist so ziemlich der Standard wenn es um Flex Entwicklung geht. Er hat einen einmaligen visuellen Editor, der Roundtip-Engineering zwischen visueller und coding Ansicht bietet. Flex Builder bietet in Sachen Run-Configuration, Debugging und Profiling so ziemlich alles was man benötigt. Der Editor ist jedoch nur mäßig, so gibt es kaum Möglichkeiten, die Sourcen zu verändern, noch nicht mal ein “Format Source” ist dabei. Für einige Sachen gibt es Plugins aber vieles bleibt außen vor. Der Flex Builder ist entweder Standalone mit Eclipse zu beziehen oder als Eclipse Plugin.

Ein zweites Eclipse Plugin sind die Flash Development Tools (FDT) von Powerflasher, die in ihrer neuesten und teuersten Version Unterstützung für Flex bieten. Der Coding Comfort soll hier sehr gut sein, aber für den fast doppelten Preis des Flex Builders ist das definitiv zu viel.

Eine Alternative bietet hier IntelliJ gerade wenn man noch in anderen Sprachen programmiert erhält man einen ausgezeichneten Flex Support. Die Editorfunktionen sind sehr umfangreich und man findet viele Features, die man normalerweise nur in einem Java-Editor finden würde. Idea 8 unterstützt auch das Debugging von Flex.

Fazit: Eclipse oder IntelliJ Idea ist hier die Entscheidung. Wer das eine oder das andere mag wird seine Flex IDE aus dem gleichen Hause nehmen. Gerade wenn beide Backends in Java gecodet werden spielt es keine Rolle. Ist das Backend zu einer Flexanwendung aber in PHP geschrieben so bietet sich die Kombination Zend Studio for Eclipse in Verbindung mit dem Flex Builder Plugin an.

Groovy & Grails

Für Groovy und Grails gibt es für alle drei IDEs Unterstützung aber in unterschiedlicher Qualität. Ein ziemlicher Ausfall ist das Plugin für Eclipse. Es kann sehr wenig und ist noch in einem frühen Stadium. IntelliJ war lange der Marktführer in Sachen Groovy-/Grails-Support, der Vorsprung schwindet aber mit jeder Version von Netbeans stärker. Die aktuelle Beta von Netbeans 6.7 reicht an die Fähigkeiten von Idea 8 heran. Hier entscheidet alleine, was es für Vorlieben gibt. Eclipse sollte aus der Entscheidung außen vorgelassen bleiben und wenn schon IntelliJ im Hause ist sollte man dabei bleiben. Startet man aber auf der grünen Wiese oder will einfach mal nur mit einer gescheiten Entwicklungsumgebung etwas Groovy und Grails programmieren, dürfte die Entscheidung eindeutig für die Netbeans 6.7 Beta ausfallen.

Java-Script / HTML

Java-Script wird von allen drei IDE hervorragend unterstützt. Für Eclipse gibt es mit Aptana sogar eine Distribution, die auf die JS Entwicklung abzielt. Idea 8 hat einen ebenfalls sehr guten Java-Script Support und zeigt dies eindrücklich mit dem Java-Script Debugger. Netbeans in der aktuellen Beta bringt auch einen exzellenten Java-Script Support mit und ist in Sachen Codeerkennung und Codevervollständigung vorne. Der HTML Support ist ebenfalls in allen drei IDEs gut bedacht und es macht für einen Entwickler durchaus Sinn eine der IDEs statt Dreamweaver :-/ oder anderer Tools wie Espresso zu benutzen. Die Entwicklungsgeschwindigkeit wird sich positiv bemerkbar machen. Man muss auch bei einer IDE nicht immer auf einen visuellen Modus verzichten.

Java

Last but not least will ich kurz auf Java eingehen, die Sprache, der alle drei IDEs ihre Existenz verdanken. Nicht nur weil sie in Java programmiert sind sondern auch weil Java die erste Sprache war, die sie unterstützten. Alle drei IDEs bieten einen hervorragenden Support für die Javaentwicklung und lassen kaum Wünsche übrig. Wer welche IDE für Java einsetzt, wird nach seinen Vorlieben (oder denen seines Projektleiters) entscheiden oder nach dem, was er gewohnt ist. Unterschiede gibt es trotz aller Gemeinsamkeiten dennoch. Ein großes Plus von Eclipse ist die Mannigfaltigkeit von Plugins, die einem die Javaentwicklung erleichtern oder diese Unterstützen. Neben dem freien Eclipse gibt es auch kostenpflichtige Distributionen, die spezielle Einsatzzwecke abdecken- Der Vorteil von Netbeans ist die Einfachheit der Inbetriebnahme. man installiert es lädt über den Plugin Manager ein paar Plugins nach und beginnt ein neues Projekt in kürzester Zeit. Wer einmal eine umfangreiche Eclipse-Installation aufgesetzt hat, kann davon nur träumen. IntelliJ Idea hat seine eingeschworene Nutzergemeinde und geht einen Sonderweg in Nutzerführung und IDE-Nutzung.

Fazit

Wer welche IDE nutzt sollte dies von seinen Vorlieben, den Vorgaben seiner Projekte und den Anforderungen abhängig machen. Geben sich die IDEs bei Java wenig, sieht es bei der Unterstützung für andere Sprachen schon wieder anders aus. Der Vorteil für den Entwickler ist, dass er für seine Technologie fast immer eine kostenfreie Option angeboten bekommt – nur selten ist ein Obulus für die Unterstützung einer Sprache notwendig. IntelliJ scheidet beim Thema Kostenfreiheit aus, da es kommerziell ist, genau wie der Flex Builder, Zend Studio oder MyEclipse. Netbeans, das lange das Stiefkind unter den IDEs war legt seit Version 6.5 ein atemberaubendes Tempo vor und hat zu den anderen IDEs längst aufgeschlossen. Es bleibt nur zu hoffen, dass Suns Übernahme durch Oracle nicht das Ende von Netbeans und die Entscheidung für JDeveloper bedeutet. Es wäre schade um eine gute IDE und auch die innovationstreibende Konkurrenz zu Eclipse wäre großteils verschwunden.

Wie auch immer die individuelle Entscheidung ausfällt, bleibt festzuhalten: Es ist gut, dass die Entwickler Freiheit in den eingesetzten Produktionsmitteln haben. Der zumeist kostenlose Zugang zu IDEs fördert auch den Zugang zur Programmierung. Und dass neben Java immer mehr Sprachen und Technologien einen zunehmend guten IDE Support erhalten ist wohl das größte Plus der aktuellen Entwicklung.