React のビルド周りで、かなり実務的な変化が起きています。Master.dev の記事は、React Compiler の Rust 版を使うように切り替えたら、コンパイル部分が一気に速くなり、しかも今まで引っかかっていた制限も少しずつ解消されてきた、と伝えています。単なるベンチマークの自慢ではなく、CI の待ち時間や設定の複雑さに直結する話なので、フロントエンドを日々触る人にはかなり刺さる内容です。特に React Router や Vite を使っているチームは、実際の移行手順まで含めて気になるはずです。
記事を書いた開発者は、Outlyne というウェブサイトビルダーの 1,036 ファイルからなる React Router のコードベースを、oxc チームが 2026 年 8 月 4 日に公式対応を出した Rust 版 React Compiler に切り替えたと説明しています。そこで得られたのは、コンパイラ部分だけで約 17.6 倍の高速化でした。Babel ベースのコンパイラでは 14.3 秒かかっていたものが、Rust 版では 0.81 秒になったそうです。
ただし、これはビルド全体の話ではありません。あくまで compiler の部分だけが大きく速くなったので、全体のビルド時間はそこまで劇的には縮まりませんでした。それでも、このケースでは 22.1 秒から 9.3 秒へと、ビルド全体でも約 2.4 倍速くなっています。開発者は、AI 支援のソフトウェア開発で変更回数が増えた今、CI の実行コストや GitHub Actions の分数が無視できないと述べています。待ち時間が短くなるだけでなく、費用面でも効いてくる、という見方です。
記事のもう一つの焦点は、Rust 版になったことで React Compiler の制限が減ったことです。v1.0 の Babel ベースの React Compiler では、try/catch の中での条件分岐があるコードなどが大きな障害になっていましたが、新しい版ではそうした JavaScript の書き方に対する対応が進んでいます。例として、try/catch 内の分岐、分割代入した props を再代入してネストした closure で使う形、computed object property keys を使う形が挙げられていました。著者のアプリでは、この改善でさらに 7 関数が compiler 対象になったそうです。内訳は try/catch の改善で 5 関数、computed object property keys で 2 関数です。
もちろん、まだ完全ではありません。記事では、try ブロックの中で throw するケースや、??=、&&=、||= といった logical assignment operators は、いまも compiler が component や hook を飛ばす要因になるとしています。ただ、Rust 版に移れば、今後それらの制限が解消されたときに自動で取り込める。Babel ベースの “行き止まり” に残るより、そのほうが先がある、というのが著者の主張です。
さらに重要なのが、lint と build で同じ React Compiler を使えるようになった点です。著者は以前、Oxlint の React Compiler 対応を先に導入したものの、build 側は古い版のままだったため、ある最適化漏れを lint の不整合だと誤解し、oxc に誤った issue を出してしまったと振り返っています。原因は、lint 側が oxc-transform-react v0.145.0 を使っていた一方で、build 側は v0.144.0 だったことでした。今は両方とも同じ compiler を使うので、lint では通ったのに production build では最適化されない、という穴を気にしなくてよくなったと説明しています。
最後には移行手順も示されています。Vite v8 以降で @vitejs/plugin-react を使っているなら、@rolldown/plugin-babel を入れて Babel ベースの設定をしていたものをやめ、oxc-transform-react を入れて react({ compiler: true }) と書けばよい。React Router の framework mode のように @vitejs/plugin-react を使わない構成では、vite-plugin-babel、babel-plugin-react-compiler、@babel/preset-typescript を外して、@acusti/vite-plugin-react-compiler に置き換える流れです。著者はこれを「より簡単で、より速く、より高機能」とまとめています。
この記事でいちばん面白いのは、単に「Rust だから速い」で終わっていないところです。もちろん 0.81 秒という数字は派手ですが、実務ではその手前にある「設定がどれだけ散らかるか」のほうが効く場面が多いと思います。Babel、lint、build、TypeScript の組み合わせが少しでもずれると、見た目は同じコードでも挙動が変わる。開発者が誤った issue を出してしまった話は、その痛みをかなり正直に表しています。高速化よりも、こうした齟齬を減らせることのほうがチーム運用では価値が大きいのではないでしょうか。
React Compiler は、昔から「適用できるコードが限られる」ことが実用上の壁でした。だから多くの人は、性能が出るかどうか以前に「自分のコードが対象になるのか」を気にしていたはずです。今回の記事が効いているのは、Rust 版への移行がその不安を少しずつ減らす方向にある、と具体例つきで示している点です。try/catch、再代入、computed key みたいな細かい構文の差で最適化が外れるのは、地味だけれど現場では本当に面倒です。そこが狭まるほど、導入判断はしやすくなる。
著者が CI の分数と GitHub Actions の待ち時間を強く気にしているのは、かなり現代的です。AI 支援でコード変更が増えると、1 回の変更の重みは軽くなる一方で、検証の回数は増えます。すると、ビルドが数十秒短くなるだけでも、積み上げるとかなり違う。個々の開発者の体感としては「ちょっと待つ」程度でも、チーム全体では時間とお金が削られる。Rust 版 React Compiler の価値は、そこにあります。
ただし、ここは誤解しやすいところでもあります。記事自身がはっきり書いているように、17.6 倍速くなったのは compiler 部分だけです。全体のビルドが同じ倍率で縮むわけではない。だから「React Compiler を Rust 化すれば全部が爆速になる」と読むのは早計です。とはいえ、build のボトルネックが複数ある現場では、ひとつでも重い層が軽くなる意味は大きい。特にフロントエンドのビルドは、依存関係や変換段数が増えるほど遅くなりがちなので、こういう局所的な改善でも十分に歓迎されるはずです。
記事の語気が少し強くなるのは、Babel ベースの compiler を「dead-end」と呼んでいる部分です。これは少し挑発的ですが、言いたいことは分かります。Babel 版は現時点で使えるとしても、今後の修正や拡張は Rust 版に集まる。つまり、今の制限に我慢しながら旧版に留まるより、早めに Rust 版へ寄せたほうが、将来の改善をそのまま受け取れる。ツールチェーンの世界では、この差はかなり大きいです。
この視点は、単に React Compiler だけの話ではありません。周辺ツールが徐々に同じ土台へ寄っていくと、開発者は「どれが正しい挙動か」を毎回考えなくてよくなる。lint が見ているもの、build が見ているもの、実際に production に出るものが一致している状態は、それだけで安心感があります。逆にそこがずれると、見逃しも誤検知も増える。著者が「coverage gaps」と表現しているのは、まさにその穴のことです。性能の話に見せかけて、実は運用の信頼性の話でもある。そこがこの文章の芯だと思います。
最後に触れておきたいのは、移行方法がかなり素直だという点です。Vite v8+ で @vitejs/plugin-react を使っているなら、設定を足すのではなく、むしろ Babel 関連を削って compiler: true を付ける方向です。React Router の framework mode でも、複数の Babel パッケージを抱える形から @acusti/vite-plugin-react-compiler へ整理できる。新機能の導入というより、設定の整理として見えるのが良いところです。
こういう変化は、派手さはなくても強いです。導入が面倒だと、どんなに速くても現場では広がりません。逆に、今ある構成を少し削るだけで済むなら、試してみる心理的コストが低い。今回の記事が伝えているのは、Rust 版 React Compiler は単なる性能改善ではなく、設定の簡素化、lint と build の一致、将来の拡張性までまとめて取りにいける移行先だ、ということだと思います。少なくとも、React と Vite を使うチームにとっては、かなり現実的な選択肢になってきたと感じます。
