- 最近、Deno Deploy、KV、Fresh、そして会社やプロジェクト全体の勢いに対する批判や懸念が出ている
- 批判の一部は妥当であり、自ら進捗を十分に公開してこなかったことで混乱を大きくした面もあったが、これらのうわさや批判の多くは根拠のない憶測や事実と異なる内容である
- Deno 2のリリース（2023年10月以降）後、月間アクティブユーザー指標ベースで採用率が2倍以上に上昇した
- Deno 2の強力なNode互換性が実運用での大きなハードルを取り除き、プラットフォームはさらに高速で強力かつシンプルになった
Deno Deployの変化と進化
- 最も多い質問のひとつは、最近のDeno Deployにおける利用可能リージョン削減の理由である
- 削減の背景にはコストだけでなく、実際の利用パターンとニーズの変化もある
- ほとんどのアプリでは、すべてのリージョンではなく、データに近い地域での速度、デバッグ、コンプライアンスが重要である
- Deployのリリース後、25から35、そして現在は6リージョンまで変動してきた
- 多くのリージョンは実際にはほとんど使われておらず、むしろ過度に分散すると性能低下（遅延、容量の問題）が発生した
- ユーザーの要望に合った実用的な「エッジ」のビジョンを再構築している
- 新しいDeployバージョンを開発中であり、プラットフォームはアプリケーション全体のホスティングを志向して進化している
- サブプロセス、バックグラウンドジョブ、OpenTelemetry、ビルドパイプライン、セルフホストリージョンなどをサポートする予定
- まもなく、アプリをリージョンに固定したり、自社クラウドで実行できる機能を提供する予定である
KV（キー・バリューストア）の方向性
- Deno KVは、設定不要でグローバル整合性を保証し、リアルタイム機能を提供するシンプルなAPIのストアである
- セッションデータ、フィーチャーフラグ、共同作業の状態などには適しているが、汎用データベース向けではない
- より広いデータ管理ニーズに向けて、2つの取り組みを進めている
- 既存のリレーショナルデータベースのDeno Deploy内での統合を強化
- コンピュートと状態の連携を単純化する新規プロジェクトを推進中（Cloudflare Durable Objectsに着想）
- この方針に従い、KVはベータのまま維持し、重大なバグやセキュリティ問題にのみ継続対応する
- 状態管理ソリューション全体の中心、あるいは進化した役割は、今後ほかのプロジェクトが担う見込みである
Freshフレームワークの現状
- Freshは今も社内のすべてのアプリやWebの基盤であり、活発に保守・改善されている
- Fresh 2に対する大きな期待と長い待機状態を認識している
- 急いでリリースするのではなく、基本品質と構造の磨き込みを優先している
- 最近公開された詳細な改善内容に関するブログ記事を参照してほしい
- 今年中に安定したFresh 2のリリースを予定している
Deno、ランタイムを超えるプラットフォーム
- Denoは単なるランタイムを超えた完全なJavaScriptシステムプラットフォームである
- ひとつのツール体系で記述、実行、テスト、デプロイ、モニタリングなどを統合して行える
- 統合性、デフォルト設定、フラグ、ツール間の連携などが継続的に強化されている
- 単純な機能同等性よりも統合されたエコシステムの構築を目標としている
- JavaScript開発の本質的な品質向上を目指し、そのための範囲拡張に挑戦している
このプラットフォームの目標と理由
- スクリプト言語は迅速な実務開発において不可欠な役割を持つ
- JavaScriptは標準化、大規模なエコシステム、汎用的な拡張性の面で未来がさらに明るい
- 「バッテリー同梱」のプラットフォームが必要であり、Denoはそれを目指している（権限管理、Webサーバー、可観測性、lint、型チェックなどを標準提供）
- 断片化したツールではなく一元化された体験を提供する
今後の計画とコミュニケーション強化
- Denoは縮小ではなく拡大局面に入っている
- プラットフォームの速度、互換性、完成度を継続的に改善し、JSRの独立したガバナンスも成長中である
- TC39/WinterTCなどコミュニティとの協業や、JavaScriptエコシステムのためのさまざまな活動も並行して進めている
- Deploy、KVの経験を基に、持続的で分散型の新製品を開発しており、まもなく追加の知らせを公開する予定である
- 論争や不信を減らすため、コミュニケーションを強化し、開発者との信頼を重視していく計画である
3件のコメント
むしろDenoよりBunのほうが良いですか？
Denoの低迷: 世界中のリージョンが6つに縮小
この投稿への反応のようですね
Freshのアップデートがなぜ遅れているのかについての話も別途投稿されていました DenoのWebフレームワーク Fresh 2 アップデート
Hacker Newsのコメント
ほとんどの開発者が単なるステートレス関数だけをデプロイしているわけではなく、フルスタックアプリのようにデータベースと通信する実際のアプリケーションを構築するのが一般的だという点は、最初から明らかだったように思う。これに今さら気づいたというのは、ある意味当然にも感じる
最近、Deno、Deploy、KV、Fresh、そして全体的な成長傾向に対する批判的な世論があった、という認識を共有。成長傾向への批判については特に言及や回答を見ていないが、意図的に触れなかったのか気になる。一部の批判は妥当だとしていたのだから、どの批判が妥当だったのか、そしてそれをどう解決しようとしているのかまで公開していれば、もっと信頼できたと思う。会社が率直に弱点まで認める姿勢は、むしろ選択におけるプラス要因になる。Migaduのpro/conページのように、長所と短所を透明に示しているのが好印象だったという体験の共有
初期にDenoに期待していた理由は、既存との互換性に執着せず、より少ない複雑さでクリーンに新しく始められる点にあった。Nodeより新たに不便な部分はあったが、十分受け入れられる範囲だと感じていた。ところが、独自の解決策よりも次第にNodeとの互換性にこだわり始め、今ではむしろNodeより複雑に感じられる二重構造になったと思う。NodeパッケージがDenoで当然動くべきなのはそうだが、一部の未実装APIやバグのせいで動かないエッジケースが多い。いちばん好きだったテストフレームワークのAVAも、いまだにサポートしていない。以前はnpm互換レイヤーを無視してDeno自体だけ使っていたが、今ではだんだん煩わしくなっている。コマンドラインオプションを見るだけでも、この数年で非常に複雑になっており、その大半がnpm連携のためなので自分には不要な情報でしかない。自分がNode互換性でいちばん望んでいたのは、Deno linterでESLint設定をサポートすることだったが、こちらには関心がなさそうだ。それでもDenoに成功してほしいのは、Nodeの改善を促す存在だからだ。ただ、今のDenoの方向性には当初の目的との一貫性が感じられない
Denoは方向性を見失ったように感じる。最初はRustで作られた安全で高速なJS/TSランタイムというシンプルなポジショニングだったのに、今ではWebサイトの「Products」ドロップダウンに複数の製品が雑然と追加されている。VercelがNextJSに続いてデプロイプラットフォームを作ったやり方を追いかけようとしたように見える
DenoがNodeとの互換性を追加して、最初の約束を捨てた時点で期待感が消えた。自分にとってDenoの核となる魅力は、Nodeにある望ましくない複雑さや過去の遺産を取り除いたことだったが、今では組み込みTypeScriptやパーミッションのような細かな違いしか残っておらず、Nodeと大差ない。bun.shも同様にNode互換性を提供している。Node互換性を追求しないサーバーサイドTypeScriptスクリプティングエンジンを知っている人はいるだろうか
npm互換性は機能追加なのだから、別に何かを失ったとは思わない。わざわざNode APIを使う必要もなく、jsr.ioで必要なライブラリだけ使えば十分だ。実際には、Nodeとは異なる開発体験を今でもDenoで享受できるという主張。ただし、完全な「純粋性」を求める人は多くないので、むしろ大衆性と実用性を選んだのは良かったという見方
Node互換性を追求しないTypeScriptランタイムを探す理由に疑問を呈する。Nodeにも問題はいろいろあるが、それでも広く使われているだけの実用性は十分ある。実用的な代替を作るには、(1) 大規模な移行に見合うほど強力な利点があるか、または (2) 最小限の移行コストで確実な改善点（性能、信頼性、使いやすさ）が必要だ。しかしDenoはそのどちらも中途半端に外している。既存のNodeコードをそのまま動かせるわけではない一方で、革新的な利点も十分ではなく、「理想主義者」や「趣味の開発者」だけを集める限界のあるアプローチだと思う
Node互換性を追求しないTypeScriptランタイムとしてはCloudflare Workersのworkerdが思い浮かぶが、根本的に汎用バックエンドランタイムではなく、実質的に提供される標準パッケージや組み込み機能がほとんどないという制約がある
自分はJSDocを使うのが好みだ。Nodeとは関係なく、コンパイルチェーンの複雑さなしに似たような利点がある
バックエンドでJSに縛られる必要がないなら、わざわざTypeScriptではなく、より良い代替を検討するのが合理的だという立場。スタック全体を自分で制御できるなら、わざわざCompile-to-JS言語にとどまる理由はない
最近の記事は、過去の https://news.ycombinator.com/item?id=43863937 への反応なのではないかという見方
CEOが書いた記事ではあるが、Denoに対する具体的な批判よりも内部決定の正当化に重点が置かれている。それでもDeno製品群は、Deno環境ではかなりうまく動いているような印象はある
まだ信頼も確信も持てない状況。Deployがどうなるかはもうすぐ分かりそうだが、KVはベータ段階のままこれ以上発展させる意思がないのなら、新規プロジェクトで使う理由はまったくないと思う。FreshはQ3の終わりごろにアルファへ向けてリファクタリングされるそうだが、実質的に最低限しか提供していなかったフレームワークであり、そのうえ目立っていたビルド／コンパイル不要の構造すら失われる。ランタイム自体は継続して開発されているが、「他ランタイムとの機能同等性は追求しない」という宣言が空しく感じられるほど、リリースノートではNode/NPM互換性に注力しているのが興味深い
KVの継続的な開発をやめるという決定は本当に悪い選択だと思う。企業がKVを使わないのは機能が悪いからではなく、ベータというラベルが付いているからだと指摘。自分はCloudflare Workers KVを多用してきて、Durable Objectsにはあまり関心がなかったのでDeno KVに期待していたが、今後は候補から外さざるを得ないのが残念だ。新製品を発表してすぐ放置するという印象は、戦略的にも非常に悪く見えるという評価
KVの活用を検討していたが、見通しが立たないので代替案を考えるようになったという率直な感想
ほとんどの開発者が単純なステートレス関数ではなく、フルスタックアプリ、つまりデータベースと密接に連携するアプリをデプロイしているという点は、実際にはサーバーレス陣営全体に当てはまる話なのだろうかと疑問。もしそうなら、それは本来のサーバーレス運動の意図に沿っているのか、それとも単にDockerやKubernetesのような複雑なインフラを避けたいから選ばれているだけなのか気になる
Deno Deployでリージョン数が減ったことについてよく質問を受けるとの説明。Deno側は、ほとんどのアプリは世界中のあらゆる場所で動く必要はなく、データに近い場所で高速に動き、デバッグしやすく、ローカル規制に適合していればよいという最適化方針を説明している。しかし自分は、実際にはDeno Deployのリージョン配置が十分近くなく、性能面に不安があったため使わなかった。データやユーザーにもっと近い選択肢はすでに多く、規制対応も大半は国単位で十分だという点から、この最適化方針には納得がいかないという意見