ハクソク

世界を動かす技術を、日本語で。

Reactは誰か好きですか？

2026年5月26日原文(jsx.lol)

概要

  • React は多くのプロジェクトで選ばれているが、適切に使われることは稀
  • パフォーマンス問題 や保守コストの高さ、バグの多さが指摘されている
  • セキュリティ脆弱性 やAPI設計の混乱、エコシステムの肥大化も問題視
  • HTMLやWeb Components など他技術への移行事例が増加傾向
  • React依存からの脱却 と技術選定の見直しを求める声が高まっている

Reactの課題と批判

  • React は万能解ではなく、道具としての適切な選択が重要
  • JS重依存 のアプローチは長期的なパフォーマンス目標と相容れない
  • 大規模プロジェクト では、宣伝よりも遅くなり、保守も開発も想定以上に困難
  • バグ数 は他の手法と変わらず、特別に優れているわけではない
  • React Server Components における重大なセキュリティ脆弱性（CVE-2025-55182、CVSS 10.0）
  • ハイドレーションパターン の非効率性
    • サーバーとクライアントで同じJSを重複配信
  • モバイル戦略 の失敗とWebの利点の喪失
  • API設計 の混乱やドキュメントの不明瞭さ
  • ネットワーク効果 による選定で技術的適合性を無視する傾向
  • 技術進化 の停滞とフロントエンドイノベーションの阻害

Reactの選定・運用に関する懸念

  • スキルギャップ ：本当に熟練したReactエンジニアは希少かつ高価
  • エコシステムの膨張 と技術的負債
  • プロジェクトの保守性 の悪化
  • Vercel（Next.js） によるベンダーロックイン
  • セキュリティ対応 の不誠実な運用
  • 開発者体験 の悪化と複雑性の増大
  • アップデートの遅延 や後方互換性の問題
  • フレームワーク主義 による本質的なユーザー課題の軽視

代替案と現実的な選択肢

  • HTMLファースト やWeb Componentsの再評価
    • 進化的強化によるユーザビリティと堅牢性の向上
  • Liveview や Svelte など他フレームワークへの移行事例
  • DOM API への回帰でパフォーマンス改善
  • React Hooks の複雑さ・パフォーマンス問題とSignalsなど新技術の台頭
  • フロントエンド技術選定 の再考とReact依存からの脱却

コミュニティの動向と今後

  • Reactコミュニティ に蔓延する品質危機
  • 新規開発者 へのReact回避の選択肢提示
  • 企業やCTO によるReact離れの実態
  • Reactの将来性 に対する不安と方向性の疑問
  • Webの原点回帰 によるキャリアとコードベースの将来性確保

結論・提言

  • React選定の自動化 をやめ、プロジェクトごとに最適な技術選定を行う必要性
  • Reactの問題点 を冷静に見極め、必要なら他技術への移行も検討
  • Web Fundamentals への回帰と、過剰なJavaScript依存の見直し
  • 技術コミュニティ 全体での議論と進化的改善の重要性

Hackerたちの意見

React好きだな。HTMXやHotwireも真剣に試してみたけど。受信トレイから来た時にブラウザAPIを使って戻るボタンを作りたかったんだ。そうじゃなければ受信トレイにリンクしてスクロールを維持するためにね。HTMLから戻る関数を呼び出すアクションを繋げなきゃいけなかったし、コントローラーで前のページを判断して、JSが有効な戻るボタンかハードリンクを送る必要があった。ロジックが3つのファイルに分散してたんだよ！Reactなら、コンポーネント内で前のページが受信トレイだったかどうかを判断して、その値に基づいて戻るボタンのJSXかリンクを表示できる。全部1つのファイルでできるからね。モデル化するのが1つの概念的なエンティティで済むし、3つのファイルで別のことをやるよりも機能的にしっかりしてる。遅い？確かに。でも、嬉しいんだ。企業のReactのスロップベースで苦しんでる？同僚のせいにしなよ、これがなかったらもっとひどかっただろうね。

└

ここでいくつかの複雑なことがあるかもしれないけど、Web Componentsでもできるよね？

└

受信トレイから来た時にブラウザAPIを使って戻るボタンを作りたかったんだ。そうじゃなければ受信トレイにリンクしてスクロールを維持するためにね。HTMLから戻る関数を呼び出すアクションを繋げなきゃいけなかったし、コントローラーで前のページを判断して、JSが有効な戻るボタンかハードリンクを送る必要があった。これが、俺がReactのSPAを嫌う理由だよ。いつもブラウザの戻るボタンやナビゲーションボタンを壊すようなバカな方法を探してる。俺は常にhtmxやサーバーレンダリング、ネイティブなものを好む（たまにフォームブースティングを除いてね）。

└

私のアドバイスは、データ状態に関連する操作にはHTMXだけを使うこと。インテリジェントな戻るボタンみたいなものは、リソースの状態に依存しない限り、バックエンドで計算するのはやめた方がいい。htmxの推奨されるやり方は、onclickボタンをインラインJSに繋げるか、嫌ならgoBackOrInboxという関数を呼び出すこと。例えば、こんな感じにすることができる：function goBackOrInbox() { if (document.referrer) { const path = new URL(document.referrer).pathname; if (path.startsWith('/inbox')) { history.back(); return; } } window.location.href = '/inbox'; } そして、このパターンをよく使うなら、ルートに応じて関数をパラメータ化することもできるよ。

└

バックボタンの問題を解決する一番の方法は、そんなに複雑にせず、戻りたいものだけが履歴に残るようにすることじゃない？問題の枠組み自体が「もっと構造を整理すれば、解決する問題じゃない」って叫んでるように感じる。

ここ16年くらいの間にJSの主要な波を全部経験してきた者として、Reactは好きだよ、ある意味ではね。Reactは他のフレームワークを除けば最悪のJSフレームワークだ。Angular 1の時代よりはReactの方がいい。Angular 1のフルボディMVCは、Backboneの「毎回ゼロから作る」アプローチよりもいい。BackboneのミニマルMVC構造は、クラシックなjQueryスープアーキテクチャよりも優れてる。jQueryのDOM操作や標準ライブラリの改善は、その時代のネイティブAPIよりも即座に選ぶよ。Reactにはトレードオフがあるけど、他のうまくいかないものを長い間試した結果、ここまで来たんだ。

└

ReactよりAngularが好きで、VueはReactより好き。

└

Angular 2+はどうなの？

└

え、Reactって今やフレームワークなの？昔はReactはただのモデルバインディングライブラリだって言われてたけど。ちなみに、俺はReact使ったことない。

└

でも、なんでVueよりReactなの？俺の一番のフラストレーションは、VueがReactの方向に進んでいくことなんだ。元々のコンポーネントアーキテクチャ、HTMLテンプレート、JavaScriptの状態、CSSスタイルがVueではすごく良かった。コンポーネント内でのデータ取得も直感的だったし。

└

そうだね、結果は経路依存だよね。もし当時の私たちが今の知識を持っていたら、ウェブがDOMドキュメントプラスRESTプラスJSハンドラーだなんて考えはもう捨ててたはず。多くの人がその考えを好きだったし、今も好きだけど、普通の開発者が扱うには全然不十分なんだよね。

└

同意だね。私も、手書きのcgi-bin HTMLからjQuery、Angular v1を経てReactに至ったよ。Reactは道具として使うのが好きだな。自分がやりたいことを実現してくれるから。

Hacker Newsで議論の続きを見る