Deno ってなんだっけ?

Deno (ディノ) Advent Calendar 3日目の記事です.

今日は改めて Deno ってなんだっけ? をおさらいしてみましょう.

ひとことでいうと

Deno は一言でいうと Node.js みたいなやつの新しいやつです.

もうすこし詳しくいうと

もうすこし詳しくいうと, Deno はターミナルから使うコマンドラインツールで, Deno を使ってサーバーを立ち上げたり, ファイル処理をしたり, いわゆるプログラミング言語で出来る様々な処理を実行することが出来ます.

Deno は Node.js と同じように Google Chrome の JavaScript エンジンである V8 エンジンをベースにして作られているので JavaScript 言語を使って Deno のプログラムを書くことが出来ます. すでに JavaScript 言語をある程度知っていれば, すぐにでも Deno のプログラムを書き始めることが出来ます.

なんで Deno があるの?

Deno (ディーノ) は Node.js みたいなやつと説明しました. 使っているベースのエンジンも同じ V8 です. では一体なぜ Deno を作る必要があるのでしょうか? Deno を使うとどういう良いことがあるのでしょうか?

Deno の始まり

実は Deno の作者は Node.js の作者と同じ人物のライアンダールという人です. ライアンは自分が作った Node.js のデザインが気に入らないので, それを直した理想のエンジンを作るために Deno プロジェクトを始めました.

その話は, ライアンの有名な Node.js における設計ミス (10 Things I Regret About Node.js) という講演で初めて発表されました.

ここでは Deno が解決したい問題のいくつかをピックアップして紹介します.

module システム複雑すぎ問題

Node.js プロジェクトが始まったのは 2009年のことです. その頃は JavaScript にはまだモジュールの仕組み (import や export) がありませんでした. しかし Node.js ではモジュールの仕組みが必要だったため, その当時に考えられていた CommonJS という仕組みでモジュールの仕組みが作られました. それが今 Node.js で使える require / exports の文法のベースになっています.

この仕組みは始めはうまく行っていましたが, だんだん複雑になりすぎて, 今や無用な複雑さである, とライアンは考えました. 初めから import / export だけでモジュールシステムを作ったらもっとシンプルな仕組みに出来るのではないかというアイデアに基づいて作られたのが Deno のモジュールの仕組みです.

実際 Deno のモジュールは, 参照されたファイルをダウンロードするだけというシンプルな挙動で, 理解するのが簡単です. Node.js のように package.json の main プロパティや type プロパティによってその先の解決の挙動が変わるようなことがないのです.

node_modules 大きすぎ問題

最近の本格的なフロントエンドプロジェクトで npm install をしたことがあるでしょうか?

webpack や babel / TypeScript を使った本格的な構成のプロジェクトで npm install をすると node_modules の中がとても巨大なディレクトリツリーになります. この原因の一つが Node.js のスモールコアという考え方である, と Deno チームは考えます. コアを小さくして, 他の全てを 3rd party (npm) に任せることは良いこともありましたが, 今や弊害の方が目立ってきています.

Deno では Go 言語のような大きくて充実した標準ライブラリを持つことで, この問題を解決しようと試みます. Deno は std と呼ばれる Golang をモデルとした大きな標準ライブラリを持ち, スモールコアではなく Battery Included な処理系を目指しています.

Promise 使ってなかった問題

今 JavaScript の世界では Promise という便利なものがあります. ネットワークアクセスのような時間はかかるけれど計算はする必要がない処理を表現するために Promise というものを使うとプログラムが非常に綺麗に書けることが分かっています. Node.js プロジェクトが始まった 2009年にはまだ Promise の定義がはっきりしていませんでした. JavaScript にきちんと Promise が導入されたのは2015年のことです. 2009年には Promise が本当に良いものかどうかみんなはっきり分かっていなかったので, 当時の Node.js チームは Node.js の API に Promise を取り込まないことを決めました (ref: Promise を削除する PR: Remove promises。また、masuidrive さんが、削除の直前に Promise のバグ修正パッチを送っていた事から、「masuidrive の悲劇」 と呼ばれたりもしています).

しかし, 現在の目から見れば Promise が有効なことは誰の目にも明らかです. 非同期な処理は Promise で表現されるべきです. したがって Deno では全ての非同期処理は Promise で表現されます. このことで, 全ての非同期処理が Promise で統一されて Deno の世界では非常にすっきりとしています.

まとめ

このように Deno (ディーノ) では Node.js が始まった頃には出来なかった様々なことや, Node.js が発展したことによって分かってきた様々な教訓を活かして, 今もう一度 Node.js のようなエンジンを作るとしたらどうするべきかというアイデアがたくさん盛り込まれて作られています. Deno は色々な点できれいで理想的な JavaScript エンジンと見ることが出来ます.

では, 今すぐに Deno を使うべきなのでしょうか? それは少し気が早いです. Deno はまだコアの API が安定していないので, 今 Deno で書いたプログラムは近い将来に動かなくなってしまう可能性がとても高いです. また, Deno が抱える弱点の一つとしてライブラリの少なさがあります. npm には現在100万以上の package が登録されていて, かなりのことがモジュールをインストールするだけで出来てしまうという強みがありますが, Deno では逆にほとんどのものをまだ自分で作っていかなければならない状況です.

それでも, Deno に注目している人が多いのは, やはり Deno の JavaScript エンジンとしての純粋な魅力が大きいと思います. Deno が描く未来の JavaScript エンジンの世界を少し先に見てみたい人, その世界を一緒に作ることに参加してみたい人は, ぜひ Deno を触ってみましょう.

明日は @keroxp さんの「Denoと過ごした１年」です.