Hinter dem Hype

Sollte man sich als Java-Entwickler mit Node.js beschäftigen?
Kommentare

Dieser Artikel gibt Ihnen eine Einführung und einen Überblick über die Node.js-Plattform. Es wird gezeigt, wie Sie einen einfachen Server erstellen, ein Modul schreiben und mit Node.js in einer kommerziellen grafischen Entwicklungsumgebung (IDE) arbeiten.

Node.js ist ziemlich hochgejubelt worden, und es lässt sich nicht leugnen, dass verschiedene Leute denken, mit Node.js ließen sich alle Probleme lösen. Sie brauchen nur den ersten Absatz auf der Website nodejs.org zu lesen, um diesen Eindruck zu gewinnen.

„Node.js is a platform built on Chrome’s JavaScript runtime for easily building fast, scalable network applications. Node.js uses an event-driven, non-blocking I/O model that makes it lightweight and efficient, perfect for data-intensive real-time applications that run across distributed devices.“ [1]

Im Buzzword-Bingo würden Sie mit diesem Absatz alle Reihen füllen. Und das an sich ist ein Problem für mich. Denn ich bin noch ein Programmierer aus der guten alten Zeit, als „load ds“ tatsächlich noch etwas sehr Wichtiges bedeutete. Wenn Sie diesen Ausdruck in eine Suchmaschine eingeben, sollten Sie ihn in Anführungszeichen setzen und den Begriff „Assembler“ hinzufügen. Andernfalls erhalten Sie Informationen zu einem Spiel, auf das ich aber nicht hinweisen wollte.

Was ist Node.js?

Um zu verstehen, was der Absatz zu vermitteln versucht, sehen wir uns Node.js zunächst aus bloßer Technologieperspektive und dann aus einer Architekturperspektive an.

Unter bloßer Technologieperspektive basiert Node.js auf der Programmiersprache JavaScript, die über das JavaScript-Modul von Chrome V8 ausgeführt wird. Das Chrome-V8-JavaScript-Modul ist ein in C++ geschriebenes Open-Source-Projekt von Google. Als Node.js-Programmierer brauchen Sie kein C++-Programmierer zu sein, doch wenn Sie native Erweiterungen schreiben möchten, sind Kenntnisse von C und C++ zweifellos von Vorteil. Zum Einstieg genügt es aber, wenn Sie JavaScript beherrschen.

Bei manchen Leuten löst es Unbehagen aus, wenn sie hören, dass ein Programm in einer dynamischen Sprache wie zum Beispiel JavaScript geschrieben ist, und zwar weil dynamische Programmiersprachen recht langsam sind und ziemlich viel Speicher und Ressourcen belegen. Beim JavaScript-Modul von Chrome V8 sieht die Sache größtenteils anders aus, da es bei der Ausführung JavaScript in nativen Code kompiliert. Natürlich sind keine Wunder zu erwarten, denn dynamische Sprachen mit ihrem typenlosen Datenmodell ziehen trotzdem noch Leistungseinbußen nach sich. Allerdings kann ich mit diesem Kompromiss leben, da typenlose Variablen andere Vorzüge haben. Doch zurück zum eigentlichen Thema des Artikels.

Bevor ich zur Architekturperspektive übergehe, sei eine persönliche Randbemerkung gestattet: Ich halte es für das beste Konzept, Node.js unter Linux zu entwickeln und auszuführen. In der letzten Zeit habe ich Code unter Windows verwendet, entwickle nun aber ausschließlich unter Linux und OS X. Der Vorteil bei Node.js unter Linux liegt darin, dass sich eine Entwicklungsumgebung leichter definieren lässt und es unkomplizierter ist, native Module zu schreiben. Betrachten Sie dies aber bitte als persönliche Beobachtung und nicht als Empfehlung.

Aus dem Blickwinkel der Architektur verwendet Node.js ein Ereignistypprogrammiermodell. Sehen Sie sich den folgenden Code an, wobei die konkreten Funktionsbezeichner momentan keine Rolle spielen. Es geht zunächst nur um die Codestruktur:

server.get('/*', function(req, res){     throw new NotFound; });

Die Variable server ist ein Objekt, das über die Funktion get verfügt. Die Funktion get übernimmt zwei Parameter, eine Zeichenfolge und ein function-Objekt. Das Funktionsobjekt ist ein entscheidendes Merkmal in Node.js, da es den Mechanismus realisiert, um Anforderungen zu verarbeiten. Es ist ein ereignisgesteuerter Ansatz, der Closures verwendet, um bestimmte Aufgaben zu behandeln. Vergleichen Sie dieses Konzept mit dem von Java, das eine Konfigurationsdatei und eine Klassenimplementierung voraussetzt (Listing 1 und 2).

Listing 1
             webdav         /files/*     
Listing 2
public class ProxyServlet extends HttpServlet {     public void service(HttpServletRequest req, HttpServletResponse res)             throws ServletException, IOException {   } }

Im Java-Ansatz erzeugt die Konfigurationsdatei web.xml einen Querverweis zwischen dem URL und dem Code, um die Anforderung zu verarbeiten. Der für die Verarbeitung der Anforderung zuständige Code ist eine Klasse, die eine andere Basisklasse erweitert. Das Java-Konzept entspricht einem klassischen objektorientierten Ansatz, wobei eine Konfigurationsdatei gemeinsam mit Code eine bestimmte Funktionalität umsetzt. Zwar haben Konfigurationsdateien durchaus ihre Berechtigung, doch laufen in vielen Projekten die Konfigurationsdateien aus dem Ruder, da sie zu komplex werden und den Code spröde machen.

Eine Konfigurationsdatei mit der Klassendefinition soll die Trennung von Verantwortlichkeiten ermöglichen. Zum Beispiel sollte ich in der Konfigurationsdatei in der Lage sein, den URL /* oder sogar /irgendetwasanderes/* zu referenzieren. Doch leider gehen Theorie und Praxis oftmals nicht Hand in Hand. Der Programmierer muss insbesondere darauf achten, dass sein Code zweckmäßig abstrahiert ist und keine ungewollten Abhängigkeiten entstehen. Ich will die objektorientierte Programmierung nicht verteufeln, ich stelle nur Probleme heraus.

Verglichen mit anderen dynamischen Sprachumgebungen weist das Node.js-Prinzip sowohl Gemeinsamkeiten als auch Unterschiede auf, wobei bestimmte Annahmen und bewährte Programmierstile vorausgesetzt werden.

Die erste Anwendung erstellen und debuggen

Wenn es irgendeine Schwäche in der Node.js-Infrastruktur gibt, dann die, dass standardmäßig keine vollständige Entwicklungsumgebung dabei ist, die auch einen Debugger enthält. Zum Beispiel präsentiert Ihnen die Node.js-Debugging-Seite die in Listing 3 angegebene Lösung.

Listing 3
% node debug myscript.js 

Als Entwickler bin ich an Umgebungen wie IntellJ, Eclipse oder NetBeans gewöhnt, und wenn ich eine derartige Lösung sehe, kann ich nur den Kopf schütteln und sagen: „Komm wieder, wenn du eine richtige Umgebung hast.“

Als alternative Debugging-Lösung bieten sich die Google Chrome Developer Tools for Java an [2]. Interessant für den Node.js-Entwickler ist der Eclipse Debugger, mit dem sich Node.js-Tools debuggen lassen, wie es unter [3] skizziert wird.

Der zweite Ansatz, der die Chrome-Tools verwendet, ist für eine Entwicklungsumgebung besser geeignet. Ich bevorzuge aber eine andere Lösung, die aus der Firma JetBrains stammt und WebStorm heißt. Obwohl ich normalerweise nach Open-Source-Tools suche, sage ich „Ja“ zu einem Closed-Source-Tool, wenn es sich als sehr nützlich erweist und preislich tragbar ist, da mir dieses Tool jede Menge Kummer erspart. Äußerst nützlich bei WebStorm ist, dass es die Entwicklungsumgebung unter Verwendung der üblichen Node.js-Programmierempfehlungen einrichtet.

Wenn Sie WebStorm heruntergeladen und installiert haben, rufen Sie WebStorm je nach Ihrem Betriebssystem entweder über ein Symbol oder ein Befehlszeilenprogramm auf. Starten Sie die Anwendung und erstellen Sie dann ein neues Projekt, was wie in Abbildung 1 gezeigt aussieht.

Abb. 1: Ein neues Projekt erstellen

Einen Projektnamen können Sie frei festlegen, wichtig ist vor allem, im Kombinationsfeld den Projekttyp Node.js Boilerplate auszuwählen. Bei diesem Projekttyp wird eine einfache Node.js-Anwendung erstellt, die die wesentlichen Komponenten (HTML5 Boilerplate, Express, Jade und Socket.IO) herunterlädt und installiert.

Nachdem das Projekt erstellt ist, zeigt WebStorm in der rechten oberen Ecke eine Warnung an, dass Sie noch einen weiteren Schritt ausführen müssen (Abb. 2).

Abb. 2: Zusätzlicher Schritt, den Sie ausführen müssen

Der zusätzliche Schritt ist wirklich notwendig, denn sonst ist Ihre Node.js-Anwendung nicht vollständig. Öffnen Sie also eine Eingabeaufforderung oder ein Terminal und führen Sie den Befehl initproject.sh aus. Daraufhin werden die Befehle ausgelöst, um die verschiedenen Bibliotheken in das Node.js-Projekt herunterzuladen und zu installieren, wie die Terminalausgabe in Abbildung 3 zeigt.

Abb. 3: Terminalausgabe beim Herunterladen zusätzlicher Bibliotheken

Wenn das Skript fertiggestellt ist, ändert sich die Projektstruktur, wie in Abbildung 4 gezeigt.

Abb. 4: Aktualisierte Projektstruktur

Nunmehr sind Sie bereit, die Node.js-Anwendung zu kodieren, zu debuggen und auszuführen.

Eine Node.js-Anwendung kennt kein main-Konzept, wie es Ihnen von Java- oder C++-Programmen her geläufig ist. Die Node.js-Anwendung ist das Skript, das Sie gerade ausführen. Im standardmäßig angelegten Projekt finden Sie eine Datei server.js. Sie müssen node aufrufen und den Skriptdateinamen als Parameter übergeben, wie die Befehlszeile im folgenden Code zeigt:

Chur-Macbook-Air:Example christianhgross$ node server.js     info  - socket.io started Listening on http://0.0.0.0:8081

Die Ausgabe ist einfach und gibt an, wo ein Webserver an Port 8081 hört. Wenn Sie einen Browser auf dem lokalen Computer ausführen und den URL http://localhost:8081 eingeben, erhalten Sie als Ergebnis eine einfache Sendebestätigung. Das heißt, dass Ihre Anwendung läuft.

Um die Anwendung von WebStorm aus zu debuggen, müssen Sie über das Menü Run | Edit configurations eine Konfiguration erstellen. In der linken oberen Ecke des Dialogfelds finden Sie nebeneinander ein Plus- und ein Minuszeichen. Klicken Sie auf das Pluszeichen. Daraufhin erscheint ein Drop-down-Kombinationsfeld. Wählen Sie hier node.js aus. Damit legen Sie fest, dass Sie für eine Node.js-Anwendung eine Debug-Konfiguration anlegen möchten. Nachdem Sie auf die Schaltfläche geklickt haben, sollte das Dialogfeld aussehen, wie in Abbildung 5 gezeigt.

Abb. 5: Debugging-Konfiguration

Schließlich müssen Sie noch das Feld Path to Node App JS File ausfüllen. Geben Sie hier server.js ein, d. h. die generierte server.js-Datei. Klicken Sie auf OK, und schon sind Sie bereit zum Debugging. Klicken Sie dazu in der Symbolleiste auf das Symbol, das wie eine Wanze aussieht, die in ein Größer-als-Zeichen läuft (Abb. 6).

Abb. 6: Die Node.js-Anwendung debuggen

Wenn Sie die Schaltfläche drücken, passiert noch nicht viel, da Sie lediglich die Anwendung genau wie von der Befehlszeile ausgeführt haben. Im Unterschied dazu können Sie hier aber die Datei server.js im Editor öffnen und einen Haltepunkt setzen, der erreicht wird, wenn Sie die Anwendung beenden und erneut zum Debuggen ausführen. Nun können Sie endlich Code schreiben, der über den generierten Code hinausgeht.

Eine Node.js-Anwendung schreiben

Basierend auf dem Code, den Sie im vorherigen Abschnitt generiert haben, erstellen wir nun eine neue Datei namens testme.js. Klicken Sie in WebStorm auf File | New, um eine neue JavaScript-Datei mit dem Namen testme anzulegen. In die erstellte JavaScript-Datei geben Sie nun den folgenden Code ein:

console.log("hello world")

Diesen Code können Sie von der Befehlszeile mit dem Befehl node testme.js ausführen oder einen neuen Debug-Konfigurationseintrag mit der Datei testme.js als auszuführendes Skript erstellen. In beiden Fällen startet node das Skript, gibt „hello world“ aus und beendet es dann.

In diesem Beispiel haben wir etwas erstellt, was das Node.js-Äquivalent von „hello world“ ist. Wir machen dies nun ein wenig komplexer und übernehmen den Code von der Node.js-Homepage per Copy and Paste in testme.js. Dieses sehr einfache Codefragment erzeugt einen rudimentären Webserver, der „hello world“ als HTTP-Antwort ausgibt. Listing 4 gibt den Code an.

Listing 4
console.log("hello world") var http = require('http'); http.createServer(function (req, res) {     res.writeHead(200, {'Content-Type': 'text/plain'});     res.end('Hello Worldn'); }).listen(1337, '127.0.0.1'); console.log('Server running at http://127.0.0.1:1337/');

Dieses Mal haben Sie einen Webserver erstellt, der auf Port 1337 hört. Und er gibt den Text „hello world“ aus. Jetzt machen wir das Ganze noch etwas komplizierter und öffnen zwei Webbrowser mit jeweils demselben URL. Wenn Sie im Browser mehrmals auf Aktualisieren klicken, erscheint jedes Mal ein „hello world“. Um dieses Beispiel abzuschließen, ändern Sie testme.js in den Code von Listing 5.

Listing 5
console.log( "hello world"); var http = require('http'); var flipFlop = 0; http.createServer(function (req, res) {     res.writeHead(200, {'Content-Type': 'text/plain'});     if( (flipFlop % 5) == 0) {         flipFlop ++;         var maxCounter = 1000000;         var val = 0.0;          for( var counter1 = 1; counter1 < maxCounter; counter1 ++) {             for( var counter2 = 1; counter2 < maxCounter; counter2 ++) {                 for( var counter3 = 1; counter3 < maxCounter; counter3 ++) {                     for( var counter4 = 1; counter4 < maxCounter; counter4 ++) {                         val = counter1 + counter2 + counter3 + counter4;                     }                 }             }         }         res.end('Hello World jackpotn');     }     else {         flipFlop ++;         res.end('Hello World nope not yetn');     } }).listen(1337, '127.0.0.1'); console.log('Server running at http://127.0.0.1:1337/');

Der modifizierte Code inkrementiert die Variable flipflop, und wenn ein Vielfaches von 5 erreicht ist, wird ein Jackpot ausgegeben und eine Schleife gestartet. Die Schleife stellt eine längere Berechnung dar, die recht viel Zeit in Anspruch nimmt. Wird kein Vielfaches getroffen, generiert die Anforderung eine Ausgabe und alles sollte in Ordnung sein.

Lassen Sie die beiden Browser diesen Code ausführen und klicken Sie fortwährend auf Aktualisieren. Sehr schnell werden Sie feststellen, dass sich beide Seiten blockieren, und hier wird es verwirrend. Denn spielen wir einmal dieses Szenario durch: Die erste Anforderung ist null, trifft den Jackpot, und noch bevor die lange Berechnung beginnt, wird die Variable flipflop inkrementiert.

Das Inkrementieren der Variablen ist wichtig, denn es bedeutet, dass die nächste Anforderung die lang laufende Berechung nicht ausführen sollte. Somit sollte eine andere Browseranforderung die Daten wie vorher zurückgeben. Doch es passiert nichts. Sie könnten sogar einen Haltepunkt unmittelbar auf die if-Anweisung setzen und feststellen, dass die Anforderung niemals das Funktionsobjekt erreicht. Einfach ausgedrückt hat der HTTP-Server die Verarbeitung von Anforderungen eingestellt.

In einem Java-Webserver-Szenario passiert dies niemals, weil jede Anforderung in einem eigenen Thread verarbeitet wird. Dagegen gibt es in einer Node.js-Anwendung nur einen einzigen Thread. Ja, Sie haben richtig gelesen: nur einen einzigen Thread! Viele Node.js-Anhänger würden sagen, dass dies eine gute Idee ist, und sie werden Gründe dafür anführen.

Mein erster Gedanke war allerdings: „Das meinen die nicht ernst.“ Ich bin mit der Programmierung von UNIX-Boxen aufgewachsen, bevor es Threads gab. In dieser Welt wurde alles in einem Thread abgewickelt, und es war die reinste Folter. Damit eine Anwendung reaktionsfreudig bleibt und in der Lage ist, mehrere Aufgaben auf einmal auszuführen, musste man einen Prozess aufteilen. Das war aufwändig und kompliziert, da immer irgendein prozessübergreifender Kommunikationsmechanismus einzurichten war.

Doch wenn ich aus einem gewissen Abstand über das Design einer Node.js-Anwendung nachdenke, leuchtet mir der Grund ein, und er verlangt von uns, sich noch einmal Listing 7 oder sogar Listing 1 anzusehen. Hier haben wir eine function-Methode, die einen Parameter als Funktionsobjekt übernimmt. Dies ist in Node.js ein bestimmendes Architekturkonzept, wobei das Funktionsobjekt als Callback übermittelt wird, wenn ein Ereignis auftritt.

Sehen wir das im Zusammenhang. Trifft eine Anforderung ein, generiert der HTTP-Server ein Ereignis, das einen Aufruf des Funktionsobjekts nach sich zieht. Das Funktionsobjekt soll das Ereignis verarbeiten und die Steuerung an den HTTP-Server zurückgeben. Wird diese Steuerung nicht zurückgegeben, bleibt der Webserver hängen und es kann keine andere Anforderung verarbeitet werden.

Somit liegt die Entscheidung bei Ihnen, wie Sie die Steuerung an den Webserver zurückgeben, ohne die übrige Anwendung zu blockieren. Praktisch möchten Sie in der Lage sein, einen Thread aufzuspannen, wie es ein Java-Programmierer tun würde. Nun sind aber Threads in dem Sinne problematisch, dass Sie damit Deadlocks, Race Conditions und jede Menge anderer Probleme hervorrufen können. Die meisten Programmierer verlassen sich stattdessen auf einen Satz von Bibliotheken auf höherer Ebene, die sich um die Details auf der systemnahen Ebene kümmern. Und dies ist der Weg, den Sie in Node.js einschlagen. Der URL [4] verweist auf eine Anzahl von Ablaufsteuerungsmodulen, mit denen Sie Ihr Node.js in die Lage versetzen, „einen Thread aufzuspannen“.

Ein eigenes Modul schreiben

Im letzten Teil dieses Artikels möchte ich darauf eingehen, wie Sie ein eigenes Modul schreiben. In reinem JavaScript würden Sie eine Klasse anlegen und dann diese Klasse füllen. Das Problem dabei ist, dass JavaScript das Konzept von Namespaces nicht kennt. Ohne Namespaces dürften Konflikte mit Klassendefinitionen auftreten, und Sie erzeugen möglicherweise Fehler, die sich nur äußerst schwer aufspüren lassen. Um Node.js erweiterbar und dennoch stabil zu machen, ist darin ein Modulkonzept realisiert. Es gibt zwei Arten von Modulen, node_modules und einfache Module. Einfache Module werden im Stammverzeichnis gespeichert. Allerdings sind sie nicht zu empfehlen, da zu viele einfache Module einen Projektarbeitsbereich vollstopfen würden.

Deshalb sollten Sie lernen, wie Sie für Ihre Anwendung ein geeignetes Modul erstellen. Mit WebStorm haben Sie schon die halbe Schlacht gewonnen, da das Tool die Verzeichnisstruktur für Sie anlegt. Führen Sie dann über WebStorm die folgenden Schritte aus:

  1. Suchen Sie im Projektarbeitsbereich das Verzeichnis node_modules.
  2. Im Verzeichnis node_modules erstellen Sie nun ein Modul namens mymodule. Dazu legen Sie ein Verzeichnis mymodule an.
  3. Im Verzeichnis mymodule erstellen Sie ein weiteres Verzeichnis namens lib.
  4. Im Verzeichnis mymodule legen Sie die Datei index.js an.
  5. Im Verzeichnis lib legen Sie die Datei mymodul.js an.

Die Verzeichnisstruktur sollte dann wie in Abbildung 7 aussehen.

Abb. 7: Die Node.js-Verzeichnisstruktur für das Modul „mymodule“

Die Verzeichnisstruktur ist wichtig, denn es ist eine bewährte Methode, ein Modul namens mymodule und darin eine Bibliothek für JavaScript-Dateien zu erzeugen, die die Funktionalität von mymodule implementieren.

Wenn Sie auf ein formales Node.js-Modul verweisen, sucht Node.js nach diesem Modul im Verzeichnis node_modules. Dann wird im Stammverzeichnis des Moduls (mymodule) die Datei package.json geladen. Diese Datei enthält die Beschreibung, wie das Modul strukturiert ist, wer es geschrieben hat, welche Abhängigkeiten bestehen, die Versionsnummer und jede Menge anderer Dinge. Das Beispiel verzichtet auf package.json, da es möglichst einfach bleiben soll. Wenn Node.js eine fehlende Datei package.json ermittelt, wird versucht, zuerst index.js und bei fehlender Datei index.js die Datei index.node zu laden.

In index.js ist es lediglich erforderlich, die geeigneten JavaScript-Dateien zu laden, die für die Funktionalität des Moduls zuständig sind. In einem anderen Beispiel heißt das, dass die Datei mymodul.js zu laden ist. Der Code hierfür ist folgender:

module.exports = require('./lib/mymodule.js');

Die Syntax ist sehr wichtig und muss eingehalten werden. Der Variablen module.exports wird die Ausgabe des require-Funktionsaufrufs zugewiesen. Die Funktion require lädt die Teile, aus denen das Modul besteht, in diesem Fall mymodule.js. Hätte ich mymodule.js weggelassen und nur das Verzeichnis lib referenziert, würden alle Dateien im Verzeichnis lib geladen. Es stellt sich die Frage, ob alle JavaScript-Dateien im lib-Verzeichnis gespeichert sein müssen. Die Antwort ist: nein. Diese Vorgehensweise hat sich lediglich bewährt, da man in index.js definiert, wo sich die Dateien für das Modul befinden.

In der Datei mymodule.js implementieren Sie nun die Funktionalität. In diesem Fall handelt es sich um eine Variablenzuweisung und einen Funktionsaufruf.

exports.answer = 42;  exports.callMe = function( inputVal) {     console.log( "[Your message => " + inputVal + "]"); }

Alles, was Sie exportieren möchten, weisen Sie der Variablen exports zu, die Node.js implizit definiert. Jede Variable, die Sie nicht exports zuweisen, ist für jeden Konsumenten Ihres Moduls zugänglich. In diesem Sinne haben Sie eine Art Deklaration von öffentlichen und privaten Klassen-Membern. Das Beispiel definiert die Variable answer und die Funktion callMe.

Damit ist die Moduldefinition vollständig, und wir müssen nun das Modul als Client aufrufen. Dazu zapfen Sie den Loader mithilfe des require-Methodenaufrufs an, der in der Datei index.js verwendet wird. Die eigentliche Aufgabe von require besteht darin, eine JavaScript-Datei zu laden, sie als Modul zu definieren und alles miteinander über implizite Variablen zu verbinden.

var mymodule = require('mymodule') mymodule.callMe( "what am I calling?"); console.log(mymodule.answer);

Die erste Zeile lädt mymodule und weist es der Variablen mymodule zu. An diesem Punkt wird alles, was ich oben an exports zugewiesen habe, an mymodule zugewiesen. Somit kann ich direkt auf die Member-Variable answer und die Funktion callMe verweisen. Node.js-Entwickler verwenden oftmals diesen Mechanismus als generische Fabrik, um die Objekte zu instanziieren, die die eigentliche Arbeit übernehmen.

Fassen wir zusammen

Node.js ist keine Patentlösung. Es ist ein brauchbares Konzept, wenn Sie JavaScript-Entwickler sind und mehr aus der Sprache JavaScript herausholen möchten. Als Java-Entwickler werden Sie angesichts dieser Lösung denken: „Ich weiß nicht, ob das wirklich etwas bringt.“ Und ehrlich gesagt liegen Sie damit gar nicht so daneben. Ich denke bei Node.js eher an eine schnelle Umsetzung von Webproblemen. So kann ich mir leicht vorstellen, die Webanwendung mit Node.js zu erstellen, und dann mit Java als Rückgrat die Verarbeitung über Webdienste vorzunehmen (entweder XML oder JSON).

In Wahrheit haben wir Unmengen von Java-Frameworks, um Webseiten zu generieren, und jedes erzeugt eine große Anzahl von Konfigurations- und Codedateien. Uns wird Flexibilität vorgegaukelt, doch sind sie in meinen Augen anfällig wie eh und je. Mit Node.js erhalte ich ein schnelles Framework, da sowohl die Client- als auch die Serverseite mit JavaScript arbeitet. Die Dinge sind einfacher, da Sie nicht darüber grübeln müssen, was ein Objekt wie realisiert. Ich bin hier nicht auf die verschiedenen Frameworks zur Webgenerierung wie Jade eingegangen, doch sind sie zweifellos eine Erkundung wert.

Insgesamt bin ich der Meinung, dass Sie als Hardcore-Webentwickler zumindest einmal einen Blick auf Node.js werfen sollten.

Aus dem Englischen von Frank Langenau.

Unsere Redaktion empfiehlt:

Relevante Beiträge

Meinungen zu diesem Beitrag

X
- Gib Deinen Standort ein -
- or -