© iurii/Shutterstock.com
Neue Runtime für serverseitiges JavaScript

Deno - der neue Dino in der Webwelt


In seinem Vortrag „10 Things I Regret About Node.js“ hat Ryan Dahl, der Schöpfer von Node.js, von falschen Designentscheidungen gesprochen, die seinerzeit bei der Entwicklung von Node.js getroffen worden seien. Da man die Zeit nicht zurückdrehen kann, hat Dahl sein neues Projekt Deno ins Leben gerufen. Das Ziel: Schwächen von Node sollen revidiert und eine moderne, sichere Plattform für serverseitiges JavaScript bereitgestellt werden. Ist der Versuch geglückt?

Manchmal haben Produkte Erfolg, obwohl sie nicht perfekt sind und zahlreiche Fehler aufweisen. Ein Paradebeispiel ist JavaScript, eine Skriptsprache, die weit entfernt ist von technischer Exzellenz und elegantem Sprachdesign. Dennoch ist JavaScript mit eine der weltweit meist verwendeten Sprachen. Ähnliches gilt auch für Node.js, die serverseitige JavaScript-Plattform, die primär in Web- und Kommandozeilenapplikationen zum Einsatz kommt. Node.js-Entwickler Ryan Dahl hat nun ein neues Projekt ins Leben gerufen: Deno. Es soll von den Erfahrungen mit Node.js profitieren und eine neue, sichere Plattform sein. Auch in Deno werden Applikationen weiterhin in JavaScript beziehungsweise TypeScript implementiert – allerdings ändern sich einige Dinge grundlegend im Vergleich zur Entwicklung mit Node.js. Eine Gegenüberstellung der beiden Plattformen wäre allerdings nicht gerecht, da sich Deno aktuell noch in einer sehr frühen Phase befindet und sich sowohl die Schnittstellen als auch einige Architektur- und Designentscheidungen ändern können. Aus diesem Grund werfen wir einen Blick auf die Aspekte von Deno, die sich von Node unterscheiden, und zeigen, wie sich diese Unterschiede auf die tägliche Arbeit auswirken.

Was macht Deno besser als Node?

Die Idee hinter Deno ist dieselbe wie bei Node: Es soll eine Plattform zur Ausführung von JavaScript abseits vom Browser bieten. Wie bei Node ist auch Deno keine vollständige Eigenimplementierung, sondern bedient sich bei verschiedenen, bereits bestehenden Projekten. So kommt für JavaScript die Google Engine V8 zum Einsatz. Diese etabliert sich zunehmend zum Standard, wenn es um die Ausführung von JavaScript in verschiedenen Umgebungen geht. Browserseitig ist V8 sowohl in Chrome als auch mittlerweile in Edge integriert. Serverseitig setzen sowohl Node als auch Deno auf diese Engine. Im Gegensatz zu Node, dessen Kern in C++ geschrieben ist, nutzt Deno Rust als Programmiersprache. Rust wurde von Mozilla Research entwickelt und soll eine bessere Sicherheit als C++ beim Speicherzugriff bieten, bei einer ähnlich guten Performance. So ist es auch nicht verwunderlich, dass eines der zentralen Elemente, der Event Loop von Deno, in Rust implementiert wurde. Mit Rusts asynchroner Laufzeit Tokio hat Ryan Dahl auch hier auf ein bereits etabliertes Projekt zurückgegriffen.

Sicherheit und Ressourcenzugriff

Einer der größten Kritikpunkte an Node sind Sicherheitslücken bei der Ausführung. Im Browser wird JavaScript in einer Sandbox ausgeführt, sodass in der Regel kein Schaden am System entstehen kann. Im Fall von Node ist die Situation anders: Eine Node-Applikation kann mit den Berechtigungen des Benutzers, der die Applikation gestartet hat, mit dem System interagieren. In erster Linie bedeutet das, dass die Applikation auf dasselbe Dateisystem wie der Benutzer zugreifen darf. Dieser Praxis schiebt Deno in seiner Standardkonfiguration einen Riegel vor und verbietet grundsätzlich den Zugriff auf das System. Erst nachdem der Benutzer den Zugriff erlaubt hat, kann die Applikation die Ressourcen verwenden. Deno geht damit wieder einen großen Schritt in die Richtung, Applikationscode in einer gesicherten Sandbox auszuführen. Es besteht ebenfalls die Möglichkeit, Zugriffe auf bestimmte Ressourcen on Demand oder generell über Kommandozeilenoptionen zuzulassen. Solche potenziell sicherheitskritischen Ausbrüche aus der Sandbox geschehen dann allerdings bewusst und nicht mehr aus dem Quellcode heraus.

TypeScript-Unterstützung

Deno greift einen der wichtigsten Trends der letzten Zeit in der JavaScript-Entwicklung auf und unterstützt TypeScript nativ. Das bedeutet, dass kein zusätzlicher Compile-Schritt benötigt wird, um den TypeScript-Code der Applikation in JavaScript umzuwandeln und auszuführen. Es ist auch kein externes Paket wie ts-node erforderlich, das sich um den Compile-Prozess und die unmittelbare Ausführung kümmert.

Modulsystem

Ein wichtiges Feature von Node ist sein Modulsystem. Es ermöglicht das Laden von Dateien und das Einfügen von Quellcode in die Applikation. Node befindet sich aktuell in einer Transition vom CommonJS-Modulsystem zum JavaScript-Standardmodulsystem. Dieser Wechsel verläuft eher schleppend, da sich die Node-Entwickler durch die große Verbreitung der Plattform keine Breaking Changes leisten können. Deno ist dagegen zu einem viel späteren Zeitpunkt entstanden, daher kann die Laufzeit sofort mit der aktuellen Modulsyntax starten. Für Entwickler bedeutet dies, dass keine require- oder module.exports-Statements mehr geschrieben werden müssen, sondern direkt mit den import- und export-Schlüsselworten gearbeitet werden kann. Im Gegensatz zum CommonJS-Modulsystem, wo die Importe dynamisch aufgelöst werden, erfolgt dies in Deno in der Regel statisch. Ein weiterer Unterschied zu Node ist, dass beim Import die Dateiendung ebenfalls angegeben werden muss. Entwickler Ryan Dahl begründet dies mit dem Hinweis, dass Deno deutlich näher am Web angesiedelt sein solle, als es bei Node der Fall sei. Wird eine Ressource geladen, muss ihre Bezeichnung vollständig angegeben werden – dazu gehört auch die Endung des Dateinamens.

Ein Erfolgsfaktor von Node ist dessen Paketmanager npm. Zwar ist npm kein fester Bestandteil von Node, jedoch arbeitet das Modulsystem der Plattform direkt mit ihm zusammen. Die Pakete werden aus einem zentralen Repository bezogen, wobei die Hürde für neue Pakete sehr gering ist: Jeder registrierte Nutzer kann Pakete publizieren. Eine Qualitätssicherung oder Sicherheitsüberprüfung fehlt. Es besteht lediglich die Möglichkeit, schädliche Pakete zu melden, die dann gegebenenfalls aus dem Repository entfernt werden. Bei der Installation eines Pakets wird der Quellcode auf das lokale System heruntergeladen und in einem Verzeichnis mit dem Namen node_modules gespeichert. Deno kommt ohne einen zusätzlichen Paketmanager aus, da das Modulsystem in der Lage ist, Pakete über URLs oder Dateisystempfade aufzulösen und die erforderlichen Ressourcen herunterzuladen. Damit wird Deno sein eigener Paketmanager, der sich sehr nahe am JavaScript-Standard bewegt. Und auch das node_modules-Verzeichnis, das nach Angaben von Ryan Dahl nur eingefügt wurde, weil die Benutzer von Node es brauchten, fällt damit weg. Ebenso benötigt Deno keine package.json- oder package-lock.json-Datei, um...

Neugierig geworden? Wir haben diese Angebote für dich:

Angebote für Teams

Für Firmen haben wir individuelle Teamlizenzen. Wir erstellen Ihnen gerne ein passendes Angebot.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang