Denoの登場でNode.jsの時代は終わるのか？

# Deno ver 1.0
5月13日、Deno v1.0の正式リリースが決定しました。
少し勉強してみましょう。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/375274/d08e4c8a-1868-8c3b-a976-2816433fe654.png)

↑ かわいい

## Denoってなに？
- DenoはNode.jsの製作者であるRyan Dahlによって作られました、新しいJS/TSランタイムです
- Denoはdefaultで安全です（許可なしではファイル・ネットワーク・環境にアクセスできません）
- DenoはTypeScriptがビルトインで入ってます
- 外部パッケージはurlでインポートできます（Goみたいに）
- ディーノって読むらしい（デノではない）

## Denoが作られた背景
一年前くらいにこの動画を見たことを思い出しました。
Node.jsの作者であるRyan Dahlが、Node.jsを開発した当時の仕様を後悔する旨の動画です。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/375274/d4149ac8-e806-8a0a-a7f5-26341467fa2c.png)
https://www.youtube.com/watch?v=M3BM9TB-8yA&t=1319s

↓は要約です。（日本語がおかしいところが多々あると思いますが、ご了承ください）

### 後悔その１: Promiseの排除
 * 2009年、Node.jsにPromiseを足したけど、バカなことに2010年に消した
 * Promiseはasync/awaitのために必要な抽象化である
 * NodeでのPromiseの統一された使用が、最終的には標準化したasync/awaitにつながった可能性がある
 * 今日、Nodeの多くの非同期APIは、このせいでとっても古い書き方になっている

### 後悔その２: 安全性（Security）
 * V8それ自体は非常に優れたセキュリティサンドボックス
 * もし自分が、特定のアプリケーションでそれをどのように維持するか考慮していたなら、Nodeは他の言語より素敵なセキュリティ保証を持てたかもしれない
 * 例: linterがパソコンやネットワークに完全なアクセス権をもっている

### 後悔その３: ビルドシステム (GYP)
 * ビルドシステムはとても難しい・重要
 * V8 (Chrome) がGYPを使い始めたので、Nodeもそれを使うようにした
 * 後で、ChromeはGYPをGNに切り替え、Nodeは一人GYPユーザーとして残ってしまった
 * GYPも醜い内部インターフェースではない-V8にバインドしようとしている人に公開されている
 * しかし、ユーザーにとってはひどいUXである。JSONではなく、PythonのJSON Adaption
 * 継続されたGYPの使用が、Node coreの最も大きい失敗である
 * 多くの人々は早い段階でFFI（つまりCantrill）への移行を提案したが、残念ながら私はそれらを無視してしまった

### 後悔その４: package.json
 * NPMのIsaacが、package.jsonの大部分を作った
 * しかし、私はNodeのrequire（）が "main"のpackage.jsonファイルを検査できるようにして、それを認可した
 * 最終的にNPMをNodeディストリビューションに含め、それが事実上の標準になった
 * モジュール用の集中管理されたリポジトリがあるのは残念なことだ
 * package.jsonを許可することで、ファイルのディレクトリとしての「モジュール」の概念が生まれた
 * これは厳密にいうと、必要な抽象化ではない
 * package.jsonにあらゆる種類の不要な情報が含まれることになった。License？ Repository？ Description？それは定型的なノイズだった
 * インポート時に相対ファイルとURLのみが使用された場合、パスがバージョンを定義するので、Dependenciesをリストする必要はない

### 後悔その５: node_modules
 * node_modulesはモジュール解決アルゴリズムを非常に複雑にした
 * vendored-by-defaultは良い意図を持っているが、実際には$NODE_PATHを使用するだけではそれを排除することはできなかった
 * ブラウザのセマンティクスから大きく逸脱している
 * 私のせいで、とても残念な気持ち
 * しかし、不幸にもこれをundoすることはできない

### 後悔その６: ".js"の拡張子なしでのrequire("module")
 * 必ずしも明示的でない
 * BrowserのJavaScriptが動く方式ではない。scriptタグのsrcアトリビュートで".js"を省略することはできない
 * module loaderは、ユーザーの意図を推測するために、複数の場所でファイルシステムを照会する必要がある

### 後悔その７: index.js
 * index.htmlなどがあったため、かわいいと思っていた
 * module loadingシステムを不必要に複雑にしてしまった
 * requireがpackage.jsonをサポートするようになった後はより不必要になってしまった

## DenoのFeature
### トップレベルAwait
もうawaitを使いたいがためにasyncの関数で囲う必要はありません。

```index.js
// Node
const fetchData = async () => await fetch('someapi/data');
const data = fetchData();


// Deno
const data = await fetch('someapi/data');
```

> 2020/05/25 追記
> Node.jsでも、 v14.3.0で、トップレベルawaitが可能になりました。

### セキュリティ
上でも何回か述べてるように、Denoでは許可なしでファイル・ネットワーク・環境にアクセスできません。

### TypeScriptビルトイン
TypeScriptのセットアップは不要です。

### URLインポート
NPMパッケージをインストールしなくても、URLで `import` できます。
 
```index.js
import stuff from 'https://package/index.js';
```


### ES6とそれ以上
モダンなJSの書き方が可能です。

### Webとの適合性
DenoのAPIはWebとの適合性があります。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/375274/8c6f52d1-101a-9c95-7d1a-42e7c5a7d762.png)

### Web Assembly
DenoはWASMバイナリーのサポートがあるようです。


## DenoはNodeをReplaceできるのか？
**遠い未来**はその可能性は高いと個人的には思ってます。（製作者自身がNode.jsの欠点を認めて作り直したランタイムなので）
しかし現在のNodeプロジェクトをDenoに乗り換えることはまずないのではないかと思います。
乗り換えにそこまで大きいメリットがないのと、現状のNPMパッケージとの適合性がないためです。

すぐデファクトスタンダードになることはないと思いますが、Web開発者なら少し触れてみても面白そうです。

https://deno.land/