LovableがViteをRustで再構築……？（っぽいことをしてみた）

日本語العربية Deutsch English Español Français हिन्दी Bahasa Indonesia 한국어 Português Русский 中文

Computing/SoftwareSmall Business/StartupsInternet Technology

Transcript

00:00:00また新たなRust書き換えプロジェクトが登場しました。今回はVite開発

00:00:03サーバーがLovableチームによってRustで再構築され、メモリ使用量が

00:00:074分の1になり、コールドスタートが2倍高速化したと謳われています。少し誤解を招く

00:00:12表現かもしれないので、その主張を検証しつつ、将来移行すべきものなのか、

00:00:15そしてViteの作者がオープンソースの未来についてどう考えているかを見ていきましょう。

00:00:24今回取り上げるプロジェクトは「OJ（Orange Juice）」と呼ばれ、

00:00:29既存のViteプロジェクトに向けて実行するだけで動く1つのRustバイナリです。Viteの

00:00:33設定を読み込み、既存のViteプラグインも動作しますが、その水面下にある開発サーバー、つまり

00:00:38ファイルウォッチャー、モジュールグラフ、HMR、React Fast RefreshがすべてRustで書き直されています。

00:00:44面白いことに、これはVite自体も採用し、voidzeroがメンテナンスしている

00:00:49RolldownとOxcを使って作られています。自分でも試すためにTanStackアプリを作成し、

00:00:53Vite devとOJ devで動かした際に違いがあるか検証しました。一見するとほぼ同じように動作し、

00:00:58SSR、ハイドレーション、サーバー関数、Fast Refresh、

00:01:03動的ファイルルーティング、サーバー形式ルート、Tailwind、アセットのインポートなど全て動きますが、

00:01:07詳しく調べていくと、いくつかの些細な違いに気づきました。1つ目はFast Refreshです。ファイルを編集すると、

00:01:13Viteではカウンターの状態が保持されますが、OJではカウントが0にリセットされ、

00:01:17変更されたコンポーネントだけでなく全体のリロードが行われていることがわかります。そこで、

00:01:22TanStack Startではない普通のReactアプリでも同じ動作を試してみたところ、

00:01:26興味深いことに、こちらでは問題なく動作しました。同じ編集をしてもカウントは保持され、

00:01:30ページ全体の更新は行われないため、真のホットアップデートが機能しているようです。なぜ

00:01:35TanStack Startと普通のReactアプリでこのような違いがあるのかは分かりませんが、まだ考慮されていない

00:01:39エッジケースの1つかもしれません。2つ目の違いは

00:01:42サーバー関数に関するものです。このサーバー関数はアプリ内部から開発サーバー全体のプロセスツリーのメモリを計測します。

00:01:46このアプリにおいてViteでは2つのプロセスで約380MBであり、OJでは

00:01:53同じく2つのプロセスで約320MBでした。したがって、このような規模の小さなアプリでは

00:01:59メモリ使用量はほぼ同じで、OJがわずかに勝っている程度です。では、このプロジェクトは

00:02:04完全に無意味なのでしょうか？いいえ、OJは元々そのような用途のために作られたわけではないからです。OJが最も力を発揮するのは

00:02:09非常に大規模なアプリです。5,000個のコンポーネントを持つReactアプリでテストを行った際、各開発サーバーを起動し、

00:02:14実際のChromeブラウザでページを開き、最も深い階層のコンポーネントがDOMに現れた時点でタイマーを止め、

00:02:19プロセスツリー全体のメモリを計測するスクリプトを使用しました。結果として、OJの通常モードは

00:02:24デフォルトのViteよりも描画完了まで約1.7倍高速で、メモリ使用量は

00:02:29約4分の1でした。もっともViteの擁護をしておくと、Vite 8.1では「bundled dev mode」という実験的機能が導入されており、

00:02:34それを有効にするとViteは1.18秒で完了し、実はOJの通常モードよりも

00:02:40少し速くなりますが、メモリの削減にはなりません。また、OJにもバンドルモードが存在し、それを使用すると

00:02:45約0.89秒とさらに高速化され、メモリもViteの約4分の1に抑えられます。

00:02:51このようにOJには確かにメモリ面での利点があり、それこそがLovableが

00:02:55このプロジェクトを開発した最大の理由です。Lovableのプレビューは実際のVite開発サーバーを動作させており、

00:03:00彼らによれば1日に約100万個のサンドボックスを稼働させているため、そのようなスケールでは

00:03:04リソース消費が非常に重要になってきます。そのため、Lovableはアプリを動作させているエコシステムを損なうことなく、

00:03:09即座に起動し軽量であり続けるプレビューを実現するためにOJを構築しました。

00:03:13また、彼らはそのユースケース、つまりAIエージェント向けに実に素晴らしい設計上の決断を下しています。編集時、

00:03:17人間は通常1ファイルずつ保存しますが、エージェントは一度に10ファイルほどを短時間で書き出します。

00:03:22Viteであればこれらの保存を個別の更新として処理してしまいますが、OJではウォッチャー、

00:03:26モジュールグラフ、コンパイラ、ホットアップデートが単一のパイプラインになっているため、連続した変更が1つの更新に統合されます。

00:03:32さらに、エージェント自身がflushエンドポイントにポストするまで更新を保留するゲート機能を有効化することもでき、

00:03:35完了した変更のみをプレビューに適用することが可能です。ご覧のように、これは

00:03:40Lovable独自のユースケースを解決するための非常に特化したプロジェクトであり、Viteの作者であるEvan You氏も

00:03:45その点を認めています。ツイートでの彼の最初の指摘は、Lovable自身の問題を見事に解決する

00:03:49非常に印象的なプロジェクトではあるものの、Vite全体の書き換えではないという点です。書き換えられたのは開発サーバーのみであり、

00:03:54またvoid0がメンテナンスするRolldownとOxcの上に構築されているため、それらを置き換えるものではありません。

00:04:00OJのパーサー、トランスフォーマー、プロダクション用バンドラーはすべてvoid0のものであり、

00:04:04Lovableはその周りにサーバーを書いたに過ぎません。本質的には、ViteがRustを駆動するNode

00:04:08プロセスであるのに対し、OJはRustプロセスがRustを駆動しており、ViteのプラグインAPIと対話できるように

00:04:13中間にJavaScriptのレイヤーがあるというイメージです。Evan氏はさらに続けて、

00:04:17OJが高速なのは単一の形式のアプリしかサポートしていないからだと指摘しています。OJは実際には

00:04:22Reactアプリ（Lovableが生成するもの）でしか動作しません。一方Viteは、

00:04:27あらゆるフレームワーク、あらゆる特殊な設定、その周りに作られたあらゆるツールをサポートする必要があり、esbuildや

00:04:31Reactプラグインのようなものは、必要に応じて各自で追加できるよう意図的に別パッケージに分けています。

00:04:36その後、彼はベンチマークの欠陥についても触れています。ブログ内のViteのコールドスタートには

00:04:40バックグラウンドワーカーでTypeScriptを実行するvite-plugin-checkerが含まれていますが、OJは実際には

00:04:45そのプラグインをサポートしていないため、その処理を完全にスキップしています。また、bundled dev

00:04:50modeを使用したViteの速度はOJのコールドスタートに近く、私たちが検証した数値とも一致していると指摘しています。しかし

00:04:55OJのメモリ使用量が著しく少ないことは認めており、Viteもその改善を目指すべきだろうと述べています。

00:04:59このツイートの中で私が最も興味深いと感じたのは、Evan氏の最後の主張です。オープンソースの力学は

00:05:03変化しており、AIによって再実装のコストが激減したため、今後は彼が言う

00:05:08オープンソースツールの「特定の用途に特化した派生版（tailored projections）」が増えるだろうということです。つまり同じ依存関係であっても、

00:05:13単一コンポーネントの制約とユースケースに合わせて再構築されるのです。彼はもう一つの例としてTanStackのRedactを挙げています。

00:05:19起こり得る未来として、メンテナーが大量のスロットPR（細かなPR）に追われる代わりに、誰もが

00:05:23自身に特化したフォークをメンテナンスするようになるかもしれません。正直なところ、それが良いことなのかは分からないものの、

00:05:28数年以内には高い確率でそうなっていくだろうと彼は考えています。一側面では、細かなフォークの存在は

00:05:33大量のPRを捌くよりメンテナーにとって都合が良いですが、エコシステムの断片化というリスクも孕んでいます。

00:05:39これがどう展開し、オープンソースの未来がどうなるかは、時が経ってみなければわかりません。

00:05:43総じて、サンドボックス内で何百万ものVite開発サーバーを動かすという全く同じ課題に

00:05:47直面していない限り、Lovable以外の人が使うようなツールではありません。

00:05:52自分のノートPCでViteが遅い、あるいはメモリを食い過ぎていると感じたことはありますか？私自身は

00:05:57ありませんが、これが実に興味深いプロジェクトであり、彼らがこれを成し遂げたのは素晴らしいことです。

00:06:01これについてどう思うか、ぜひコメント欄で教えてください。チャンネル登録もよろしくお願いします。それでは

00:06:04また次回お会いしましょう。

00:06:09また次回お会いしましょう。

Key Takeaway

Lovableが開発した「OJ」は、RolldownとOxcを活用してViteの開発サーバーをRustで再構築し、1日100万件規模のAIプレビュー環境においてメモリ消費量を4分の1に削減する特化型ツールである。

Highlights

5,000コンポーネント規模のReactアプリにおいて、OJは既存のViteと比べて描画完了速度が約1.7倍速く、メモリ使用量を約4分の1に削減する。
Vite 8.1の実験機能「bundled dev mode」は1.18秒で描画しOJの通常モードより高速だが、メモリ削減効果は持たない。
OJはファイルウォッチャー、モジュールグラフ、コンパイラ、HMRを単一パイプライン化し、AIエージェントによる複数ファイルの連続書き出しを1つの更新に統合する。
OJのパーサー、トランスフォーマー、プロダクション用バンドラーにはvoidzeroのRolldownとOxcが採用されている。
Viteの作者Evan You氏は、AIによる再実装コストの低下により、特定ユースケースに特化したオープンソースの派生版（tailored projections）が増加すると予測している。

Timeline

Rust製Vite開発サーバー「OJ」の概要と検証

OJは既存のViteプロジェクト上で設定やプラグインをそのまま引き継いで動作する1つのRustバイナリである。
ファイルウォッチャー、モジュールグラフ、HMR、React Fast Refreshなどの開発サーバー基盤がRustで再構築されている。
TanStack StartアプリではFast Refresh時に状態がリセットされる現象が発生する一方、通常のReactアプリでは状態が保持される。

OJはvoidzeroがメンテナンスするRolldownとOxcを基盤に採用している。TanStackアプリによる検証では、SSRやハイドレーション、サーバー関数、Tailwindなどの基本機能は正常に動作する。しかし、Fast Refresh処理において、通常のReactアプリではコンポーネント状態が保持されるものの、TanStack Startアプリではページ全体の更新が走りカウントがリセットされる差異が存在する。小規模アプリにおけるメモリ使用量はViteの約380MBに対しOJが約320MBと僅差にとどまる。

大規模アプリにおけるパフォーマンス比較とLovableのユースケース

5,000コンポーネント規模のテストでは、OJの通常モードがViteに対し描画完了まで約1.7倍高速で、メモリ使用量は約4分の1となる。
OJのバンドルモードでは描画時間が約0.89秒まで短縮され、Viteの約4分の1のメモリ使用量を維持する。
1日約100万個のサンドボックスを運用するLovableは、リソース効率化とAIエージェントの連続ファイル書き出し処理のためにOJを構築した。

大規模なReactアプリ環境においてOJはメモリ削減と起動速度の面で大きな優位性を示す。Vite 8.1の実験的機能である「bundled dev mode」は1.18秒とOJの通常モードを上回る速度を出すが、メモリ削減効果は得られない。LovableはAIエージェント特有の動作パターンに対応するため、連続するファイル保存を単一の更新に統合するパイプライン構造を採用し、処理完了まで更新を保留するゲート機能を実装している。

Evan You氏による見解とオープンソースの未来

OJはVite全体の書き換えではなく、特定環境向けの開発サーバー部分のみをRust化した実装である。
ベンチマーク内のViteにはvite-plugin-checkerが含まれていたため、処理をスキップしているOJとの単純比較には欠陥が存在する。
AI時代のオープンソース開発では、単一コンポーネントの制約に合わせた「用途特化型の派生版（tailored projections）」が増加する傾向にある。

Vite作者のEvan You氏は、OJがNodeプロセス上でRustを動かすViteとは異なり、Rustプロセス主導で動作している構造を指摘した。OJはReactアプリ専用に最適化されており、多様なフレームワークや外部プラグインに対応する汎用性を持つViteとは設計思想が異なる。AI技術によって再実装コストが激減した結果、メンテナーが大量の個別PRに対応する形態から、開発者が各々の目的に特化したフォークを維持する形態へ変化し、エコシステムの断片化が進む可能性が提示されている。

Community Posts

No posts yet. Be the first to write about this video!

Write about this video