1. kt3k

    No comment

    kt3k
Changes in body
Source | HTML | Preview
@@ -1,76 +1,76 @@
<!--
想定読者:
- プログラミングを始めて少し時間が経った人 (でも登壇とかするまで上級者ではない人).
- 仕事で React / Vue / Go / Node.js とかを触り始めて, 少し面白さを感じつつあるけどまだ完全にはしっくりきていないない人.
- Deno っていうのが去年ぐらい流行っていた気がするけど, ちゃんと追っていなかったのでなんだったか忘れてしまった人.
- JS が出来そうな人がたまに Deno の話をしていて何のことかちょっと気になっている人.
-->
<img src="https://deno.land/images/deno_logo_3.svg" width="300" />
Deno (ディーノ) Advent Calendar 3日目の記事です.
今日は改めて Deno ってなんだっけ? をおさらいしてみましょう.
# ひとことでいうと
Deno は一言でいうと [Node.js](https://nodejs.org/ja/about/) みたいなやつの新しいやつです.
# もうすこし詳しくいうと
もうすこし詳しくいうと, Deno はターミナルから使うコマンドラインツールで, Deno を使ってサーバーを立ち上げたり, ファイル処理をしたり, いわゆるプログラミング言語で出来る様々な処理を実行することが出来ます.
Deno は Node.js と同じように Google Chrome の JavaScript エンジンである [V8 エンジン][v8]をベースにして作られているので JavaScript 言語を使って Deno のプログラムを書くことが出来ます. すでに JavaScript 言語をある程度知っていれば, すぐにでも Deno のプログラムを書き始めることが出来ます.
# なんで Deno があるの?
Deno (ディーノ) は Node.js みたいなやつと説明しました. 使っているベースのエンジンも同じ V8 です. では一体なぜ Deno を作る必要があるのでしょうか? Deno を使うとどういう良いことがあるのでしょうか?
<!--
Node.js を使っていてはなぜいけないのでしょうか?
Node.js を使っていけないということはありません. むしろ, 本格的なアプリケーションを JavaScript で作ろうと考えている場合は Node.js を使うべきです. Deno はまだまだ未完成なエンジンなので, 今 Deno を本気で使おうとすると逆に痛い目を見るでしょう.
それでも, いまたくさんの人たちが Deno を開発したり, Deno を使ったアプリケーションや, ツールを Node.js を使うよりも苦労しながら作ったりしています. それほど Deno に注目する人が多い理由はなんでしょうか?
-->
# Deno の始まり
実は Deno の作者は Node.js の作者と同じ人物の[ライアンダール](https://en.wikipedia.org/wiki/Ryan_Dahl)という人です. ライアンは自分が作った Node.js のデザインが気に入らないので, それを直した理想のエンジンを作るために Deno プロジェクトを始めました.
その話は, ライアンの有名な [Node.js における設計ミス](https://yosuke-furukawa.hatenablog.com/entry/2018/06/07/080335) (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](https://github.com/denoland/deno/tree/master/std) と呼ばれる Golang をモデルとした大きな標準ライブラリを持ち, スモールコアではなく Battery Included な処理系を目指しています.
## Promise 使ってなかった問題
-今 JavaScript の世界では Promise という便利なものがあります. ネットワークアクセスのような時間はかかるけれど計算はする必要がない処理を表現するために Promise というものを使うとプログラムが非常に綺麗に書けるということが分かっています. Node.js プロジェクトが始まった 2009年にはまだ Promise の定義がはっきりしていませんでした. JavaScript にきちんと Promise の定義が導入されたのは2015年のことです. 2009年には Promise が本当に良いものかどうかみんなはっきり分かっていなかったので, 当時の Node.js チームは Node.js の API に Promise を取り込まないことを決めました (この出来事は[「masuidrive の悲劇」](https://www.slideshare.net/koichik/node1/12)として後世まで語り継がれることとなりました).
+今 JavaScript の世界では Promise という便利なものがあります. ネットワークアクセスのような時間はかかるけれど計算はする必要がない処理を表現するために Promise というものを使うとプログラムが非常に綺麗に書けることが分かっています. Node.js プロジェクトが始まった 2009年にはまだ Promise の定義がはっきりしていませんでした. JavaScript にきちんと Promise が導入されたのは2015年のことです. 2009年には Promise が本当に良いものかどうかみんなはっきり分かっていなかったので, 当時の Node.js チームは Node.js の API に Promise を取り込まないことを決めました (この出来事は[「masuidrive の悲劇」](https://www.slideshare.net/koichik/node1/12)として後世まで語り継がれることとなりました).
しかし, 現在の目から見れば Promise が有効なことは誰の目にも明らかです. 非同期な処理は Promise で表現されるべきです. したがって Deno では全ての非同期処理は Promise で表現されます. このことで, 全ての非同期処理が Promise で統一されて Deno の世界では非常にすっきりとしています.
# まとめ
このように Deno では Node.js が始まった頃には出来なかった様々なことや, Node.js が発展したことによって分かってきた様々な教訓を活かして, 今もう一度 Node.js のようなエンジンを作るとしたらどうするべきかというアイデアがたくさん盛り込まれて作られています. Deno は色々な点できれいで理想的な JavaScript エンジンと見ることが出来ます.
では, 今すぐに Deno を使うべきなのでしょうか? それは少し気が早いです. Deno はまだコアの API が安定していないので, 今 Deno で書いたプログラムは近い将来に動かなくなってしまう可能性がとても高いです. また, Deno が抱える弱点の一つとしてライブラリの少なさがあります. npm には現在[100万以上の package](http://www.modulecounts.com/) が登録されていて, かなりのことがモジュールをインストールするだけで出来てしまうという強みがありますが, Deno では逆にほとんどのものをまだ自分で作っていかなければならない状況です.
それでも, Deno に注目している人が多いのは, やはり Deno の JavaScript エンジンとしての純粋な魅力が大きいと思います. Deno が描く未来の JavaScript エンジンの世界を少し先に見てみたい人, その世界を一緒に作ることに参加してみたい人は, ぜひ Deno を触ってみましょう.
[v8]: https://ja.wikipedia.org/wiki/V8_(JavaScript%E3%82%A8%E3%83%B3%E3%82%B8%E3%83%B3)