🌀

React不要論2026

2026/02/28に公開5件

 Reactは「高度なPolyfill」だった
2010年代半ばの未熟なWebプラットフォームにおいて、Reactは極めて優秀な穴埋め（Polyfill）だった
当時のブラウザはAPIが貧弱で、複雑なUIを作るのが困難だった

現在はブラウザの標準機能（HTML/CSS/Web API）が十分に追いつき進化している
かつてReactが担っていた役割の多くは、ブラウザの標準機能でカバーできる
宣言型UIという思想自体は良かったが、現在のReactやNext.jsは過剰に複雑化してしまった



 JSは本来「ちょっとしたこと」を担当すべき
現代のVanilla HTML/CSS/JSで大半のユースケースは事足りる
状態管理やDOM構築のすべてをJSに丸抱えさせる必要はない

手続き型のJSは決して悪くない
過去の手続き型（jQuery時代など）が批判されたのはDOM操作APIが貧弱だったため
現在は標準APIが優秀になり、スパゲッティ化しにくい
DOMの一部を書き換える程度のちょっとした操作なら、手続き型のVanilla JSを使うのが最もシンプルで無駄がない



 考えるレイヤーの比較：Drag and Dropの実装
考えるレイヤー（抽象化の層）は少ないほうがいい
ReactでDnDを実装する場合
仮想DOMと実際のDOMという2つの世界を常に意識しなければならない
Stateの更新、再レンダリングの最適化、useEffectの依存配列など、React独自のルールと格闘することになる
やりたいことは要素を動かすだけなのに、フレームワークのお作法を守るためのコードばかりが増える

手続き型（Vanilla JS等）でDnDを実装する場合
考えるレイヤーは「そこにある実DOMをどう動かすか」の1層だけになる
軽量なライブラリ（SortableJSなど）を使えば、DOMを直接操作するだけで良い



 エコシステムの呪縛からの解放
React専用のライブラリがなくても高い生産性は維持できる
Tailwindが書ければ、ReactがなくてもUIの組み上げは十分に早い

ブラウザ標準タグの進化が著しい
dialogタグを使えば、フォーカストラップやEscキーで閉じる処理をブラウザが勝手にやってくれる
templateタグを活用すれば、SPAレベルのインタラクションも手続き型で楽に作れる
複雑なアニメーションも標準CSSでこなせる



 Webアプリアーキテクチャの自然な姿
Next.jsによるフルスタック開発の限界
Reactと密結合すぎ、フロントとバックの境界が曖昧
RailsやLaravelなどの成熟したFWが標準で持つ、認証、認可、ORM、バックグラウンドジョブ、メール送信、ファイルストレージ操作といったエコシステムが欠けている

MPAの再評価
サーバーがHTMLを返すというWeb標準の通信のほうが自然なアプローチ
TurboやHTMXは、この標準の自然な拡張として機能する
状態管理はサーバー側に任せ、クライアントは受け取ったHTMLの断片を差し替えるだけで済む



 まとめ
Reactエコシステムがないと開発できないというのは思い込みだった
普通のWebアプリを作る上で、二重管理などの不要な複雑さを持ち込むべきではない
成熟したバックエンドFW + Turbo/HTMX + Tailwind + ちょっとした手続き型のJS、という構成が、考えるレイヤーの少ない実用的な最適解になる

Discussion

まっきんとっしゅ

質問です！
ReactでDnDを実装する場合
に
仮想DOMと実際のDOMという2つの世界を常に意識しなければならない
とのことですが、具体的には何を意識する必要があるのでしょうか？

Reactを使っている場合とそうでない場合で具体的に何が異なるかを詳しく教えてほしいです！

ごりへい

「自然」や「Web標準」といった表現が設計思想なのか仕様上の話なのかがごちゃ混ぜになっているように思います。
筆者にとっての最適解は理解できますが、それがWeb開発全体の最適解になるわけではないと感じました。

shuent

それがWeb開発全体の最適解になるわけではない

最適解があるならWeb用の開発FWやセオリーが1つで良い訳ですし、全くもってその通りです。

shuent

思いの外バズって

Reactヘイトでインプ集めたみたいで嫌ですね

びびったので言い訳させてください
ただ振り上げた拳を下ろすわけにはいかない、、！
Reactのf(state) という思想は好きだし、

ちょっとしたフロントエンド中心のアプリ作るなら楽。

今だとAIのプロトタイピングはReact中心にコーディングされるし。

裏側の仕組みは置いておいて、データをjsxで表現するのは可読性と生産性高いですし。
export default function App() {
  const user = {
    id: 1,
    profile: {
      name: "Taro",
      contact: {
        email: "taro@example.com"
      }
    }
  };
  return (
    <div>
      <h1>User</h1>
      <p>ID: {user.id}</p>
      <p>Name: {user.profile.name}</p>
      <p>Email: {user.profile.contact.email}</p>
    </div>
  );
}
この記事を書こうというドライバーになったのは、
Vercel帝国で Next.jsのためのReactという方向に拡張が進み、フロントエンドライブラリだったはずのReactが大きく拡張されすぎて、正直なところ何がコアなのか分かりづらくなってきている、
SSRと同じ「サーバーからHTMLを配信する」なら、シンプルにやれる方法に戻れるよね、
と考えたことからでした。
整理したら、Reactそのものというより、

エコシステム全体の複雑化や、Next.js前提で進んでいく流れへのつらみへの文句でしたね。
気軽に主語でか発言するんじゃないですね。

musoukun

ヘイトとかって言ってこんなん白黒つける事でもない。
僕はこの考えめっちゃすこれる。AI時代にはマジでこの考え大アリのアリでしょ。
わかってる人にはわかる。

ブラウザの機能で補っていけるのも共感。