Reactは本当に必要？業界で高まる批判的な声を総まとめ#
📖 読了時間の目安：約4〜5分
Reactはフロントエンド開発の「デファクトスタンダード」として長年君臨してきました。
しかし今、業界の各所からReactへの批判的な声が相次いでいます。
この記事では、海外の技術コミュニティで話題になっている議論をもとに、Reactに対する主要な懸念点を整理します。
この記事でわかること
- Reactが抱える主要な問題点（パフォーマンス・セキュリティ・複雑性）
- 業界で「React離れ」が起きているとされる背景
- 代替アプローチとして語られている考え方
- 新規プロジェクトでReactを選ぶ前に考えるべきこと
【結論】まず押さえたい重要ポイント3選#
① 深刻なセキュリティ脆弱性が報告された React Server Componentsに、認証不要のリモートコード実行を可能にする脆弱性（CVE-2025-55182）が報告されており、CVSSスコアは最大値の10.0とされています。
② 「とりあえずReact」という選択が技術的負債を生む 「みんな知っているから」という理由だけでReactが選ばれるケースが多く、技術的な適合性よりネットワーク効果がアーキテクチャを決めてしまっているという指摘があります。
③ JS重視のアプローチは長期的なパフォーマンス目標と相性が悪い JSヘビーなプロジェクトは、時間の経過とともに速度が低下し続ける傾向があり、開発・保守コストも想定以上にかかるという声があります。
Reactとは？基本概念の整理#
ReactはMeta（旧Facebook）が開発したUIライブラリで、コンポーネントベースの設計と仮想DOM（VDOM）を特徴としています。
長年にわたりフロントエンド開発の主流として使われてきましたが、その設計思想や運用実態に対して、近年さまざまな角度から疑問の声が上がっています。
Reactの主な批判ポイントと技術的問題#
🔴 ハイドレーションの「無駄」問題#
Reactのデフォルトのハイドレーションパターンについて、次のような皮肉が語られています。
- サーバー側でJavaScriptを使って計算する
- HTMLをすぐに配信する
- そして……サーバーにある同じJavaScriptをクライアントにも送り込む
この「二度手間」とも言える挙動が、パフォーマンス上の問題として指摘されています。
🔴 APIの複雑さとドキュメントの混乱#
ReactのAPIは設計が複雑であるとされており、正しい使い方がエンジニア間で常に議論の的になっているという声があります。
また、3年離れた後に戻ってきたとき、他のスタックなら問題なく作業を再開できるはずが、Reactエコシステムの変化が激しすぎてついていけないという体験談も報告されています。
🔴 モダンWebの機能との相性問題#
以下のような標準的なWeb機能がReactでは正常に動作しないケースが指摘されています。
autofocusの挙動が壊れている- カスタム要素（Custom Elements）が実験的バージョン以外では動かない
dialogやpopoverなどのモダンHTML要素にuseEffectが必要- 合成イベントシステムがDOMの実際の動作を学ぶ妨げになっている
ある開発者は「これはモダンUIではなく、2013年当時のUIだ」と表現しています。
🔴 後方互換性の名のもとにコードが壊れる#
Reactはアップデートのたびにコードが壊れることがあるという批判も存在します。
「後方互換性を保つという名目のもとで、誤った種類の後方互換性を実装し続けている」
という意見が、技術コミュニティで共有されています。
業界への影響：「Reactクライシス」は本当か？#
CTOたちの静かなReact離れ#
シリコンバレーの一部のCTOたちが、Reactから離れ始めているという報告があります。
その背景として挙げられているのは以下の点です。
- 本当にスキルのあるReact開発者は少なく、採用コストが高い
- 経験豊富なエンジニアが複雑さに嫌気を感じ、他技術を使う職場へ転職するケースが増えている
MicrosoftのEdgeブラウザの事例#
MicrosoftのEdgeチームが、ReactからWeb Components + HTMLファーストのアーキテクチャへ移行したことで、ユーザー体験が大きく改善したという事例が紹介されています。
特に、低速接続環境のユーザーへの恩恵が大きかったとされています。
Next.jsのVercelロックイン問題#
ReactのメジャーなフレームワークであるNext.jsについても、以下の懸念が語られています。
- Vercel（Next.jsの開発元）のサービス外では使いづらくなってきている
- 「オープンソースに見せかけたベンダーロックイン」という批判
- セキュリティ脆弱性の開示方法がコミュニティへの敬意を欠いていたという指摘
代替アプローチとして語られているもの#
React批判の文脈では、いくつかの代替的な考え方が紹介されています。
HTMLファーストとプログレッシブエンハンスメント#
「ベースラインのHTMLをJSが使えるときだけ段階的に強化する」というアプローチには、次のメリットがあるとされています。
- ユーザーが早い段階で使えるようになる
- 低速接続でもサイトが「使えないもの」にならない
- 何かが壊れても、基本機能は維持される
ネイティブDOM APIへの回帰#
ある開発チームがReactの仮想DOMからモダンDOM APIへ移行した結果、速度とインタラクションの即時改善が確認されたという報告もあります。
JavaScriptは「必要最小限」に#
「多くのインタラクションにJavaScriptは欠かせないが、だからといってJavaScriptを増やし続ける理由にはならない」という考え方も紹介されています。
Reactを選ぶ前に考えるべきこと：実用的な視点#
| チェックポイント | 内容 |
|---|---|
| 技術的な必要性 | 「みんなが知ってるから」ではなく、制約と要件に合っているか？ |
| パフォーマンス計画 | 長期的にJSヘビーな構成を維持できるか？ |
| チームのスキル | 本当に深く理解しているエンジニアがいるか？ |
| ベンダー依存 | Next.js採用時、Vercelへの依存をどう管理するか？ |
| セキュリティ体制 | 最新の脆弱性情報を追跡・対応できるか？ |
よくある質問（FAQ）#
Q. Reactを使ってはいけないということ？
ソース記事の立場は「Reactにも使いどころはある」としつつも、「ほぼ常に間違った選択になっている」という意見が紹介されています。「使ってはいけない」ではなく、本当に適切なケースかを問い直すことが重要だという主張です。
Q. 新規開発者はReactを学ぶべき？
ある記事では、「新規Web開発者がReactを避けることも選択肢として真剣に検討する価値がある。ただし短期的な就職市場での機会は減る可能性がある」と述べられています。
Q. React 19での改善はなかったの？
React 19に関連する変更について、公開後に多くの反発と議論が起き、一部変更が一時的に保留されたという経緯が紹介されています。詳細は元記事を参照してください。
Q. 「フレームワーク主義」とは何？
ソース記事では「frameworkism（フレームワーク主義）」という概念が紹介されており、「ユーザー体験を改善する方法はフレームワークのエコシステムに沿ったツールを増やすことだ」という考え方を指しています。これが実際のエンジニアリングではなく、それらしく見える作業になりがちだという批判です。
まとめ：押さえておくべき重要ポイント#
✅ CVSS 10.0の深刻な脆弱性（CVE-2025-55182）がReact Server Componentsに報告されている
✅ JSヘビーなアプローチは、長期的なパフォーマンスの劣化と開発・保守コストの増大につながりやすい
✅ 「とりあえずReact」という選択が、技術的適合性ではなくネットワーク効果によって行われている現状への批判が多い
✅ HTMLファーストやネイティブDOM APIへの回帰が、現実的な代替手段として語られている
✅ 熟練したReact開発者の確保は困難かつ高コストになってきているという報告がある
Reactを採用する際は「みんなが使っているから」ではなく、プロジェクトの要件・チームのスキル・長期的な保守性を総合的に判断することが重要です。
