ホームページ >ウェブフロントエンド >jsチュートリアル >デノのことが好きです
Deno 安定版は約 3 ~ 4 年前に導入されました。当時、Node.js の作成者である Ryan Dahl が Deno のパトロンでもあったため、かなりの注目を集めました。はぁ!そうですよね。なぜ彼は自分の「子供」と競争するために新しいツールを作成したのでしょうか?
Ryan Dahl は、Node.js には重大な弱点があることを認めました。当初、Node.js はシンプルさと柔軟性に重点を置いて設計されました。しかし、何年にもわたって、すべてが制御不能になりました。 Node.js は非常に強力に発展し、ますます注目を集めていますが、人々がこの新星にすべてを詰め込もうとして、必要以上に複雑になってしまいました。
Deno は、Node の弱点に対処するために生まれました。しかし、立ち上げ当初はその強みを発揮できていませんでした。 Node の最大の利点の 1 つである npm サポートがないことは言うまでもなく、そのパフォーマンスは Node.js よりも劣っていました。これにより、事態はますます困難になりました。
好奇心旺盛な私は、Deno を使用していくつかのコード スニペットをすぐに試してみたところ、ライブラリ システムの不便さに気づきました。 「わあ、私のお気に入りのライブラリがこのプラットフォームに表示されるまでには長い時間がかかるかもしれない。すべてが新しく見え、見慣れないもののように見える。」と私は思いました!
ブログを「解体して再構築」し始めてからすべてが変わりました。テクノロジーの選択について何度も躊躇し熟考した後、Fresh という名前が誕生しました。ただし、Fresh はランタイム環境として Deno を必要とします。これまでに導入経験がなかったが、「単なる JavaScript 実行環境だ!」と考えていた。私にもっと自信を与えてくれました。次の話はこの記事です。
今日は、私がDenoと仕事をする際に「らしい」と感じる5つのポイントをまとめます。
Deno は TypeScript をネイティブにサポートしています。これは、他のライブラリのように .js への変換手順を経ることなく、.ts ファイルを直接実行できることを意味します。多くの人は、これが ts-node のような TypeScript コードを実行するツールを使用するのと違うのではないかと疑問に思っています。答えは間違いなく「はい」です。 ts-node が複雑なケースで動作するには TypeScript 構成ファイルが必要ですが、Deno は必要ないからです。 TypeScript のデフォルトのサポートにより、.ts コードを直接実行するプロセスが簡素化されます。
私は、自分自身でいくつかの小さなタスクを処理するためのスクリプトを作成することがよくあります。新しいスクリプトを作成するときは、.js と .ts のどちらを選択するかいつも迷います。そして Deno が登場すると、.ts がデフォルトの選択肢になりました。 Node プロジェクトでも、簡単なタスクを実行するスクリプトを作成する必要がある場合は、.ts を選択し、Deno を使用してそのコードを実行することを好みます。
JavaScript/TypeScript プロジェクト全般、特に Node.js に携われば取り組むほど、いつも疑問に思ったり、面倒に感じたりすることが 1 つあります。それは、設定ファイルが多すぎるということです。異なるプロジェクトにはそれぞれ異なる名前のファイルがあります。 package.json、package-lock.js、およびプロジェクトで Typescript を使用している場合は追加の tsconfig.js から...webpack、vite、tailwind、postcss などをさらにいくつか設定する必要があるかどうかは言うまでもありません...まあまあ!最初は不慣れのため、プロジェクトに登場する各設定ファイルの意味や使い方を理解するために本を読まなければならず、「一体どうやってこのような設定ファイルを何百も作成できるのか?」と静かに悪態をつきながら読みました。
Deno に移行したとき、設定ファイルがまったくないことに気づき驚きました。つまり、設定を行わずにプロジェクトを実行できるということですが、現実的ではありませんよね?存在するとしても、それは 1 つの deno.json ファイルです。 Deno は、多くの複雑な構成を巧みに削除するか、単一の JSON ファイルに配置しました。奇妙な名前が再び表示されることを気にせずにプロジェクトを開くことができて、本当に安心しました!
Deno はこれまでも、そしてこれからも可能な限り Web API をサポートしようとしています。 Web API は、ブラウザで使用できる標準化された API のセットです。 Web API の適切なサポートにより、Deno で実行されるプログラムをブラウザーでも実行できるようになり、一度書き込めばどこでも実行できるというパラダイムに従います。これにより、「ユニバーサル」ライブラリへの道が開かれます。
サーバーレス、特に Cloudflare Workers を使用したことがある場合は、Workers が Node.js と完全に互換性がないことをご存知でしょう。そのため、Node 固有のライブラリを使用しても機能しない可能性があります。一方、ライブラリが Web API を使用しているか、Web API と互換性がある場合は、スムーズに動作します。これはデノにも当てはまります。
ノード API のサポートにより、Deno はほとんどの「パッケージ」を npm で実行できます。したがって、互換性を気にすることなく、npm パッケージを自由に使用できます。
Node プロジェクトを開始すると、デフォルトですべてのユーザーの権限が付与されるという明白な事実があるのは非常に奇妙です。これは、プログラムがユーザーに代わってシステム内のファイルに自由にアクセスしたり、コマンドを実行したりできることを意味します。かなり危険ですよね?最初に確認せずに誤って他人のプロジェクトを「実行」し、そのプロジェクトがあなたのマシン上のすべてのデータをスキャンし、サーバーに送り返したり、身代金のためにすべてのファイルを暗号化したりした場合を想像してください。そのときは、人生が台無しになったと考えてください。これは許しがたい間違いです。修正しました!
Deno は、アプリケーションの実行時にアクセス許可を要求するフラグを追加することで、この欠陥に対処しています。アクセス許可には、ファイル アクセス、インターネット アクセスなどが含まれます。プログラムがファイル システムにアクセスしたり、インターネットに接続したりする場合は、少なくともアクセス許可を要求する必要があります。例:
$ deno run --allow-read --allow-write --allow-net index.ts
「要求」する必要がある権限が多数あります。詳細については、「セキュリティとアクセス許可 |」を参照してください。デノドキュメント。最も簡単な方法は、-A または --allow-all フラグを使用してすべての権限を許可することです。
私はそれが導入されたばかりの初期の頃を覚えています。 Deno はプログラムのパフォーマンスの点で Node.js に遅れを取っているように見えました。具体的には、ベンチマーク テストでは、同じプログラムを実行した場合の Deno と Node の違いが示されました。デノはいつもあと一歩及ばなかった。ある時点で、bun.sh が突然現れました。 Bun はパフォーマンスの点で両方の Node.js を上回っていたため、現象として浮上しました。これにより、デノはさらに鈍く見えました。
実際、bun を使用していくつかの Node アプリケーションを実行すると、かなりの数の問題やバグに遭遇しました。パンはまだ「本番」の準備ができていないようです。そのため、その時点では、安定性を愛する人にとっては Node が依然として頼りになる選択肢であると結論付けました。
最近、Deno 2.0 のリリースにより、パフォーマンスを向上させ、この「黒い恐竜」のプログラミング エクスペリエンスを強化するために多大な努力が払われました。彼らがリリースした最新のドキュメントによると、Deno は、有名な名前である Node や bun と比較して、あらゆる面で際立っています。
上記はDenoと仕事をする際に私が気に入っているポイントです。アプリケーションをデプロイするための Deno Deploy を無料で提供するなど、さらにいくつかの機能があります。ただし、パフォーマンスやモジュール システム、Node との互換性の低さを「批判」する記事を今でも時々見かけます。これらの制限は、最新の 2.0 バージョンで解決されました。 Deno に対する私の見方は、最初にリリースされたときと比べて変わりました。Deno がコミュニティからさらに注目され、将来さらに飛躍することを願っています。
あなたはどうですか?デノを使ったことはありますか?この JavaScript 実行環境に関して、賞賛や批判はありますか?以下にコメントを残してください!
以上がデノのことが好きですの詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。