さらばReact。DHHや主要OSSがReactを採用しない技術的な理由

Reactは長年にわたり、フロントエンド開発の中心的存在として扱われてきました。
求人市場、学習教材、UIライブラリ、周辺ツールの充実度を見ても、その影響力は明らかです。
しかし一方で、経験豊富な開発者や設計思想の強いOSSプロジェクトの中には、意図的にReactを採用しないという判断を下す例が少なくありません。
これは流行への逆張りでも、感情的なアンチでもなく、技術的な比較検討の結果です。

たとえば、Ruby on Railsの生みの親として知られるDHHは、React的なアプローチに距離を置き、HTML中心の設計やサーバー主導のUI更新を推進してきました。
また、近年注目される複数のOSSも、Reactを前提としない構成を選んでいます。
そこには「人気がある技術」と「長期的に保守しやすい技術」は必ずしも一致しない、という現実があります。

本記事では、Reactを使わない選択がなぜ成立するのかを、感覚論ではなく構造的に整理します。
具体的には、次のような論点を扱います。

• 状態管理の複雑化と責務分散の問題
• ビルド環境の肥大化と依存関係リスク
• サーバーサイド回帰が進む現在との相性
• 小規模〜中規模開発での過剰設計

Reactが優れた場面は確かに存在します。
しかし、すべての開発における最適解ではありません。
だからこそ今、「なぜ採用しないのか」を理解することには大きな価値があります。
この記事では、React神話をいったん脇に置き、現場の設計判断として冷静に検証していきます。

React一強の時代は終わったのか？主要OSSが採用しない現状

Reactは長年にわたり、フロントエンド開発の代表的選択肢として広く支持されてきました。
実際、求人市場、学習教材、コンポーネントライブラリ、周辺ツールの充実度を見れば、その影響力は依然として大きいです。
しかし、技術選定を現場の要件や長期運用の観点から見ると、「人気が高いこと」と「採用すべきこと」は同義ではありません。
ここ数年、主要なOSSや経験豊富な開発者コミュニティでは、Reactを標準前提としない設計も明確に増えています。

この変化は、Reactが劣った技術になったという意味ではありません。
むしろ、業界全体が成熟し、用途ごとに適切な道具を選ぶ段階へ移行した結果と捉えるべきです。
以前は「とりあえずReactを使う」が合理的だった場面でも、現在はサーバーサイドレンダリング、HTML主体の画面更新、軽量ライブラリ、Web Componentsなど、選択肢が大幅に増えました。
技術の多様化が進んだことで、一強構造が相対的に崩れているのです。

また、OSSの世界では企業開発とは異なる評価軸が存在します。
広告宣伝や採用市場の都合ではなく、限られた人数で長く維持できるか、更新コストが低いか、依存先の変化に振り回されないか、といった点が極めて重要になります。
その結果、Reactを使わない判断が増えるのは自然な流れです。

React人気と実運用での採用判断は別問題

Reactが人気である理由は明確です。
学習情報が多く、エンジニア採用でも経験者を見つけやすく、大規模UIの分割設計にも向いています。
企業が短期間でチームを組成し、一定品質で開発を進めるには合理的な選択肢です。
したがって、人気それ自体には十分な理由があります。

ただし、人気指標はそのまま実運用の最適解にはなりません。
たとえば、社内管理画面や小規模な予約フォーム、更新頻度の低いコーポレートサイトでは、Reactが提供する高度な抽象化を使い切れないケースがあります。
その場合、導入コストだけが残り、運用負荷が相対的に高くなることがあります。

技術選定では、少なくとも次の3点を分けて考える必要があります。

• 開発開始時の生産性
• 数年単位の保守コスト
• 参加メンバーの習熟難易度

Reactは一つ目では強い場面がありますが、二つ目と三つ目で常に優位とは限りません。
Hooks、状態管理、ビルド設定、フレームワーク連携など、理解すべき概念は少なくないためです。
初期実装が速く見えても、担当者交代や機能追加の段階で複雑さが表面化することは珍しくありません。

つまり、「多くの会社が使っているから安全」という判断は、技術的には不十分です。
安全性は採用数ではなく、対象プロジェクトとの適合性から評価されるべきです。

OSSメンテナーが重視するのは保守性と依存性

OSSメンテナーの視点では、華やかな開発体験よりも継続可能性が重要です。
個人または少人数で維持されるプロジェクトでは、半年後、一年後に無理なく更新できる設計こそ価値があります。
ここで大きな論点になるのが、保守性と依存性です。

React単体はライブラリですが、実運用では周辺技術との組み合わせが前提になりやすいです。
ルーティング、状態管理、ビルド、テスト、SSR対応など、複数のレイヤーが積み上がります。
すると、あるパッケージの破壊的変更が別の層へ波及し、メンテナーの負担が増大します。

以下は典型的な比較です。

観点	依存が多い構成	依存が少ない構成
更新作業	複数ライブラリ確認が必要	影響範囲が限定的
障害調査	切り分けが難しい	原因特定しやすい
新規参加	学習項目が多い	全体像を掴みやすい

OSSでは、利用者が多いほど問い合わせも増えます。
そのため、内部構造が単純で説明しやすいことは大きな利点です。
HTMLと少量のJavaScriptで成立する設計、あるいは標準API中心の構成が好まれるのは、この合理性によります。

さらに、外部依存が少ないほど、特定企業の方針変更やエコシステムの流行変化にも左右されにくくなります。
これはソフトウェア工学でいう結合度の問題です。
結合度が低いシステムほど変更に強く、寿命が長くなります。

したがって、主要OSSがReactを採用しない現状は、単なる好みではありません。
限られた資源で長く価値を提供するための、極めて現実的な設計判断なのです。

DHHがReactを選ばない理由：HotwireとHTML中心設計の思想

DHHがReactを積極採用しない理由を理解するには、単にフレームワークの好みとして捉えてはいけません。
そこには一貫した設計思想があります。
要点は、Webの本来の強みであるHTML、HTTP、サーバーサイドレンダリングを中心に据え、必要以上にクライアント側へ責務を移さないという姿勢です。
これは懐古主義ではなく、複雑性を制御するための工学的判断です。

近年のフロントエンド開発では、ブラウザ側で状態を保持し、画面遷移や描画更新まで担当する構成が一般化しました。
その結果、高度なUI体験を実現できる一方で、ビルド環境、状態同期、API設計、認証処理、キャッシュ整合性など、考慮すべき要素が急増しました。
DHHはこの流れに対し、問題を解決するために別の問題を増やしているケースがあると見ています。

Hotwireは、その代替案として位置づけられます。
HTMLをサーバーで生成し、その差分や断片をクライアントへ届けることで、JavaScriptアプリケーションを肥大化させずに高い操作性を実現しようとします。
重要なのは、画面を動的にすること自体ではなく、どこに責務を置くと保守しやすいかという視点です。

JavaScript肥大化よりサーバー主導UIを優先する考え方

React的な構成では、UIロジックの多くがクライアントへ集まります。
入力状態、一覧更新、画面遷移、非同期通信の管理などをブラウザで処理するため、アプリケーションとしての自由度は高まります。
しかし、自由度の上昇は同時に設計責任の増大を意味します。
状態遷移が増えれば、バグの発生点も増えます。
通信境界が増えれば、例外系の考慮も必要になります。

DHHが重視するのは、Webアプリケーションの多くはそこまで複雑なクライアント制御を必要としないという現実です。
たとえば、CRUD中心の業務システム、管理画面、掲示板、予約管理などでは、ユーザー操作に応じてHTMLを更新できれば十分な場面が少なくありません。
そこに大規模なSPA構成を持ち込むと、要求以上の複雑さを抱える可能性があります。

サーバー主導UIでは、業務ルールと表示ロジックを比較的近い場所に配置できます。
これにより、仕様変更時の追跡が容易になります。
たとえば価格計算ルールが変わった場合、APIとフロント双方の整合を取るより、サーバー側でHTML生成まで完結する方が変更点は明快です。

簡単な例を示します。

def create
  @task = Task.create!(task_params)
  render turbo_stream: turbo_stream.append("tasks", partial: "tasks/task", locals: { task: @task })
end

このように、作成後に更新すべきHTML断片を返すだけで、画面は自然に更新されます。
クライアント側で状態ストアを組み立てなくても、必要な体験は実現できます。
DHHの思想は、JavaScriptを否定することではなく、必要最小限に留めることにあります。

Railsとの統合で開発速度を高める利点

DHHの議論では、Hotwire単体よりRailsとの統合が本質です。
Railsは長年、設定より規約、同じ場所に同じ責務を置くという思想で設計されてきました。
モデル、ビュー、コントローラの役割が明確であり、プロジェクト構造にも一定の規律があります。
この規律が、開発速度と保守性を支えています。

Reactを別途導入する場合、フロントエンドとバックエンドの境界をどう切るかという新たな設計課題が発生します。
APIの形式、認証方式、型共有、デプロイ手順、テスト責務の分担など、決めるべきことが増えます。
高度なチームでは対応可能ですが、全案件で必要とは限りません。

RailsとHotwireを組み合わせると、同一アプリケーション内で画面、業務ロジック、データ永続化を一貫して扱えます。
これは変更要求への応答速度に直結します。
仕様変更があった際、単一リポジトリで完結しやすく、担当者間の調整コストも下がります。

下表は比較の要点です。

観点	Rails + Hotwire	API + React
初期構築	速い	設計項目が多い
変更対応	一体的に修正しやすい	層をまたぐ調整が必要
学習範囲	比較的集中する	周辺知識が広い

もちろん、複雑なリアルタイムUIや高度なクライアント体験が主役のサービスではReactが有力です。
しかし、すべての案件がその条件に当てはまるわけではありません。
DHHがReactを選ばない理由は、Reactに欠陥があるからではなく、より少ない複雑さで目的を達成できる場面が多いと見ているからです。
これは流行ではなく、コスト構造を見据えた合理的な判断です。

Reactの技術的課題① 状態管理が複雑化しやすい理由

Reactが高く評価される理由の一つは、UIを状態の写像として扱える点にあります。
状態が変われば画面が再描画されるというモデルは理解しやすく、宣言的UIの利点も大きいです。
しかし、実務でアプリケーション規模が拡大すると、問題は「状態という概念があること」ではなく、「どの状態を、どこで、誰が管理するのか」に移ります。
ここで設計を誤ると、コードベース全体の見通しが急速に悪化します。

小規模な画面では、入力フォームの値やモーダル開閉のような局所状態だけを扱えば十分です。
ところが、認証情報、フィルタ条件、ページネーション、APIキャッシュ、リアルタイム更新、楽観的UI更新などが加わると、状態の種類が増えます。
それぞれ性質が異なるため、単一の方法で綺麗に整理するのは容易ではありません。

React自体は柔軟であるがゆえに、状態管理の唯一解を強く規定しません。
この自由度は上級者には有利ですが、チーム開発では判断コストとして現れます。
結果として、同じプロジェクト内で複数流儀が混在し、長期保守時の負債になることがあります。

useState・Context・外部ストアの選択コスト

Reactで状態を扱う手段は複数あります。
代表例はuseState、Context、そしてZustandやReduxのような外部ストアです。
どれも有効な道具ですが、問題は「どれを使うべきか」が要件依存であり、初見での判断が難しい点です。

たとえば、フォーム入力のような局所状態ならuseStateで十分です。
一方、複数階層で共有するテーマ設定やユーザー情報はContextが候補になります。
しかし、更新頻度が高い一覧データや複雑な非同期状態は、外部ストアの方が扱いやすい場合があります。
ここで迷いが生じます。

手法	向いている用途	注意点
useState	単一コンポーネント内の状態	共有が増えると辛い
Context	広域共有設定	再描画設計に注意
外部ストア	複雑な共有状態	学習コストが増える

理論上は適材適所ですが、現場では境界が曖昧です。
ある画面ではuseStateで始めたものの、後から共有要件が増えてContextへ移行し、さらに非同期更新の都合で外部ストアへ再移行する、といった変遷も珍しくありません。
これはツールの欠陥ではなく、アプリケーションの成長に対して初期設計が追いつかないことに起因します。

簡単な例でも、判断の違いはすぐ表れます。

const [user, setUser] = useState(null)

このuserがローカル状態なのか、全体共有なのか、キャッシュ対象なのかで最適解は変わります。
コード1行の背後に、設計上の分岐が存在しているわけです。

責務分散で追跡しづらくなるデータフロー

状態管理が難しくなる本質は、責務が複数箇所へ分散しやすいことです。
Reactアプリでは、UI部品、カスタムフック、Context Provider、APIクライアント、外部ストア、ルーターなど、状態に関与する場所が増えます。
すると、ある値が「どこで作られ、どこで変更され、何に影響するのか」を追跡するコストが上がります。

たとえば、検索画面で一覧が更新されない不具合が起きたとします。
原因候補は入力状態、debounce処理、URLクエリ同期、キャッシュ無効化、フェッチ失敗、描画条件のいずれにもあり得ます。
単純な表示バグでも、複数レイヤーを横断して調査する必要があります。

この問題は、関数型UIの採用そのものより、責務境界が増えることに起因します。
抽象化は局所的には便利でも、全体像を見えにくくする場合があります。
特に担当者交代時、新規参加者はコードの文法より先に、データの流れを理解しなければなりません。

以下のような構造は典型例です。

• 入力値はコンポーネントのstate
• 認証情報はContext
• 商品一覧は外部ストア
• URL条件はルーター管理
• 通信結果はキャッシュライブラリ管理

それぞれ合理的でも、全体では理解対象が分散します。
システム設計では、局所最適の積み重ねが全体最適になるとは限りません。

したがって、Reactの状態管理が複雑化しやすい理由は、Hooksが難しいからでも、ライブラリが多すぎるからでもありません。
複数の正解が存在し、責務配置の判断を開発者へ委ねる設計だからです。
自由度は強力ですが、同時に設計能力を要求します。
そこにReactの魅力と難しさが同居しているのです。

Reactの技術的課題② ビルド環境と依存関係の肥大化

ReactそのものはUIライブラリであり、単体で見れば比較的明快な設計です。
しかし、実務でReactを採用する際、実際に向き合う対象はReact単体ではありません。
開発サーバー、モジュール解決、トランスパイル、最適化、テスト、Lint、型検査、デプロイ設定など、多数の周辺要素を含んだエコシステム全体です。
ここにReact採用の本質的なコストがあります。

現代のWeb開発では、単純なHTMLとJavaScriptファイルをそのまま配置するだけでは済まない場面が増えました。
コンポーネント分割、ES Modules、TypeScript、CSS Modules、画像最適化、コード分割などを効率よく扱うには、ビルド工程が必要です。
Reactはその恩恵を強く受ける一方で、ツールチェーンへの依存度も高くなります。

小規模な個人開発では便利でも、長期運用や企業環境では話が変わります。
ツールの更新周期、破壊的変更、CI環境との整合、チームメンバー間のローカル差異など、アプリ本体以外の管理負荷が無視できなくなります。
ソフトウェア工学の観点では、機能要求とは別に運用複雑性が増えている状態です。

Vite・Webpack・Babelが必要になる背景

React開発でViteやWebpack、Babelといった名前が頻繁に登場するのは偶然ではありません。
Reactの開発体験を高めるために、ブラウザがそのまま理解できない構文や、配布に適した形への変換が必要になるからです。

JSXは代表例です。
次のような記述は読みやすく強力ですが、そのままでは多くの実行環境で直接扱えません。

function App() {
  return <h1>Hello</h1>
}

このコードはJavaScriptへ変換される必要があります。
Babelはその変換を担い、WebpackやViteは依存関係を束ね、開発サーバーや本番ビルドを担当します。
役割分担としては合理的です。
しかし、開発者が学ぶべき対象はReact APIだけではなくなります。

下表のように、各ツールには別々の責務があります。

ツール	主な役割	現場での論点
Babel	構文変換	設定の理解が必要
Webpack	バンドルと最適化	設定が複雑化しやすい
Vite	高速開発環境とビルド	プラグイン依存が増える

現在はViteの普及で以前より簡単になりました。
それでも、背後にある仕組みが消えたわけではありません。
トラブル時には設定、依存バージョン、プラグイン挙動を確認する必要があります。
抽象化は普段の利便性を上げますが、障害時には内部理解が要求されます。

node_modules問題とサプライチェーンリスク

React周辺のもう一つの論点は、依存パッケージの増加です。
npmエコシステムは非常に活発で、多様な課題に対して即座にライブラリが見つかります。
これは大きな利点です。
一方で、依存が多い構成は別種のリスクを生みます。

典型例がnode_modulesの肥大化です。
アプリ側では数個のライブラリしか追加していないつもりでも、それらがさらに多数の依存を持つため、実際には数百から数千単位のパッケージがインストールされることがあります。
容量の問題だけではなく、調査対象が増える点が本質です。

ある日ビルドが失敗したとして、原因が自分のコードなのか、間接依存の更新なのか、OS差異なのかを切り分けるには時間がかかります。
再現性確保のためlockfile管理やCI固定化が重要になるのは、このためです。

さらに見逃せないのがサプライチェーンリスクです。
外部パッケージは便利ですが、保守停止、乗っ取り、悪意ある更新、品質低下の可能性をゼロにはできません。
実際、広く使われるエコシステムほど攻撃対象になりやすい傾向があります。

論点	発生要因	影響
肥大化	多層依存	セットアップ遅延
障害調査	間接依存の不具合	復旧時間増加
セキュリティ	外部供給網への依存	情報漏えい・改ざん懸念

もちろん、これはReact固有の欠陥ではなく、現代JavaScript開発全般の構造的課題です。
ただしReactは巨大な周辺エコシステムと共に使われることが多いため、その影響を受けやすい立場にあります。

したがって、ビルド環境と依存関係の肥大化とは、単にセットアップが面倒という話ではありません。
開発速度、保守コスト、障害対応力、セキュリティ体制まで含めた総合的な設計問題です。
Reactを選ぶ際には、UIの書きやすさだけでなく、その背後で運用する仕組み全体まで評価する必要があります。

Reactの技術的課題③ サーバーサイド回帰との相性

Reactはクライアントサイドレンダリングを広く普及させた代表的存在です。
ブラウザ上で状態を保持し、画面を書き換え、アプリケーションのような操作感を実現する思想は、多くのWebサービスに革新をもたらしました。
しかし、技術の進化は直線的ではありません。
一定期間を経て、業界全体は再びサーバーサイドの価値を見直し始めています。
ここで重要なのは、昔に戻ることではなく、どこで処理するのが合理的かを再評価している点です。

初期表示速度、SEO、認証との整合、キャッシュ戦略、運用コストといった観点から、すべてをクライアントへ寄せる設計が常に最適とは言えないことが明らかになってきました。
その結果、SSR、MPA、HTML over the wireといったアプローチが再注目されています。
React自身もServer ComponentsやSSR系フレームワークを発展させていることから、この潮流は一時的なものではありません。

問題は、Reactが悪いことではなく、Reactが広めたCSR中心の設計を前提にすると、別の最適解を取りにくい場面があることです。
特に小中規模開発では、その差が顕著になります。

SSR・MPA・HTML over the wireの再評価

SSRは、サーバー側でHTMLを生成して返す方式です。
ユーザーはJavaScriptの初期実行を待たずに内容を確認しやすく、検索エンジンにも情報を渡しやすい利点があります。
MPAはページ単位で遷移する古典的な構成ですが、現在では部分更新やプリフェッチ技術と組み合わせることで、十分に快適な体験を提供できます。

HTML over the wireは、画面更新に必要なHTML断片をサーバーから送る発想です。
JSON APIとクライアントテンプレートを経由せず、表示結果そのものを届けるため、責務分担が明快になります。
これは単純化という意味で非常に強い設計です。

下表は各方式の整理です。

方式	主な描画場所	強み	注意点
CSR	ブラウザ	高い対話性	初期負荷が増えやすい
SSR	サーバー	初期表示とSEO	サーバー負荷設計が必要
MPA	サーバー中心	構成が明快	遷移体験の工夫が必要
HTML over the wire	サーバー中心	実装責務が単純	高度UIは設計工夫が必要

ここで注目すべきは、近年のネットワーク速度やブラウザ性能向上により、MPAやSSRの弱点だった体感速度がかなり改善された点です。
過去にはCSRでなければ得られなかった快適さが、別方式でも実現しやすくなりました。
技術条件が変われば、合理的な選択も変わります。

小中規模開発ではCSRが過剰になるケース

CSRの強みは、複雑な画面状態を長時間維持しながら高頻度で操作するアプリケーションにあります。
たとえばリアルタイムダッシュボード、デザインツール、複雑な管理コンソールなどでは大きな価値があります。
しかし、すべての案件がその性質を持つわけではありません。

小中規模開発では、画面数が限られ、業務フローも単純なことが多いです。
問い合わせフォーム、予約管理、記事一覧、会員情報変更、簡易ECなどは典型例です。
この種の要件では、ページ遷移やフォーム送信が中心であり、常時複雑なクライアント状態を保持する必要は高くありません。

それにもかかわらずCSR前提で設計すると、API設計、認証連携、ローディング管理、エラー状態管理、ルーティング、ビルド環境整備など、問題領域が不必要に増えることがあります。
機能要求は小さいのに、実装責務だけが大きくなる構図です。

たとえば住所変更画面一つでも、CSRでは入力状態、送信中状態、成功通知、失敗時再試行、画面遷移後の再取得などを個別に扱います。
サーバー主導構成なら、フォーム送信とレスポンスでかなりの部分を自然に処理できます。
どちらが優れているかではなく、問題の大きさに対して道具が過大でないかが論点です。

ソフトウェア設計では、将来拡張性を理由に過剰な抽象化を入れすぎると、現在の開発速度を損ないます。
しかも将来その拡張が来ないことも珍しくありません。
小中規模案件でCSRが過剰になるとは、まさにこの現象です。

したがって、サーバーサイド回帰との相性という論点は、Reactを否定する話ではありません。
クライアント中心設計が適切な案件も多く存在します。
ただし、近年はサーバー中心の選択肢が再び現実的かつ強力になっています。
だからこそ、Reactを自動的に選ぶのではなく、要件の複雑さと責務配置の釣り合いから判断する姿勢が重要です。

Reactを使わない主要OSSと代替技術の選択肢

Reactを採用しないという判断は、何も「フロントエンドを捨てる」という意味ではありません。
実際には、別の思想を持つ技術を選ぶことで、要件に対してより適した構成を実現しようとする動きです。
近年のOSSコミュニティでは、React一択ではなく、用途別に複数の選択肢を使い分ける傾向が強まっています。
これは市場が成熟した証拠でもあります。

重要なのは、フレームワークの優劣を単純比較しないことです。
UI更新頻度、チーム規模、学習コスト、既存バックエンドとの統合性、長期保守性など、判断軸は複数あります。
Reactが最適な案件もあれば、より軽量な仕組みの方が合理的な案件もあります。
主要OSSがReact以外を選ぶ背景には、この現実的な最適化があります。

また、代替技術は単なる「軽いReact風ツール」ではありません。
それぞれが異なる設計哲学を持ち、複雑さの置き場所も異なります。
ここを理解せずに比較すると、本質を見誤ります。

Svelte・Vue・Alpine.js・Stimulusは何が違うのか

Svelte、Vue、Alpine.js、Stimulusは同じフロントエンド領域に属しながら、問題解決のアプローチが大きく異なります。
Reactの代用品として一括りにすると、かえって選定を誤ります。

Svelteは、実行時ライブラリへ依存しすぎず、コンパイル時に最適化する思想が特徴です。
ブラウザで余計な抽象レイヤーを減らし、少ないコード量で高い体験を目指します。
Vueはテンプレート構文とリアクティブシステムのバランスが良く、段階導入しやすい点が強みです。
既存HTMLへ部分的に組み込むことも比較的容易です。

Alpine.jsは、HTML属性の拡張で軽い動きを加える発想です。
モーダル開閉やタブ切替のような小規模インタラクションに向いています。
Stimulusは、HTMLを主役に据え、JavaScriptは振る舞いを添える役割に限定します。
RailsやHotwireとの相性が良く、サーバー主導設計と親和性があります。

技術	主な思想	向いている用途	複雑さの位置
Svelte	コンパイル最適化	高速UI・中規模SPA	ビルド時
Vue	バランス型	幅広いWeb開発	フレームワーク内
Alpine.js	HTML拡張	小規模UI改善	最小限
Stimulus	HTML中心	サーバー連携型UI	サーバー寄り

この比較から分かる通り、何を選ぶべきかは「どれが人気か」では決まりません。
どこに複雑さを置くか、どこまで抽象化が必要かで決まります。
Reactを選ばないOSSが増えるのは、代替案が十分に成熟したからでもあります。

Vanilla JavaScript回帰が成立する条件

近年、あえてフレームワークを使わず、Vanilla JavaScriptへ戻る流れも一部で見られます。
これは過去への逆行ではありません。
ブラウザ標準APIが大幅に進化したことで、以前ならライブラリ必須だった機能を素のJavaScriptで実装しやすくなったためです。

たとえば、querySelector、fetch、classList、template、Custom Elements、ES Modulesなど、現代ブラウザには十分に強力な機能があります。
簡単な動的UIであれば、少量のコードで実現できます。

document.querySelector("#open").addEventListener("click", () => {
  document.querySelector("#modal").hidden = false
})

この程度の処理に巨大な依存関係は不要です。
学習対象も少なく、デバッグも直接的です。
特にランディングページ、管理画面の一部機能、社内ツール、埋め込みウィジェットでは有効です。

ただし、Vanilla JavaScriptが常に優れているわけではありません。
状態共有、画面遷移、複数人開発、大規模UI設計が必要になると、規律あるフレームワークの価値が上がります。
つまり、成立条件があります。
要件が限定的で、画面構造が比較的単純であり、長期的な機能拡張が大規模でない場合です。

Vanilla回帰の本質は、「ライブラリを減らすこと」ではなく、「必要な抽象化だけを採用すること」です。
過剰な道具を避け、問題のサイズに見合った実装を選ぶ姿勢と言い換えてもよいでしょう。

したがって、Reactを使わない主要OSSの選択肢は十分に存在します。
SvelteやVueのような包括的な選択肢もあれば、Alpine.jsやStimulusのような局所最適もあり、場合によってはVanilla JavaScriptも成立します。
重要なのは宗教的な支持ではなく、要求仕様に対して最も小さな複雑さで目的を達成できる技術を選ぶことです。

Reactを採用すべきプロジェクト、避けるべきプロジェクト

Reactに対する議論では、優れているか、時代遅れか、といった二項対立になりがちです。
しかし、技術選定は本来そのような単純な話ではありません。
重要なのは、Reactが強い問題領域と、別の選択肢の方が合理的な問題領域を切り分けることです。
どれほど優秀な道具でも、対象が変われば評価軸も変わります。

Reactは汎用性が高く、巨大なエコシステムを持ち、多人数開発にも耐えやすい設計資産があります。
一方で、その柔軟さを活かせない案件では、学習コストや構成コストが先に立つことがあります。
したがって、「Reactを使うべきか」という問いに普遍的な答えはありません。
「この案件にReactは必要か」と問い直すことが重要です。

ソフトウェア工学では、設計の価値は抽象的な美しさではなく、制約条件の中で目的を達成できるかで決まります。
Reactの採否も同じです。
チーム構成、変更頻度、UI複雑度、運用期間、採用市場まで含めて判断すべきです。

大規模SPAでReactが強いケース

Reactが真価を発揮しやすいのは、大規模なSPAです。
画面遷移を頻繁に行いながら、状態を保持し、複雑な操作を連続的に提供するアプリケーションでは、コンポーネント指向と宣言的UIが強く機能します。

たとえば、SaaS型ダッシュボード、分析画面、デザインツール、プロジェクト管理ツール、リアルタイム監視画面などは典型例です。
これらは単なるページ表示ではなく、アプリケーションそのものとして振る舞います。
ドラッグ操作、複数ペイン同期、フィルタ状態保持、部分更新、リアルタイム反映など、クライアント側の責務が大きい領域です。

この種の案件では、Reactの分割可能なUI構造が有効です。
画面を独立した部品へ分解し、状態変化に応じて再描画するモデルは、機能追加やチーム分業と相性が良いです。
周辺ライブラリも豊富で、要件に応じた拡張がしやすい点も利点です。

以下の条件が揃うなら、Reactは有力候補です。

• 長期間にわたり継続開発する
• 画面操作が複雑で状態が多い
• 複数人で並行開発する
• UI品質が競争力になる

つまり、Reactは「複雑さを管理するためのコストを払う価値がある案件」で強いのです。
初期コストより将来の拡張性が重要な場合、その投資は十分に回収されます。

要件が明快ならシンプル構成が勝つケース

一方で、要件が明快で、業務フローが単純な案件では、Reactの利点が相対的に小さくなります。
ここでいう明快とは、入力して送信する、一覧を見る、編集する、確認して完了する、といった処理の流れが予測可能である状態です。

たとえば、予約フォーム、社内申請画面、商品紹介サイト、イベント申込ページ、会員情報変更画面などはその代表例です。
これらは利用者にとって重要なサービスですが、クライアント側で巨大な状態機械を持つ必要はないことが多いです。

その場合、サーバーサイドレンダリング、MPA、軽量ライブラリ、あるいは素のJavaScriptで十分な成果を得られます。
構成が単純であるほど、引き継ぎや障害対応も容易になります。
将来の担当者がReact経験者である保証はありませんが、HTMLと標準的なサーバー構成は長く理解されやすい資産です。

観点	React構成	シンプル構成
初期セットアップ	やや重い	速い
学習コスト	高め	低め
高度UI対応	強い	限定的
保守の直感性	設計次第	高い

ここで注意すべきは、シンプル構成は妥協案ではないという点です。
問題が単純なら、解法も単純であるべきです。
過剰な抽象化を避けることは、むしろ優れた設計判断です。

Reactを避けるべきプロジェクトとは、Reactが悪い案件ではなく、Reactが持つ強みを使い切れない案件です。
逆に、Reactを採用すべきプロジェクトとは、UIの複雑さと継続開発の要求が高く、その抽象化コストに見合う案件です。
結論として、技術選定で最も重要なのは流行への同調ではなく、要件の複雑さと道具の重さを釣り合わせることです。

学習・開発体験を高める周辺サービスとツールの活用法

フロントエンド開発において、技術選定そのものと同じくらい重要なのが開発体験の最適化です。
特にReactのようにエコシステムが広く、抽象化レイヤーが多い技術では、理解速度と検証速度が生産性に直結します。
つまり、フレームワーク単体ではなく、それを取り巻くツール群まで含めて開発環境を設計する必要があります。

現代の開発は、コードを書く時間よりも「理解する時間」「検証する時間」の比率が増えています。
そのため、エディタ、補助AI、ドキュメントアクセス、そしてソースコードの読み解き能力が重要になります。
これらは単なる便利機能ではなく、設計判断の精度を左右する要素です。

VSCode・Cursor・GitHub Copilotで検証速度を上げる

VSCodeは事実上の標準エディタとして広く使われていますが、その価値は単なるコード編集機能にとどまりません。
拡張機能エコシステムによって、リンター、型チェック、デバッガ、Git統合などが統合され、開発環境全体を一つのツールとして扱える点にあります。

近年ではCursorのようなAI統合型エディタが登場し、コード生成と編集の境界が曖昧になりつつあります。
またGitHub Copilotは補完というより、仮説生成装置として機能するようになっています。
これにより、実装速度だけでなく、設計の試行錯誤速度も向上します。

たとえばReactコンポーネントの設計では、単純なUI生成よりも状態設計や副作用の分離が問題になります。
Copilotを用いることで、複数の実装パターンを短時間で試すことができ、設計比較が容易になります。

function useFetch(url: string) {
  const [data, setData] = useState(null)
  useEffect(() => {
    fetch(url)
      .then(res => res.json())
      .then(setData)
  }, [url])
  return data
}

このようなフックも、AI支援を使えば改善案や代替設計を即座に得ることができ、検証サイクルが短縮されます。
重要なのは、正解を得ることではなく、複数案を短時間で評価できる環境を持つことです。

公式ドキュメントとOSSコードリーディングの重要性

一方で、AIツールや補助機能だけに依存することは危険です。
最終的な設計判断の根拠は、公式ドキュメントと実装コードにあります。
特にReactのような成熟したOSSでは、仕様の背景や設計意図がドキュメントに明確に記載されています。

公式ドキュメントは単なるAPIリファレンスではなく、設計思想の説明書でもあります。
例えばHooksの導入理由やレンダリングモデルの設計は、表面的な使い方だけでは理解できません。
ここを正しく理解しないと、誤った抽象化や過剰な設計につながります。

さらに重要なのがOSSコードリーディングです。
実際のライブラリ実装を見ることで、抽象化の限界や設計トレードオフを理解できます。
React本体のコードは決して読みやすいとは言えませんが、それ自体が設計の結果です。

たとえばレンダリング処理の一部を追うことで、なぜ再レンダリングが発生するのか、どのタイミングで差分計算が行われるのかが理解できます。
これはドキュメントだけでは得られない情報です。

情報源	役割	得られる価値
公式ドキュメント	正式仕様	設計思想の理解
OSSコード	実装詳細	挙動の根拠理解
AIツール	補助生成	仮説と比較

結局のところ、開発体験を高めるとは、ツールを増やすことではなく、理解までの距離を短くすることです。
VSCodeやAI支援はその加速装置であり、ドキュメントとソースコードはその基盤です。
この両者をバランスよく使うことで、Reactのような複雑な技術スタックでも、設計判断の精度を維持することができます。

さらばReactとは何を意味するのか：技術選定を目的から考えよう

「さらばReact」という表現は、Reactという技術そのものを否定する言葉ではありません。
むしろこれは、フロントエンド開発における技術選定の意思決定プロセスを再定義しようとする姿勢を象徴しています。
長年Reactはデファクトスタンダードとして扱われ、多くのプロジェクトで「とりあえずReactを使う」という選択が合理的とされてきました。
しかし、技術環境が成熟した現在、その前提は必ずしも成立しなくなっています。

重要なのは、技術を中心に設計を考えるのではなく、目的を中心に技術を選ぶという発想です。
これはソフトウェア工学における基本原則ですが、実務ではしばしば逆転します。
特定のフレームワークを前提に設計を開始すると、そのフレームワークの制約や思想に引きずられ、結果として過剰な複雑性や不要な抽象化が生まれることがあります。

Reactは非常に優れたツールです。
しかし、それは万能ではありません。
コンポーネント指向、仮想DOM、豊富なエコシステムは大規模UIにおいて強力ですが、すべてのWebアプリケーションがその複雑さを必要とするわけではありません。
むしろ、多くの業務システムやコンテンツ中心のWebサイトでは、より単純な構成の方が合理的である場合が少なくありません。

ここで問題となるのは、技術選定が目的ではなく手段であるという基本認識が薄れやすい点です。
開発者コミュニティや求人市場の影響により、「使われているから採用する」という意思決定が起こりがちですが、それは本来の設計思考とは異なります。
目的から逆算した設計ではなく、技術から目的を合わせにいく設計は、長期的な保守性や理解容易性を損なう可能性があります。

技術選定を目的から考えるということは、まず以下のような観点を明確にすることを意味します。

• UIの複雑さはどの程度か
• 状態管理の寿命はどれくらいか
• チーム規模とスキル分布はどうなっているか
• 将来的な拡張はどの程度見込まれるか

これらの要件を整理した上で、初めてReactが適切かどうかを判断すべきです。
逆に言えば、これらの要件がシンプルであれば、Reactは過剰な選択肢となる可能性があります。

例えば、単純なフォーム送信と一覧表示が中心のシステムであれば、サーバーサイドレンダリングやMPA構成、あるいは軽量なテンプレートエンジンで十分成立します。
その場合、Reactの導入は初期構築コストや依存関係の増加という形で負担になることがあります。

一方で、複雑な状態遷移を持つダッシュボードやリアルタイム更新が必要なアプリケーションでは、Reactのコンポーネントモデルと再レンダリング制御は非常に有効です。
このように、技術の適否は常に文脈依存です。

また、技術選定の議論では「学習コスト」と「運用コスト」が混同されがちです。
Reactは学習コストが中程度以上ある一方で、適切に設計された場合の運用コストは低く抑えられることがあります。
しかし、設計が不適切な場合、その逆転現象が起きることもあります。
つまり、初期の学習難易度だけで判断することは合理的ではありません。

さらに重要なのは、エコシステム依存の問題です。
Reactは周辺ツールが非常に豊富である反面、それらを適切に選択しなければ構成が複雑化します。
状態管理ライブラリ、ルーティング、ビルドツール、テスト環境などが組み合わさることで、システム全体の理解コストが上昇することがあります。

このような背景を踏まえると、「さらばReact」とは単なる脱React宣言ではなく、「技術を中心に据える思考からの脱却」を意味します。
つまり、フレームワークを出発点にするのではなく、問題領域を出発点にする設計思想への回帰です。

最終的に重要なのは、特定の技術を使うことではなく、問題を最も単純な構造で解決することです。
その結果としてReactが選ばれることもあれば、選ばれないこともあります。
この柔軟な判断こそが、現代のフロントエンド開発において求められる成熟した技術選定の姿勢だと言えます。