ViteのRust製ライバルが登場（ほぼ）

LovableのOJ (OJ) は、単なるJavaScriptツールチェーンのRustへの書き換えではありません。これは趣味の週末プロジェクトではなく、ファイルウォッチャーやモジュールグラフから、ホットモジュールリロード、React fast refreshに至るまで、Viteのコアとなるdev serverを戦略的かつパフォーマンス重視でオーバーホールしたものです。Lovableは、Vite自身も活用しVoidZeroがメンテナンスするRolldownやOxcといった技術を用いてOJを設計しており、その本気度がうかがえます。

大手プレビューサービスプロバイダーであるLovableは、毎日約100万件ものViteサンドボックスを立ち上げるという、極めて困難な運用課題に直面しています。この想像を絶する規模において、メモリ消費量やコールドスタート時間は単なる開発者の利便性の問題ではなく、ビジネスの重要指標となります。OJはこの課題に対し、5,000個のコンポーネントを持つ大規模アプリケーションにおいて、デフォルトのViteと比較してコールドスタートからページ描画まで最大1.7倍の高速化と、メモリ消費量4分の1を実現し、同社のプラットフォームに不可欠な即時起動かつ軽量なプレビュー環境を提供しています。

AIエージェントが一度に多数のファイルを書き込むような特殊な要求を考えてみてください。通常のViteであれば、保存のたびに更新がトリガーされます。しかしOJは、統合されたウォッチャー、モジュールグラフ、コンパイラ、ホットアップデートパイプライン内で、これらの連続的な変更をインテリジェントに統合し、単一のアトミックな更新として処理します。さらに、エージェントが明示的にflushエンドポイントへポストするまで更新を保留するオプションゲートも備えており、完全に完了した変更のみがプレビューに反映されるようになっています。このような特注の最適化は個人の開発者には全く無縁ですが、Lovableの大規模なエージェント駆動型インフラストラクチャを実現するためには不可欠なものです。

OJに関するLovableの主要なベンチマーク結果は、間違いなく印象的です。5,000コンポーネント規模の巨大なアプリケーションにおいて、OJはデフォルトのViteよりも1.7倍高速なコールドスタートを実現し、メモリ消費量はViteのわずか4分の1に抑えられています。これらの数値は、極端なスケールで苦労している人々にとって非常に魅力的です。

しかし、慌ててpackage.jsonを書き換えるのはまだ早いです。一般的な小規模アプリケーションでは、OJによるパフォーマンス向上は最小限であり、メモリ使用量もViteと比べてわずかに改善する程度です。大幅なメリットは、Lovableの主要なユースケースである、大規模かつ頻繁な起動・終了が発生する条件下で初めて発揮されます。

Viteの生みの親であるEvan You氏は、重要な注意点を正しく指摘しています。OJのベンチマークでは、vite-plugin-checkerによる型チェックなど、Viteが通常行う処理が除外されていることが多く、OJは単にそれをバイパスしています。これにより、比較は不完全なものとなっていますが、それでも有益な情報を提供しています。

さらに、Vite自身の実験的なbundled dev modeは、コールドスタートの速度差を大幅に縮めており、OJを上回る場合さえあります。しかし、メモリ消費量の違いには対応できておらず、大規模デプロイメントにおいては依然としてOJが明確な優位性を持っています。トレードオフは確実に存在します。

OJの印象的なベンチマークには、大きな注意書きが伴います。このスピードは普遍的なものではなく、極端な専門化の結果です。Lovableは、Viteのコアdev serverを主にReactアプリケーション（Lovableが生成するまさにその種類）のために書き換えました。その結果、Viteを広く普及させている広範なフレームワークや設定のサポートを意図的に犠牲にしています。

この専門化は互換性の問題を引き起こします。テストの結果、深刻な React Fast Refresh のバグが明らかになりました。TanStackアプリケーションで状態が失われ、ホットアップデートではなく完全なリロードが発生していました。プレーンなReactアプリでは正常に動作したものの、このエッジケースは成熟度の差を浮き彫りにしています。Viteのような汎用ツールは、こうした不整合を長年かけて解消してきたからです。

アーキテクチャの観点から見ると、OJはRustファーストのアプローチを直接採用しています。これは、RolldownやOxcといった他のRustツールを駆動するRustプロセスとして動作し、JavaScriptブリッジはViteプラグインとの互換性を保つためだけに存在します。これは、Node.jsプロセスとしてRustコンポーネントをオーケストレーションするViteとは対照的です。Viteの柔軟性にはオーバーヘッドが伴いますが、OJの直接的なRustパイプラインはそのオーバーヘッドを取り除き、ターゲットとするユースケースに対して生の速度を提供します。Lovableの動機に関する詳細は、こちらをご覧ください：Faster previews, soon powered by OJ - Lovable。

OJはViteの直接的な競合製品ではありません。Viteの作者であるEvan Youが鋭く指摘するように、これは「調整された投影（tailored projection）」です。LovableはViteの開発サーバーの主要部分を書き換えましたが、それは何百万ものサンドボックス化されたReactアプリケーションという、彼ら独自の制約に合わせて最適化するためでした。これはViteを置き換えることではなく、特定の巨大な問題を解決するために、全く異なるパラメータの下で戦略的に再実装されたものです。

You氏はこれを単なる孤立した出来事ではなく、より広範で、おそらく避けられないトレンドの先駆けと見ています。AIが再実装のコストを低下させるにつれ、開発者はこうした専門化された「Slop Forks（ずさんなフォーク）」をますます作成するようになるでしょう。オープンソースのメンテナーが何千ものニッチなプルリクエストと格闘する代わりに、企業は自社のニーズに合わせてカスタマイズされた、高度に最適化された独自のバージョンを維持するようになるはずです。

この未来は、魅力的でありながらも不安定な諸刃の剣を突きつけています。一方で、プロジェクトの全体的なビジョンと一致しないような、非常に特定の貢献の洪水からコアメンテナーを解放するという利点があります。他方で、貴重な改善が企業内のフォークに閉じ込められ、中央のプロジェクトに還元されないという、エコシステムの断片化のリスクもあります。Evan You自身も、このダイナミクスが最終的にオープンソースコラボレーションの精神にとって有益かどうかは不透明であると認めています。これがイノベーションにつながるのか、それとも孤立につながるのか、時間が経たなければわかりません。

Orange Juice (OJ) とは何ですか？

Orange Juice (OJ) は、Lovable社によって作成された、RustによるVite開発サーバーの再実装です。毎日何百万ものプレビューサンドボックスを実行するという同社の特定のユースケースのために、高性能かつ低メモリな代替手段として設計されています。

OJはViteの完全な代替品ですか？

いいえ。OJはファイルウォッチャー、モジュールグラフ、HMRといった開発サーバーのコンポーネントのみを書き換えたものです。Viteの完全な書き換えではなく、依然としてViteのプラグインエコシステムに依存しています。また、現在は主にReactアプリケーション向けに最適化されています。

OJはViteよりも大幅に高速ですか？

大規模なアプリケーション（例：5,000以上のコンポーネント）では、OJは大幅なパフォーマンス向上を示しており、コールドスタートでは2倍近く高速で、メモリ使用量も4分の1に抑えられています。小規模なプロジェクトでは、その差はそれほど顕著ではありません。

Viteの作者であるEvan YouはOJについて何と言っていますか？

Evan Youは、OJをLovableの問題をうまく解決する印象的なプロジェクトであると評価しました。また、Viteの完全な代替品ではないことを明確にし、Viteが広大なエコシステムをサポートしなければならないのに対し、OJの速度はその狭い焦点から生まれていると指摘しました。彼はこれを、オープンソースにおける「調整された投影」や「Slop Forks」という将来のトレンドの例として挙げています。