👐🏻 👨🏾‍🏭 🧜🏽 5 Ansprüche an Deno 🤙🏾 👩🏽‍🤝‍👩🏼 🧕🏻

Vorwort

Ich bin nicht Teil des Deno-Teams. Ich bin nicht sein Fan. Ich folge ihm nicht. Ich glaube nicht einmal wirklich an ihn. Aber angesichts der negativen Reaktion der Community kann ich einfach nicht anders, als einzugreifen. In diesem Artikel möchte ich die häufigsten Ansprüche gegen Deno betrachten und eine alternative Sichtweise anbieten.

Deno - der Mörder von NodeJs

Das ist nicht so. Auf diese Weise wird es nur von „Deno-Zeugen“, verrückten Fans oder hype-hungrigen Übersetzern beworben. Soweit ich weiß, positioniert selbst Ryan Dahl selbst (Deno-Autor) seine Entwicklung nicht als Ersatz oder Alternative zu NodeJs. Seine Vision ist vielmehr "was in Zukunft vielleicht die gleichen NodeJs sein werden". Das Konzept, wenn Sie wollen (wir schelten die Konzepte von Autos oder Smartphones nicht wegen ihrer Unpraktikabilität in der modernen Realität). Aus Ryans Sicht hat NodeJs einige Probleme. Und er zeigte der Community eine bestimmte Vorstellung davon, wie diese Probleme gelöst werden könnten. Und daran können Sie teilnehmen. Kommen Sie jetzt zu GitHub und beschreiben Sie die Architekturprobleme, die Sie sehen. Besprechen Sie sie. Überlegen Sie sich Lösungen.

Ich glaube nicht, dass Deno jemals NodeJs ersetzen wird. Aber es kann für ihn werden, was TypeScript für JavaScript geworden ist.

Import per URL

Viele Leute betrachten es ein bisschen aus dem falschen Blickwinkel. Die Idee ist, die globale Abhängigkeitsliste für das gesamte Projekt zu löschen. Damit haben Sie anstelle eines großen package.json eine eigene unabhängige Liste von Abhängigkeiten in jedem Ihrer Module / Dateien. Darin sehe ich mehrere Vorteile.

Wenn Sie eine Funktion schreiben müssen, müssen Sie nicht prüfen, welche Abhängigkeiten bereits im Projekt verwendet werden. Sie sind nicht auf sie beschränkt. Sie verwenden, was Sie brauchen.
Sie können Funktionen hinzufügen, ohne auf das Erbe zu achten. Die neuen Module haben ihre eigenen Abhängigkeiten, und die alten haben ihre eigenen.
Während der Migration eines großen Projekts auf eine neue Version einer Abhängigkeit können Sie die Codebasis ändern und diese Änderungen in Teilen implementieren.

Für diesen Ansatz benötigen Sie jedoch die Fähigkeit, die Abhängigkeiten für jedes Modul zu beschreiben. Name, Version und Bezugsquellen für diese Abhängigkeit. Importieren Sie daher mit einer URL. Und das ist nicht einmal Denos Vorstellung. Dies ist Teil des Standards . Es ist nur so, dass jeder daran gewöhnt ist, so zu arbeiten, wie er es gewohnt ist. Dies ist jedoch nicht der einzige Weg.

Aber wie arbeite ich jetzt ohne Internet?

Genau wie Sie mit NodeJs arbeiten würden. Was Deno, dass NodeJs Abhängigkeiten in ein separates Verzeichnis herunterladen. Nur in NodeJs starten Sie dies npm install, und Deno tut dies automatisch, wenn Sie es zum ersten Mal starten.

Es klingt interessant, aber ich lehne ab!

Kein Problem. Es gibt so etwas - Karten importieren . Und Deno unterstützt ihn , wenn auch nicht vollständig. So können Sie Synonyme für alle Abhängigkeiten beschreiben, indem Sie zu einem Analogon kommen package.json. Aber Sie werden nicht darauf beschränkt sein:

Einzelne Module können weiterhin ihre eigenen Abhängigkeitsversionen verwenden und die Importzuordnung bei Bedarf ignorieren.
Die Spezifikation für Importkarten schlägt die Möglichkeit vor, mehrere Quellen zum Herunterladen anzugeben. Deno unterstützt dies derzeit nicht. Aber technisch ist es möglich. Sie können mehrere Quellen angeben. Wenn eine nicht verfügbar ist, wird die Abhängigkeit von der anderen heruntergeladen.
```
{
   "imports": {
      "moment/": [
         "https://deno.land/x/moment/",
         "https://raw.githubusercontent.com/lisniuse/deno_moment/master/"
      ]
   }
}
```

Ohne npm kann ich das Konsolendienstprogramm nicht global bereitstellen!

Nun, eigentlich kannst du . deno installDies ist ein Analogon npm install --global. Deno lädt die erforderliche Bibliothek herunter, kompiliert sie in eine Binärdatei und speichert sie global. Der Unterschied besteht darin, dass Sie der Bibliothek eine Berechtigung erteilen müssen . Das heißt, ein global installiertes Paket erhält ohne Ihre Zustimmung keinen Zugriff auf das Netzwerk oder auf Dateien oder wo auch immer.

Seltsames Gefühl deja vu

Und es ist nicht ohne Gründlichkeit. Deno ist der gleiche NodeJs . Ich sehe nur wenige Unterschiede:

Deno lehnte die Abwärtskompatibilität ab. Was ihm erlaubte, die gleichen Dinge zu realisieren, indem er nicht sein eigenes Fahrrad benutzte, sondern das in der Spezifikation der Sprache beschriebene Fahrrad. Ich bin sicher, wenn eine Art „Node-next“ ohne Abwärtskompatibilität herauskommen würde, würden wir ungefähr das Gleiche bekommen, was Deno bietet. Und NodeJs bewegen sich allmählich in diese Richtung: Alle neuen ES-Chips (wie ES-Module, Top-Level-Warten usw.) werden schrittweise in NodeJs eingeführt.
Ablehnung der allgemeinen Abhängigkeitsliste. Dies kann ein Plus oder Minus sein. Das hängt von den konkreten Fällen ab. Es kann jedoch nicht geleugnet werden, dass eine solche Architektur ein Existenzrecht hat.
Die Idee ist, zu verhindern, dass das Skript ohne ausdrückliche Erlaubnis auf das System zugreift.

Das sind meiner Meinung nach alle Unterschiede. Ich sehe also keinen Grund, Deno zu hassen. Ist das seine aggressiven PR-Leute :)

5 Ansprüche an Deno