👐🏼 🍉 👩🏿‍🤝‍👩🏾 デノへの5つの主張 🌭 😾 👨🏽‍🏭

序文

私はデノチームの一員ではありません。私は彼のファンではありません。私は彼についていません。私は本当に彼を信じていません。しかし、コミュニティの否定的な反応を見て、私は介入せずにはいられません。この記事では、Denoに対する最も一般的な主張を検討し、別の視点を提供したいと思います。

Deno-NodeJのキラー

本当じゃない。このように、それは「証人証人」、狂ったファン、または大げさな飢えた翻訳者によってのみ宣伝されます。私の知る限り、Ryan Dahl自身（Denoの作者）でさえ、彼の開発をNodeJの代替または代替として位置付けていません。むしろ、彼のビジョンは「将来的に同じNodeJになる可能性がある」ということです。必要に応じて、コンセプト（車やスマートフォンのコンセプトが現代の現実では非現実的であることを非難することはありません）。 Ryanの観点から見ると、NodeJにはいくつかの問題があります。そして彼はコミュニティにこれらの問題をどのように解決できるかについての特定の考えを示しました。そして、あなたはこれに参加することができます。今すぐGitHubにアクセスして、目に見えるアーキテクチャの問題について説明してください。それらについて話し合います。ソリューションを考え出す。

DenoがNodeJを置き換えることはないと思います。しかし、彼にとっては、TypeScript for JavaScriptがどのようなものになったのかがわかるでしょう。

URLでインポート

多くの人が少し間違った角度から見ています。アイデアは、プロジェクト全体のグローバル依存関係リストを削除することです。そのため、1つの大きなpackage.jsonの代わりに、各モジュール/ファイルに独自の独立した依存関係リストがあります。これにはいくつかの利点があります。

機能を記述する必要がある場合、プロジェクトですでに使用されている依存関係を確認する必要はありません。あなたはそれらに限定されません。必要なものを使用します。
レガシーを見なくても機能を追加できます。新しいモジュールには独自の依存関係があり、古いモジュールには独自の依存関係があります。
大きなプロジェクトをいくつかの依存関係の新しいバージョンに移行するときに、コードベースを変更し、これらの変更を部分的にロールアウトできます。

ただし、このアプローチでは、各モジュールの依存関係を記述する機能が必要です。名前、バージョン、およびこの依存関係を取得する場所。そのため、URLを指定してインポートします。そしてそれはデノの考えでさえありません。これは標準の一部です。誰もが慣れているように働くことに慣れているだけです。しかし、これが唯一の方法ではありません。

しかし、現在インターネットなしでどのように作業するのですか？

NodeJで作業するように。なんとデノ、NodeJは依存関係を別のディレクトリにダウンロードします。NodeJでのみこれを起動し、Denoはnpm install初めて起動したときにこれを自動的に実行します。

面白そうですが、断ります！

問題ない。そのようなものインポートマップがあります。そして、デーノは彼をサポートしますが、完全ではありません。したがって、analogに来ることで、すべての依存関係の同義語を記述できますpackage.json。しかし、これに限定されません。

個々のモジュールは独自の依存関係バージョンを引き続き使用でき、必要に応じてインポートマップを無視します。
インポートマップの仕様では、ダウンロード用に複数のソースを指定する機能が提案されています。Denoは現在これをサポートしていません。しかし、技術的には可能です。複数のソースを指定できますが、一方が利用できない場合、依存関係はもう一方からダウンロードされます。
```
{
   "imports": {
      "moment/": [
         "https://deno.land/x/moment/",
         "https://raw.githubusercontent.com/lisniuse/deno_moment/master/"
      ]
   }
}
```

npmがないと、コンソールユーティリティをグローバルに配信できません。

まあ、実際にはできます。deno installこれはアナログnpm install --globalです。Denoは、必要なライブラリをダウンロードしてバイナリにコンパイルし、グローバルに保存します。違いは、ライブラリに何らかの許可を与える必要があることです。つまり、グローバルにインストールされたパッケージは、ユーザーの同意なしに、ネットワーク、ファイル、またはどこにもアクセスできません。

奇妙な気持ちdeja vu

そして、それは完全性なしではありません。Denoは同じNodeJです。違いはほんのわずかです。

Denoは下位互換性を拒否しました。自分の自転車ではなく、言語の仕様に記載されている自転車を使用して、彼が同じことを実現することができた理由。ある種の「Node-next」が下位互換性なしで出てきた場合、Denoが提供するものとほぼ同じになると確信しています。そして、NodeJは徐々にこの方向に進んでいます。すべての新しいESチップ（ESモジュール、トップレベル待機など）は、NodeJに徐々に導入されています。
依存関係の一般的なリストの拒否。これはプラスまたはマイナスです。特定のケースによって異なります。しかし、そのようなアーキテクチャが存在する権利を持っていることは否定できません。
意図は、スクリプトが明示的な許可なしにシステムにアクセスするのを防ぐことです。

それが私の意見のすべての違いです。だから、デノを嫌う理由はない。それは彼の積極的な広報担当者です:)

デノへの5つの主張