Bunの速さでNext.js

リディアというスピーカーが自己紹介し、JavaScriptランタイムとパフォーマンスについて専門知識を持つことを述べます。Vercelでの経験を通じてNext開発者がアプリをより速く構築できるよう指導してきたことが背景にあります。BUNランタイムとNext.jsフレームワークのパフォーマンスの組み合わせについて聴衆に紹介する興奮を表現しており、これが講演の中心テーマとなることが示唆されます。

Next.jsが過去数年間でウェブパフォーマンスとプロセス全体を根本的に改善してきた成果が詳細に説明されます。Webpackからの最適化、TurboPackの導入、画像とフォント最適化、サーバーサイドレンダリング、ISR、React Server Components(RSC)によるデータフェッチングの改善が具体的に列挙されます。これらの改善はすべてフレームワークレベルでの最適化ですが、一定の限界があり、その限界がランタイム層にあることが指摘される重要な転換点となります。

Next.jsアプリケーションは通常Node.jsランタイム上で実行されることが説明され、Node.jsがJavaScriptエンジン、イベントループ、ファイルIO、OS接続などを管理することが詳細に述べられます。2009年のNode導入時はハードウェアが4コア、限定的メモリという制限があり、シングルスレッドのイベントループモデルが最適でした。しかし2025年では、サーバーは数百のCPUコア、テラバイトのメモリ、50倍高速なストレージを備えているにもかかわらず、依然として2009年ベースのアーキテクチャを使用しているという矛盾が浮き彫りになります。

Nodeが素晴らしい技術であることが認められつつも、現代のサーバーレス関数や開発サーバーの短いバースト処理では、起動の1ミリ秒単位が重要であり、データレイヤーのすべてがレイテンシに加算されることが指摘されます。Next.jsアプリケーションのページレンダリング、アセット配信、レスポンスストリーミングはすべてJavaScriptからV8からNode経由のレイヤーを通り、この複数レイヤーの存在が開発サーバー起動、ファイル再ビルド、ホットリロード時にパフォーマンスを制限しています。本当に高速化したいなら、フレームワークではなくランタイム自体を再考する必要があることが結論づけられ、BUNの登場の必要性が論理的に導かれます。

BUNはNode上に構築された単なるレイヤーではなく、2025年のハードウェアのために一から構築された新しいランタイムであることが強調されます。BUNはZigという最新のシステムズ言語で構築され、金属に非常に近い実行速度を実現し、JavaScriptエンジンとしてApple JavaScriptCoreを採用しています。JavaScriptCoreは起動が高速であり、V8のような初期化最適化の一部を遅延できるため、開発サーバーやサーバーレス環境、短いビルドスクリプトなど現代のタスクに最適です。コアランタイムがZigで書かれることで、LibUVの多くの抽象化レイヤーを削除し、OSへのダイレクトシステムコールが可能になり、レイテンシが大幅に削減されます。

BUNは100% Node互換を目指しながらも、SQL、S3、Redis、ハッシング、シェルなど多くの追加の組み込みAPIを搭載していることが説明されます。JavaScriptの開発者のように毎回依存関係をインストールするのではなく、これらのバッテリー内蔵APIはランタイムに組み込まれており、本当にZigで構築されているためパフォーマンスも最適化されています。具体的には、BUN.SQLはMySQL2より最大11倍速く、BUN.S3クライアントはAWS S3 SDKより最大6倍速く、Amazon S3、Supabase Storage、Cloudflare R2などのS3互換ストレージとも互換性があります。さらに、BUNのパッケージマネージャーはYARNより17倍速く、NPMより7倍速く、高速な組み込みバンドラー、トランスパイラー、テストランナー(vTestより14倍速く、Jestより23倍速い)も提供されており、設定なしにTypeScriptとJSXをサポートします。

BUNランタイムを使用するには、BUNをインストール後、開発コマンドに`bun run --bun`フラグを追加するだけという非常にシンプルな方法が説明されます。`--bun`フラグが必要な理由は、BUNがNode互換性を重視し、通常は`bun run next dev`でNode shebangを検出してNodeにフォールバックするためですが、このフラグによってshebangをスキップしBUNランタイムを強制します。BUNはNode互換設計なので、コードベースやパッケージ、ミドルウェアについて何も変更する必要がなく、すべてが引き続き動作するはずであり、そうでなければそれはBUNのバグと見なされます。Next.jsアプリケーションがBUN上で実行されるようになれば、サーバー機能やReact Server Componentsで直接S3クライアントなどのBUN組み込みAPIにアクセスでき、追加の依存関係をインストールする必要がなくなります。

Node.jsとBUNの差の具体例として、S3クライアントの使用が比較されます。Node.jsではAWS SDK依存関係が必要ですが、BUNではコードがより少なく、依存関係も少なく、Amazon S3、Cloudflare R2、Supabase StorageなどのS3プロバイダー全体と即座に互換性があります。さらに完全な例として、React Server ComponentでS3、BUNシェル、SQLを直接使用して、SQLでデータベースをクエリしてブログポストをフェッチ、S3用のプリサインURLを画像に生成、BUNシェルを使用して単語を数えるという一連の処理が可能になります。この場合、BUNはランタイム、データベース接続、シェルをすべてネイティブに処理し、追加のAPIレイヤーや第三者ツールは不要で、金属に近い処理が実現されることが強調されます。

BUNが提供する優れた開発者体験(DX)として、設定なしで任意のJS、TS、TSX、JSXファイルを実行でき、TSNode、Babel、SWCなどについて考える必要がないことが説明されます。Next.jsを使用していなくても、開発やクイックビルドスクリプトでBUN runを試すことで、設定がないため大幅にライフを改善できます。さらに、BUN xはNPXへのBUNの相当で、何も変更する必要がなく、`bun x create next app`ウェブコマンドはNPXで次を作成するより5倍速く、BUN実行時を使用する必要さえなく、単に非常に高速です。`bun install`コマンドも実行時を変更する必要なく、基本的なNext.jsプロジェクトでもインストールが大幅に高速化されることが述べられます。

ローカルでBUNを実行することとは別に、BUNで実行するアプリケーションをデプロイする方法が説明されます。現在、RenderやRailway上で、またはDockerでアプリケーションをコンテナ化することで、複数のプラットフォームでBUNでNext.jsを使用できます。しかし、理想的にはVercelにもデプロイしたいというニーズから、スピーカーがVercelのネイティブBUNサポートをリクエストしたところ、素晴らしい応答が得られ、数週間後にBUNサポートが少なくとも内部で達成されました。ネイティブBUNサポートが非常に近い将来Vercelに到来することが期待されており、これによって任意の他のNext.jsプロジェクトと同じくらい簡単にVercel上でBUNアプリケーションを実行できるようになることが強調されます。

VercelでホストされたアプリケーションがBUNランタイムを使用することで得られる具体的なパフォーマンス向上が示されます。HONO APIの例では、単にBUNをVercelで実行するだけで、すでにCPUドロップまたはメモリドロップで30%の削減が観察されています。これはフレームワークレベルの最適化ではなく、ランタイムレベルでの改善であり、サーバー機能やReact Server Componentsなど他の機能でも同じランタイムの利点が得られることが説明されます。BUNはCPUとメモリ使用量で多く節約するため、コスト削減と応答性の向上という実質的なメリットが実現されることが明確にされます。

ネイティブBUNサポートを待つ必要なく、段階的にBUNを採用する方法が推奨されます。推奨される順序は、まず`bun install`に切り替える(コードベースで何も変更しない)、その後`bun run --bun`でローカルでBUN実行時を試す、最後に意味のあるところでBUNのネイティブAPIに段階的に移動することです。各ステップが逆向きであるため、BUNのネイティブAPIの1つが動作しなかった場合、常にNodeに戻すことができるという柔軟性が提供されます。スピーカーはBUNのエンジニアチームに感謝し、彼らが毎日一生懸命働いてBUNをさらに速く、より安定して、使うのがより楽しくしていること、そしてJavaScriptで可能なことの限界を押しているコミットメントを称賛します。Next.jsはウェブ向けの構築方法を再想像しましたが、BUNはそれに電力を供給することを再想像したというビジョンで講演が締め括られます。