ハクソク

世界を動かす技術を、日本語で。

デノの死は大いに誇張されている

370日前原文(deno.com)

概要

  • Denoやその関連プロダクトに対する 批判と誤解 が広がっていることを認識。
  • Deno 2以降、ユーザー数が倍増 し、採用が拡大していることを強調。
  • Deno DeployやKV、Freshなど 各プロダクトの現状と今後の方針 を説明。
  • Denoは単なるランタイムではなく、統合プラットフォーム への進化を目指している。
  • 今後は 透明性の向上と積極的な情報発信 に注力する方針を明言。

Denoの現状と今後の展望：批判への回答

最近の批判と現状認識

  • DenoやDeploy、KV、Fresh などについて、 批判や懸念 がSNS等で拡散することを確認。
  • 一部の 批判は妥当 であり、Denoチームが 情報発信不足 だったことを認めること。
  • 他の批判は 事実誤認や憶測 に基づくものであることを説明。
  • 本記事の目的は、 現状の共有と誤解の解消 を行うこと。

Denoの成長と現状

  • Deno 2リリース以降、月間アクティブユーザーが倍増 したことを報告。
  • Node互換性の強化 により、採用障壁を大きく低減したこと。
  • パフォーマンス、シンプルさ、機能性 が向上したことを強調。
  • Denoは かつてないほど幅広く、真剣に利用 されていることを確認。

Deno Deployの現状と方向性

  • Deno Deployのリージョン削減 についての質問や懸念が増加していることを認識。
  • リージョン削減の理由は コストと実利用状況 に基づく最適化であり、 ネガティブな憶測は誤り であることを説明。
  • 多くのアプリケーションは 単一リージョンで十分 であり、余剰リージョンはほとんど使われていなかったことを確認。
  • Deno Deployは進化中 であり、近く最新バージョンをリリース予定であることを告知。
  • サブプロセス、バックグラウンドタスク、OpenTelemetry、セルフホスト対応 など多機能化を進めていることを報告。
  • 近く リージョン固定や独自クラウドでの運用 も可能になる予定であることを発表。

KV（Key-Valueストア）の現状と今後

  • Deno KVはゼロセットアップでグローバル一貫性を持つKVS として高評価を得ていることを確認。
  • セッションデータやフラグ管理等、 用途限定で有用 であることを説明。
  • 汎用データベースやリレーショナルDBの代替にはならない ことを明言。
  • 今後は リレーショナルDBの統合強化 や、 Cloudflare Durable Objectsに着想を得た新たな状態管理プロジェクト を進行中であることを発表。
  • Deno KVは当面β版のまま とし、重大バグやセキュリティ対応のみ継続することを宣言。
  • 状態管理の主役は他の新プロジェクトへ移行する可能性が高いことを示唆。

Freshの現状と今後

  • Freshは活発に開発・利用中 であり、全社的に重要な基盤であることを強調。
  • Fresh 2のリリースを待つ声 が多いことを認識し、 品質重視のためリリースを遅らせている ことを説明。
  • 近日中に 安定版リリース予定 であり、詳細は直近のブログ記事で確認できることを案内。

Denoプラットフォームの全体像

  • Denoは 単なるランタイムでなく、JavaScriptシステム構築・運用の統合プラットフォーム へ進化していることを強調。
  • 主な内蔵機能：
    • TypeScript・JSX対応
    • 詳細なパーミッション＆サンドボックス
    • LSP、VS Code拡張、型チェック機能
    • Jupyterノートブック統合
    • deno compileによる単体バイナリ生成
    • Node/npm高互換性（ワークスペース対応含む）
    • OpenTelemetryによる標準トレーシング
    • deno fmtによる自動整形（JS/TS/CSS/SQL対応）
    • ES Modules・Web標準準拠
    • グローバルデプロイ（Deno Deploy）
    • 公開システム（JSR）とオープンガバナンス
  • 統合ツールチェーンで開発・テスト・デプロイ・監視 まで一貫して実施可能であることを強調。
  • 目指すのは 他ランタイムの機能追従ではなく、JavaScript開発の根本的改善 であることを明言。

Denoの存在意義と哲学

  • スクリプト言語はビジネスロジックに最適 であり、JavaScriptは最も普及し将来性があると認識。
  • JavaScriptには 統合された高品質なプラットフォーム が必要であり、Denoはその実現を目指すことを強調。
  • Denoは“バッテリー同梱”の思想で、認可・Webサーバ・監視・型安全性等を一体提供 することを説明。

今後の展望とコミュニティへの約束

  • 事業縮小ではなく、さらなる拡大と進化 を継続する方針を宣言。
  • パフォーマンス、互換性、完成度 の全方位的な強化を継続することを約束。
  • JSRの成熟と独立したコミュニティ主導組織への移行 を積極推進中であることを報告。
  • TC39やWinterTCでの標準化活動や、OracleのJavaScript商標問題への挑戦 も継続することを明言。
  • DeployやKVの経験を活かした新プロダクトの開発 を進行中であり、詳細は近日公開予定であることを発表。
  • 今後は 情報発信と透明性強化 に努めることを約束。

総括

  • Deno利用者やコミュニティへの感謝 を表明し、今後の発展と協力を呼びかけること。

– Ryan

Hackerたちの意見

これはおそらく https://news.ycombinator.com/item?id=43863937 に対する反応だね。

投稿はCEOによるもので、Denoに対する批判にはあまり触れていないみたいで、自分たちの内部の決定（彼の？）を正当化しているように見える。でも、Denoの製品は本当にうまく機能しているみたいだね！

└

Denoに対するどんな批判が無視されたと思う？

ほとんどの開発者は単純なステートレス関数をデプロイしていたわけじゃなくて、データベースとやり取りするフルスタックアプリを作っていたんだ。ほとんどの場合、データベースは単一のリージョンにあるし。最近のサーバーレスを使っている人たちにとって、これが一般的に当てはまるのか気になるな。もしそうなら、このムーブメントの元々の意図がこれだったのか、単にdockerやk8sに関わりたくないだけなのか。

└

俺の直感では、人々は現代的なHerokuを求めてると思う。管理されたRDBMSと、それを使う自動スケーリングのサーバーセットがあれば、巨大なスケールを必要としない多くの企業をカバーできるよ。

Denoにはすごくワクワクしてたけど、彼らが以前の約束を投げ捨てて、Nodeとの後方互換性を追加した時にはがっかりした。私にとっての大きな売りは、DenoがNodeの無駄や荷物なしで使えるものだったのに、それを捨てて、基本的にNodeに組み込みのTypeScriptサポートといくつかのマイナーな機能（パーミッションとか）を追加しただけになっちゃった。bun.shも似たような話で、Nodeの後方互換性があるけど（V8は使ってないけど）。Nodeと互換性を持たないサーバーサイドのTypeScriptスクリプトエンジンを知っている人いる？

└

Nodeとの後方互換性を持たないサーバーサイドのTypeScriptスクリプトエンジンを知っている人いる？それって何の意味があるの？静的型に恋しているけど、ブラウザをターゲットにするからJavaScriptを使わなきゃならないなら、TypeScriptを選ぶ理由はなんとなく分かる。でも、バックエンドにいて、JSが必要ないなら、なんで「Compile-to-JS」言語であるTypeScriptに自分を制限するの？スタックをコントロールして、別の選択をしようよ。

└

JSDoc好きだな。Nodeとは関係ないし、コンパイルツールチェーンの複雑さなしで同じような利点が得られるからね。

└

Nodeと後方互換性を持たないサーバーサイドのTypeScriptスクリプトエンジンを知ってる人いる？他の失敗するプロジェクトは見つかるだろうけど、なんでそんなのを探したいの？Nodeにはたくさんの問題がある（これは大きな技術プロジェクトだから言えること）。それでも非常に広く使われているのを止めるには十分じゃない。使われる製品の問題を解決するには、Nodeのようなものを提供するだけじゃ不十分で、問題がないものを提供する必要がある。1. 大規模な移行が必要だけど、素晴らしい利点があるツールを提供する。これが新しいプロジェクトを引き寄せたり、既存のツールを凌駕することがある。2. 最小限の移行コストで、同じ問題がないツールを提供する。これが既存のものを置き換えるかもしれない。理想的には、他にも魅力（パフォーマンス、信頼性、使いやすさ）があれば人々は移行するだろう。Denoはこの点で典型的な失敗例だった。#1でも#2でもなく、両方の悪いところを持ってる。利点は「正しい方法」で物事を進めたことだけど、欠点はNodeで動くほとんどのコードが動かなかったこと。これは熱心な信者や趣味の人しか引き寄せないアプローチだね。

└

機能追加（npm互換性）を失うことのように扱うのはなんで？アプリでNodeのAPIを使う必要はないよ - DenoのAPIはかなり充実してるし。jsr.ioにあるライブラリで満足できるなら、それを使ってもいいし。Nodeじゃない何かを使う開発者体験が欲しいなら、Denoからでも得られるよ。でも、純粋さにこだわる人は少ないみたいだから、それに頼らなくてよかったのは幸運だね。

└

Nodeと後方互換性を持たないサーバーサイドのTypeScriptスクリプトエンジンを知ってる人いる？Cloudflare Workersのworkerdが思い浮かぶけど、根本的に違うものだよね。https://github.com/cloudflare/workerd これは一般的なバックエンドランタイムを目指してるわけじゃなくて、ほとんどバッテリーがないんだ。

信頼感が持てないな。Deployがどうなるかはすぐに分かるだろうけど、それが「差し迫っている」からね。もし彼らがKVをベータから開発する気がないなら、もう新しいプロジェクトで使う理由はない。Freshは「2025年第3四半期後半（おそらく9月）」にアルファ版がリファクタリングされている。最初はかなり基本的なフレームワークだったし、コンパイルやビルドステップがないのが唯一面白いアイデアだったけど、それもなくなっちゃう。ランタイムは活発に開発されているけど、この声明には笑っちゃうな：> 他のランタイムとの機能の平等を追い求めているわけではない。Node/NPMの互換性に関するリリースノートはそうは言ってないけど。

└

KVはベータから開発を進める気がないなら、もう終わりだね。新しいプロジェクトで使う理由がないよ。君の言う通りだと思う。何かに使おうと思ってたけど、今は他の選択肢を考えてる…

└

KVは終わったね。これはひどい決断だよ。企業はKVがベータだから頼ってないんじゃなくて、アイデアが悪かったからじゃない。Cloudflare Workers KVはよく使ってるけど、耐久オブジェクトには興味ないんだ。Deno KVには今まですごく興味があったのに。製品を発表して放棄するのは良くない印象だよね。ライアンは素晴らしい技術者だけど、こういう決定は戦略的に見て良くないよ。

最近Denoに関する批判がいくつかあった - Deploy、KV、Fresh、そして全体的な勢いについて。彼らは自分たちの勢いに対する批判には一度も返答していないように見える（私自身は見たことがないけど、どんな主張があるのかすら分からない）、それは意図的だったのか、それとも見逃していたのか？ > その批判のいくつかは正当だと思う。何が正当な批判だったのか、そしてそれをどう解決しようとしているのかを示すのも良かったと思う。確かに、少し「自分の足を撃つ」ようなことかもしれないけど、個人的には欠点について率直な企業の方が好きだし、選ぶ可能性が高くなる。Migaduはその良い例で、彼らはMigaduを使うことの欠点について率直に書かれたプロ/コンページを持っている（https://migadu.com/procon/）。そのページが存在すること自体が、私が最初にMigaduを選んだ理由の約20%だと思う。

└

彼らが勢いをどうやって対処したかというと：> Deno 2が昨年10月にリリースされてから - たった6ヶ月ちょっと前！ - Denoの採用は月間アクティブユーザーの指標によると2倍以上になった。明らかな疑問は：2倍になったけど、何と比べて？何を測ってるの？実際の採用に関する指標は公開してないみたい。おそらく、新しいから人々が期待をかけていたんだと思う。失望は漠然とした希望や夢と比較してのものだね。

Denoの問題は、方向性を見失ってしまったことだね。数年前に最初に発表されたときは、単に「Rustで書かれた」安全で速いJS/TSランタイムだったと思うけど、今はウェブサイトに行くと「製品」ドロップダウンにいろんなものが入ってる。VercelがNextJSの初期作業の後にデプロイメントプラットフォームを導入したのを見て、同じようにしようとした感じだね。

└

これが原因なのか、それともJavaScript / Nodeコミュニティがしっかりしてきたのか？Denoがやろうとしていたことは一時期はすごくクールだと思ってたけど、js/nodeの方が早くパリティを達成したね。

Denoにワクワクしてたのは、まさに後方互換性のないグリーンフィールドアプローチだったから。初期は複雑さを減らすことに集中していて、それがうまくいってた。Nodeと比べると新しい痛点は確かにあったけど、結構管理しやすかった。ある時点で、そういう痛点に対するネイティブな解決策を考える代わりに、後方互換性に頼るようになった。今ではDenoはNodeよりも複雑に感じるのは、両方のアプローチを含んでいるから。Nodeパッケージが動くべきエッジケースがたくさんあっても、未実装のAPIやオプション、Denoにしかないバグのせいで動かないことがある。俺のお気に入りのテストフレームワーク、AVAはまだサポートされてない。以前はnpm互換レイヤーを無視してDeno自体をターゲットにしてたけど、今はそれがやりにくくなってきた。例えば、deno run --helpを見て、どれだけのコマンドラインオプションや環境変数があるか見てみて。ここ数年で爆発的に増えた。多くはnpmとの相互運用性のためだ。俺にとっては、ただの雑音だよ。Node互換性で一番欲しいのは、DenoリンターでのESLint設定のサポートなんだけど、それをやりたがってないみたい。Denoが成功することを本当に望んでるのは、Nodeに何年も前にやるべきだったこと、例えばパーミッションシステムの追加を促しているから。今のDenoのビジョンは、元々の目的とあまり整合性がないと思う。

└

僕のお気に入りのテストフレームワーク、AVAはまだサポートされてないんだ。最近確認した？ドキュメントにはAVAがサポートされてるって書いてあるよ。まあ、Denoを使ってるほとんどの開発者はサードパーティのテストフレームワークじゃなくて、組み込みのdeno testを使ってると思うけど。> Nodeの互換性で一番欲しいのは、DenoのリンターでESLintの設定をサポートしてほしいことなんだ。これも最近確認した？ドキュメントによるとこれはサポートされてるみたいだよ：「Denoの組み込みリンター、deno lintはESLintの推奨ルールセットをサポートしていて、コードに対して包括的なフィードバックを提供するよ。(...) カスタムルールやプラグイン、設定を指定して、リンティングプロセスを自分のニーズに合わせることができる。」（https://docs.deno.com/runtime/fundamentals/linting_and_forma...) Denoを6年間使ってるけど、ほとんどのDenoプロジェクトがカスタムのテストやリンティングの設定を持ってないのは実際に嬉しいよ。

└

npmの互換性について文句言いながら、互換性が足りないって文句言うのはどういうこと？両方を求めてるみたいだね — すごくシンプルで目的がはっきりしてるけど、Nodeエコシステムのたくさんのオプションも広くサポートしてほしいって。彼らの目的はJSのための単一のツールチェーンとシステムを作ることで、その分野でたくさんの問題を解決してるんだ。合理的なプロフェッショナルなプロダクションセットアップのために大量のツールを設定する必要はないよ — Otelも組み込まれてるし！それが彼らの目標なら、完全なeslint互換性に時間をかける理由は何なの？それは古い世界だよ。

ほとんどの開発者はシンプルなステートレス関数をデプロイしてたわけじゃないよ。データベースと連携するフルスタックアプリを作ってたんだ。正直、最初からそれはすごく明らかだったよね。これが当てはまらないユースケースを考えるのは難しい。彼らが気づいてくれてよかった。

└

これが当てはまらないユースケースを考えるのは難しいよね。特に2021年（確か）には、ラムダやエッジファンクションのアーキテクチャが強く推進されてたから、その方向に進むのは理解できる。でも、すべてのことに言えるように、最終的にはバランスが取れて、ほとんどのソフトウェアはまだ「古いスタイル」だって気づくんだよね。

Denoがすごく好きなんだ。毎日使ってる。でも、これは僕が書くブログ記事じゃないな。なんか防御的に感じる。