Archive

Posts Tagged ‘AJAX’

Vormerken: Nächstes Treffen der Flex UserGroup am 2. September

July 23rd, 2009 Reto Kiefer No comments

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

Gehört JavaScript wirklich die Zukunft der Web Anwendungen?

July 10th, 2009 Reto Kiefer 2 comments

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.

JSON Formatter

June 7th, 2008 Reto Kiefer No comments

Ich bin ja bekanntermaßen kein Fan von JSON sondern ziehe wohlformatiertes XML der besseren Lesbarkeit und Verarbeitbarkeit (außerhalb von Java-Script) vor. Nun kann man es sich nicht immer aussuchen und da wir in einem aktuellen Projekt festgestellt haben, dass ExtJS deutlich besser mit JSON als mit XML umgehen kann (obwohl letzteres theoretisch unterstützt wird) generieren wir nun JSON als Service-Rückgabe alternativ zu XML.

Das Problem beim Betrachten von JSON im Unterschied zu XML ist, dass man es gänzlich ungeordnet sieht. Zeichen hängt an Zeichen und man sieht nicht auf den ersten Blick welche Hierarchien es in dem JSON Fragment gibt.

Hier hilft ein nützliches online Tool namens JSON Formatter. Einfach den JSON-Code oder eine Service-URL, die JSON zurückgibt eingeben, Process clicken und schon sieht man sein JSON perfekt eingerückt und gut lesbar formatiert.

Das macht die Arbeit mit JSON nicht erfreulicher aber leichter ;o)

Categories: AJAX, Development, PHP Tags: , ,

ExtJS im Lizenzchaos

May 2nd, 2008 Reto Kiefer No comments

Die beliebte AJAX Library ExtJs hat sich den Unmut vieler Entwickler zugezogen, in dem sie in einem minor Release die Lizenz gewechselt haben.

Es ist nicht das erste mal, dass ExtJs so etwas tut, die Library startete ursprünglich einmal unter einer BSD Lizenz, wechselte dann aber unter die LGPL mit einigen Zusatzbestimmungen.

Nun aber kommt der Wechsel zu einem Dual-Lizenzmodell, auf der einen Seite GPL auf der anderen Seite eine kommerzielle Lizenz. Der Aufschrei in der Entwicklerwelt und der Blogosphäre ist groß, denn von nun man muss man entweder seine Modifikationen / Erweiterungen an ExtJS wiederum unter der GPL veröffentlichen (was für viele kommerzielle Projekte ausscheidet) oder aber man muss eine kommerzielle Lizenz erwerben.

Es ist natürlich und legitim, dass man mit einer guten Software Geld verdienen will, aber dann sollte man von Anfang an ehrlich zu seinen Anwendern sein. Nicht erst mit einer geschäftsfreundlichen Lizenz anfangen, um die Leute anzufixen um dann später mit der Lizenzerpressung das Hand-Aufhalten zu beginnen. So bringt man das ganze OpenSource-Modell in Verruf.

Auch ein mittlerweile erfolgtes nachträgliches Nachbessern seitens ExtJS löst das Problem der kommerziellen Nutzung nicht.

Categories: AJAX, Development Tags: ,