Deno ist – wie Node.js – eine Laufzeitumgebung für JavaScript. Genau wie Node.js bietet Deno einen Weg, serverseitiges JavaScript – oder TypeScript – zu schreiben. Es ähnelt Node.js in seinem Funktionsumfang in vielerlei Hinsicht, nutzt genau wie Node die V8-JavaScript-Engine unter der Haube und wurde sogar von derselben Person ins Leben gerufen, die auch hinter Node steckt. Anders als Node wurde Deno jedoch nicht in C++ und JS, sondern in Rust und TypeScript implementiert. Das bedeutet für euch: Ihr könnt direkt in Deno statisch typisierten Code schreiben, ohne jemals eine TS-config.json-Datei auch nur anfassen zu müssen – ihr könnt auf alle Features innerhalb der Runtime vom Deno-Namespace aus zugreifen.

Deno kommt standardmäßig mit einigen Security-Vorkehrungen.

Angenommen, ihr wollt über console.log( Deno.cwd() ) das aktuelle Working-Directory ausloggen. Solche Skripte könnt ihr via deno run über die Kommandozeile ausführen – allerdings nicht, ohne vorher die Erlaubnis zur Ausführung solcher Aktionen innerhalb der Runtime zu erteilen. In diesem konkreten Fall erreichen wir das über die –-allow-read-flag:

deno run --allow-read main.ts

Dahinter steckt eine Sache namens Sandbox, die Programme davon abhält, Dinge zu tun, die ihr nicht erlauben wollt. Das ist nützlich, wenn ihr ein JS-Programm außerhalb des Browsers ausführen wollt, aber nicht wollt, dass es auf innerhalb eures Systems einfach so auf alles Mögliche zugreift.

In Node.js gibt es nichts, was eine Node.js-App davon abhält, zum Beispiel eure SSH-Keys abzugreifen und sie an einen Server weiterzuleiten. Dagegen kann sich schützen, wer darauf achtet, nur Pakete von vertrauenswürdigen Urhebern zu installieren. Ein bisschen Sicherheitsrisiko ist da aber immer noch, auch diese Pakete können gehackt werden.

Mittels der Sandbox repliziert Deno das Permission-Modell des Browsers – auch im Browser ausgeführtes JS benötigt eure explizite Erlaubnis für die Ausführung jeglicher Aktion auf eurem System. Weitere Flags, über die ihr Deno Erlaubnisse erteilen könnt, sind zum Beispiel --allow-write oder --allow-net.

Eine Sache, die TypeScript-Nutzer begeistern dürfte, ist, dass Deno – wie TypeScript seit V 3.8 – top-level-await implementiert.

In Deno könnt ihr über die fetch-API einen Network-Request ausführen – als würdet ihr euch im Browser befinden:

const res = await fetch( ‘https://t3n.de’ );

Und weil Deno top-level-await unterstützt, braucht ihr dafür nicht einmal eine async-Funktion.

Deno will euren Code so browserkompatibel machen wie möglich. Die Runtime beinhaltet ein window-Objekt mit Lifecycle-Events,

window.onload = event => console.log( ‘t3n says hi 🦕’ )

auf die ihr Event-Listener ansetzen könnt. Das ermöglicht es, Code zu schreiben, der sowohl browser- als auch serverseitig ausgeführt werden kann.

Deno kann außerdem auch WebAssembly-Binaries ausführen.

const wasmBinary = new Uint8Array([ 0, 23, 77]);
const wasmModule = new WebAssembly.Module(wasmBinary);

Eine Sache, die in Deno allerdings nicht funktioniert, sind npm-Pakete. Deno ist Runtime- und Package-Manager in einem und damit nicht mit dem separaten Paketmanager kompatibel. In Deno könnt ihr Pakete stattdessen mittels ES-Module-Syntax via deren URL importieren, zum Beispiel so:

import { serve } from ‘ https://deno.land/std/http/server.ts’ ;

Remote-Modules werden via URL referenziert. Wenn ihr ein Skript das erste Mal ausführt, wird dessen Code lokal gespeichert und gecached. Es gibt keine package.json. Code kann über jede URL referenziert werden, ähnlich, wie das auch im Browser funktioniert.

Deno verfügt über eine Auswahl an Standard-Modulen für häufige Use-Cases. Zum Beispiel könnt ihr wie oben im Beispiel über das http-Modul serve importieren und es nutzen, um einen Server zu erstellen, der wie eine async-Iterable gehandhabt wird:

// main.ts
import { serve } from ‘https://deno.land/std/http/server.ts’;
const s = serve({ port: 8000 });

for await (const req of s)

req.respond( {body: ‘Deno 🦕 is cool’} );

Ausführen könnt ihr das Ganze dann über deno run --allow-net main.ts 

Deno wurde am Mittwoch in V 1.0 released. Kurzfristig wird die Runtime Node.js sicher nicht ersetzen. Node schafft ein geschlossenes Ökosystem, das mittlerweile relativ stabil ist. Ob die JavaScript-Entwickler-Community sich auf längere Sicht zugunsten des Dinos von Node.js abwenden wird, bleibt abzuwarten. Wer sich die Runtime genauer anschauen will, findet auf der Website zum Projekt neben einem Blogpost zu V 1.0 auch ein ausführliches Manual, die Standard-Library und alle bislang unterstützten Third-Party-Module.

Zum Weiterlesen: Web-Development jetzt und später: 3 ½ Vorhersagen, die du lesen solltest