Lovable 预览功能从 Vite 切换到 Rust 开发工具 OJ

AIによるアプリ開発サービスを提供するLovableは9月15日、開発中のアプリを動かして画面や動作を確認するプレビュー機能で、Rust製の開発ツール「OJ」の導入を進めていると発表した。プレビューを支える開発サーバーをViteからOJへ段階的に切り替えており、メモリ使用量の削減や表示までの待ち時間の短縮につながったと報告している。

Faster previews, soon powered by OJ - Lovable

OJでは、既存のVite設定や、OJが対応するViteプラグインを使ってReactアプリを開発・ビルドできる。Raphael Amorim氏が個人で開発を始め、8月24日付の紹介記事でMITライセンスでの公開を案内していた。今回、リポジトリをLovableのGitHub組織へ移管した。

プレビュー用の開発サーバーをRustで軽量化

Lovableでは、プレビューごとに隔離された実行環境（サンドボックス）を用意し、開発サーバーでアプリを動かしてコードの変更をブラウザーへ反映する。同社は1日に約100万の実行環境を稼働させており、一つ一つのメモリ消費や起動の負担が積み重なる。Amorim氏がOJの開発を始めた背景にも、複数のAIエージェントがViteでビルドを繰り返す際の大量のメモリ消費があった。

OJの開発サーバーはRustで実装されている。基盤にはViteと同じく、複数のコードファイルをまとめるRolldownと、コードを解析・変換するOxcを使う。プラグインやサーバー側のコードでJavaScriptの実行が必要な場合は、Node.jsを使う。また、AIエージェントによる複数ファイルの編集をまとめて画面に反映し、変更途中の状態が何度も表示されるのを抑えられるという。

Lovableでの導入効果と⁠、ベンチマークの比較条件

Lovableは、実サービスのプレビューでOJとViteを比較した実験結果を報告している。プレビューを開いてからアプリを操作できるまでの時間は中央値で17.4秒から8.0秒へ、実行環境の確保にかかる時間は中央値で14.5秒から3.0秒へ短縮した。アプリ読み込み前の開発サーバープロセスのメモリ使用量も、Node.js／Vite構成の約15％に減ったという。切り替えは既存アプリがそのまま動くことを確認しながら進め、利用者による設定変更は不要としている。

ブログでは、画面を構成するコンポーネントを1万個使った別のテストで、起動時間（コールドスタート）がViteの4.9秒に対してOJは1.2秒だったと報告している。ただし、この比較では、型エラーをブラウザーに表示するvite-plugin-checkerがVite側だけで動作している。OJはこのプラグインに未対応で、その処理を行っていない。

リポジトリのベンチマークには、両者とも複数のコードファイルをまとめてブラウザーへ配信する「バンドル開発モード」での比較もある。Vite側で使ったモードは実験段階にある。

MシリーズのMacで1万個のReactコンポーネントを使った場合、サーバー起動と画面表示の合計時間の中央値はOJが1.315秒、Vite 8.2.1が1.528秒と近かった。サーバープロセスのメモリ使用量には大きな差があり、それぞれ115MBと1751MBだった。

コラム⁠：Evan You氏のOJ評と⁠、オープンソースの今後

Viteの開発者であるEvan You氏は9月16日の投稿で、OJを高く評価し、Lovableの課題をうまく解決していると述べた。そのうえで、Vite全体の書き直しではなく、VoidZeroチームが保守するRolldownとOxcを使い、開発サーバー部分をRustで再実装したものと説明している。

You氏は、OJが実現した互換性を評価しつつ、Viteのすべての用途をカバーしているわけではないと説明した。OJは特定の種類のアプリに対象を絞り、その用途で必要なライブラリなどを積極的にRustで再実装して最適化している。一方、Viteはより多くのフレームワークやアプリ構成、Viteを基盤にするプロジェクトを支える必要がある。依存するソフトウェアの扱いにも違いがあり、Viteは一部のパッケージを本体に組み込まず、ユーザーが個別に更新できるようにしているという。

性能面では、You氏はブログの起動時間比較がやや誤解を招くと指摘した。理由として、Vite側だけに型検査プラグインの負荷が含まれることと、リポジトリのバンドル開発モード同士の比較では起動時間が近いことを挙げている。メモリ使用量についてはOJが大幅に少ないことを評価し、Viteでも削減に取り組むべきだとしている。

さらに、AIによって再実装のコストが大幅に下がり、オープンソースのライブラリなどを特定用途向けに作り直す動きは、今後も増えていくだろうとの見方を示した。メンテナーが大量の雑なプルリクエスト（slop PRs）への対応に追われる代わりに、それぞれが雑なフォーク（slop fork、派生版）を作り、自分でメンテナンスする未来もあり得るという。その良し悪しについては「正直、分からない」としつつ、数年後にはそうした状況になる可能性はかなり高いと考えている。