Vergleich zwischen Node.js und Deno

Vorwort

Wenn Sie den Bereich Webentwicklung verfolgt haben, haben Sie in letzter Zeit wahrscheinlich viel über Deno gehört – eine neue JavaScript-Runtime, die auch als Nachfolger von Node.js gilt. Aber was bedeutet das, brauchen wir das „nächste Node.js“?

Was ist Deno?

Um zu verstehen, was vor sich geht, müssen wir uns zunächst ansehen, was Deno eigentlich ist. Wie ich bereits sagte, handelt es sich hierbei um eine neue JavaScript-Laufzeitumgebung, also die Umgebung, in der Ihr JS-Code ausgeführt wird. Es wurde ursprünglich von Ryan Dahl erstellt, der zuvor für uns Deno mit Node.js verglichen hat.

Ryan kündigte Deno in einem Vortrag auf der JSConf EU 2018 mit dem Titel „Die 10 Dinge, die wir an Node.js bereuen“ an. Allein anhand dieser Information können Sie erkennen, wie die Dinge laufen. Deno wurde von Grund auf als die derzeit bessere Implementierung von Node.js entwickelt.

Aber was ist falsch an Node.js? Wie schlägt sich Deno im Vergleich zu seinem etablierteren Cousin?

Vergleich mit Node.js

Obwohl Deno und Node.js ähnliche Tools sind, die ähnliche Vorgänge ausführen, gehen die Unterschiede zwischen ihnen weit über eine bloße Namensumkehr hinaus.

Architektur

Werfen wir zunächst einen Blick auf die internen Vorgänge von Deno. Wie Node.js basiert es auf der V8-JavaScript-Engine von Chromium und verwendet eine ereignisgesteuerte, nicht blockierende Architektur. Die Hauptschreibsprache der beiden ist jedoch unterschiedlich. Node.js ist hauptsächlich in C++ geschrieben, mit libuv als asynchroner E/A-Bibliothek, während Deno in Rust geschrieben ist und seine asynchrone Bibliothek Tokio ebenfalls in Rust geschrieben ist.

Wir müssen abwarten und sehen, wie sich diese Unterschiede auf die Leistung in der Praxis auswirken. Derzeit ist der Unterschied zwischen den beiden laut Denos Benchmark nicht erkennbar oder zumindest sehr gering.

ES-Module

Wie Sie wahrscheinlich wissen, ist das aktuelle Modulsystem von Node.js das sogenannte CommonJS (das mit require()), obwohl ESM (ECMAScript Modules (Module mit Import und Export)) schon seit geraumer Zeit ein offizieller Standard für JS ist und auf die 2015 eingeführte ES6 zurückgeht. Natürlich unterstützt Node.js ESM, aber diese Funktion ist derzeit (v14.xx) als experimentell gekennzeichnet, was die JS-Community dazu zwingt, weiterhin das CommonJS-Modulsystem oder andere Bundler zu verwenden.

Dies ist, was Deno mitbringt, das nur ESM-Module unterstützt – ein echtes Modulsystem!

Abhängigkeitsverwaltung

Aber über ESM hinaus bringt Deno noch viele weitere Änderungen zum Abhängigkeitsmanagement für Node.js.

Deno verfolgt einen völlig anderen Ansatz für Abhängigkeiten, basierend auf Erfahrungen mit dem npm-Register mit Millionen von Paketen und dem schwarzen Loch des node_modules-Verzeichnisses. Deno erfordert kein Register oder Paketmanager wie npm, sondern importiert und verwendet Abhängigkeiten direkt von URLs:

importiere { serve } von "https://deno.land/[email protected]/http/server.ts";
const s = dienen({ Port: 8000 });
console.log("http://localhost:8000/");
für warten (const req von s) {
    req.respond({ body: "Hallo Welt\n" });
}

Die heruntergeladenen Module werden dann unsichtbar irgendwo auf Ihrem Computer gespeichert. Ja, das bedeutet keine node_modules mehr!

Aber warte! Es gibt mehr ... oder sollte ich weniger sagen, weil Deno auch die Einheitsdatei package.json entfernt, die jetzt erstellt wird. Es gibt keine Alternative zur Datei deps.ts, die eher wie eine Umleitungssortierdatei für alle externen Module fungiert:

exportiere { assert } von "https://deno.land/[email protected]/testing/asserts.ts";
export { grün, fett } von "https://deno.land/[email protected]/fmt/colors.ts";

Da Deno jetzt Abhängigkeiten von URLs laden kann, handelt es sich beim NPM-Register nicht um dieselbe Anforderung wie bei Node.js. Wenn Sie jedoch an dieser Option interessiert sind, bietet Deno sein eigenes Paket-Hosting an.

TypeScript und andere Features

Ja, Sie haben richtig gelesen – JavaScript ist die primäre Sprache, die mit Deno verwendet wird, TypeScript wird jedoch ebenfalls unterstützt. Die Unterstützung ist integriert und erfordert keine benutzerdefinierten Register oder komplizierte Einrichtung.

Zusätzlich zur TS-Unterstützung verfügt Deno jedoch über viele andere nützliche integrierte Tools. Die meisten davon erscheinen in Form von Befehlen wie fmt, bundle oder doc, die Funktionen wie Codeformatierung, Verpackung bzw. Dokumentgenerierung bereitstellen.

API

Was die API betrifft, ist Deno definitiv etwas Eigenes. Alles ist in TypeScript geschrieben und die asynchrone API basiert ausschließlich auf Promises. Die Kernfunktionalität ist auf das absolute Minimum beschränkt, alles andere ist in der Standardbibliothek zu finden.

Oberflächlich betrachtet sieht das alles gut und sehr vielversprechend aus, aber die Euphorie verfliegt sofort, wenn man erkennt, dass die Änderung aller APIs bedeutet, dass die Konvertierung einer Node.js-Codebasis in Deno viel schwieriger ist. Leider hat alles Neue und Bessere seinen Preis, nicht wahr?

Sicherheit

Schließlich ist Sicherheit einer der wichtigsten Aspekte von Deno. Im Vergleich zu Node.js führt es eine Sandbox für den ausgeführten Code aus und ermöglicht so nur den Zugriff auf ausgewählte Teile des Systems. Dies bedeutet, dass der Zugriff auf Dinge wie Festplatte, Netzwerk und Unterprozesse durch Übergeben der entsprechenden Flags einfach eingeschränkt werden kann.

Also, was bedeutet das?

Ich habe Ihnen daher nur kurz einige der Funktionen von Deno vorgestellt, damit Sie sich einen Überblick verschaffen können. Sie können tiefer graben, wenn Sie möchten (ich werde am Ende dieses Beitrags einige Links zu tollen Artikeln einfügen).

Kommen wir zur Hauptfrage dieses Blogbeitrags zurück – was bedeutet das? Nun, hauptsächlich, weil Deno v1 bereits am 13. Mai 2020 veröffentlicht wurde (genau ein Jahr nach seiner Erstveröffentlichung). Jetzt fragen sich alle, ob dies der „nächste große Trend“ sein wird oder ob es Node.js vollständig ersetzen wird.

Persönlich denke ich, dass es zu früh ist, darüber zu diskutieren. Angesichts der Größe des Projekts und der Erwartungen der Community hat das Projekt, obwohl es sich derzeit in der Version v1 befindet, noch einen langen Weg vor sich, bis es ein brauchbarer Ersatz für Node.js wird. Bedenken Sie, dass diese Technologien (trotz aller Unterschiede) immer noch versuchen, dasselbe zu tun und gleichzeitig miteinander konkurrieren müssen. Und die Tatsache, dass die Node.js-Entwicklung nicht aus der Mode kommt (z. B. Promise-basierte FS-API-Variante oder experimentelle ESM-Unterstützung), bedeutet, dass wir wahrscheinlich noch lange in einer Welt mit zwei JavaScript-Laufzeitumgebungen leben werden (als ob das für JS-Entwickler etwas Neues wäre). Und bedenken Sie, ich habe noch nicht einmal das riesige NPM-Register und -Ökosystem erwähnt, das zwar keineswegs perfekt ist, aber dennoch einen großen Mehrwert für Node.js darstellt – etwas, das Deno noch nicht hat.

Fazit

Alles in allem wird Node.js nicht verschwinden, und wenn Sie ein ernsthaftes Produktionsprojekt starten, ist es wahrscheinlich am besten, zumindest vorerst bei Node.js zu bleiben. Allerdings gibt es nichts (ich schon gar nicht) und niemanden, der Sie davon abhalten kann, Deno auch für ernsthafte Projekte zu verwenden. Es scheint sicherlich die Zukunft zu sein, aber so weit sind wir einfach noch nicht.

Das Obige ist der detaillierte Inhalt zum Vergleich von node.js und Deno. Weitere Informationen zu node.js und Deno finden Sie in den anderen verwandten Artikeln auf 123WORDPRESS.COM!