Node.js und Deno im Vergleich

the next big thing Golo Roden  –  25 Kommentare

Mit Node.js und Deno stehen inzwischen zwei Laufzeitumgebungen auf Basis von V8 zur Verfügung, die JavaScript (und TypeScript) ausführen können. Während Node.js seit über 10 Jahren existiert, ist Deno noch verhältnismäßig jung. Wie unterscheiden sich die beiden Plattformen, und was spricht für Node.js, was für Deno?

Node.js ist eine serverseitige Laufzeitumgebung für JavaScript, die auf dem V8-Compiler von Google basiert, der auch im Webbrowser Chrome zum Einsatz kommt. Seit der Einführung von Node.js im Jahr 2009 hat sich die Plattform zu einer der wichtigsten Entwicklungsplattformen für Web- und Cloud-Anwendungen entwickelt.

Am 20. Oktober ist nun die neue Version 15 von Node.js erschienen, inzwischen ist auch die bis dahin aktuelle Version 14 zur neuen LTS-Version geworden, die sich durch verlängerte Unterstützung durch die Entwicklerinnen und Entwickler auszeichnet. Zu den Neuigkeiten in und um Node.js 15 habe ich vor knapp zwei Wochen auch ein Video auf YouTube veröffentlicht:

Node.js 15 – das ist alles neu

Deno als Node.js 2.0?

Allerdings ist Node.js nicht die einzige Laufzeitumgebung, die für JavaScript zur Verfügung steht. Vom ursprünglichen Autor von Node.js, Ryan Dahl, gibt es inzwischen eine zweite Plattform namens Deno. Prinzipiell ist Deno durchaus zu Node.js vergleichbar, da es ebenfalls auf V8 basiert – die Unterschiede liegen eher im Detail.

Im Jahr 2018 hatte Dahl hierzu einen Vortrag auf der JSConf.eu gehalten, in dem er einen Rückblick auf jene Dinge gegeben hat, die er im Nachhinein bei Node.js bereut. Dazu zählen beispielsweise die ursprünglich fehlende Unterstützung für Promises und die Einführung der Datei package.json beziehungsweise des node_modules-Verzeichnisses. Beide seien im Lauf der Zeit ausgeartet, zudem habe sich mit npm eine Abhängigkeit von einer zentralen Registry ergeben. Zu guter Letzt seien diverse APIs von Node.js nicht kompatibel zu den äquivalenten APIs der Webbrowser, was für Entwicklerinnen und Entwickler von Nachteil sei.

Auch zu diesem Thema gibt es ein YouTube-Video, in dem ich auf die einzelnen Punkte näher eingehe:

Was ich an Node.js bereue

TypeScript und integrierte Werkzeuge

Tatsächlich kann Deno mit einigen Aspekten punkten, wobei von den von Dahl kritisierten Punkten lediglich das Fehlen der Sandbox, in deren Rahmen JavaScript-Code isoliert ausgeführt werden kann, als wirklicher Nachteil bei Node.js gelten kann. Alle anderen Kritikpunkte sind entweder zwischenzeitlich in Node.js gelöst oder in der Praxis nur wenig relevant.

Trotzdem hat Deno ein paar interessante Dinge zu bieten: Zum einen unterstützt es nicht nur JavaScript, sondern kann auch TypeScript-Code ausführen. Dazu ist der TypeScript-Compiler direkt in Deno integriert, was allerdings im Hinblick auf Updates und Performance nicht nur Vorteile bietet – die Integration ist durchaus umstritten, und in der Deno-Community wird sogar darüber diskutiert, den TypeScript-Compiler durch eine eigene Implementierung in Rust abzulösen.

Praktisch ist aber auf jeden Fall die Integration verschiedener Werkzeuge in das Single-File-Binary von Deno, beispielsweise zum Formatieren und Analysieren von Code. Insofern ersetzt Deno nicht nur Node.js, sondern auch einige der dort häufig eingesetzten Tools wie Prettier oder ESLint.

Tatsächlich sind es eher diese Aspekte, die Deno interessant machen, da von den ursprünglichen Kritikpunkten an Node.js wie gesagt nicht mehr viel geblieben ist.

Deno oder Node.js – das ist hier die Frage

Unterm Strich stellt sich also die Frage, ob man bei Node.js bleiben oder auf Deno wechseln sollte. Trotz des Aufsehens, das die Veröffentlichung von Deno 1.0 im Juni dieses Jahres verursacht hat (aktuell ist Version 1.5 vom 30. Oktober 2020), spricht aktuell nur sehr wenig für Deno. Das stärkste Argument ist sicherlich die Sandbox – und, mit Abstrichen, das integrierte Tooling.

Was Deno aber ganz klar fehlt, ist die breite Unterstützung der Community und der Industrie: Während es für Node.js inzwischen nahezu 1,5 Millionen npm-Module gibt, sieht die Unterstützung für Deno weit weniger gut aus. Das liegt in der Natur der Sache, da Deno noch recht jung ist, es ist aber ein grundsätzliches Problem. Warum sollte man auf eine Plattform wechseln, die deutlich weniger Unterstützung erfährt als jene, die sie ablösen möchte?

Hinzu kommt, dass Deno natürlich nicht nur Vorteile bringt, sondern auch (neue) Nachteile. Während es in Node.js nämlich seit über 10 Jahren etablierte Vorgehensweisen und bewährte Ansätze gibt, ist in Deno quasi alles neu. Verbindet man das mit einigen zumindest fragwürdigen Ansätzen, beispielsweise eine zentrale Paketverwaltung zugunsten von Vendoring aufzugeben, und mit der völlig offenen Frage, wie die Zukunft von Deno aussehen wird, ist es schon fraglich, ob ein Wechsel ratsam ist.

Auch zu diesem Thema gibt es nochmals ein Video von mir:

Und nun? Deno vs Node.js

Und nun?

Wie sich Deno im Lauf der Zeit entwickeln wird, bleibt also abzuwarten. Für eine produktive Entwicklung kann man daher derzeit niemandem raten, auf Deno zu setzen – hier hat Node.js schlichtweg zu viel Vorsprung, der nicht so rasch einzuholen ist. Fraglich ist auch, was passieren würde, sollte Deno diesen Vorsprung einholen: Denn dann wäre es zunächst bestenfalls ein gleichwertiger Kandidat, aber deshalb noch lange nicht vorzuziehen.

Es könnte also sein, dass Deno der ewige Zweite bleibt – doch wie gesagt, das ist letzten Endes alles spekulativ. Daher lautet mein persönliches Fazit, zunächst weiterhin mit Node.js zu arbeiten, aber Deno aufmerksam zu verfolgen. Im Zweifelsfall ist es nämlich gar nicht so wichtig, direkt am ersten Tag gewechselt zu sein, sondern viel eher, eine spannende Entwicklung nicht zu verschlafen. Und dafür den eigenen Tellerrand ein bisschen zu erweitern, ist generell eine gute Idee.