JavaScript is the new Black

May 18, 2013

Vor ca. 5-6 Jahren war ich ziemlich froh, dass ich endlich mit "diesem JavaScript Krams" aufhören konnte. Bis dato habe ich eigentlich recht viel Javascript in meinen Business-Applikationen eingesetzt, jedoch meist ohne oder mit Lowlevel-Frameworks (wer erinnert sich noch gerne an Prototype?). Ajax-Funktionalität war noch nicht weit genug weggekapselt und man hatte in jedem Projekt immer wieder viel und oft den gleichen Boilerplate-Code per Hand zu schreiben. Schnell wurde das unübersichtlich, Editoren (von IDEs ganz zu schweigen) gabs auch keine - kurz, das ganze Ökosystem war einfach noch nicht so weit.

Das ist jetzt mittlerweile anders geworden.
Das Ökosystem UND meine Einstellung zu Javascript!
Eine ganze Reihe guter Frameworks, IDEs für on- und offline Einsatz, und sogar Javascript auf dem Server. Performant und leistungsfähig ist "dieser JavaScript Krams" auch noch geworden. Und wer hätte es gedacht? Das macht sogar Spaß! Also... kann es machen, wenn man mit dem richtigen Framework arbeitet!

Im Dezember letzten Jahres habe ich bei der JUG DA den Vortrag von Golo Roden über Node.js gehört. Da bin ich schon wieder etwas auf Javascript und das Konzept "Serverseites Scripting" neugierig geworden (davor hielt ich nicht viel von der Sache, aber ich kannte es ja auch noch nicht), habe es aber nicht wirklich geschafft, mich an die Sache ranzusetzen und mich einzuarbeiten. Heiko kam dann kurze Zeit später mit dem Meteor-Framework an und schlug vor, darüber einen Artikel zu schreiben, oder eine Session zu entwickeln, die auf verschiedenen Konferenzen gehalten werden könne.

Meteor basiert auf und nutzt Node.js, bricht aber an der ein oder anderen Stelle mit dem Single-Thread-Modell. Ein Hauptaugenmerk liegt auf dem Live-Update von Daten und der Applikations-Logik bei allen aktiven und verbundenen Clients. Wird eine Datei (egal ob HTML, JS oder CSS, ...) auf dem Server geändert, wird diese sofort allen Clients untergeschoben und diese integrieren die neue Logik unterbrechungsfrei. Ändern sich gemeinsam genutzte Daten auf einem Client, werden diese Änderungen sofort an alle anderen Clients weitergegeben. Somit ist die Anwendung jederzeit überall aktuell!
Die MongoDB wird embedded mitgeliefert (kann aber auch separat installiert und angesprochen werden) und stellt ebenfalls eine zentrale Komponente dar. Die Spracherweiterung von Meteor stellt so z.B. eine völlig schlanke (und für den Entwickler transparente!) Möglichkeit dar, eine Collection in der Datenbank abzubilden bzw. zu persistieren: wird der Collection beim Erzeugen ein Name mitgegeben, wird diese unter dem verwendeten Namen mit der MongoDB synchronisiert. Lässt man den Namen weg, ist die Collection nur zur Laufzeit vorhanden, bzw. im jeweilig erzeugten Sichtbarkeits-Kontext.
Meteor ist quasi ein Bundle von verschiedenen Packages wie sie auch für Node.js zur Verfügung stehen, mit einer eigenen Spracherweiterung und einer integrierten Template-Engine. Diese ist per default Handlebars, kann aber auch gegen andere präferierte Template-Engines ausgetauscht werden. Grundsätzlich ist man nie an irgendetwas fest gebunden. Handlebars reicht aber für meine Zwecke bislang völlig aus.

Jetzt sitzen wir also hier, entwickeln parallel unsere Vortrags-Session und die dazugehörige Demo-Anwendung mit Meteor. Es ist noch etwas Arbeit, aber es macht unheimlich viel Spaß! Am 24. Juni ist es dann soweit und wir präsentieren auf der DWX13 in Nürnberg: Meteor vor dem Einschlag!

Tags: javascript nodejs meteor mongodb