Clean(er) Code mit ECMAScript 6

Artikel als PDF herunterladen:
Download Clean(er) Code mit ECMAScript 6

JavaScript ist nicht gerade für seine übersichtlichen Quellcodes bekannt. ECMAScript 6 versucht mit dieser Tatsache aufzuräumen. In diesem Artikel stelle ich einige der neuen Features auf den Prüfstand und versuche herauszufinden, wie man heutige JavaScript-Projekte übersichtlicher und damit einfacher lesbar gestalten kann.

Der Kern von JavaScript wurde innerhalb von drei Tagen entwickelt und war ursprünglich nur dazu gedacht, etwas Dynamik in die bis dahin statischen HTML-Seiten zu bringen. Heute erfreut sich JavaScript einer immer stärker werdenden Beliebtheit und wird zur Umsetzung ganzer Anwendungen eingesetzt. Damit ist klar, dass sich die Anforderungen an die Sprache seit ihrer Schaffung drastisch geändert haben. Komplexere Anwendungen und größere Teams erfordern eine gute Organisation und Lesbarkeit des Quellcodes. Eine Eigenschaft, für die JavaScript heute nicht gerade bekannt ist.

ECMAScript 2015 ist die inzwischen sechste Spezifikation für JavaScript. Sie bringt Neuerungen, die bei der Erfüllung dieser Anforderungen helfen können. Nachfolgend stelle ich die meiner Meinung nach wichtigsten Neuerungen in ECMAScript 6 vor und zeige, wie diese den bisherigen Code (basierend auf ECMAScript 5) verbessern können.

weiterlesen

ng-week: </> + ()-[]->() = b+

Unsere diesjährige Projektwoche stand ganz im Zeichen von JavaScript und Cypher. Wir wollten gemeinsam eine Anwendung entwickeln, die im Frontend auf AngularJS setzt und zur Datenhaltung eine Neo4J-Graphdatenbank verwendet. Die Anwendung sollte dabei ohne (Java-)Backend auskommen. Um das Ergebnis kurz vorwegzunehmen: Das hat super funktioniert!

Als Anwendungsfall diente eine klassische Adressverwaltung: Personen stehen mit Organisationen in Beziehung, Personen besitzen Kontaktdaten, Organisationen haben kontextabhängige Adressen, Personen finden sich in Empfängerlisten für Marketing-Aktionen wieder und vieles mehr. Die Modellierung dieser Beziehungen als Graph ist sehr intuitiv und hat uns gute Dienste als Diskussionsgrundlage geleistet.

Die technische Umsetzung blieb nicht ohne Herausforderungen. Es zeigte sich sehr schnell, dass das Rest-API der Neo4j-DB nicht auf die $resource Abstraktion von AngularJS passt. Auch mit dem $http-Service haben wir uns schwer getan. Wir hätten beinahe einen HATEOAS-Transformer implementiert, wäre nicht Peter – der erst später zu uns stieß – mit der Frage ins Haus gefallen, warum wir nicht den JavaScript-Treiber der Neo4j-DB verwenden. Eine kurze Evaluierung des APIs ergab: Das müsste gehen! Obwohl eine frühe 1.0, erwies sich der Treiber überaus stabil und weitgehend erwartungskonform.

Der JavaScript-Teil hat bei mir gemischte Gefühle hinterlassen. Das Bootstrapping der Anwendung mittels AngularJS war in wenigen Minuten erledigt. Allerdings ein Build-System aufzubauen, wo alle Ressourcen am Ende automatisch an der richtigen Stelle landen, hat mich viel fluchen lassen. Plugins für Grunt scheinen durchweg nichts von Fehler-Reporting zu halten. Eine Inkompatibilität zwischen grunt-usemin und grunt-angular-file-loader war so nur durch Raten zu finden.

Eine weitere Spitzfindigkeit zeigte sich in der Integration des Neo4j-Treibers mit AngularJS. Beide Frameworks setzen auf Promises – allerdings in verschiedenen Implementierungen. Der Neo4j-Treiber nutzt eine eigene, an ES6 angelehnte Implementierung, während AngularJS mit $q einen Service hat, der an den Digest-Zyklus des Frameworks gekoppelt ist. Die Folge war, dass Ergebnisse aus Datenbank-Abfragen nie unmittelbar angezeigt wurden. Peter – diesmal der, der von Anfang an dabei war – konnte den gordischen Knoten zerschlagen. Die von ihm etablierte Verwendungsweise von $q kannte ich bis dato nicht.

Als Fazit lässt sich festhalten: Keiner hat das Java-Backend vermisst. Wir haben uns durch JavaScript, AngularJS, NPM, Grunt, Bootstrap, Less, Neo4j und Cypher gekämpft und selbst alte Hasen konnten dabei noch neue Tricks dazulernen. Wir haben einen funktionsfähigen Prototyp implementiert, deren Fertigstellung im Wesentlichen jetzt nur noch Fleißarbeit ist. Auf unsere Zusammenarbeit und das erzielte Ergebnis können wir durchaus stolz sein.

JavaScript-Clients mit Dojo

Artikel als PDF herunterladen:
Download JavaScript-Clients mit Dojo

Der klassische Fat-Client ist tot! Immer mehr Anwendungen setzen stattdessen auf Webclients, welche sich kaum noch von herkömmlichen GUIs unterscheiden. Das Dojo Toolkit soll die Entwicklung solcher Clients vereinfachen und beschleunigen. Der folgende Artikel stellt die Bibliothek vor und bietet einen Einstieg in die Arbeit mit Dojo.

Das Dojo Toolkit ist eine umfangreiche Open-Source-Bibliothek (BSD/Academic Free License) für die Entwicklung JavaScript-basierter Clients. Das Projekt gibt es seit 2004 und ist momentan in der Version 1.10 verfügbar. Entwickelt und vertrieben wird Dojo unter der Schirmherrschaft einer gleichnamigen Stiftung. Außerdem erhält es Unterstützung von namhaften Unternehmen wie IBM und AOL. Das Toolkit ist in drei Namespaces gegliedert (siehe Bild 1). Der Teil „Dojo“ enthält grundlegende Funktionen wie Ajax-Kommunikation oder das Arbeiten mit Arrays. In „Dijit“ werden häufig benötigte GUI-Komponenten (Buttons, Kalender, etc.) bereitgestellt, welche durch ein Baukastensystem zu einer Oberfläche zusammengesetzt werden können. Der dritte Teil („DojoX“) enthält unterschiedlichste, teilweise experimentelle Funktionalität und soll in einer zukünftigen Version aufgelöst werden.

Aufbau des Dojo ToolkitsBild 1: Aufbau des Dojo Toolkit

weiterlesen