ハクソク

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

Reactは誰か好きですか？

12時間前原文(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は道具として使うのが好きだな。自分がやりたいことを実現してくれるから。

└

ReactはBackboneやMarionetteに比べて大きな進化だったね。jQuery以前は、DOMすら標準化されてなくて、ほんとにひどい状況だった。あの頃はXMLHttpRequest（特に.NET WebFormの時代）を使っていて、JSONが出る前のIEではActiveXObjectを使わなきゃいけなかった。

└

Angular 1.0の時代からはかなり遠くに来たし、すべてのウェブサイトがJavaScriptを必要としているわけじゃないよね。

└

同じ道を歩んできた者として、同意するよ。以前のパラダイムと比べて、Reactは複雑さや豊かなインタラクティビティを本当にうまく組み合わせられる。欠点があってもね。

└

Angular（1でも2でも）を使ってた時には、Reactで経験したような問題は一度もなかったな。アプリの複雑さはもっとあったのにね。まあ、これは単なる経験談かもしれないけど、あんまり嫌いじゃなかったよ。（私は主にバックエンドの開発者で、フロントエンドもやるから、どちらも特に好きってわけじゃないけど。）

偏見があるけど、私はその流れを作った人の一人だから、Reactが大好きなんだ。前はフロントエンドの問題を解決するために、あらゆる手を尽くしてたけど、Reactが出てからはその必要がなくなった。今はただ、ものを作ることに集中できるよ。

もちろん、みんな使ってるよ。Reactや他のウェブフレームワークを使うことを強制されることはないけど、JavaScriptは実質的に強制されてるのに、Reactが勝ってる。これは、少なくとも他のほとんどのフレームワークよりも人々が好んでいる証拠だと思う。2010年代後半まで、ウェブ開発に対する一般的な不満は、どれだけ速く変わるか、どれだけ新しいものが次々と出てくるかだったけど、それは確かに正当な不満だった。でも、Reactの一強が台頭してきたら、みんなそれがダメだって文句を言い始めるんだよね。ほんと、勝てないよ。

└

私は仕事で使うフレームワークやライブラリを選んだことがないんだ。ほとんどいつも、誰かが数年前に始めたものや、厳格な選択肢に縛られた組織のものをやってる。個人的にはReactは選ばないかな :) Reactが勝ってるのは、デフォルトの選択肢になって、みんなが自分の好みに合ったものを好むからだと思う。

└

逆に、ReactとNext.jsを使わざるを得ない状況だよ。多くのSaaSベンダーがVercelと提携していて、拡張ポイントもそれにしか提供されてないからね。別のものが欲しいなら、自分で統合を実装するか、すでにやってるオープンソースプロジェクトを探すか、AIに聞くしかない。趣味のプロジェクトならできるけど、プロの現場では考えられないよ。

└

Reactには利点もあるけど、最適なツールかどうかに関して惰性で選ばれる傾向もある。「みんなReactを使ってるから、これで採用プールを最大化できる」「Reactプロジェクトは履歴書に良い印象を与える」ってね。

そうそう！間違いなく、最も直感的なインターフェースで、宣言型と命令型のスタイルをうまく融合させてるよね。個人的には、UIフレームワークの中でJSXに匹敵するものはないと思う。

└

それがそんなに直感的なら、どうしてほとんどのReactアプリにはパフォーマンスバグが含まれてるの？

└

Flutter、SwiftUI、Jetpack Composeなど、他にもたくさんのプラットフォームがReactをUIフレームワークとして実装してるよね。

僕がすごく楽しんだトークの一つがこれだよ：https://www.youtube.com/watch?v=h9SDuTSy7ps。僕の経験では、Reactのアーキテクチャは本当に良くて、大規模なアプリケーションを作るのに適してる。残念ながら、Reactの最大の問題は、JS/TSエコシステムに強制的に入れられることだね。これは間違いなく、僕がネイティブでやりたいシステムじゃなくて、コンパイル対象だと思ってる。Elmには満足してるよ。コミュニティはすごく小さいけど、自分でライブラリを作らなきゃいけないこともある。TEAは時々…（Reactから来たから）不自然に感じるけど、暗黙的で予期しない状態（useEffectを参照）を気にしなくていいから、Elmでの作業はいつもワクワクする。さらに、ClaudeはElmの方がReactよりも大規模で怖いコードベースの中でうまく管理できてるみたい。

└

TEAは好きだけど、再利用可能なコンポーネントや十分に複雑なページに対してどうスケールするのか、完全には理解してない。これに対処するための合意された方法はあるのかな？状態は大きなNOだって聞いたから、ちょっと矛盾してる気もするけど、これって結局、すべてのElmアプリが効果なしのグローバルなReduxとReactアプリってことになるの？Elmでの作業や楽しんでることについてもっと詳しく知りたいな。リンクも全然OKだよ。

Reactよりも、一般的にコードでUIを書く最適な方法について興味があるんだ。Reactのファンで、ほぼすべてのウェブアプリに使ってるけど、ReactでUIを書くのは、Goでコマンドラインツールを書くのやElixirでリアルタイムアプリを書くのと比べて、あまり自然に感じない。特定のことには、言語によってはすごく自然で摩擦がないものがあるけど、UIに関してはまだ誰も完全に解決してない気がする。Swift、JSX/HTML、Svelte、最近のフレームワークなど、どれもある程度問題を回避してる感じがする。プロセスのどこかで、言語やフレームワークのデザイナーが妥協して、プロジェクトの要件を満たすために変な構文を実装しなきゃいけなかったんじゃないかな。UIの自然なインターフェースは視覚的だから、Figmaみたいなツールが解決策の重要な部分になるけど、それでも何かが足りない気がする。視覚をコードで表現するもっと直感的な方法があるはずだよ。今の解決策は、正確に説明するのが難しいけど、いつもどこかが物足りない感じがする。

└

エンジニアとして、どんな問題も「これには完璧な解決策があるはず、まだ見つけてないだけだ」と考えがちだけど、年が経つにつれて、理想的な答えを受け入れるようになってきた。もしかしたら、そんなものはないのかも。問題の領域があまりにも複雑で、すべての形に対して人間的に実現可能な一般的な解決策が存在しないのかもしれない。これが当てはまるのは、UIが多分そうだね。

└

ある言語は特定のことに対して非常に自然で摩擦がないと感じるけど、UIに関してはまだ誰も完璧に解決していない。まさにその通り。90年代初頭に書かれた問題に関する本を見てみると、今でも適用できるものが多い。 > 現在の解決策は、正確に説明するのが難しいけど、常に何かが欠けているように感じる。これに関する最良の分析は、Chattyの「プログラム = データ + アルゴリズム + アーキテクチャ：インタラクティブソフトウェア工学への影響」にあると思う。ちょっと読みづらいけど、絶対に価値がある。簡単にまとめると、問題はアーキテクチャ的、もっと具体的には言語/アーキテクチャのミスマッチにある。私たちの「汎用」プログラミング言語が引き起こすアーキテクチャ、つまりコール/リターンのアーキテクチャスタイルは、ユーザーインターフェースに必要なアーキテクチャとは一致せず、むしろそのスタイルと対立している。これについても「プログラマーはコール/リターンの穏やかな専制から逃れられるか？」で書いた。今のアプローチは、代替アーキテクチャスタイルを簡単に表現できるプログラミング言語をまず作ること：Objective-Smalltalk。これを使って、HTMXNativeや他の便利な機能を含むUIフレームワーク「interscript」を作ってる。うまくいってるみたいだよ...

ずっとReactのコードを書いてきたけど、今は仕事で大きなVueプロジェクトに取り組んでる。みんなVueは二つの中で簡単で親しみやすい選択肢だって言ってたけど、最近はちょっと違う見方をしてる。Reactはそのエレガンスの中で、基本的には関数だけのコンポーネントを提供してくれる。これ以上のことはあまりないんだよね（Next.jsエコシステムは別として）。フロントエンド開発で出会った中で一番エレガントだと思う。対してVueは、なんかごちゃごちゃしてる感じがする。明らかにJavaScriptをちゃんと学びたくないバックエンド開発者たちによって取り入れられて、称賛された結果、きれいにまとまらない変なミックスが生まれたって感じ。

└

この意見は理解できないな。Reactのコンポーネントはただの関数じゃなくて、フックを通じてアクセスされる魔法のように注入されたコンテキストが加わったものなんだ。それにはいろんな保証が必要で、気をつけてないとデバッグが難しくなることもある。個人的には、エレガントとは言えないな。主要なフレームワークでプロジェクトをやってきたし、今は大きなAngularのウェブアプリを作ってる。Angularでは、コンポーネントはクラスとテンプレート（スタイルも含む）で表現される。イベントリスナーは主にクラスのメソッドを呼び出すだけ。状態はクラスのプロパティとしてシンプルに表現できる。すごく自然で、注意点もずっと少ない（ゼロではないけど）。

└

Vueを使い始めてどれくらい経つの？数年前、Reactから来た時はVueに対して似たような意見を持ってた。でも今はReactよりもVueが好きで、個人のプロジェクトでも仕事でも使うようになった。エルゴノミクスがちょっと違うけど、Reactでやりやすいこともあれば、Vueでやりやすいこともある。信号を使うってのは、僕にとって大きなプラスだね。

いくつかの点では改善されたけど、ほとんどの時間は面倒だった。Angularプロジェクトに取り組む前は、Reactが一番嫌いなフロントエンドライブラリだった。Solid.jsが僕の精神を取り戻してくれた（Svelte 5もね）。速くて小さくて、必要なものが含まれてて、ただJS/TSを書いてる感じ。残念ながら、企業は開発者や自分たち、ユーザーを苦しめるのが好きすぎるから、結局ReactやAngularになるんだよね。

私の旅路。生のPHP + SQLクエリ -> Python + サーバーサイドレンダリングのHTML -> Ruby/PythonのAPI + ひどいJSフロントエンド -> Python + EmberJS（覚えてる？） -> Go/Ruby/Python/もう気にしない + React。Reactの問題は、JS/TSや他の開発者（絶対私じゃない！ほんとに！）が書くひどいコードがテストを通過して、読みづらくてメンテナンスも大変なことにある。JSのトレードオフは、急速に進化するウェブ環境に対応できるけど、NPMやサプライチェーンのハックに定期的に対処しなきゃいけないってこと。まあ、Reactのイベント、フック、再レンダリングの複雑さには慣れてるから、インタラクティブなプログラムを作りたいし、タダで手に入るものなんてないからね。データフェッチングライブラリのTanstack Queryは、キャッシュの無効化や再レンダリングの難しい問題を解決してくれる。Reactは、実際にユーザーのためにインターフェースを作るのが楽しいと思わせてくれたものだよ。とにかく、何かを作りたいんだ。ちょっとHTMXを使って、超シンプルなシングルページツールを基本的なJavaScriptで実験してる。Next.jsはいいけど、Vercelを使わせようとするのがちょっとしつこいかな。Flask-Adminは、サーバーホスティングされたアプリケーションからページをレンダリングしなきゃいけない本当にシンプルなツールに好きだな。