Denoよどこへ行く
最近めっきりDenoに触ってない。一言で言うと飽きてしまった。
とはいえどうなってるかくらいの情報は追っているのだが、どうも使いたいと言う気分にならない。
今自分はDenoコントリビューターではないのでいち開発者としての外から見たDenoの現状を語ってみる
Web標準
最近のDenoはWeb標準に追従している
具体的には、fetch APIの実装に始まり、ブラウザに実装されているAPIの実装を頑張っている
windowオブジェクトもあるし、webcryptoやWebGPUのような、ブラウザでも誰も使ったことのないようなAPIまで実装している
自分はどうもこの流れに乗れなかった
この方針は現在のDenoコアチームの強い姿勢であり、最近JavaScriptの標準化団体であるTC39に参加したという だがDenoがサーバーサイドの言語である以上、ブラウザに存在する様々なブラウザ的問題を解決するための仕組みやAPIを実装する必要がわからない
まぁあってもいいねくらいのものではなく、ただ標準だからというレベルでの実装をしているものも多く、どういうことなのかいまいち理解できない
fetchは答えか？
fetchについても、最初はサーバーにもあると便利かもと思っていたが、仕様を知れば知るほどブラウザのために作られたものだと感じられる
特に、Node.jsのhttp.AgentのようなTCPレベルでのHTTPクライアントの制御ということがfetchではできない
HTTP/1下でのコネクションの並列数の制限や、HTTP/2下でのストリーム制御などはDenoではできない
なぜならそれはWeb標準にないからだ（ちなみにnode-fetchにはAgentを使わせるオプションがあったりする）
なぜないかといえば、ブラウザにおけるHTTP通信はセキュリティの都合上、ブラウザの厳格な管理下に置かれているからだ
ブラウザ上でのHTTP通信はブラウザに隠蔽されており制御は全くできない
それはほとんどの場合問題にならないが、それはクライアントアプリを作っているからだ
サーバーサイドにおけるHTTP通信は、それ自体がボトルネックになるほど負荷に気を遣わないといけないものだ
TCP Readタイムアウトの秒数をミスったせいでリクエストが詰まって落ちるなどのことも考えないといけない
fetchにはそういったTCPレベルでの制御機構がない。なぜならブラウザのために作られたからだ。
それはサーバーサイドで使うべきものだろうか？
URL Importの利点とは？
Denoの特徴としてnpmやyarnのようなパッケージマネージャを置かないというものがある
パッケージはURLでimportする
code:ts
登場時はその仕組みに感心していたが、今振り返るとどういういいことがあるのだろうかと首を傾げてしまう
確かにNode.jsのnpmの仕組みはとても複雑だが、色々と頑張って実装されているので実用上は便利に使えると思う
Node.jsにおけるパッケージシステムの問題点は、パッケージが多すぎるとか、ESM/CJSのモジュール戦争などのnpm以外の部分にあったように思う
Denoのこの仕組みの致命的な問題点は、パッケージのバージョニングが難しいという点だ
あるバージョンのパッケージを入れるためには、URLにそれを明示しなければならない
code:ts
このような感じだ。しかしこれはpackage.jsonのようなメタファイルではないので、更新するには手動で更新しなければならない。これが地味に面倒だ
加えて、こういったURLバージョニングの仕様というのもそれを配信するサーバーによって異なるので、npmのような統一的なバージョニング仕様がない
アプリを作る前にそういったことに頭を悩ませるよりは脳死でnpm iで動く方がなんだかんだ便利なのではと感じる
Deno Deploy
VercelやHerokuのようなものと考えて良いだろう
これはDenoがDeno Land Incとして会社化された時に発表されたDeno専用のPaaSだ
これを成長させて利益を得ようというのが現在のDenoチームの方針のようである
これが成功するのかどうかは正直よく分からない
Vercelはかつてはnowという似たようなサービスをやっていたが、Next.jsの成長と共に舵を切り、Node.jsで作られたWebサイトのホストに特化し、成長している
nowの終了は個人的にはガッカリしたものだが、ビジネス的には正しい判断だったのだろう
nowはNode.jsプログラムの優れたプレイグラウンドだったが、高負荷のWeb APIをデプロイするような柔軟性はなかった
また、その方針でAWSやGCPを崩せるビジョンがなかったのだろう
だがNext.jsの爆発的な普及は世の中のWebサイト(!= Webサービス）需要そのもので、そこにターゲットを絞ったのは優れていたと思う（そのせいで自分はVercel製品は使わなくなってしまったが…）
ではDeno Deployはどうなのだろうか。Denoしかデプロイできないプラットフォームを普及させるには、Denoの圧倒的な人気が必要になるが、それをNode.jsやPython、Goなどと争って行けるのだろうか。
そしてこういったプラットフォームで利益を出すには、圧倒的な大口顧客が必要になると思うが、そういったヘビーユーザの使用に耐えられるほどの柔軟性を提供できるのかは注目である
セキュリティ
Denoのプログラムにはパーミッションが与えられ、必要以上の権限をもつ動作を行えないというものがある
code:sh
$ deno run --allow-net server.ts
このような感じだ。これは昨今のセキュリティ意識としては正しい方針だったと思う
しかしこれも使うのが難しい機能だ
実世界のプログラムは様々なパーミッションを必要とするので甘めに設定せざるを得ないし、使うパッケージのパーミッションについて考えなくてはいけない
だが繰り返すが、これは現代のプログラムにおいて必要な機能だ
実際のサーバーサイドセキュリティはこういったもの以外にも多層防御を敷くのが一般的なので、そちらが進化したらプログラムレベルでは必要なくなる日が来るのかも知れない
セキュリティと開発の利便性は常に天秤であり、開発体験が損なわれない形で進化を遂げてほしい