"Wenn Sie Node.js verwenden, dann machen Sie in Ihrem Leben etwas falsch", sagt Toby DiPasquale in seinem Blog. Schon der Ansatz, die V8-Engine des Chromium-Projekts auf Servern einzusetzen, sei völlig daneben. In seinem Unternehmen sei das die Fehlerquelle Nummer eins in der internen Liste offener Issues. Außerdem sei Node viel langsamer als nicht-optimiertes Scala.
In all seinen Jahren als Server-Programmierer habe DiPasquale nie ein derartig unkomfortables Framework wie Node.js gesehen. Schon nach sechs Monaten sei es unmöglich, die eigenen Entwicklungen nachzuvollziehen. Und das Modell, dass alle Prozesse zeitgleich ablaufen, mit alten Browserkomponenten und JavaScript umzusetzen, verursache bei ihm Kopfschmerzen.
Was DiPasquale am meiste am Node.js-Hype aufregt, ist die damit verbreitete Annahme, dass Skalierbarkeit das selbe wie Geschwindigkeit sei, und dass CPU-Leistung jetzt gar nicht mehr wichtig sei, weil Events nicht mehr blockieren und alles auf einem CPU-Kern läuft.
Abschließend bemängelt DiPasquale JavaScript als Sprach-Basis für ein Tool wie Node.js. Selbst Ruby und Python verständen mittlerweile Dependency Injection und hätten begriffen, dass Modularisierung langfristige Vorteile mit sich bringen, will man ein Projekt über lange Zeiträume pflegen. JavaScript verzichte auf solche wichtigen Erkenntnisse und stelle in dieser Hinsicht eher einen Rückschritt dar, meint DiPasquale.
Es ist interessant zu beobachten, wie wenige Stimmen gegen Node.js laut werden, wie konkret jedoch die einzelnen Kritiken ausfallen. Nicolas Cannasse bemängelt das Fehlen von Fairness sowie die Unvermeidlichkeit von Starving (siehe Cannasses Erläuterung). Der Anonyme Blogger FSK hat sich Node.js nur wenige Minuten angeschaut und kam zu demselben Schluss wie DiPasquale. Auf Ycombinator wird heftig debattiert, und sich gefragt, ob es nicht bessere Alternativen (Erlang, Twisted (Python), EventMachine (Ruby)) gibt, um den IO-Flaschenhals zu beseitigen (Was sich mit DiPasquales Befürchtung deckt, dass Node.js ein Fall von "Worse is Better" werden könnte).
Kommentare
Eine schwarz-weiss Bewertung halte ich hier für falsch. Genauso gleich unruhig zu werden blos weil bei Hacker News mal wieder die stampede der unzufriedenen Senior-Devs über die eigens in den Sand gesetzten Projekte heult. Das haben wir ja vor kurzem schon mit MongoDB erlebt. Gähn. Manche Leute sollten einfach mal nach 40 Stunden in der Woche nach Hause gehen. Das ist das was mir die Node Plattform immer wieder ermöglicht. Ein Wert den ich höher schätze als theoretische Diskussionen von Sprach-Fanboys #zitieren
Erstens ist "dependency injection" kein Problem dass mit irgendeiner Skript-Sprache besser oder schlechter zu lösen ist. Was wichtig ist, ist ein gutes Framework zu haben, dass einen erlaubt schnell eine Struktur aus Modulen und Klassen aufzubauen, die leicht austauschbar sind. Javascript hat viele gute Frameworks und ausserdem unterstützt Node.js module. Ich nutre z.b. für meine Node.js Scripte als Unterbau das Dojo Toolkit. Dojo bringt alles mit sich um ein gut struktueriertes Projekt aufzubauen (http://dojotoolkit.org/reference-guide/dojo/index.html).
Zweiter Vorteil für mich, ist dass man bei Node.js die gleiche Sprache im Frontend sowie im Backend für die Entwicklung nutzt. Ich interessiere mich für Node.js da ich gerne mal mit Operational Transforms arbeiten möchte um etwas wie Etherpad zu schreiben. Bei solch einen Projekt nutzt man die gleichen Klassen im Browser sowie auf dem Server damit zweimal die Daten auf die gleiche Art und Weise bearbeitet werden können. "Früher" mustte man ein OT Script Serverseitig in Java oder Python schreiben und dann das gleiche nochmal in Javascript. Mit Node.js braucht man das Script nur einmal in Javascript zu schreiben. Dies finde ich einfach genial, sowas können andere Sprachen nicht. #zitieren