navios

Ihr Partner für’s Web

Deno, die Alternative zu Node.js?

Ryan Dahl, der Vater der JavaScript-Laufzeitumgebung Node.js und Projektleiter bis 2012 sprach am 2. Juni 2018 auf der JSConf EU über die größten Designfehler, die er bei der Entwicklung von Node.js gemacht und die er heute sehr bereut. Anschließend stellte er den Prototyp vor, die alles besser machen soll.

Designfehler von Node.js

In seinem Vortrag (Transkript oder Video) erläuterte er ausführlich, was seiner Meinung nach beim Design falsch gelaufen ist und was er heute anders machen würde.

Entfernung von Promises

So hatte er anfangs Promises eingeführt, aber nach kurzer Zeit wieder entfernt. Promises wären die nötige Abstraktion für async/await gewesen und hätten vieles bei den Async-APIs vereinfacht.

Sicherheit

V8 hat ansich eine sehr gute Sandbox. Mit etwas mehr Überlegung hätte Node.js dies nutzen können und dadurch bessere Sicherheit als andere Programmiersprachen bieten könne. Als Beispiel nannte er einen Linter, der eigentlich keinen Zugriff auf den ganzen Rechner und das Netzwerk haben müsse.

Das Build-System (GYP)

V8 nutzte durch Chrome anfangs GYP als Build-System und somit entschied sich Dahl es auch für Node.js zu verwenden. Allerdings wechselte Chrome dann zu GN und hinterlies Node.js als einzigen GYP Nutzer. Bei GYP zu bleiben hält er für den größten Fehler, da es nötig komplex sei und eine „schreckliche Erfahrung“ für den Nutzer. Vorschläge vieler zu einem Foreign Function Interface (FFI) zu wechseln, habe er aber geflissentlich ignoriert.

Verwendung von package.json

Des Weiteren bereut er die Verzahnung von Node.js mit NPMs package.json und letztlich die Integration von NPM in die Distribution, was es damit zum De-facto-Standard machte. Zentralisierte Paketquellen seine eine „unglückliche“ Entscheidung gewesen.

Die Verwendung von package.json verhalf dem Konzept „Module als Verzeichnis von Dateien“ zu seinem Aufstieg, was letztendlich so im Web nicht existiert. Dies führte dann dazu, das diese Datei nun jede Menge unnötigem „Boilerplate Noise“ mit sich führt.

node_modules

Das Verzeichnis „node_modules“ verkompliziere den Modul-Resolution-Algorithmus massiv und weiche stark von der Browser-Semantik ab.

require("module") ohne „.js“ Endung

Eine unnötige Vereinfachung, die dem Modul-Lader jede Menge Arbeit aufbürdet um zu erraten, was der Entwickler eigentlich beabsichtigte. Auch deckt sich das nicht mit dem Vorgehen im Browser, wo man im Script-Tag auch nicht einfach die Endung weglassen kann.

index.js

Viel unnötige Arbeit für den Modul-Lader und besonders überflüssig, nachdem require letztendlich package.json unterstützt hat.

Deno, die Alternative zu Node.js?

Nach dieser ganzen Reue stellte er schließlich sein neuestes Projekt vor: Deno, eine „sichere TypeScript Laufzeitumgebung auf V8“. Allerdings handelt es sich noch um einen Prototyp in einem sehr frühem Stadium. Seine Designziele sind:

  • Sicherheit steht im Vordergrund. JavaScripts Sandbox wird im vollen Umfang ausgenutzt. Jedes Script erhält nur die Rechte, die es auch für seine Arbeit braucht. Systemaufrufe erfolgen über ein Bus-System.

  • Das Modulsystem wird entscheidend vereinfacht, wobei keine Kompatibilität mit Node-Modulen angestrebt ist. Der Import erfolgt ausschließlich über relative oder absolute URLs und externe Resourcen werden beim ersten Zugriff gecacht.

  • Der TypeScript-Compiler soll direkt in die ausführbare Datei integriert werden und sich um Modul-Resolution kümmern. V8 Snapshots sollen den Start beschleunigen.

  • Ziel ist es, Deno als einzelne ausführbare Datei auszuliefern, die mit möglichst wenigen externen Abhängigkeiten auskommt.

  • Vorteile von 2018 nutzen. Zum Beispiel die Möglichkeit Bundles auszuliefern oder bereits vorhandene native Infrastruktur einzusetzen.

  • Sofortiger Programmstop bei unbehandelten Promises, top-level await, Browser Kompatibilität wo möglich.

Da selbstverständlich alles noch weit entfernt von einem wirklich produktiv benutzbaren System ist, kann man natürlich nur gespannt sein, wie es sich weiter entwickelt. Ryan Dahl hat ja bereits mit Node.js bewiesen, dass er etwas entwickeln kann, was weltweit großen Anklang findet.