Bunがウェブリクエストを処理するのがこんなに速いのは驚きだね。記事ではZigが要因として挙げられてるけど、メモリを細かく管理することでNodeに対して2倍以上の速度が出るって本当なのかな？同様に、彼らは正確には言ってないけど、Bunを温かいパッケージキャッシュで動かしてるみたいだね…他のはどうなんだろう？キャッシュ持ってるのかな？

もうすぐアプリを単一の実行ファイルにビルドできるようになるよ -- ネイティブ依存関係も含めてね。 おお、それは知らなかった！めっちゃいい機能だね！

しかも、Anthropicに買収されたし。 これがポジティブだと思う人いるの？

彼らは約2ヶ月前に会社の半分を解雇したみたいだよ: https://news.ycombinator.com/item?id=47467746

選択肢があるのはいいことだね、エコシステムが停滞しないように。

もう単一の実行ファイルを出荷できるよ。私の製品のCLIはNodeの単一実行ファイルアプリケーションなんだ。

そうだね、この記事を読んでるとすぐに思うのは、deno packが私のオープンソースパッケージのnpm publishワークフローの素晴らしい代替になるかもしれないってこと。Deno優先/Deno中心に移行を続けたいけど、逆にNodeのTypeScriptサポートが増えてきたから、TypeScript専用のnpmパッケージに切り替えようかなって（ちょっとした）メッセージをエコシステムに送りたいとも思ってる。JSRが存在するのは嬉しいけど、あれは（ほぼ）クリーンなエコシステムだからね。

私は両方使ってるし、好きだよ。BunはNodeの代替としてそのまま使える。テスト設定やtsconfig、esmodulesとか面倒なことを気にしたくないなら、Bunはそのまま動くと思う。Denoにはいい標準ライブラリがあって、CLIサポートも素晴らしい。以前はDeno Deployが大好きだったけど、最近はちょっと使いづらくなってきたね。

Bunの成長の一因は、単にV8に疲れた人が多いからだと思う。JavaScriptCoreは異なるランタイム特性を持ってるし、言語エンジンの多様性があるのはいいことだよね。（ChakraCoreがほとんど使われなくなって、TC-39についていけてないのは残念だし、SpiderMonkeyのNode互換ラッパーもまだないけど、JavaScriptCoreのラッパーがあるのは新鮮な風だね。）

ほとんどの人にとって、Denoが約束するものは必要ないからだと思う。例えば、私は基本的なSvelteKitサーバーを動かすためにNode.jsやBunを使うだけだから、最初にHTMLをレンダリングするためにね。コア機能はすべてCrystalやRustで書かれたバックエンドサービスに委ねてる。そんな目的のために500MBのRAMを占有するような肥大化したJSランタイムは必要ないよ（Crystalのサービスはそれぞれ20MB以上しか使わないし）。Bunはスリムなランタイムを約束していて、すべての重要な機能がZigで書かれてるから、速度とメモリフットプリントが向上してる。JavaScriptCoreもV8に比べてメモリを少なく使うしね。私たちが期待するのは、Bunが安定して、メモリリークやクラッシュなしに24/7動作できることだけ。残念ながら、今はその約束が果たされてないね。

DenoとBunは、立ち上げたときに全然違うことに注力してたんだよね。Denoは、Nodeの元クリエイターであるライアンがNodeに対して感じていた問題を解決しようとしてた。一方でBunは、Nodeとの互換性やNext.jsみたいな人気のフレームワークを最初から動かせることに焦点を当ててた。Denoは長い間、依存関係やフレームワークがうまく動かなかったし、最初はnpmから依存関係をインストールする機能すらなかったんだよね。（振り返ってみると、npmのサプライチェーン攻撃のことを考えると、ライアンはこれらのことについて正しかったかも。）だから、BunはNodeのより良いバージョンで、すごく使いやすい機能がたくさんあって、設定もずっと少なくて済んだ。Denoチームも、成功するためにはNodeとの互換性が必要だって気づいたみたいで、ここ数年はその方向に注力してるっぽい。編集：今はDenoの方がBunよりNodeとの互換性が高いよ。

Denoを約1年使ってたけど、君が言った理由で好きだったんだ。でも、AstroやPrisma、Viteみたいなパッケージとの互換性の問題が多すぎて、結局Bunに切り替えたら、ずっとスムーズになったよ！

誰か、Bunの急成長の理由を説明してくれない？私の場合、ちょっとしたTypeScriptのサイドプロジェクトを始めるとき、npmやyarn、berry、pnpm、bubble、vite、webpack、rollup、rolldown、rollout、swc、esbuild、teatimeなどの海に溺れる代わりに、ただ一つのツールを使えばいいから。ああ、あれの中にはポケモンの技もあるけど、実際のJS/TSエコシステムのツールじゃないやつもあるよ。

Denoが最初に出たとき、インポートにURLを使ってたのが主な問題だったんだ。その後npmのサポートが追加されたけど、その頃にはBunがすでにあって、シェアを奪われちゃったんだよね。

同じく、私は主にバックエンド開発者だけど、個人プロジェクトでフロントエンドに手を出すときは、Denoが一番まともな選択肢に思える。使っててすごく快適なんだよね。JSの人たちの間であまり広がってないのがちょっと残念。

私はJSパッケージ開発者としての経験を話せるよ。数週間前に最後に試したんだけど、Node.js、Deno、Bun、ウェブの両方で動くnpmパッケージを作ってるんだ。これがNode.jsとDenoの2つのプラットフォームでやるのが面倒なんだ。Node.jsは、ネットワーク関連のことが入るときにワークアラウンドが必要だから、fetchが同じようには動かない。だから、Node.jsのワークアラウンドを考慮してコードを構成することになる。同じ話は他のAPIにも当てはまる。でも、動くかどうかはテストできる！Denoはもっと面倒で、パッケージを公開する前にDenoでテストできないんだ。npmにリリースする前に、tarファイルをインストールしてテスト用に配布してた。Nodeでは動くし、vite（ブラウザ用のNode）でも動くし、Bunでも問題なく動く。でもDenoでは、package.jsonに切り替えないと動かないし、Denoがサポートしている仕様のサブセットを正確に使わないといけない。「deno install xyz.tar」もできないから、npmを使わなきゃいけない（package.jsonに1行追加するだけ）、その後にDenoを実行することができる。ドキュメントもヒントもなく、ただ試行錯誤。さらに厄介なのは、npmとBunは両方とも「link」を提供してる。パッケージリポジトリでnpm/bun linkを呼び出して、テストリポジトリでnpm/bun link @yourpackageを実行するだけで、それでインストール完了。ソースのビルドディレクトリへのダイナミックリンクを作成して、パッキングやtarを送ることなく再ビルドできるから、パッケージディレクトリでビルドすれば、テストプロジェクトがすぐに更新される。Denoにはそれがない。しかも、それがないって教えてくれない。エラーメッセージもほとんどないし、変な方法で失敗するだけ。何時間もかけてやってみたけど、今はDenoのテストなしで公開して、バグ報告を待つだけ。だから、3つの中でBunが一番動く。これが全て。どのプラットフォームよりも良い。動くだけで、CLIもエラーメッセージもいいし、起動も速い。Web APIとNode API（たぶん）と、すごく良い独自のAPIもあって、Nodeよりも良いよ。例えばBun linkを実行すると、何が起こったかを正確に教えてくれる。「これが起こった、これを他で使うためにやらなきゃいけない」って。Nodeにはそれがない！DenoはBunの戦略、つまりnpm開発者のバックボーンを利用するのがより良い選択だって認識したと思う。だから、今はNode.jsの機能をゆっくり導入してるんだろうけど、それは彼らの元々のUSPに反してるよね。

Denoは、できるだけ多くのNodeJSテストを通過しようとゼロから作られてるんだ。Bunは、確かWebkitJSライブラリを利用していて、NodeJS特有のものは必要に応じてシムしてるよ。

その通り！全く問題がないから、ちょっと不思議な気分になるよ。普通、似たような技術を使うときは、少なくとも何かしらの問題があるもんだけど、ゼロってのはね。