Deno ver 1.0
5月13日、Deno v1.0の正式リリースが決定しました。
少し勉強してみましょう。
↑ かわいい
Denoってなに？
- DenoはNode.jsの製作者であるRyan Dahlによって作られました、新しいJS/TSランタイムです
- Denoはdefaultで安全です（許可なしではファイル・ネットワーク・環境にアクセスできません）
- DenoはTypeScriptがビルトインで入ってます
- 外部パッケージはurlでインポートできます（Goみたいに）
- ディーノって読むらしい（デノではない）
Denoが作られた背景
一年前くらいにこの動画を見たことを思い出しました。
Node.jsの作者であるRyan Dahlが、Node.jsを開発した当時の仕様を後悔する旨の動画です。
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との適合性があります。
Web Assembly
DenoはWASMバイナリーのサポートがあるようです。
DenoはNodeをReplaceできるのか？
遠い未来はその可能性は高いと個人的には思ってます。（製作者自身がNode.jsの欠点を認めて作り直したランタイムなので）
しかし現在のNodeプロジェクトをDenoに乗り換えることはまずないのではないかと思います。
乗り換えにそこまで大きいメリットがないのと、現状のNPMパッケージとの適合性がないためです。
すぐデファクトスタンダードになることはないと思いますが、Web開発者なら少し触れてみても面白そうです。