Node.jsとDenoの比較

序文

Web 開発の分野をフォローしている方なら、おそらく最近 Deno についてよく耳にしているでしょう。Deno は、Node.js の後継とも考えられている新しい JavaScript ランタイムです。しかし、これは何を意味するのでしょうか。「次の Node.js」が必要なのでしょうか?

Denoとは何ですか?

何が起こっているのかを理解するには、まず Deno が実際に何であるかを確認する必要があります。前に述べたように、これは新しい JavaScript ランタイムであり、JS コードが実行される環境です。これは元々 Ryan Dahl によって作成されましたが、彼は以前 Deno と Node.js を比較してくれました。

Ryan 氏は、JSConf EU 2018 の「Node.js について後悔していること 10 選」という講演で Deno を発表しました。その情報だけでも、物事がどのように進んでいるかがわかります。 Deno は、現在利用可能な Node.js のより優れた実装となるようにゼロから作成されました。

しかし、Node.js の何が問題なのでしょうか? Deno は、より定評のある同種の製品と比べてどうでしょうか?

Node.jsとの比較

Deno と Node.js は同様の操作を実行する類似のツールですが、両者の違いは単なる名前の反転をはるかに超えています。

建築

まず、Deno の内部を見てみましょう。 Node.js と同様に、Chromium の V8 JavaScript エンジンをベースとしており、イベント駆動型の非ブロッキング アーキテクチャを使用します。しかし、両者の主な書き言葉は異なります。 Node.js は主に C++ で書かれており、非同期 I/O ライブラリとして libuv が使用されています。一方、Deno は Rust で書かれており、その非同期ライブラリ Tokio も Rust で書かれています。

これらの違いが実際のパフォーマンスにどのように反映されるかは、待って確認する必要があります。現状では、Deno のベンチマークによれば、両者の違いは区別がつかないか、少なくとも非常に微妙です。

ESモジュール

ご存知のとおり、Node.js の現在のモジュール システムはいわゆる CommonJS (require() を含むもの) ですが、ESM (ECMAScript モジュール (インポートとエクスポートを含むモジュール)) は、2015 年に導入された ES6 にまで遡り、かなり長い間 JS の公式標準となっています。もちろん、Node.js は ESM をサポートしていますが、この機能は現在 (v14.xx) 実験的なものとしてマークされており、JS コミュニティは引き続き CommonJS モジュール システムまたは他のバンドラーを使用する必要があります。

これが Deno に搭載されているもので、ESM モジュールのみをサポートする、本物のモジュール システムです。

依存関係の管理

しかし、ESM 以外にも、Deno は Node.js の依存関係管理に多くの変更をもたらします。

Deno は、何百万ものパッケージを含む npm レジストリと node_modules ディレクトリのブラックホールの経験に基づいて、依存関係に対してまったく異なるアプローチを採用しています。 Deno は npm のようなレジストリやパッケージ マネージャーを必要とせず、代わりに URL から直接依存関係をインポートして使用します。

「https://deno.land/[email protected]/http/server.ts」から {serve} をインポートします。
定数s = serve({ ポート: 8000 });
コンソールログ("http://localhost:8000/");
await (const req of s) {
    req.respond({ 本文: "Hello World\n" });
}

ダウンロードされたモジュールは、コンピューターのどこかに目に見えない形で保存されます。はい、これは node_modules がなくなることを意味します。

でも待ってください！さらに、Deno では現在作成されている、すべてに対応する package.json ファイルも削除されるため、さらに増えます... または、減ったと言ったほうがよいでしょう。 deps.ts ファイルに代わるものはありません。このファイルは、すべての外部モジュールのリダイレクト ソート ファイルのように機能します。

「https://deno.land/[email protected]/testing/asserts.ts」から { assert } をエクスポートします。
「https://deno.land/[email protected]/fmt/colors.ts」から { 緑、太字 } をエクスポートします。

NPM レジストリに関しては、Deno は URL から依存関係をロードできるようになったため、Node.js の場合と同じ要件ではありません。しかし、このオプションに興味がある場合、Deno は独自のパッケージ ホスティングを提供しています。

TypeScriptとその他の機能

はい、その通りです。Deno で使用される主な言語は JavaScript で、TypeScript もサポートされています。サポートは組み込まれており、カスタム レジスタや複雑なセットアップは必要ありません。

ただし、TS サポートに加えて、Deno には他の多くの便利なツールが組み込まれています。それらのほとんどは、fmt、bundle、doc などのコマンドの形式で表示され、それぞれコードのフォーマット、パッケージ化、ドキュメント生成などの機能を提供します。

API

API に関しては、Deno は間違いなく独自のものです。すべては TypeScript で記述されており、非同期 API は Promise のみに基づいています。コア機能は最小限に制限されていますが、その他すべては標準ライブラリにあります。

表面的には、これはすべて良好で非常に有望に見えますが、すべての API を変更すると、Node.js コードベースを Deno に変換するのがはるかに困難になることに気付くと、高揚感はすぐに消えてしまいます。残念ながら、新しくて良いものには必ず代償が伴いますよね？

安全性

最後に、セキュリティは Deno の最も重要な側面の 1 つです。 Node.js と比較すると、実行されたコードをサンドボックス化し、システムの選択された部分のみにアクセスを許可します。つまり、適切なフラグを渡すことで、ディスク、ネットワーク、サブプロセスなどへのアクセスを簡単に制限できます。

それで、これは何を意味するのでしょうか?

そこで、Deno の機能のいくつかを非常に簡単に紹介し、その要点を理解できるようにしました。必要に応じて、さらに深く掘り下げることもできます (この投稿の最後に、優れた記事へのリンクをいくつか掲載します)。

このブログ投稿の主な質問に戻りましょう。これは何を意味するのでしょうか?まあ、主な理由は、Deno v1 がすでに 2020 年 5 月 13 日 (最初のリリースからちょうど 1 年後) にリリースされていたためです。誰もが今、これが「次の大きなもの」になるのか、それとも Node.js を完全に置き換えるのか疑問に思っています。

個人的には、これについて議論するのは時期尚早だと思います。プロジェクトの規模とコミュニティの期待を考えると、プロジェクトはまだバージョン 1 であるにもかかわらず、Node.js の実用的な代替品となるにはまだまだ長い道のりがあります。覚えておいてください、これらのテクノロジーは（それぞれに違いはありますが）依然として同じことをしようとしており、同時に互いに競争しなければなりません。また、Node.js 開発が時代遅れにならないという事実 (例: Promise ベースの FS API バリアントや ESM の実験的サポート) は、おそらく長い間、2 つの JavaScript ランタイムが存在する世界で生活することになるだろう (それが JS 開発者にとって新しいことであるかのように) ことを意味します。また、大規模な NPM レジストリとエコシステムについてはまだ触れていないことに注意してください。これらは決して完璧ではありませんが、Node.js に多くの価値を追加します。これは Deno にはまだないものです。

結論

全体的に見て、Node.js はなくなることはありません。本番環境向けの本格的なプロジェクトを開始する場合は、少なくとも今のところは Node.js を使い続けるのが最善でしょう。そうは言っても、たとえ本格的なプロジェクトであっても、Deno の使用を阻止できるものは何もありません (もちろん私も)。それは確かに未来のように思えますが、私たちはまだそこに達していないのです。

上記は、node.jsとDenoの比較の詳細な内容です。node.jsとDenoの詳細については、123WORDPRESS.COMの他の関連記事に注目してください。