ハクソク

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

Bun 1.4

2026年8月20日原文(bun.com)

概要

  • Bun v1.4 は、Node.js互換性・パフォーマンス・開発体験を大幅に強化
  • メモリ・CPU消費削減、起動速度向上 など、実運用向け最適化
  • 新API・ツール追加 や、ZigからRustへの全面書き換えを実施
  • Node.jsテストスイート の大部分に合格、主要フレームワークも動作
  • プロファイリング・バンドル分析 など、観測性・デバッグ機能が強化

Bun v1.4の主な進化点

  • Node.js互換性の拡大

    • Node.jsテストスイートから 1,517件の新テスト を追加
    • node:http, node:fs, node:cluster, node:timers, node:zlib, node:vm, node:stream などが97%以上合格
    • node:quic は99%、 node:events, node:trace_events, node:sqlite は100%合格
    • Playwright, Next.js 16, vitest, OpenTelemetry, dd-trace など、主要パッケージの動作確認済み
    • Nuxt, testcontainers, dockerode, grpc-js, Fastify, TypeORM など、多数のパッケージがBunで動作

  • 新API・機能追加

    • Bun.Image, Bun.WebView, Bun.markdown, Bun.cron(), Bun.Terminal など新API
    • bun run --parallel, bun test --parallel, bun audit fix, bun dedupe, bun prune などの新コマンド
    • worker_threads, ws, socket.upgradeTLS, node:cluster, node:repl, node:trace_events, node:domain などのNode API実装

  • パフォーマンス最適化

    • idle CPU使用率5倍削減、メモリ最大35%削減、Linuxで50%高速起動
    • メモリアロケータをJavaScriptCoreのlibpasからmimallocへ統一 し、メモリ解放最適化
    • ガベージコレクタ・futexコール削減、lazy zeroing実装 による効率化
    • Windowsで2.5倍、Linuxで2倍の起動速度向上

  • メモリ使用量の具体的改善

    • HTTPサーバ用途で13%～48%のメモリ削減
    • Next.js SSRでNode.jsより大幅に低いメモリ消費 （4,000ページでBun:238MB, Node:410MB）

  • バイナリサイズ削減

    • Linux/Windowsで最大17%小型化

観測性・デバッグ機能

  • bun --cpu-prof, bun --heap-prof でChrome DevTools/VS Code互換のプロファイル出力
  • bun --cpu-prof-md, bun --heap-prof-md でMarkdown形式のプロファイル生成
    • ターミナルで関数別CPU使用率、ヒープ占有オブジェクト、GCルート等を可視化
  • bun build --metafile-md でバンドル分析をMarkdown出力
    • モジュールごとの出力サイズ、依存チェーン、エントリーポイント解析

Bun 1.4アップグレード・導入方法

  • インストール 
    curl -fsSL https://bun.sh/install | bash
  • アップグレード 
    bun upgrade

まとめ

  • Bun v1.4 は、Node.js互換性・パフォーマンス・観測性の全方位進化
  • 既存JavaScriptエコシステムとの高い互換性 と 開発効率向上
  • 今後もNode.js100%互換に向けた進化が継続

関連ドキュメント・詳細情報

Hackerたちの意見

彼らのプロモーションビデオで「依存関係をインストールせずにできる」と繰り返してるのが変だよね。ヘッドレスブラウザテストがしたいのに、それを提供するプロジェクトをインストールするのが悪いの？なんでこの巨大なバイナリにすべてを再実装したいのか理解できない。Bunがこれらの異なる技術のニュアンスを理解していると思う理由は何？それぞれの専門に特化したプロジェクトの方がいいんじゃない？JSランタイム、パッケージマネージャー、テストランナー（ユニットとヘッドレスブラウザ両方）、バンドラー、JSX、PostgreSQL/MySQL/SQLiteドライバー、S3クライアント、Redisクライアント、フォーマッター、リンターなどなど。YAML、TOML、Markdownのパーサーもあるし、これだけでそれぞれ別のプロジェクトとしての複雑さがあるよね。1.4のためにプッシュしてる素晴らしい機能を得るには、すべてが準備できるまで待たなきゃいけないのが明らかにデメリットだと思う。1.3が2025年10月にリリースされたことを考えると、こんなに多くの大きな技術で10ヶ月のリリースサイクルは厳しいよね。Rustの書き直しのせいで許すのは早いけど、Bun 1.2は2025年1月にリリースされたから、Jarredがアルゴリズムをうまく扱えることは尊敬する。72時間にわたって10個の巧妙に作られたXティーザー投稿があったしね。https://xcancel.com/jarredsumner

└

JSエコシステムがこんなにフリップフロップしてるのは変だよね。ほんの1〜3年前には、最大の不満は標準ライブラリがないことと、すべてにパッケージを使わなきゃいけないことだったのに。今、Bunが実際にそれをやってるのに、なんでそれが悪いの？それに、まだオープンソースだから、君が言ってる実装に専念するチームも、必要ならコミュニティから注目を受けられるよ。俺は、Nodeがもっと標準でいろいろ含んでくれた方がいいと思ってるし、Nodeエコシステムでのサプライチェーン攻撃が多いから、必要なパッケージの数を大幅に減らせると思う。

└

ネイティブコードでランタイムにある方が速いよ。選択肢が増えるし、外部依存関係も使えるからね。

└

なんでこの巨大なバイナリにすべてを再実装したいのか理解できない。Bunがこれらの異なる技術のニュアンスを理解していると思う理由は何？それぞれの専門に特化したプロジェクトの方がいいんじゃない？ これ面白いよね。HNのトップ記事が悪意のあるRustクレートパッケージについてで、みんなJS/npmと比較して、両方の言語が弱い標準ライブラリのせいで頻繁にセキュリティ問題に悩まされてるって言ってる。

└

これらの問題は実際には解決済みのように感じるから、標準ライブラリに含まれるのはいいことだと思う（新しい技術がそれに取って代わるときに、互換性のために永遠に保持しなきゃいけない代償はあるけど）。共通のものに対して大きな標準ライブラリを持つのは、ゴーランみたいに進むべきだと思う。もし依存関係が基本的にどこでもデフォルトでインストールされるなら、標準ライブラリに入れるべきかもね。

└

彼らのプロモーションビデオで「依存関係をインストールせずにできる」と繰り返してるのが変だよね。数年前、JavaScriptエコシステムがすべてに依存関係を頼りすぎているという不満が一般的だったのを覚えてる？左パッドの事件で、開発者が抗議のために人気の依存関係を削除したのを覚えてる？それとも、colors.jsが破壊されて、それに依存していたものが全部壊れたこと？node-ipcパッケージが開発者のマシン上のファイルを削除するようにサボタージュされたこともあったよね。それから、人気の依存関係のビルドスクリプトにマルウェアを挿入しようとするサプライチェーン攻撃の波があった。だから、エコシステムはよりバッテリーインクルードスタイルの開発に向かい始めたんだ。

└

あなたが挙げた中で、こういう言語ランタイムに含まれるべきだと思うものは以下の通りだね：JavaScriptランタイム（もちろん）、パッケージマネージャー、ユニットテスト用のテストランナー、バンドラー、JSX、SQLiteバインディング、フォーマッター、リンター、YAMLとTOMLのパーサー。もしかしたらMarkdownパーサーやHTML5パーサーも必要かも。JSON、CSV、XMLのパーサーは絶対に必要だね。つまり、Pythonに似た感じ。ただ、Pythonはちょっと無秩序なところがあるけど。これらを全部持ってるなら、一貫性が必要だよね。

└

理想的には、特定のプロジェクトのために作られたものでないものは、OSの一部か、他のテスト済みでサポートされているシステムパッケージの一部であるべきだね。例えば、依存関係のリスクを避けるために、TOMLのパーシングのサブセットを再実装することを選ぶかもしれない。私はJavaScriptやTypeScriptは書かないけど、もし書くなら、Bunの「バッテリー込み」のアプローチは魅力的だと思う。信頼できると判断できる範囲でね。

└

「依存関係をインストールせずにできる」と繰り返すプロモーションビデオが変だよね。1.3では依存関係をダウンロードしないとREPLすら使えなかったのに。1.4ではやっと組み込まれたから、やった！これだけで1.4をインストールする理由になるよ。本当にポータブルなTypeScript REPLがやっと来たね。

└

Nodeが欲しいならNodeを使えばいいのに、他の何かがNodeじゃないって文句言うのはおかしいよ。

└

これらのいくつかは状況によるものだけど、現代のプラットフォームに対する期待が多いよね。Pythonを見てみると、標準ライブラリにはtomlパーサーやsqliteクライアントみたいなものが入ってるし。JSエコシステムはできるだけ避けてるけど、いいPostgresクライアントを見つけるための簡単な検索でも、あんまり役に立たなかったな。 https://wiki.postgresql.org/wiki/List_of_drivers 選択肢は2つあって、node-postgres/pgが一番サポートされてる感じかな。それか、もっと抽象化されてるけどあまり活発じゃないpostgres.jsとか。 Javaの質問と比べると、公式のJDBCドライバーが一番の選択肢ってのは明らかだよね。

最近、バックエンド開発にRustに切り替えたんだ。Node.jsエコシステムの断片化と、物事が脆弱に感じるのに疲れたから。Bunは、サードパーティのライブラリやバンドラーを使わずにいろんなことができるから、すごく興味深いよね。誰かNode.jsの代わりに使ってる人いる？今のところの体験はどう？試してみる価値がありそうだな。確かにAPIを作るのにRustより良い選択肢があるかもしれないけど、学びたかったから、やってみるのもいいかなって。

Hacker Newsで議論の続きを見る