Deno ist das Gleiche wie Node.js, aber anders

JavaScript ist seit mehr als einem Jahrzehnt auf dem Vormarsch. Was als Sprache begann, um etwas Interaktivität in statisches HTML zu streuen, hat sich zur wohl am weitesten verbreiteten Universalprogrammiersprache der Welt entwickelt. Die Vormachtstellung von JavaScript zeigt sich auch auf der Serverseite, wo Node.js seit vielen Jahren in den Stellenausschreibungen zu finden ist. In letzter Zeit gab es einige Aufmerksamkeit für eine ähnliche Technologie: Deno.

Finden wir heraus, was Deno ist und wie es im Vergleich zu Node.js funktioniert. Das Wichtigste zuerst: Der Name Deno ist ein Anagramm von Node. Dabei handelt es sich um zwei verschiedene Open-Source-Softwareprojekte. Deno klingt wie ein billiger Abklatsch des etablierteren Node.js, wenn man die Problemdomäne und die allgemeine Ähnlichkeit der beiden Technologien bedenkt. Sobald man jedoch erfährt, dass beide ursprünglich von der gleichen Person, Ryan Dahl, ins Leben gerufen wurden, ändert sich die Wahrnehmung.

Dahl veröffentlichte die erste Version von Node.js im Mai 2009. Im Januar 2012 zog er sich von dem Projekt zurück, um sich auf andere Dinge zu konzentrieren. Zur Überraschung vieler kündigte er Deno 2018 in einem Konferenzvortrag mit dem Titel 10 Things I Regret About Node.js an. In seinem Vortrag skizziert der Urvater von Node.js einige der Dinge, die er heute anders machen würde. Das ist es, was Deno ist: Eine alternative Sichtweise auf eine serverseitige JavaScript-Laufzeitumgebung.

Seit der Enthüllung von Deno ist eine Entwickler-Community darum herum entstanden. Vielen außerhalb des Dev-Bereichs sind ihre Bemühungen mit der Veröffentlichung von 1.0 im Mai 2020 aufgefallen.

Was haben Node.js und Deno gemeinsam?

Sowohl Deno als auch Node laufen auf der gleichen Technologieplattform: Die V8-JavaScript-Engine. Dabei handelt es sich um eine weit verbreitete JavaScript-Runtime, die größtenteils von Google für seinen Webbrowser Chrome entwickelt wird, aber auch in Chromium-Varianten wie Opera und Microsoft Edge vorhanden ist. In das V8-Projekt wurde von Freiwilligen und Unternehmen viel Zeit und Ressourcen investiert. Kurz gesagt, V8 ist ein Renner: Es ist unglaublich schnell und erhält neue Spracheigenschaften von ECMAScript-262 (dem Standard, der JavaScript definiert).

Node und Deno machen beide mehr oder weniger das Gleiche: Sie führen JavaScript-Code auf einem Server aus (ja, es gibt immer einen Server, auch wenn man serverlos ist). Die Bandbreiten an Apps, die entwickelt werden können, ist groß; eine Datenpumpe, die Datenströme von einem Ort und Format zu einem anderen befördert, ist ein häufiger Anwendungsfall, ebenso wie API-Backends für SPAs. Allerdings kann man auch komplexe Full-Stack-Backend-Apps wie die Blogging-Plattform Ghost oder benutzerdefinierte Apps mit einem Framework wie Next.js schreiben, das auf dem Server und auf dem Client läuft.

Die gemeinsame Architektur von JavaScript/V8 bedeutet, dass beide ähnliche Leistungsmerkmale aufweisen. Es kann einige Unterschiede geben, wo sich die eine besser eignet als die andere - aber als Basis sind beide performant genug für die meisten Anwendungen und können horizontal skalieren. Wenn man den absolut besten Datendurchsatz sucht, sollte man sich wahrscheinlich etwas wie .NET Core oder ähnliches auf sehr niedrigem Level ansehen. Es gibt Bereiche, in denen die V8-Performance nicht ausreicht, aber wenn man in diesen Bereichen tätig ist, dann weiß man das wahrscheinlich.

Das JavaScript-Ökosystem ist riesig. Die Grundkenntnisse, die man benötigt, um entweder mit Node oder Deno zu arbeiten, ähneln sich sehr. Die Syntax ist identisch, auch wenn Deno eigentlich die Verwendung von TypeScript im Benutzerbereich vorschreibt. TypeScript ist eine Erweiterung von JavaScript und fügt optionale Typisierung und andere Funktionen hinzu, die in der Entwicklungsphase nützlich sein können. Außerdem ist es erwähnenswert, dass man Node.js-Apps in TypeScript entwickeln kann. Letztendlich führt die V8-Engine lose JavaScripts aus, die aus der TypeScript-Quelle kompiliert wurden.

Wie unterscheidet sich Deno von Node.js?

Anders als bei Node ist die Verwendung von TypeScript bei Deno eine Voraussetzung. Einige Komponenten von Deno selbst sind in TypeScript geschrieben, was das Team aber ändern möchte, da es für diesen Zweck nicht gut geeignet ist. TS ist nicht streng typisiert und bietet keine absolut sichere Laufzeit, die 100%ige Typsicherheit erzwingt, sondern verlässt sich ziemlich stark auf Typinferenz, um Typüberprüfung und damit verbundene Entwicklungszeit-Tools in IDEs für JavaScript zu ermöglichen.

Ein weiterer wesentlicher Unterschied ist das Sicherheitsmodell. Node.js hatte nie ein universelles Sicherheitsmodell eingebaut. Das bedeutet, dass es einfach ist, Code zu schreiben, der in den falschen Händen - vorsätzlich oder versehentlich - großen Schaden anrichten wird. Der Ansatz in Deno ist anders, im Einklang mit Browsern und dem Ibexa DXP-Berechtigungsmodell:

    Deno ist standardmäßig sicher. Daher hat ein Deno-Modul zum Beispiel keinen Datei-, Netzwerk- oder Umgebungszugriff, es sei denn, dieser wird ausdrücklich aktiviert. Der Zugriff auf sicherheitssensible Bereiche oder Funktionen erfordert die Verwendung von Berechtigungen, die einem deno-Prozess auf der Befehlszeile erteilt werden.
    - Deno-Handbuch: Berechtigungen

Die Standardbibliothek ist ein weiterer Bereich, in dem sich Deno von Node.js unterscheidet. Node hat eine recht kleine Standardbibliothek, was zu einer großen Anzahl externer Pakete geführt hat, was (nach Meinung einiger) standardmäßig in der Distribution angeboten werden sollte. Bei Deno ist das wiederum anders. Hier wird eine umfangreichere, von Go inspirierte Standardbibliothek angeboten:

    Deno_std ist eine lose Portierung der Standardbibliothek von Go. Im Zweifelsfall sollte man einfach den Quellcode, die Dokumentation und die Tests von Go portieren. Es gibt viele Fälle, in denen die Natur von JavaScript, TypeScript oder Deno selbst es begründet, von Go abzuweichen, aber wenn möglich, wollen wir die Energie nutzen, die in die Entwicklung von Go geflossen ist. Generell begrüßen wir direkte Portierungen von Go-Code.
    - Deno-Standardbibliothek

Bezogen auf externe Pakete ist dies ein weiterer großer Unterschied zwischen beiden. Node.js verlässt sich auf ein zentrales Repository, NPM, zum Speichern und Bereitstellen von Bibliotheken und anderem Code. Dieses Ökosystem ist ein großer Vorteil für Entwickler, da es doppelten Code reduziert. Mit über einer Million Paketen auf NPM ist es in Entwicklerkreisen eine gängige Redewendung zu sagen, dass es dafür ein NPM-Paket gibt. Und oft stimmt das auch, und der Nutzen ist offensichtlich.

Gemeinsamer Code ist guter Code, und Deno hat nicht die Absicht, alles in der stdlib zu implementieren. Was grundlegend anders ist, ist das Distributionsmodell. Anstelle eines zentralen Repositorys kann jede URL ein Paket enthalten. Das Projekt hostet eine Reihe von Paketen unter deno.land/x, aber es wird nirgends vorgeschrieben. Das heißt, es gibt keinen zentralen Eigentümer wie bei NPM (jetzt im Besitz von GitHub im Eigentum von Microsoft). Dieser Ansatz bedeutet, dass man einen HTTP-Server (öffentlich oder privat) hosten und Bibliotheken direkt von dort referenzieren kann.

Ein weiterer Bereich, der mit Erweiterungen zusammenhängt, ist die Vereinfachung des Code-Packaging. Als Node.js entstand, gab es kein Standard-Modulformat in der ECMAScript-Spezifikation. Aus diesem Grund hat Node.js ein eigenes Modulformat entwickelt, das als CommonJS bekannt ist. Aufgrund der Popularität von Node.js wurde CommonJS zum De-facto-Standard für Module im JavaScript-Ökosystem. Seitdem hat das ECMAScript regelmäßige Updates erfahren und enthält nun einen Standard für JavaScript-Module, die auch in Browsern funktionieren.

Mittlerweile unterstützt auch Node.js JavaScript-Module, aber ein Großteil des Ökosystems verwendet weiterhin CommonJS. Beide Formate leisten mehr oder weniger das Gleiche, aber mit einer unterschiedlichen Syntax. Das kann die Arbeit mit Node unübersichtlich machen, da man für eine Kernfunktionalität zwei verschiedene Wege nutzen kann. Deno standardisiert auf ECMAScript-Module.

Zu guter Letzt ist da noch das Maskottchen, Deno. Das Artwork der Software-Kollektion (das Hauptbild des Blogposts wurde von Dimitrij Agal zur Verfügung gestellt) ist ein Blick wert. Wer könnte zu dem kleinen Kerl schon nein sagen?

Fazit

Wie wir festgestellt haben, gibt es eine Reihe von Gemeinsamkeiten zwischen Deno und Node.js, aber auch einige wichtige Unterschiede in der Philosophie und Implementierung. Der vielleicht umstrittenste Unterschied ist die neue Art der Abhängigkeitsverwaltung in Deno. Das Auflösen einer komplexen Menge von Abhängigkeiten könnte in diesem vollständig verteilten Modell eine größere Herausforderung darstellen (und potenziell unzuverlässiger sein). Erwähnenswert ist, dass man Pakete aus dem NPM-Katalog mit jspm verwenden kann, das NPM-Pakete als ES-Module hostet.

Node.js hat eine enorme Marktmacht, es ist eine gefragte Technologie und hierfür werden Entwickler sowohl von Startups als auch von großen Unternehmen gesucht. Das lebendige Ökosystem beweist, dass an Node.js prinzipiell nichts auszusetzen ist und es einen wesentlichen Beitrag zur JavaScript-Erfolgsgeschichte des letzten Jahrzehnts leistet. Node.js wird nirgendwo verschwinden, aber Deno könnte sich eine eigene Nische schaffen. Eine Sache, die einem dabei in den Sinn kommt, ist FaaS (Function as a Service), dessen Entwicklung mit der umfangreicheren Standardbibliothek von Deno einfacher sein könnte.

Aber Moment mal... Dies ist der Ibexa-Blog. Was hat Deno mit uns zu tun? Nun, im Moment noch nichts. Wir verwenden viel JavaScript, zum Beispiel React.js-Komponenten für die Administrationsoberfläche, und unsere Asset-Build-Pipeline basiert auf Node.js, mit freundlicher Genehmigung von Symfony Encore. Aber die Ibexa DXP-Produktlinie nutzt derzeit keine aktiven JavaScript-Serverdienste in Node.js, Deno oder Netscape Livewire.

Implementierungen, bei denen Ibexa DXP zum Einsatz kommt, unterscheiden sich von anderen Fällen. Unsere Technologie ist oft ein Teil eines Puzzles, das viele Technologiekomponenten umfasst, von A/B-Testing-Services bis hin zu Integrationen in Unternehmens-Backend-Systeme wie ERPs. Hier kommt häufig serverseitiges JavaScript zum Einsatz, meist als Node.js-Apps, die auch auf der Ibexa Cloud laufen, aber zunehmend auch als Cloud-Funktionen wie Azure Functions oder AWS Lambda.

Als Sammelsurium von Daten und Diensten muss eine Digital Experience Platform in der Lage sein, sich mit allem zu verbinden. Deshalb ist von Vorteil für unsere Kunden, Partner und uns, dass wir uns über neue Technologien auf dem Laufenden halten. Integrationen sind der Schlüssel für DXPs und Deno könnte in naher Zukunft ein Kandidat in diesem Bereich sein. Selbst wenn dem nicht so ist, lernt man immer durch das Studium alternativer Lösungsmöglichkeiten. Sogar die, für die man sich nicht entscheidet.