Reactはデフォルトとして勝っているが、フロントエンドの革新を遅らせている
(lorenstew.art)- 今日では React の採用は技術的優位ではなくデフォルトとして行われており、これはフロントエンド生態系の革新を鈍らせている
- 多くのチームが制約条件を検討せずに「みんなが知っている React」を選ぶことで、ネットワーク効果が技術的適合性よりもアーキテクチャの意思決定を左右する状況になっている
- Svelte、Solid、Qwik のような革新的なフレームワークは、より優れた性能モデルを提供するが、採用率不足のため主流競争で押し出されている
- React には優れた点が多いが、問題は React をデフォルトとする思考様式が機会費用を増やし、より良い代替案を検討する余地を塞いでいることにある
- 健全な生態系には多様性と競争が必要であり、フレームワークはデフォルトではなく制約と適合性に応じて選ぶべきだというメッセージを伝えている
React のデフォルト勝利とその限界
- React はもはや技術的優位で選ばれるのではなく、デフォルトとして採用されることが多い
- これはチームがプロジェクトの制約を評価せず、自動的に React を使う習慣を強化している
- 代替フレームワーク（Svelte、Solid、Qwik）は、特定のシナリオでは React より性能面で優れているにもかかわらず、十分に評価されていない
- React 自体の問題というより、React をデフォルトとする思考様式が革新を阻害する構造を作っている
革新の天井
- React の Virtual DOM は 2013 年には適切だったが、今日では不要なオーバーヘッドとして作用している
- Hooks はクラスコンポーネントの問題を解決したが、依存配列や stale closure のような新たな複雑さを導入した
- Server Components と React Compiler は性能改善を試みているが、これは React モデルの制約を回避するための便法である
- 一方で Svelte の Runes、Solid の細粒度リアクティビティ、Qwik の Resumability は、まったく異なるモデルでより高い潜在力を示している
技術的負債
- React をデフォルトで選ぶと、不要なランタイムコストと再レンダリング管理の負担が発生する
- 開発者はビジネス価値ではなく、effect の依存関係や hydration 管理に時間を使うことになる
- ベンチマークでは、Solid は React より 2〜3 倍高速な更新性能を示している
- React パターン中心の思考は Web の基礎力を弱め、アーキテクチャの慣性を深める
代替フレームワーク
-
Svelte: コンパイラ革命
- Svelte は作業の大半を コンパイル時に処理し、virtual DOM を取り除く
- コンポーネントは Web の基本構造に近づき、実行時オーバーヘッドが大幅に減少する
- しかし「仕事の機会が少ない」という認識のため導入率は低い
- The Guardian、Wired、Shawn Wang などのさまざまな事例で、Svelte 導入後にバンドルサイズと読み込み時間が大きく減少し、開発生産性が向上したことが証明されている
- たとえば Shawn Wang は、React では 187KB だったサイトサイズを Svelte で 9KB まで削減した
-
Solid: 細粒度リアクティビティの原始的アプローチ
- Solid は 精密なリアクティビティ（細粒度リアクティビティ） を JSX 構文と組み合わせて提供する
- signal を通じて変更された DOM にのみ直接アクセスし、reconciliation のボトルネックを完全に回避する
- 卓越した性能と簡潔な状態管理の強みを持つ
- まだ採用事例は限られているが、初期導入チームの経験を見ると、効率性・コードの単純さの両面で大きな革新を体験している
-
Qwik: Resumability の革新
- Qwik は traditional hydration の代わりに、resumability により即時の startup を強みとしている
- 現在必要な機能だけを段階的にロードし、状態・コードの両方をシリアライズ可能にする
- 大規模サイト、長時間セッション、低速ネットワークで卓越した成果を示す
- まだ多くのチームは試していないが、導入したチームでは 初期読み込み時間とリソース効率 の両方で大きな改善が報告されている
-
React API の複雑さと代替フレームワークの単純さ
- React API は hook、context、reducer、memoization などの複雑な概念を含んでおり、開発者の認知負荷が高い
- 誤用すると依存関係の問題によるバグ発生や過剰な設計負担が大きい
- たとえば、Cloudflare の 2025 年 9 月 12 日の障害原因も、useEffect の依存配列設定ミスによって発生した
- 一方で、Svelte・Solid・Qwik などの代替案は、はるかに小さく集中した API によって シンプルさと Web の根本原理を強調している
- この 3 つのフレームワークはいずれも技術的優位性を十分に備えているが、React というデフォルト文化のために、ほとんど実験すらされないのが現実である
ネットワーク効果の牢獄
- React 支配は自己強化的な障壁を生み出している
- 求人市場では「React 開発者」ばかりが求められ、組織ごとに コンポーネントライブラリや開発習慣などが React 向けに固定化される
- リスク回避志向のリーダーは当然のように安全な React を選び、教育機関もそれに合わせる
- こうした構造は 健全な競争が失われた生態系の特徴である
ネットワーク効果を破る
- そこから脱するには 意識的な選択が必要だ
- 技術リーダーは惰性を捨て、要件に応じて構造を決めるべきであり、企業はパイロット予算を割り当てて代替案を試すことができる
- 開発者も単一のパラダイムに固執せず、さまざまなフレームワークの思想を身につける必要がある
- 教育機関は フレームワーク非依存の概念に関する授業を増やすべきであり、オープンソース貢献者は小さな生態系の支援に力を注げる
変化は自然には訪れず、意図的に作り出さなければならない。
フレームワーク評価チェックリスト
新規プロジェクトでは、次を評価基準にできる
- 性能要件: 初期読み込み、更新効率、バンドルサイズなどと、コンパイル時最適化の有無
- チーム能力と学習曲線: 既存経験を考慮し、Solid のように React と親和性のある代替案も存在する
- 拡張性と保有コスト: 保守、依存関係管理、技術的負債を含む長期コストを評価する
- 生態系適合性: 成熟度と革新性のバランス、非中核業務でのパイロット導入や ROI テスト
よくある反論と対応
- 生態系の成熟度: 古い生態系が必然的に今日の問題により適しているとは限らない。サードパーティパッケージへの依存度が高まると、保守負担、セキュリティ脆弱性、バンドル肥大化などの副作用が大きい。むしろ小さな生態系は Web の根本により集中でき、AI ツールの発展によって容易かつ迅速にカスタムソリューションを開発できる。
- 採用問題: 需要がそのまま採用基準になる。中核でない領域で代替案を試した後、現場学習で不足する能力を補える。
- コンポーネントライブラリ: フレームワーク非依存のデザインシステムや Web Components の活用により、ロックインを減らしつつ生産性を維持できる。
- 安定性: React も hooks、Server Components など絶えず変化している。代替フレームワークのほうが、より一貫した API を提供する場合も多い。
- 大規模事例による検証の必要性: かつて jQuery も世界的な事例だった。過去の成功が未来にも有効だという保証はない。
生態系・産業全体に及ぶ害
- React の単一文化は Web の発展そのものを遅くする
- 才能と資本が React の課題解決にばかり集中し、プラットフォーム固有の革新は遅延する
- 教育機関も 即時の就業可能性重視のカリキュラムにより、移植性のない技術学習ばかりを増やしてしまう
- プラットフォーム（Web）自体の発展が「React さえあればよい」という答えに阻まれ、生態系の多様性不足が長期的には全員に損失として返ってくる
私たちが作れる望ましい生態系
- 多様性は健全な生態系の必須条件である
- 複数のパラダイムが競争し交流するとき、革新が生まれる
- 開発者は複数の思考様式を学びながら成長し、Web プラットフォーム自体も多様な挑戦意識のおかげで発展する
- 1 つのフレームワークにオールインすることは単一障害点になる。限界に達すれば成長は止まり、より良い機会も失われる
- プロジェクトごとに技術的制約と適合性を中心に選ぶべきであり、React のデフォルトにだけ依存しない姿勢が必要だ
- 多様性だけが真の革新を保証する
- 今こそ、みんなが同じ「種（React）」ばかりを植えるのではなく、より多様なフレームワーク実験を通じて Web 生態系をもっと強靭で革新的なものにしていく時だ
- 選択は私たちの手にある
19件のコメント
ジュニア開発者がReactを選ぶのは仕方ないが、シニア開発者が他の代替案について考えるのをやめてしまうのは問題だ。
ReactやJavaは、すでにもっとずっと優れた代替がたくさんある時代遅れのゴミなのに、あまりにも長くのさばっているのは事実ではあるｗ
実験は、あの大混乱だったフレームワーク時代にかなりやったけど…
実務では、これまで使っていたものを全面的に置き換える必要はないし、新規案件だとしても
これまで問題なく使っていたものを捨てて新しく学び、乗り換えることに同意する人はあまりいないという採用面の問題もあるし…
Solidがうまくいってほしいですね……。Reactの独占状態をどう打ち破るべきか。
この10年近く、FEエコシステムでは数多くのツールが登場し、栄枯盛衰を経てようやくある程度安定してきたのに、またあの大混乱をもう一度やれというのか..
かなり偏った文章ではないでしょうか?
"Svelte、Solid、Qwik のような革新的なフレームワークは、より優れたパフォーマンスモデルを提供しているが、採用率の低さによって主流の競争から押し出されている"
イノベーションという言葉の意味を理解する一貫した基準がないのであれば、
前提からして間違っているように思います。
こういう文章を見ると、プロダクトを作ることに気を配るのではなく、ソフトウェアエンジニアリングそのものにばかり没頭しているように思えます。どうせどれも大差ないのだから、プロダクトをきちんと作るべきなのに、いつも新しいフレームワークだの新しいアーキテクチャだのを探し回ってはオーバーエンジニアリングして、これがいいからまた変えようと言い出す。新しいものが良いのではなく、何であれ上手く使ってプロダクトを出すことが重要だと思います。
仕方のないことです。国内の大手テック企業がReact（Next.js）基準で採用しているからです。
メジャーなVue.jsでさえ、大手テック企業で募集しているポジションはそれほど多くありません。
エコシステムを無視できないのが…最近出てくるサードパーティーやオープンソースのライブラリの大半はReactは公式サポートしていても、ほかのフレームワークはコミュニティサポート בלבדなので、あれこれ組み合わせて使おうとすると、結局Reactがいちばん安全な選択肢にならざるを得ない…
フロントエンドほど多様に実験している分野があるだろうか……
ReactはFacebook開発チームの献身のおかげでWebアプリ開発の挑戦を数多く可能にした。悪役ではない。PHPやjQueryの時代を終わらせてくれた。
Hacker Newsの意見
Reactはただデフォルトになってしまったのではなく、非常に効果的でよく設計されていたからこそ事実上の標準になり、同時に今では悪役のような存在にもなってしまったのだと思う
Reactがイノベーションを遅らせているという主張は、かなり的外れに感じる
Reactは、数多くの「自分も混ぜてくれ」的なフレームワークや混乱した設計の中で、事実上ほぼ唯一の安定的で合理的な選択肢だ
謙虚に反対する
私は複雑なインタラクティブアプリをReactで作ったことはなく、以前にチームメンバーがすでにReactを選んでいた簡単なサイトを何度か作っただけだ
その結果、Reactはむしろシンプルなサイトでは明らかにスケールダウンしにくいと感じた
単純なログインページなら、状態をDOMに直接保持し、
<form>だけで値を送信すればよく、パスワードの表示・非表示も少しのJSで済むしかしReactで実装しようとすると、JSX、hooks、コンポーネントのライフサイクル、開発ビルド、本番パッケージングなど、学ぶべきことが多すぎる
VueやAlpineなど他のフレームワークは「漸進的」に使え、CDNだけですぐ始めることもできる
Reactも漸進的だと主張されるが、JSXの性質上、ビルド・コンパイル工程が必須なので、CDNですぐ始める方法が公式ドキュメントにない
無理やり不可能ではないが、結局コンパイラまでクライアントに同梱することになるので、現実的には最悪だ
ほとんどのサイトはFacebook、Spotify、Netflix級ではないのに（しかも NetflixもReactから距離を置くと発表）、Reactがそんなに効果的でよく設計されているという主張には同意しがたい
Reactが12年前に登場したときは本当に革新的だった
しかしすぐに似たようなフレームワークがいくつも現れ、その後は「まあまあ使える」水準にとどまり、イノベーションの中心ではなくなった
今では古いVirtual DOM設計の問題を解決しようとしながら、boilerplateが増え続け、最新の代替案と比べて魅力が落ちている
記事タイトルの意味が逆転している
実際には「イノベーション」のほうがReactの方程式（成功の方程式）に追いつけていないと感じる
そもそも、どれほどイノベーションが必要なのかという問いもある
実際には、反復と改善のほうが優れていて安価なことが多い
私はこの記事と、2015〜16年ごろの多元主義的な視点が気に入っている
「Svelteで別の小規模ユースケースを作ろう」とチームに言いたいが、評価チェックリストは記事の主張と正反対に働く
性能: 99%のアプリでは違いを体感できないので、結局Reactを選ぶ
チームの習熟度と学習コスト: みんなReactしか知らず、Qwikなどは知らない。自然とReactを選ぶ
拡張性、運用コスト: 大きな差はない
エコシステム: Reactのほうがはるかに大きく安定している。Reactを選ぶ
しかも最近はAIツールもReactへの対応が良く、開発者たちもほとんど自動的にReact中心で学習している
結局Reactが合理的な選択肢にならざるを得ない
Web Componentsがこのフレームワーク寡占状態からの脱出口になると思う
Reactを除くすべてのフレームワークがWeb Componentsを積極的に支持し、それぞれが独自のReactエコシステムを再構築するのではなく、互換性のあるコンポーネントとユーティリティのエコシステムを活用するのが答えだ
多くの人はWeb Componentsをフレームワークの競合相手と見ているが、実際にはコンポーネント実装とブラウザの間のインターフェースを定義し、相互運用性と信頼性の高い組み立てを可能にするものだ
こうした低レベルAPIの上では、さまざまなコンポーネント作成手法（ビルド不要、JSX、テンプレート、カスタム構文、コンパイラなど）や、さまざまなコンポーネント構成・状態管理のイノベーションも引き続き実現できる
「うちの新しいFlugleフレームワークはどのフレームワークとも相性が良く、自動化ツールも豊富です！」と誇れるようになってこそ、React独占体制を打ち破れる
私もboilerplateを避けるためにwrapperを使ってWeb Componentsを使っている
この方法で、少ない労力でWeb Componentsの機能の80%を得られた
関連GitHub: ZjsComponent、以前のHN議論へのリンクも参照（HN議論）
完璧ではないが、私にとってこれより簡単かつ速く新しいHTMLコンポーネントを作る方法はない
React Native級の代替がないなら、Web Componentsだけでは不十分だ
ブラウザ技術はネイティブアプリ水準に到達するほど速くない
Reactの最大の価値は、プラットフォーム全体でGUI開発を統一できる点にある
lit web componentsで業務アプリを作った経験がある
すべてのプロパティがstring型でなければならず、かなり不便で、real-time中心のコンポーネントライブラリとは比較にならなかった
うちの大企業では社内アプリで中央のReactライブラリを必ず使わなければならない
「デフォルトだからReact」ではなく「Reactしか使えない」状態だ
脱出口は、その中央ライブラリをWeb Componentsで再実装し、好きなフレームワークを使えるようにすることだと思う
React UIライブラリでWeb Componentsをうまく使った人がいるのか気になる
特定のデザインシステムに合わせてコンポーネントライブラリを作るときは、RACのようなheadlessライブラリに依存するのが満足度が高い
Web Componentsが補完的な存在になり得ることはわかるが、実際にどこで使うのが最も良いのかはよくわからない
実のところこの記事は、Reactの性能の問題ではなく、「社会的な利得」が代替案よりはるかに大きいため、他の選択肢が難しいという話だ
つまり、Reactが技術的に突出していなくてもデフォルトの選択になり、ネットワーク効果が技術的適合性よりも意思決定に大きく影響しているという点には同意する
それでもチームにとっては、Reactには代替案に対する明確な利点が引き続き存在する
実際、たいていの有能なチームは、自分たちが本当に例外的なケースのときだけ別の代替案を採用すべきだとよく理解している
複数の企業やスタートアップで技術スタックの決定に関わったが、Reactを選ぶ根拠として「フレームワーク自体の長所」が挙がるのを聞いたことはない
常に慣れ、採用のしやすさ、エコシステムを基準に決まっていた
Web開発者が合理的な判断を下すと仮定しているが、私の経験ではそうではない
人は「社会的証明」や「権威」などの人間のバイアスに簡単に振り回される
「Reactが良いから使う」という言葉は聞いたことがない
いつも「採用しやすいから」という理由だけだ
Reactは複雑な問題の解決に強みがある
とはいえ、すべての問題が複雑なわけではないし、複雑なツールをデフォルトにすると、プロジェクトに不要な複雑さと柔軟性の低下を持ち込む
過去の機能や将来の機能のために保守しなければならないエコシステムの不安定さも、Reactだけの問題ではない
今後は、現世代のweb appパラダイムを超える新しい流れを期待したい
フロントエンドの単一文化（React独占）を懸念する理由はあるが、気になるのは、実際には10年前はまったく逆の状況だったことだ
新しいフレームワークが毎週のようにHNに流れ込み、Angular 1.xから2.0への混乱、「JavaScript fatigue」という言葉まで出るほどフロントエンド開発は大変だった
今ではReactが明確な標準として固まり、そのおかげで安心してサービス開発に集中できる
Reactを称賛しているわけではないが（私もhooksは好きではないが）、2015年のような時代ではなくなったことには感謝している
今は時が流れ、少しずつ空気が変わってきているのが興味深い
狂ったように多種多様なboutique JavaScriptライブラリがあふれていた時代を覚えている
Reactが主流になったのは一種の勝利だと思う
「イノベーション」という曖昧な概念のために、慣れていて安定したものを無理に捨てるのは警戒すべきだ
本当に共感する
2009〜2015年にかなり先進的な立場で、ネイティブアプリ級のブラウザUXをたくさん作ってきた
Web標準と、それをできるだけ直接活用することが強みだったが、その後バックエンドへ軸足を移し、Reactの台頭を遠くから見ていた
Reactは非効率に見えたし、JSXの「すべてが式でなければならない」という制約も窮屈だった
それでもReactがstate managementに重要なパラダイム変化をもたらした功績は大きいと評価している
過去の状態モデルから単方向のimmutable dataフローへ変わるのは大変だったが、最終的には意味があった
混乱していた時代だったとはいえ、Reactがイノベーションを起こし、Webアプリ設計の考え方に大きな変化を与えたのは事実だ
しかし今SolidJSと比べると、Solidのほうが同じ利点をより簡潔に、より高性能に、はるかに扱いやすく提供している
JSX、サーバーコンポーネント、reactiveな状態管理もよりよく提供しており、React開発者も簡単に移行できる
アプリ構造の考え方もほぼそのままなので、Reactで実質的に得られるほぼすべての利点を、より良く、より速く、さらにバンドルサイズも大幅に減らした形で享受できる
それでも市場全体がReactに集中しているので、無理にでも使い続けるしかない
SolidJSにもまだ痛い部分はある
最大の問題は、propがsignalなのかそうでないのか直感的にわかりにくいことだ
型システムも大した助けにならない
Reactでは参照が変わればpropを受け取る側で必ず再レンダリングされると明確だが、Solidでは変化が監視されるのか曖昧だ
ほとんどの人は、自分に慣れたものを使うことで満足しているのだと思う
Reactを無理に使いたくない開発者は多いが、結局は自分がよく知っているものを使うしかない
時間は限られていて、家族や趣味など他の生活のためにも効率的な選択が必要だ
Reactに縛られる必要は必ずしもない
私の会社では（ほぼ私一人で）過去10年間開発してきたフレームワークもあり、MITライセンスでオープンソース公開している
Q.jsリンク
意見を聞きたい
Hooksはclass componentの欠点を解消したが、新たな複雑さ（依存配列、stale closure、誤用など）も生んだ
ただ、こうした問題はhooksだけのせいではなく、昔のclassベースのコンポーネント時代にも存在していた
依存配列の問題は、昔からpropsやstateの変更を見落として発生するバグがよくあった
stale closureもsetStateの第2引数で同じように起きていた
ライフサイクルメソッド（componentDidMount、componentWillMountなど）の誤用も頻繁だった
「Effectは本当に必要なときだけ使え」といった文書は昔でも必要だったと思う
hooksはミスの機会を減らし、その機会を見つけやすくし、警告まで出してくれるので、確かに改善に貢献している
依存配列の問題は、eslintでreact-hook関連ルールを使えば非常に簡単に解決できる
propのテストにfast-checkを使うと、些細な変化が起きたときのバグ予防に非常に役立つ
JavaScriptコミュニティは数年間イノベーションを止めてもよさそうだ
イノベーションが多すぎたわりに中身が伴っていなかった
今こそブラウザ側が、Webのための合理的なコンポーネント開発を担うべきだ
バックエンド支援のcomboboxや標準のdate pickerだけでもブラウザ単位でサポートされれば、毎回そうした基本UIコントロールの状態管理のイノベーションに執着しなくて済む
ブラウザがもはや本来の役割を十分果たしていないのも問題だと思う
GoogleはChromeを通じてほぼ独占に近い影響力を持っており、Googleが関心を持って開発リソースを割くこと以外は、Web標準でも進展しにくい
SafariやFirefoxがある程度バランスを取ってはいるが、本当に差別化されたプラットフォームへ進化するには、誰かがリーダーシップを握って押し進める必要がある
結局、JS陣営はプラットフォームレベルの支援がないため、NANDチップをはんだ付けするように延々とハックを続けるしかないという残念な状況だ
最近のブラウザとCSSは、従来JSに依存していたユースケースを着実に改善・解決してきたと感じる
こうした動きは今後もさらに広がってほしい
いっそショッピング、バンキング、ソーシャルなど5〜6種類にブラウザを分けることも考えてよいかもしれない
各サービスがバックエンドでだけイノベーションを競い、フロントエンドは統一された体験を提供するほうがユーザーには有益だ
各社が同じようなフロントエンドを延々と個別に開発し続けるのは、とてつもない無駄だ
サンドイッチ店はより良いサンドイッチを作ることで競争すべきであって、アプリをインストールするユーザーの8%を奪うために似たようなフロントエンドを作ることが本質ではない
実際、これほど複雑なプラットフォーム（HTML/CSS/JS）の上でフレームワークたちが成し遂げてきたことを見ると驚くばかりだ
「Web」は文書・テキストと単純なフォームに集中していた頃には適した構造だったが、今では複雑なインタラクティブアプリには非常に不向きな土台だ
いつか完全に新しく組み直されるべきだ
Reactは「最高だから」勝ったのではなく、「安全なデフォルト」になったから勝った
誰もがReactを知っていて、採用もしやすく、エコシステムも大きいから、それが安定している
その結果イノベーションは減り、より軽量なSvelteやSolidのような代替案は試すことすらされなくなる
Reactは今でもよく機能するが、実際には適合性より惰性で使われていることが多いと思う
筆者の意見には共感する。とはいえ、Reactを使う惰性が言われるほど間違っているわけでもない。おっしゃるようなSvelteなどの代替がiPhone 17だとすれば、ReactはiPhone 15ないし16くらいだと思う。コストに対してまだ十分使えて、あえて乗り換える必要も感じないということだ。フロントエンド大混乱期に私たちがReactを選んできたのは、筆者の意見とは違って意識的に行われたことではない。いろいろ使ってみた結果、Reactがいちばん実用的に感じられたから選ばれてきたのだ。将来Reactが使いづらくなり、他のもののほうがより実用的に見えるようになれば、あえて意識して挑戦や実験をしなくても、自然な移行が起きると思う。
VHSとベータマックスが一騎打ちを繰り広げたビデオテープ規格戦争の事例を見ると、技術的に優れているからといって、常に市場で選ばれるわけではないようです。
フロントエンドは必要以上の革新をやりすぎているのが問題ではないですか
ある程度は共感します。
バックエンドでは、Spring Bootフレームワークが電子政府フレームワークまで作られるに至るほど、フォーマットが定まれば生産性が向上する面が確かにあるため、Reactもそうした形へと変化していくのではないかと思います。
はい、かなり多くの人が理解できるコンポーネントベースの設計とレンダリングの挙動を確立したことが、Reactの意義だと思います。ただ、Reactはそれ自体でWebアプリを作るには低レベルなフレームワークなので、せめてルーターやフォームくらいは標準で提供してほしいですし、stateとeffectについては深い比較をデフォルトでサポートし、構造体と関数だけでロジックを書けていたらどうだっただろう、と考えます。JavaScriptの浅い比較という制約のせいで、カスタムフックの文法でクラスを書くことになってしまうんですよね。
低レベル……というには……フォームを実装するなら
htmlのinputタグだけ使えば済むことなのに、state だの JSX だの非制御／制御コンポーネントだの、あまりに無駄に知っておくべきことが多く、たくさんのコードを生成しなければならないし、そういうことが本文の動機になったのではないかと思いますね同感です