Reactを本当に好きな人なんているのか？

 (jsx.lol)
1 ポイント 投稿者 GN⁺ 4 시간 전 | 3件のコメント | WhatsAppで共有
  • React と React 系ツールに関する 批判的な文章を集めてキュレーションした資料集 で、さまざまな開発者・ブロガーの記事を引用形式で整理
  • 性能低下、複雑性の増大、ハイドレーションの問題 など、React が抱える構造的な限界を指摘する文章を多数収録
  • React 中心の技術選定 は技術的適合性よりも慣性やネットワーク効果によって固定化されており、「誰もが React を知っている」という前提がアーキテクチャの判断より先行しているとの批判を受けている
  • React Server Components と Next.js をめぐるセキュリティ・ガバナンス上の懸念が強まり、CVE-2025-55182 は 認証不要のリモートコード実行脆弱性として CVSS 10.0 で公開された
  • React エコシステムの API 設計の混乱 と 品質危機、複雑性は長期保守と学習を困難にし、Hooks・モダン UI 機能・リリースの流れに至るまで React の方向性をめぐる論争へとつながっている

サイト概要

  • "Does anybody actually like React?" という挑発的な問いを掲げたキュレーションサイト
  • React および React に影響を受けたツールに関する批判記事を集めた cherry-picked コレクション
  • RSS 購読機能を提供

React 自体への根本的な批判

セキュリティおよびガバナンスの問題

API 設計と学習コストの問題

  • Is it Time to Regulate React?

    • React の中核的な失敗は 混乱を招く API 設計 によってさらに悪化している
    • ドキュメントは煮え切らず、正しい使い方をめぐる議論が延々と続く

  • I don't have time to learn React

    • React がモダン UI を教えてくれるという主張とは異なり、実際にはモダン UI をほとんど扱えていない
    • autofocus が壊れており、custom elements は実験版を除いて動作しない
    • dialog や popover などのモダン機能を使うには useEffect が必要
    • synthetic event システムのせいで、実際の DOM の挙動をほとんど学べない
    • モダン UI ではなく 2013 年水準の UI だ

  • The React Blog Post: Reflections and Reactions

    • すべての問題を「skill issue」で片付け、外部ライブラリで解決できると言う態度はおかしい
    • 3 年ぶりに戻ってきても作業できるべき技術だが、フロントエンド、とくに React はそうではない

  • React, where are you going?

    • 今日の React を以前ほど楽しめなくしている 2 つの問題は ownership と complexity だ
    • 新しい開発者が React に萎縮してしまうのではないかという懸念

性能とユーザー体験の問題

  • Why use React?

    • 基本的に悪名高い ハイドレーションのパターン に閉じ込められる
    • サーバーで JS によってすべての計算を行い、HTML を即座に送り、その後まったく同じ JS をクライアントにも送る構造

  • How React 19 (Almost) Made the Internet Slower

    • 公然たる反発と激しい論争の末、React チームは変更を保留した

  • An even faster Microsoft Edge

    • React から モダンな Web Components + HTML-first アーキテクチャ へ移行
    • とくに低性能ハードウェアのユーザーに大きな恩恵

  • Switching costs

    • クライアントサイド React が強いる ひどいユーザー体験 への不満がもっと増えてほしい
    • しかし実際の不満はほとんど 開発者体験 に集中している

  • Pivoting From React to Native DOM APIs: A Real World Example

    • ある開発チームが React の「圧倒的な VDOM」からモダンな DOM API へ移行
    • 速度とインタラクションの改善 をすぐに実感

モバイルおよびプラットフォームの問題

エコシステムとコミュニティの問題

  • React Won by Default – And It's Killing Frontend Innovation

    • 新しいフロントエンドが必要になったとき、「制約条件は何で、どのツールが適しているか」ではなく、**「Reactを使おう、みんな知ってるから」**から始まる
    • 技術的適合性ではなく、ネットワーク効果がアーキテクチャを決める自己強化サイクル

  • Conferences, Clarity, and Smokescreens

    • コンサルティング業務と業界データによれば、Reactコミュニティは深刻で測定可能な品質危機に陥っている
    • React Summitの参加者はこの事実を知らされていない

  • Why Silicon Valley CTOs Are Secretly Moving Away from React

    • React開発者は多いが、深いパターンを理解する真の熟練者はますます希少かつ高額になっている
    • 最も経験豊富なエンジニアたちは複雑さに疲れ、別の技術スタックへ転職しつつある

  • Increasingly miffed about the state of React releases

    • 最後のReactリリースから1年半が経過しており、これまでのどのリリース周期よりも長い

React Server Componentsへの批判

  • React Server Components: the Good, the Bad, and the Ugly

    • Reactはクライアントサイドの改善をほとんど放棄していた（2019年に実験を中止して以降）
    • Facebook規模の問題をFacebook規模のリソースで解決するために作られたレガシーフレームワークであり、ほとんどのユースケースには不向き

  • React Server Components are a bad choice (for shipping)

    • 迅速にリリースしたいなら、React Server Componentsは使うべきではない
    • 学習・実験・コンテンツ制作の目的であれば使用可能

基本への回帰と代替手段の強調

マイグレーションと移行事例

全体的な流れと今後の見通し

Hooks と代替パラダイム

  • Why Signals Are Better Than React Hooks

    • ReactのHooksは正しく使うだけでも難しく、高性能に使うのはさらに難しい
    • 多くのアプリケーションでコード品質と性能低下の原因

比喩的な批判

  • What Is React.js?

    • 支持者たちの奇妙さ、過剰な自己真面目さ、終わりのないドキュメントをキリスト教になぞらえた動画

関連記事

3件のコメント

 
bichi 7 분 전

Reactはただの信仰です（カルト）
 
bichi 5 분 전

Ant Millみたいなものですね //
 
GN⁺ 4 시간 전
Hacker Newsの意見

  • Reactには気に入らない点がいくつかある。Reactは画面にインタラクティブなHTMLを描画するためのフレームワークであって、ものすごく複雑なプログラミングをさせるためのものではない。
    第一に、複雑な概念や用語に頼りすぎている。Vueと比べると、useEffectはwatch、useMemoはcomputedに相当する。
    第二に、こうした無駄に「賢い」やり方が用語を超えてエコシステムにも染み込んでいる。昔のReduxは数字を1つ増やすだけでも複数のファイルに大量のコードを書く必要があり、作者が賢そうなコンピュータサイエンスの概念を好んでいたからに見えた。同じ時期のVueXなら、その数字をただ増やせばよかった。幸い、最近のReactエコシステムにはまともな状態管理が増えている。
    第三に、ReactはCSS作業用のツールを標準では提供していない。
    第四に、Reactは最適化を自動でやってくれない。useEffectやuseMemoをいつどう使うべきか、あるいは使うべきでないかを理解していなければならず、React最適化に関する口伝も多い。再レンダリングが中核的な目的なのにこうなっているのが問題だ。Vueではフレームワークが自分の道具を使わせ、その中で大半を最適化してくれるので、Vueアプリを手動で最適化しようと考えたことはない。
    第五に、その口伝自体が問題だ。React APIと「正しいReactの書き方」があまりに何度も大きく変わってきたため、今でも正しい話とそうでない話を見分けるのがとても難しい。
    結局のところ、Reactはアイデア、コンピュータサイエンス、高水準の抽象化に過度に集中していて、実際にインタラクティブなHTMLを簡単に描画できるようにすることにはあまり集中していない、と要約できる。
    React、Vue、Svelteをどれもかなり使っているが、Reactを使うときはVueやSvelteならすでに処理してくれていたことをずっと気にし続けなければならない。性能面では3つとも似たようなものだ。
    以前、関連する文章も書いた: https://www.brachkow.com/notes/what-i-like-in-vue/

  • この約16年間でJavaScriptの主な流れを一通り経験してきた立場からすると、ある意味ではReactが好きだ。
    Reactは、これまで試してきた他のすべてを除けば最悪のJavaScriptフレームワークだ。
    Angular 1時代と比べるなら、いつでもReactを選ぶ。Backboneのように毎回ゼロから自分で組み立てるやり方よりはAngular 1の重たいMVCを選ぶし、古典的なjQueryスープ構造よりはBackboneの最低限のMVC構造の方がましだった。あの時代のネイティブAPIよりは、jQueryのDOM操作と標準ライブラリ強化を即座に選んでいただろう。
    Reactにもトレードオフはあるが、動かなかった数多くの代替案を長く経験した末にここへたどり着いたのだ。

    • Reactは好んで使うし、それ以前に出てきたものよりはReactを選ぶ。ただし必要なものがその程度なら、htmx/data-starとサーバーレンダリングよりReactを選ぶことはないし、少し複雑なページが数枚ある程度でも同じだ。
    • ただ、なぜVueよりReactなのかは分からない。最大のもどかしさは、Vueが結局Reactの方向へ動いていくことだった。Vue本来のコンポーネント構造、つまりHTMLテンプレート、JavaScriptの状態、CSSスタイルが一緒にあるやり方は本当に良かった。コンポーネント内でURLからデータを取得する方式もとても直感的だった。
    • 同意する。手書きのcgi-bin HTMLからjQuery、Angular v1、Reactへと移ってきたが、Reactは喜んで手に取る道具だ。自分がやりたいことをやってくれる。
    • AngularよりReactが好きで、ReactよりVueが好きだ。
    • Svelteを使ったことがあるのか気になる。なぜ誰かがReactをより好むのか、正直よく分からない。Reactの唯一の利点は、フロントエンドにおけるIBMのような存在だという点だと思う。Reactを選んだせいで解雇された人はいない。

  • もちろんReactを好きな人はいる。JavaScriptのように事実上強制されるものでもないし、Reactや他のWebフレームワークを強制されるわけでもないのにReactが勝った。少なくとも、ほとんどの他のフレームワークより十分に好まれている証拠と見ていい。
    2010年代後半まで、Web開発についてよくある不満は変化が速すぎて新しく学ぶことが次々に出てくることだったし、その不満はもっともだった。ところがReactという単一文化が頂点に立つと、今度はそれが嫌だとみんなが不満を言う。本当に勝ちようがない。

    • 仕事でフレームワークやライブラリを選べたことはほとんどなかった。ほぼ常に、誰かが数年前に始めた作業を引き継ぐか、厳しく選択肢が決まっている組織に縛られていた。個人的にはReactを選ばない。
      Reactが勝ったのは、デフォルトの選択肢になったことと、人は自分が慣れたものを好むからだ。
    • Reactには利点もあるが、その仕事に最適なツールだからというより、惰性で選ばれる傾向もある。「みんなReactを使っているから採用候補や外注先の母集団を最大化できる」「Reactのプロジェクトは履歴書映えする」といった理由が働く。
    • むしろReactとNext.jsを強制的に使わされる。多くのSaaSベンダーがVercelと提携し、拡張ポイントをそちらにしか開いていないからだ。
      別のものを使いたければ、統合を自分で実装するか、すでにやってあるオープンソースのプロジェクトを探すか、AIに聞くしかない。
      趣味のプロジェクトなら可能でも、業務環境では想像しにくい。
    • 誰もReactを強制されていない、というのがどういう意味なのか分からない。Lispを学んで好きなもの全部に使えて、企業文化が技術選定に何の影響も及ぼさない、そんなすばらしい新世界がどこにあるのか知りたい。

  • React は好き。HTMX/Hotwire 系も真面目に使ってみたことがある
    受信トレイから来た場合はブラウザ API で戻る動作を行い、そうでなければスクロール位置を保持するために受信トレイへのリンクへ送る「戻る」ボタンを作りたかった。HTML で動作を結び付けて戻る関数を呼び出し、コントローラで前のページを判定したうえで、JavaScript が有効な戻るボタンかハードリンクを返す必要があった。ロジックが 3つのファイル に散らばっていた
    React ではコンポーネント内の JavaScript が前のページが受信トレイかどうかを判断し、その値に応じて戻るボタンの JSX やリンクを表示できる。すべて 1つのファイル の中で完結する。自分としては 1 つの概念的エンティティをモデリングすればよいが、別のやり方では 3 つのエンティティに機能を無理やり押し込まなければならなかった
    遅いかと言われれば、たしかに遅い。それでも自分を幸せにしてくれる。会社の汚い React コードベースで苦しんでいるなら、同僚を責めるべきだ。React がなければ、きっともっとひどかったはずだ

    • だから React のシングルページアプリは嫌い。いつもブラウザの 戻るボタンとナビゲーションボタン を壊す愚かな方法を見つけるように思える
      たまにフォーム強化程度ならともかく、基本的には常に htmx/サーバーレンダリングとネイティブ動作のほうを好む
    • HTMX はデータ状態に関わる作業にだけ使うのがよいと思う。賢い戻るボタンのようにリソース状態に依存しないものは、バックエンドで計算しないほうがよい
      推奨される htmx のやり方なら、onclick ボタンをインライン JavaScript に結び付けるか、それが嫌なら goBackOrInbox のような関数を呼べばよい
      function goBackOrInbox() { if (document.referrer) { const path = new URL(document.referrer).pathname; if (path.startsWith('/inbox')) { history.back(); return; } } window.location.href = '/inbox'; }
      こういうパターンを多用するなら、移動先のパスを引数に取るようにパラメータ化すればよい
    • 戻るボタン問題を解く最善の方法は、あまり複雑にせず、本当に戻りたいものだけが ブラウザ履歴 に入るよう保証することではないかと思う。問題設定そのものが「構造をもっとよく設計すれば解く必要のない問題になる」と叫んでいるように見える
    • あちこちに複雑な部分はあるだろうけれど、Web Components でもできるのではないかと思う

  • React コードを長く書いてきて、今は会社で大規模な Vue プロジェクトをやっている。以前はみんな Vue のほうが両者の中でより簡単で取っつきやすい選択肢だと言っていたが、今では違って見え始めている
    React はエレガントで、コンポーネントが本質的にただの関数であるだけで、それ以外はあまりない。Next.js のエコシステムはひとまず脇に置くとして、フロントエンド開発で見てきたものの中で最もエレガントだ
    一方で Vue は混ざりもののように感じる。JavaScript をきちんと学びたくなかったバックエンド開発者たちが受け入れて称賛した痕跡が見え、その結果はきれいに噛み合わないぎこちない混合物のように思える

    • こういう見方はいつも理解できない。React コンポーネントはただの関数ではなく、フックを通じてアクセスする 魔法のように注入されたコンテキスト が付いた関数だ。このフックはさまざまな保証を要求し、それを意識していないとデバッグしにくい結果が生じる。エレガントとは程遠いと思う
      主要なフレームワークは全部使ったことがあり、今は大規模な Angular の Web アプリを作っている。Angular ではコンポーネントはクラスとテンプレート、スタイルで表現される。イベントリスナーはたいていクラスのメソッドを呼び、状態はクラスのプロパティのように単純にできる。ずっと自然で、落とし穴もずっと少ない。もちろんゼロではないが
    • Vue をどれくらい長く使ったのか気になる。自分も数年前、React のバックグラウンドから Vue を見て似たようなことを考えていた。でも今は React より Vue を好み、個人プロジェクトでも仕事のプロジェクトでも Vue を先に選ぶ
      使い心地は少し違う。React のほうが簡単なこともあれば Vue のほうが簡単なこともあるが、Vue が シグナル を使っている点は自分にとって大きな利点だ

  • Reactそのものより、一般的にコードでUIを最もうまく記述する方法という問いのほうに関心がある。
    Reactのファンで、作るほぼすべてのWebアプリケーションにReactを使っているが、最大かつ最も明確な問題は、ReactでUIを書くことが、Goでコマンドラインツールを書くことやElixirでリアルタイムアプリを書くことほど自然には感じられない点だ。
    ある種の言語は特定の作業に対して驚くほど自然で摩擦がない。しかしUIについては、まだ誰も本当に征服できていない。Swift、JSX/HTML、Svelte、その手の人気フレームワークが何であれ、どれもある程度は問題を回避しているように感じる。言語やフレームワークの設計者が、どこかの時点で要件を満たすために、汚かったり奇妙だったり苦しかったりする構文を妥協してねじ込んだように見える。
    UIの自然なインターフェースは視覚的なものなので、Figmaのようなツールが解決策の重要な一部になり得る。それでも何かが欠けている感じがする。視覚的なものをコードで表現する、もっと直感的な方法があるはずだ。今の解決策はうまく説明しにくいが、いつもどこかであと一歩足りない

    • かなり近い感覚。Reactが出た当時は、当時の代替案と比べて完璧に思えて、本当に気に入っていた。
      今でもSvelte、Vue、Solidを含むほぼすべてのものよりReactを好んでいる。とはいえ最近はCrank(https://crank.js.org/)を使い始めていて、自分が行きたい方向にもう一歩近いように見える。ただ、今のところはおもちゃのプロジェクトでしか使っていないので、性能面と開発者体験の両方でどれだけうまくスケールするかは何とも言えない
    • 「ある種の言語は特定の作業に対して驚くほど自然で摩擦がないが、UIはまだ誰も本当に征服していない」という点に強く同意する。90年代初頭にこの問題を扱った本[1]を見ると、今でもそのまま当てはまる。
      これまで見た中で最良の分析は、Chattyの「Programs = Data + Algorithms + Architecture: consequences for interactive software engineering」[2]にある。少し読みにくいが、十分に読む価値がある。
      短く要約すると、問題はアーキテクチャ、より具体的には言語とアーキテクチャの不一致だ。「汎用」プログラミング言語が導く呼び出し/返却アーキテクチャのスタイルは、ユーザーインターフェースに必要なアーキテクチャと合わず、むしろ衝突している。
      このテーマについては「Can Programmers Escape the Gentle Tyranny of call/return?」にも書いた。
      現在のアプローチは、代替アーキテクチャスタイルを容易に表現できるプログラミング言語であるObjective-Smalltalk[4]をまず作ることだ。
      それで今、interscriptというUIフレームワークを作っていて、HTMXNativeやいくつかの付随要素も含まれる。
      かなりうまくいっているようだ。
      [1] 例: Myersら「Languages for developing user interfaces」 https://api.taylorfrancis.com/content/books/mono/download?id...
      [2] https://opendl.ifip-tc6.org/db/conf/ehci/ehci2007/Chatty07.p...
      [3] https://2020.programming-conference.org/details/salon-2020-p...
      [4] https://objective.st
    • エンジニアとしては、あらゆる問題を見て「完璧な解決策があるはずで、まだ見つけていないだけだ」と考えがちだ。
      しかし時間がたつにつれて、より理想主義的でない答えを受け入れるようになる。もしかすると、そうした解決策は存在しないのかもしれない。問題空間があまりにも複雑で、あらゆる形態を包摂する人間的に実行可能な一般解など存在しないのかもしれない。それが当てはまる分野があるとすれば、おそらくUIだろう

  • その通り。Reactは宣言的スタイルと命令的スタイルをうまく結びつけた、群を抜いて最も直感的なインターフェースだ。あらゆる言語のUIフレームワークを見渡しても、JSXに近いものはないと思う

    • Flutter、SwiftUI、Jetpack Composeなど、多くの他プラットフォームがReactを自分たちのUIフレームワークのように実装してきた
    • そんなに直感的なら、なぜほぼすべてのReactアプリにパフォーマンスバグが入っているのか分からない

  • Svelteが本当に好きで、より複雑なアプリにはSvelteKitを使っている。
    以前ならReactを使っていただろう多くのケースで、はるかに良い改善だと感じた。
    Svelteは、Web開発、HTML、CSS、JavaScriptの基本を知っている人にとって、ずっと学びやすく見える。ところが最近はWeb開発をReactから始める人をよく見かけるが、順序が少し逆な感じがする。
    個人的にはSvelteKit + Capacitorでモバイルアプリを作っていて、設定はここに書いた: https://bryanhogan.com/blog/web-to-app-sveltekit-capacitor
    シンプルなランディングページにはAstroを好む

    • 私もいつもSvelte + SvelteKitを先に選ぶ。シンプルなアプリにKitを使うのはやりすぎかもしれないが、予想外に複雑になったときに持っていると助かる。
      最近の人たちがReactでWeb開発を始めるのは順序が逆だという点に同意する。SvelteはHTMLを母語のように扱うので、この問題をうまく防いでくれる。Svelte(Kit)でWeb開発を始めれば、Reactで始めるよりも基礎を多く学べる可能性が高い
    • 自分にはSvelte + Astroの組み合わせが合っている。ドキュメントサイトや、選択的にインタラクションが入るページにとても良い

  • 私はReactを可能にした人たちの一部だったのでバイアスはあるが、Reactが本当に好きだ。それ以前は、フロントエンドで直面する問題を直すためにあらゆることを試していた。しかしReactが登場してからは、そうする必要がなくなり、ただ作ることに集中できるようになった

  • とても良かった発表の一つが https://www.youtube.com/watch?v=h9SDuTSy7ps。私の経験では、React のアーキテクチャは本当に優れていて、大規模なアプリケーションを作るのにかなり向いている
    残念ながら React の最大の問題は、JS/TS エコシステムに入ることを強制される点。私にとって JavaScript/TypeScript は、疑いなく直接扱いたいシステムというよりコンパイル対象に近い
    Elm には満足している。コミュニティは本当に小さく、ときにはライブラリを自分で作らなければならない。TEA は React から来た立場だと時々不自然だが、useEffect のような暗黙的で予期しない状態を心配しなくていいので、Elm で作業しているときはいつも楽しい
    しかも Claude は、少なくとも大きくて厄介なコードベースの中では、React より Elm のほうでよりうまく持ちこたえるように見える

    • 私の経験では Elm は事実上死んでいる。今も動くライブラリがある React と TypeScript を使ったほうがいいだろう。TypeScript をネイティブにコンパイル可能にしようという試みもあった
    • TEA は好きだが、再利用可能なコンポーネントや十分に複雑なページを持つアプリで、どうスケールするのかを完全には理解できていない。これを扱うための合意されたやり方があるのか気になる
      状態は大きなタブーのように見えるので、少し衝突しているようにも思える。結局のところ、すべての Elm アプリは副作用のないグローバル Redux + React アプリになるということなのかも気になる。Elm の何が楽しいのか、どんなふうに作業するのかをもっと詳しく知りたい。リンクも歓迎