Deno
TypeScriptランタイム。Node.jsの作者Ryan Dahlが作っている。
面白い。
良さそうだと思うところ
requireを撤廃できそう
念願のPromiseを返すAPI
上記2点から生まれたnpmの混乱をリセットできる
歴史的経緯からフロントエンドにもたらされた「回りくどさ」もリセットできる。
受け入れられるかちょっとわからないなと思うところ
TypeScriptの採用自体が結構opinionatedかも
JSにしておけばブラウザとimport文が互換だったかもしれない(import "~.ts"はブラウザで動く見込みなし)
実行のたびに承認を求めるのが結構面倒
Androidアプリみたいに、一度承認したものに関しては2度聞かないでもいいような気がする
権限変更されたときにはもちろん出すべき
どうなんだろうと思っているところ
中央リポジトリどうするんだろう?
「中央リポジトリが一つである必要はない」という意見だと人づてに聞いたけど、混乱を生む気がする
少なくとも「coreに役割が近いやつ」と「Portも含む雑多なやつ」に分けたほうがいいのかもしれない
stdにどこまで含むか、公式repositoryにどこまで含むかの線引が外から見ててよくわからない
まぁ考えること自体時期尚早な気もするから黙ってる
awesome-denoに雑多に集めて、公式がそれを見て考えて慎重に立ててくれるのが良さそうかなー
立てるだけ立てて実装無いやつとかもあるし
昨日あった面白いこと
ここ数日でjinjorさんがdenoを触り始めてて、すごい勢いで作ってるから自分もdenoいじりたくなってdeno-opnを作る
公開してから3時間後にegoistがdenopkgを公開
えっegoist、deno触ってたのという驚き
あと多分自分の公開見てから作ってるので早すぎる(ドメインも取ってるし)
わざわざクリスマスイブに、TL周りの人4人でdenoいじってる事態になる
気になっていること
Native Addonについて
jinjorさんも言及していたけど、Rustからdenoはライブラリとして扱うことができる
「実行可能ファイルを生成するときに限定されるけど、Native Addonを追加できるよ」というふうに書いているが、これはNativeにdenoをくるんでしまえばいいよねという話かな。
一方で例えばdenoからzipや画像を扱うような速度が要求されるケースでどうするのかという疑問はある
wasm?
あとはハードウェアアクセスなど
luaみたいな役割になってくるのかもしれない
未来的な話
Denoはbrowser compatibleを目指している
Denoが流行らなかったとしても、Node.jsの未来の姿としてふさわしい仕組みがたくさん見て取れる
実験場としても面白いし、手軽さの面でNode.jsを引き継ぎつつ安定性を備えたエンジンとしても良いし、「何故か」Nodeが主役になっているフロントエンドツールチェインに対して、新たな提案をしてくれると感じる
特にフロントエンドの人や、バンドラーを作っている人たちがDenoをどうとらえて、どう利用するのか楽しみ
基本的には下記の記事通りに実装が進んでいる
面白いけど、ここまでのセキュアなものが本当に必要なのかは不明ですね。一方で最近 npm の脆弱性も増えているので必要な面もわかります。
気持ちは同感なのだけど、懸念が現実化したのがflatmap-streamであり、やっぱり面倒でも必要なんだろうと思う
ロードマップ
We want to be secure by default; user should be able to run untrusted code, like the web.
「Webのように」信頼できないコードをユーザが実行できるように、デフォルトでセキュアにしたい。
この方針は正しいように思える
npmのように粒度が非常に小さいライブラリに大量に依存する文化では、そもそも一つ一つのライブラリが安全か確かめるすべはない
Webブラウザは「安全でないコードを実行する」エキスパート
Webのサンドボックスを見習うのはよさげ
Denoは「脅威」として下記の2つを挙げている
ローカルファイルの変更や削除(Modifiying/deleting local files)
情報漏えい(Leaking private information)
それを防ぐために、下記をデフォルトで禁止している
ネットワークアクセス(Network access)
ローカルファイルへのWrite(Local write access)
JS以外の拡張(Non-JS extensions)
サブプロセス(Subprocesses)
環境変数へのアクセス(Env access)
一方で下記のものをデフォルトで許可している
ローカルファイルのRead(Local read access.)
これはちょっと面白い。ReadはNetwork accessと組み合わせないと脅威になりえないという考え方。
Readに比べてWriteの敷居を上げるというのは、Deno製ツールの利用方法にも影響を与えるかも
例えばbrowserify index.js -o bundle.jsよりもbrowserify index.js > bundle.jsを推奨するような。
破壊的な挙動に歯止めがかかり、ツールの行儀の良さにもつながるかも
引数、標準入出力(argv, stdout, stderr, stdin access always allowed.)
多分、一時ディレクトリ。でもsymlinkを作られたらどうしようか。(Maybe: temp dir write access. (But what if they create symlinks there?))
その他
@__syumaiさんがかなり追っている
denoのio package見に行ったらいい話が書いてあった
初期はGoで実装されていたからか、Goのインターフェースを流用している箇所がある。言語も先輩を素直に見習うのはすごく良いことだと思う
sinatraライクなWAF。今の所GETのみ動作。
HTTP APIについて
今ryがどう考えてるか不明だけど、RustのHTTP実装のHyperをそのまま流用すると言っていた