英国を拠点とするウェブ開発者、David Bushell は、『Friendship ended with Deno, now Node is my best friend.(Deno との友情は終わり、今は Node が私の最高の友人だ)』と題したブログ記事で、Deno を長期間使用した後の Node.js への復帰を記録していた。熱心な Deno ユーザーであった Bushell は、クライアントプロジェクトで Node.js を再評価する機会に恵まれ、自分が不在の間にプラットフォームがどれほど進化したかに驚いた。

2026年10月03日、Deno から Node.js へ
Deno から Node.js への移行dbushell.com

この画像は Deno から Node.js への移行を示しており、記事の主題である Deno から Node.js への移行を反映している。

Bushell の説明によれば、Node.js は彼の以前の不満を解消するほど大きく改善されたという。モダン ECMAScript の機能が完全にサポートされ、レガシー API は近代化され置き換えられ、かつて当たり前だった require() ステートメントは現代の Node.js 開発では不要になった。個人の静的サイトジェネレーターの移行において、Bushell は次の 3 つの変更だけで済んだと報告している:Deno のファイルシステム API を node:fs に置き換え、Deno.serve を Hono の Node アダプター(node:http のラッパー)に置き換え、@std/path を node:path に直接インポートとして置き換える。移行プロセス全体で idiomatic Deno のコーディングスタイルを維持しながら、Node.js v26.10.0 への移行完了後にビルド性能が 15% 向上したことに驚いた。

Bushell は、自分の Deno 離れを、プラットフォームへの信頼を徐々に失わせた使いやすさと信頼性の持続的な問題に起因すると見ている。具体的には、ワークフローを妨げた ZSH 統合の数週間にわたる破綻、パッケージ管理を混乱させた JSR パッケージレジストリからの積極的なレート制限(429 Too Many Requests)レスポンス、および同時 HTTP リクエスト負荷下で Deno が失敗する原因となった繰り返し発生するバグを挙げている。これらの技術的懸念を超えて、Bushell はより根本的に、Deno Land Inc. が何年も前から意味のあるイノベーションを停止したと示唆している。スタッフのレイオフと、彼が『AI ファンタジーと vibe-coding Temu Cloudflare』と呼ぶ戦略的転換を、プロジェクトの方向性とビジョンの低下の証拠として指摘している。Deno が革新的な JavaScript ランタイムとして最初に魅力的だったことを認めつつ、Bushell は自分の投稿で、彼が不在の間に Node.js が開発者エクスペリエンス、性能、エコシステムの成熟度で大きく進歩したため、『今日 Deno ランタイムを使用する理由はない』と結論付けている。