Reactはデフォルトで勝利し、イノベーションを鈍化させている

2025年9月16日原文(lorenstew.art)

概要

React は技術的優位性ではなく デフォルト選択 で勝っている現状
これが フロントエンドの革新停滞 を招いている問題提起
Svelte, Solid, Qwik などの新興フレームワークの技術的利点と採用障壁の解説
React依存による技術的負債 やエコシステムの弊害を指摘
多様性ある選択と評価基準の重要性を強調

Reactのデフォルト化がもたらす停滞

React はもはや技術的優位性ではなく、 既定路線 として選ばれる状況
新規プロジェクトでは「 Reactを使おう」が前提となり、 要件や最適なツールの議論が省略 されやすい現実
この傾向が ネットワーク効果 による自己強化サイクルを生み、技術的適合性よりも知名度がアーキテクチャ選定を左右
Svelte （コンパイル時最適化）、 Solid （細粒度リアクティビティ）、 Qwik （Resumability）など、 革新的アプローチ が正当に評価されにくい現象
問題はReact自体ではなく、「 React前提思考」というマインドセット

Reactの技術的限界とイノベーション天井

Virtual DOM は2013年当時の課題解決策だったが、 現代のコンパイラ技術では不要なオーバーヘッド となるケースも
Hooks はクラスコンポーネントの課題を解決したが、新たな 複雑性 （依存配列・クロージャ・副作用の誤用）を生んでいる
Server Components はパフォーマンス向上をもたらすが、 構造の複雑化や新たな障害要因 を追加
React Compiler はuseMemo/useCallbackなどのパターンを自動化するが、 根本的な制約を最適化で補っている 現状
Svelte 5のRunes や Solidの細粒度リアクティビティ、 QwikのResumability のような根本的に異なるモデルとの 発想の天井 の違い

React依存による技術的負債

Reactデフォルト選択 は、 ランタイムや再調整コスト を無自覚に受け入れる傾向
再レンダリング管理・副作用依存・ハイドレーション境界など、 開発者の労力が本質的価値創出以外に消耗
JavaScriptのクリティカルパスコスト （The Cost of JavaScript）というパフォーマンス研究の教訓
「 Reactパターン」中心の思考が、 Webの基礎知識の移植性やスキルの汎用性を損なう 問題
Solid などのベンチマークで、 リアクティビティ重視シナリオで2-3倍高速 な更新性能が示されている事実

革新的フレームワークの特長と採用障壁

Svelte
- コンパイラ型で ランタイム・オーバーヘッドを排除
- Web標準に近いメンタルモデル で学習コスト低減
- The Guardian などの採用実績、 バンドルサイズ・ロード時間の大幅削減 事例
- 「求人が少ない」 という理由で採用が進まない現状
Solid
- JSX互換性と細粒度リアクティビティ による高効率な更新
- 不要な再描画を最小化 し、状態管理も簡素化
- 事例は少ないが、初期導入者から高評価
Qwik
- Resumability による 即時起動 と 必要最小限のロード
- 大規模・長時間利用・低速回線向けに最適
- 実例は少ないが、導入チームは劇的な起動速度向上を報告
いずれも技術的優位性は高いが、 デフォルト選択の壁 で採用が進まない
ReactのAPI面積 は大きく、 hooks, context, reducer, memo化 など複雑性が高い
例： Cloudflareの障害 （useEffectの依存配列ミスによるAPI連打）など、 複雑なAPIがバグの温床
Svelte, Solid, Qwik は APIが小さく、学習・保守コスト低減

ネットワーク効果という牢獄

React の支配で「 Reactエンジニア」という職種が生まれ、 スキルの多様性が制限
コンポーネントライブラリ や チームの慣性 による組織的ロックイン
リスク回避志向 で「安全策」としてReactが選ばれる傾向
教育機関 も「就職に有利なReact」を重視
技術的優位性ではなく、 エコシステムによる囲い込み が進行

ネットワーク効果からの脱却策

技術リーダー は「慣性」ではなく 要件と技術的適合性で選定
企業は イノベーション予算 を活用し、代替技術の試験導入
開発者 は単一フレームワーク思考からの脱却・多様なメンタルモデル習得
教育者 は フレームワーク非依存の基礎 も指導
OSS貢献 で代替エコシステムの成熟促進
自動的な変化は起きない ため、意識的な選択が必要

フレームワーク選定チェックリスト

パフォーマンス要件 ：起動速度・更新効率・バンドルサイズなどを評価。速度重視ならコンパイル型を優先
チームスキルと学習コスト ：既存知識を考慮しつつ、移行パスや互換性（例：SolidのJSX）も検討
スケーリングと運用コスト ：長期的な保守・依存管理・技術的負債も含めて算出。代替案は運用コスト低減例多し
エコシステム適合性 ：成熟度と革新性のバランス。非ミッションクリティカル領域でパイロット導入推奨

よくある反論と再考

「エコシステムの成熟度」
- 成熟は価値だが、 慣性や依存リスク も孕む
- サードパーティ依存による 保守・セキュリティ・バンドル肥大化 リスク
- AIコーディング支援 で自作ユーティリティの障壁が低下し、汎用ライブラリ依存の必要性減少
「採用が難しい」
- 需要があれば供給は増加。 非クリティカル領域で試験導入・現場育成 でリスク分散
「コンポーネントライブラリ」
- フレームワーク非依存のデザインシステムやWeb Components でロックイン回避
「安定性」
- Reactも クラス→Hooks→Server Components と絶えず変化。 代替案の方がAPI安定性高い例も
「大規模実績」
- jQuery もかつては大規模実績だったが、 技術進化により役割交代 した歴史

エコシステム単一化の弊害

単一フレームワーク支配 はWeb進化の停滞を招く
人材・投資・教育 が現状維持に流れ、 基礎技術や革新への投資が減少
Reactで十分 という思考が プラットフォーム改善の遅延 を招く
多様性の消失はエコシステム全体の損失

多様性ある未来への提言

健全なエコシステム には多様性が不可欠
異なるアプローチの競争・交差受粉 がイノベーションの源泉
複数のメンタルモデル を学ぶことで開発者も成長
一つのモデルに全てを賭けるのはリスク、限界到達時の脆弱性
次のプロジェクトは「デフォルト」ではなく、「要件と技術的適合性」で選択
多様な選択がエコシステム全体の革新力と回復力を高める

React-by-default に安住せず、 多様なフレームワーク評価と採用 を意識的に進めることが、 Webフロントエンドの未来 をより豊かで革新的なものにする鍵

Hackerたちの意見

フックはクラスコンポーネントの問題を解決したけど、新たな複雑さを持ち込んだよね。依存配列や古いクロージャー、誤用されたエフェクトとか。Reactのドキュメントでも「エフェクトは必要ないかもしれない」って控えめに言ってるし。サーバーコンポーネントはファーストバイトまでの時間を改善するけど、アーキテクチャの複雑さや新しい失敗モードを加える。Reactにはたくさんの正当な批判があるけど、これはその一つじゃないと思う。これらの問題はフックが新しく持ち込んだものじゃなくて、クラスコンポーネントAPIにもあった問題なんだ。ひとつずつ見ていくと、依存配列：特定のpropsや状態が変わったときに呼ばれるはずのコードを含むライフサイクルがあって、でもそのうちの一つをチェックするのを完全に忘れちゃったバグの数は数えきれない。古いクロージャー：setStateの第二引数がこのバグを引き起こした。あと、ライフサイクルメソッドの中でメソッドをバインドしちゃう人もいて、同じ結果になる。エフェクトの誤用：クラスコンポーネントはクラスのコンストラクタやライフサイクルメソッド（componentWillMount、componentDidMount、componentWillReceiveProps、shouldComponentUpdate、componentWillUpdate、componentDidUpdate、componentWillUnmount）にアクセスできたけど、これらの誤用はめちゃくちゃ一般的だった。「エフェクトは必要ないかもしれない」っていう記事が「ライフサイクルメソッドは必要ないかもしれない」や「setStateの第二引数は必要ないかもしれない」ってタイトルだったら、過去にはすごく役立ったと思う。フックはミスをする機会を減らして、そういう機会を列挙しやすくして、重要なのはそれを検出してユーザーに警告するのを簡単にしたんだ。

└

fast-checkを使ったプロップテストは、小さな変更があるときにすごく役立つって感じた。

その気持ち、めっちゃわかる！前はフロントエンドの仕事をたくさんやってて、かなり最先端のこともやってた。ブラウザで高性能なユーザー体験を提供するって、以前はネイティブアプリでしかできないと思われてたことだよね。2009年から2015年くらいの話。ウェブ標準の基礎に深く関わっていて、それをほぼ直接活用してた。しばらくバックエンドの仕事に重心を移して、Reactの台頭とともにその成長を疑いの目で見てた。なんか非効率的なやり方に思えたから。それに、JSXの制限で全てが式でなきゃいけないっていうのが、目をえぐりたくなるほどだった。それでも、Reactは状態管理に関する重要なパラダイムシフトの基盤を築いてくれた。古いメンタルモデルから不変データの一方向フローへの道…全く新しいメンタルモデルを再学習するのは痛かったけど、大事なことだった。時には混沌としてたけど、Reactはウェブアプリケーションアーキテクチャを考える上で多くの価値を提供してくれた。でも、今はSolidJSみたいなものと比べると、Solidが基本的に同じ利点を持ちながら、もっとシンプルでパフォーマンスもいいアーキテクチャを提供してるのがはっきりわかる。Reactよりも整理しやすく、考えやすい形で。JSXもサーバーコンポーネントも、リアクティブな状態管理も（実際にはそれにとってはもっと良くてクリーンな基盤）あって、Reactの開発者ならほとんど神経回路を再配線することなくSolidに移行できる。アプリケーションのアーキテクチャや構造について考え方を根本的に変える必要もない。基本的にReactがやってることを、もっと良く、速く、そしてバンドルサイズも劇的に小さくやってるだけ。なのに、業界全体の慣性のせいで、いくつかのコンテキストでは仕方なくReactを使わなきゃいけないのが本当に残念。

└

使わなくてもいいよ！私の会社（ほぼ私が開発した）でこの10年間に開発したフレームワークについてどう思う？MITライセンスでオープンソースにするよ：https://github.com/Qbix/Q.js

└

基本的にReactがやってることを、もっと良くやってる。SolidJSにはまだいくつかの大きな痛点があるけど、私が見つけたのは、propがシグナルなのか、シグナルになるべきなのかがわからないこと。型システムがあまり役に立たない。Reactでは、参照が変わったら、その参照をpropとして読むコンポーネントが再レンダリングされるって確信できるけど、Solidでは更新が観察されるかどうかがあまり明確じゃない。

└

なのに、業界全体の慣性のせいで、いくつかのコンテキストでは仕方なくReactを使わなきゃいけないのが本当に残念。多くの人が仕方なく働いていて、ほんとにそうじゃなければいいのにって思ってると思うよ。それは、彼らが知ってるものを使うことを意味するし、それがReactになる。私もその気持ち、めっちゃわかる。人々は子供や趣味に時間を使いたいし、最悪の場合、年老いた親の世話をしてるかもしれない。

JavaScriptの人たちは数年間、革新をやめるべきだと思う。行き詰まった革新が多すぎる。ウェブのJavaScriptプロジェクトを構築する方法は何通りあるんだ？ブラウザの人たちはもっとしっかりしたコンポーネントを開発するべきだよ。バックエンドをサポートするコンボボックスとか、ブラウザ間で標準化された日付ピッカーとかどう？そうすれば、2025年でもブラウザがまだ持ってない基本的な操作コントロールの状態管理を常に革新する必要がなくなる。

└

問題の一因は、ブラウザが本来の目的を果たしていないことだと思う。GoogleはChromeを通じてほぼ独占的な立場を持っていて、やりたいことは何でもできるし、やりたくないことはやらなくてもいい。だから、基準がGoogleが開発に時間をかけたいと思うこと以外にはほとんど機能しない。彼らは独占的すぎないから、ブラウザを完全にロックダウンされた製品にすることもできない。SafariやFirefox（この順番で…ちょっと残念だけど）がそれを阻んでいる。だからブラウザはあまり進化せず、ドキュメントビューアからアプリケーションランタイムに変わるという強い技術的な力があるのに、結局あまり動いていない。SilverlightやJavaアプレット/JNLPの夢を実現するチャンスがあるのに、誰もそれをコントロールできないならやりたくないと思っている。FirefoxもOSSの精神で一人で先駆けるだけの開発力はないしね。だから、JSの人たちは、ブラウザやプラットフォームレベルでより良いものを提供されないから、アプリランタイム版のNANDチップで頑張るしかないんだよね。

└

確かに最近、ブラウザやCSSは通常はJSに頼るような多くのユースケースを解決してきてる。これをさらに進めていくべきだね。

└

正直、これらのフレームワークがこんなにすごいことを成し遂げてるのは、狂ったプラットフォームで作業してるからだと思う。HTML、CSS、JSは、ウェブが主にテキストと簡単なフォームだった頃には意味があったけど、今はインタラクティブなアプリを作るにはクソみたいな基盤だよ。全部捨てて、再構築する必要がある。

└

もっと言うと、ブラウザは5つか6つ必要だと思う。ショッピング用、バンキング用、ソーシャル用…こういうプラットフォーム同士はバックエンドで競争して、フロントエンドでは一貫した体験を提供すればいいんだ。そうすれば、私たちのデバイスで動くコードを書いてる人たちがユーザーを裏切るような利害の対立がなくなる。使いやすさも向上するし、一つの銀行の構造や流れ、ホットキーを覚えれば、他の銀行のインターフェースも簡単にナビゲートできるようになる。各ビジネスが別々のフロントエンドを作るのは無駄だよね。結局、競合とほぼ同じものになるんだから。サンドイッチ屋は、アプリを8%の顧客にインストールさせるためにどう動くかで競争するんじゃなくて、より良いサンドイッチを作ることで競争すべきだよ。

これはほとんどReactがどれだけ優れているかへの不満だね。Reactがあまりにも優れているから、代替案の技術的な利点がReactを選ぶ社会的な利点に勝るのが難しい。これはReactの技術的なメリットへの大きな賛辞でもなく、Reactの競合への批判でもないことに注意してほしい。実際、著者の主張のいくつかには同意するし、例えば：> Reactはもはや技術的なメリットで勝っていない。今日ではデフォルトで勝っている。> その反射が自己永続的なサイクルを生み出して、ネットワーク効果が技術的な適合ではなくアーキテクチャを決定する。私も同意する！でも、チームはまだ大半がより良い選択肢を選んでいる。なぜなら、Reactの利点は確かに代替案の利点を上回っているから。著者が見落としているのは、代替案の技術的な利点は狭いユースケースを除いては小さいってことだと思う。そして、ほとんどの有能なチームは実際にその狭いユースケースにいるかどうかを特定して、正しく代替案を選んでいると思う。

Hacker Newsで議論の続きを見る

ハクソク