ありがとう、Deno

DenoはCloudflareに合流し、ランタイムへの投資を終了します。Denoの存在のおかげで、私たちは皆より良い環境になりました。 Ryan Dahlは先週、DenoチームがCloudflareに合流することを発表しました。Denoランタイムは今後1年かけて縮小され、JSRはCloudflareのインフラストラクチャ上で引き続き稼働します。Cloudflareの投稿によると、チームの新しい仕事はDenoのworkerdへの統合です。この発表は、Deno 2がリリースされてからちょうど2年後のことでした。Bunは10ヶ月前にAnthropicに加わりました。代替ランタイムの実験は終わり、Nodeがデフォルトで勝利したと結論づけるのは魅力的です。現実には、エコシステムはDeno自身からではなくても、Denoが推進していたメリットを得ています。 健全なエコシステムには競争が不可欠です。 残念ながら、Denoはプロダクションで本当にクリティカルマスに到達することはありませんでした。2026年においても、Nodeは2018年と同様に支配的です。Denoが達成したのは、既存のものを活性化させ、圧力をかけることでした。そして、その圧力は一方通行ではありませんでした。 Denoはクリーンなブレークとして始まりました。Ryanは2018年のJSConf EUで立ち上がり、Nodeと異なる点として、デフォルトで拒否するパーミッション、ファーストクラスの入力としてのTypeScript、サーバー上でのWeb標準API、ESモジュールのみ、単一実行ファイルなどを挙げました。そして、決定的に、npm、package.json、node_modulesはありませんでした。依存関係はURLでした。スライドにはっきりと書かれていました。「依存関係をリストする必要はありません」。 npmとNodeで長年作業してきた多くの人々は、その最後の部分（パーミッションやTypeScriptは明らかに良かった）に懐疑的で、当時そのことを言いました。私たちは以前、ホットリンク時代に、すべてのページが誰かのサーバーからjquery.min.jsをプルし、それが移動したり侵害されたりすると壊れてしまうような経験をしてきました。URLは、どこにあったかを示しますが、それが何であるかは示しません。テストしたバイトが実際にデプロイするバイトと同じであると気になったら、整合性ハッシュとそれを記録する場所が必要になり、ロックファイルを発明したことになります。 Node TSCのMatteo Collinaは2020年に、「もう一つのleft-pad事件が起こるのを待っているが、今回はそれを修正できる『中央エンティティ』がない」と述べました。この懐疑論の一部は防御的なものでしたが、結局のところ正しかったのです。 Deno 1.0は2020年に当初の条件でリリースされ、その後4年間かけてそれらを1つずつ後退させていきました。まずdeps.tsという規約、すべてのURLを再エクスポートする1つのファイル、つまりマニフェストでした。次にlock.json、URLごとの整合性ハッシュ、つまりロックファイルでした。そしてimport maps、これによりベアスペシファイアを再び書けるようになりました。 Deno自身のドキュメントでは現在、HTTPSインポートよりもレジストリを推奨しています。なぜなら、それらは「ファイル間で異なるバージョンにドリフトする可能性があり」、「提供ホストを信頼する」からです。それらは2018年の異議であり、ガイダンスとして再提示されました。 そしてBunが登場しました。Bun 0.1は2022年7月にリリースされ、逆の賭けをしました。速度のためにツールチェーンをゼロから再構築しましたが、既存のnpmパッケージを実行し、package.jsonを読み込み、nodeのドロップイン代替として機能しました。約6週間後、Denoは「Denoの大きな変化」を発表し、npm:スペシファイア、3ヶ月以内にnpmパッケージの80〜90％を動作させるというコミットメント、そして「最速のJavaScriptランタイム」になるという新しい目標を掲げました。Denoは、このシフトの理由をユーザーフィードバックだとしましたが、タイミングから見てBunが大きな要因だったことを示唆しています。 Deno 2は2024年10月に、Nodeおよびnpmとの完全な互換性を完了しました。Nodeのエコシステムの代替として立ち上げられてから4年後、Denoはそれを実行するもう一つの方法になりました。それは正しい判断であり、また、エコシステムが10年以上の依存関係を一晩で放棄するわけではないという認めでもありました。 Cloudflareのworkerdは、2022年にオープンソース化されて以来、同じ理由で独自のNode互換レイヤーを成長させました。それがパッケージのある場所です。 Nodeも対応する必要がありました。2018年以来、グローバルなfetch、WebSocket、Web Streams、Web Cryptoをリリースしました。安定したテストランナーと--watch、--env-file、単一実行ファイルビルド、安定したパーミッションモデル、デフォルトでのタイプストリッピング、node:sqlite、そしてrequire(esm)です。 Nodeのコントリビューター（多くのボランティア）は、耳を傾け、大きな変更を加えるという大変な作業を行いました。彼らはその功績に値しますが、他の3つのランタイムがこれらのアイデアの多くを最初にリリースしなければ、このタイムラインでは起こらなかったと思います。成熟したオープンソースプロジェクトは、良いアイデアを欠くことはめったにありません。それは緊急性を欠いており、競合他社がその緊急性を供給します。 標準化作業も同様の圧力から生まれました。WinterCGは2022年に結成されました。なぜなら、いくつかの真剣なランタイムが「最小限の共通APIは何か？」という実用的な問いを立てたからです。そして今、Ecma TC55として、それは次に統合されるランタイムのいずれよりも長く続くはずです。 パッケージマネージャーとレジストリ JavaScriptパッケージエコシステムはその歴史のほとんどにおいてモノカルチャーでした。1つのクライアント、1つのレジストリ、そして15年間事実上文書化されないままだったほど非公式なAPI契約でした。それ以降のほぼすべての改善は、現状を受け入れることを拒否した誰かから来ています。 Yarn（2016年）は、インストールが決定論的であることを主張し、ロックファイル、ワークスペース、オフラインキャッシュを提供しました。npm 5はその翌年、package-lock.jsonをリリースしました。pnpmは、node_modulesが何百メガバイトもの重複ファイルである必要はないことを示しました。Bunは、インクリメンタルインストールを非常に高速にしたため、既存のパッケージマネージャーはパフォーマンスを見直す必要がありました。 Denoは、依存関係のソースを採取する前に読み取れるべきだと主張しました。URLインポートは長続きしませんでしたが、そのアイデアは残りました。 最も明確な最近の例はインストールスクリプトです。pnpmとBunはデフォルトでそれらの実行を停止しました。vltは決して実行しませんでした。私がnpmで働いていた間、この議論は常に内部で行われていましたが、決してデフォルトにはなりませんでした。今年の6月、サプライチェーンワームの連続発生の後、GitHubはnpm 12もデフォルトでそれらの実行を停止すると発表しました。そのアイデア自体は長年変わっていませんでしたが、他の多くのパッケージマネージャーがそれをリリースしたため、npmはもはやそれを過激なものとして扱うことができなくなりました。 圧力は双方向にも働きます。私たちはpnpmからカタログを借用し、pnpmのnamedRegistriesは私たちのnamed-registryエイリアスを借用しました。 レジストリ側では、JSRは称賛に値します。それは私たちとは異なる一連の賭けをしました。TypeScriptソースを公開し、ESMを要求し、コードからドキュメントを生成します。私たちはその一部に同意しませんでしたが、ユーザーからの要望があったため、vltにjsr:サポートを追加しました。それが風下に生き残るのは、私が知る限り、実行コストが低く、APIが文書化されており、Cloudflareがそれを維持する理由があったからです。 何が変わるか 現在最も人気のある2つの独立した、ベンチャーバックされたJavaScriptランタイムは、ビジネスが別の何かである企業の中に存在します。Jarred Sumnerは、BunチームとClaude Codeチームの関係は「Google Chrome <> V8の関係に似ているだろう」と述べ、より独立性が高まるでしょう。Cloudflareの投稿は、workerdのロードマップがCloudflareのものであることを明確にしています。JavaScriptCoreとV8は常にそのように資金提供されてきましたが、それでも変化です。 Denoランタイムのコミュニティフォークが登場するかどうかは、エコシステムが安全で標準を優先するランタイムを、クラウドに接続されていないものを支払ってでも評価するかどうかを示します。そして、celldをworkerdに統合することは、これまでほとんど選択肢がなかったレイヤーに新しい選択肢をもたらします。それは、RyanとBert Belderが主導する、WorkersとDurable Objectsの自己ホスト可能なオープン実装です。 JavaScriptはほぼすべてのレイヤーで保険を持っています。3つの実行エンジン、いくつかのランタイム、いくつかのパッケージマネージャーです。ランタイムレイヤーが現在行っているように、1つのレイヤーが統合されると、他のレイヤーが支えます。これを可能にする混乱は、人々が最も不満に思うことでもあります。「JavaScript疲れ」は10年間続くジョークでした。毎週新しいフレームワーク、毎月新しいバンドラー、そしてさらに別のパッケージマネージャー（はい、私が貢献したことを認識しています）。しかし、fetch、パーミッションモデル、またはビルドステップなしのTypeScriptを得るためにNodeを離れる必要はありませんでした。そして、インストールスクリプトがデフォルトでオフになったものを得るためにパッケージマネージャーを切り替える必要もありません。それらのものは、誰かが最初にそれをリリースし、既存のものが応答しなければならなかったために、人々がすでに使用していたツールに現れました。プロジェクトは