フロントエンドでフレームワークが毎年変わる理由

フロントエンドのフレームワークが「毎年変わる」と感じる理由

フロントエンドは不安定な分野だから毎年技術が変わっている、と思われがちですが、実際にはそうではありません。
変わっているのは「流行」ではなく解決しようとしている問題の場所です。問題の場所が移動するたびに、最適なフレームワークが変わっているだけです。

つまり、フロントエンドは場当たり的に新しいものが出ているのではなく、
「ボトルネックが移動 → 最適解が変化 → フレームワークが交代」
という構造で進化しています。

この構造を知らないと、Reactの次は何か、なぜ新しいものが出続けるのかが理解できません。

そもそもフロントエンドの役割が変わり続けている

昔のWebページは、単なる文書でした。
サーバがHTMLを作り、ブラウザはそれを表示するだけです。

時代	フロントエンドの役割
2000年前後	HTML表示（文書ビューア）
2010年前後	UI操作（アプリ的挙動）
2020年前後	状態管理・画面遷移
現在	アプリケーション実行環境

この役割の変化が、フレームワーク交代の本質です。

昔のフロントエンドでは、JavaScriptは補助機能でした。
しかし現在は、アプリケーションの本体がブラウザで動いています。

役割が変われば、必要な設計思想も変わります。
その結果、フレームワークが入れ替わります。

jQueryが最適だった時代

最初の問題は「ブラウザが動かない」でした。

Internet Explorer、Firefox、SafariでDOMの仕様が違い、同じJavaScriptが動きません。
その差異を吸収したのがjQueryです。

jQueryの役割はUIライブラリではありません。
ブラウザ互換レイヤーです。

例えばクリックイベントです。

document.getElementById("btn").onclick = function(){};

昔はこれがブラウザごとに挙動が違いました。
jQueryはそれを統一しました。

$("#btn").on("click", function(){});

つまり当時のボトルネックは「ブラウザ差異」であり、
それを解決する最適解がjQueryでした。

次の問題：画面が壊れる

AJAXが普及すると、ページ遷移せず画面を書き換えるようになります。
ここで新しい問題が発生します。

DOMが複雑になり、管理不能になる

例として、次のような状態になります。

• ボタンを押すとリストが増える
• 削除すると別のUIが更新される
• 並び替えるとカウンターが変わる

jQueryは「操作」は得意ですが、「状態」は扱えません。
どこを変更すれば正しい画面になるのかが人間にしか分からなくなります。

この問題の名前が「状態管理」です。

SPAフレームワークが登場した理由

React、Vue、Angularが解決したのはUIではありません。
状態管理です。

Reactの本質はVirtual DOMではなく、

「状態が変わればUIが決まる」

という一方向データフローです。

つまり

jQuery
→ DOMを直接操作する

React
→ 状態を変更するだけでDOMが決まる

この違いにより、画面崩壊が防げるようになりました。

フレームワークが変わったのではなく、
ボトルネックが「ブラウザ差異」から「状態管理」に移動したのです。

さらに新しい問題：表示が遅い

SPAが普及すると、新たな問題が発生します。

初回表示が遅い

理由は単純で、ブラウザがアプリをダウンロードしてから描画するためです。

SPAの初回表示の流れはこうなります。

1. HTML取得
2. JSダウンロード
3. JS実行
4. DOM生成
5. 画面表示

つまり、ページ表示前にアプリが起動しています。
これがSEOとLCPの問題を引き起こしました。

ここで登場したのがSSRです。

SSRが流行した本当の理由

SSRはSEO対策のため、と思われがちですが半分違います。
本当の目的は描画の場所をサーバに戻すことです。

SPAは「クライアントCPU」がボトルネックでした。
SSRはそれを「サーバCPU」に移した技術です。

方式	描画する場所
SPA	ブラウザ
SSR	サーバ

これにより初回表示が劇的に速くなりました。

つまりフレームワークの変化ではなく、
計算資源の配置変更が起きています。

そして現在：RSCが出てきた理由

SSRでも問題は残りました。

それは「不要なJavaScriptが多すぎる」ことです。

ユーザーが触らない部分までJSが配布され、
モバイル端末でパフォーマンスが悪化しました。

React Server Components（RSC）はここを解決します。

• インタラクションが必要な部分だけJS配布
• それ以外はサーバ描画

つまりRSCはSSRの次ではなく、
JS配布量の最適化です。

フレームワークが毎年変わるように見える本当の原因

ここまでを見ると、共通点があります。

時代	ボトルネック	登場技術
ブラウザ差異	互換性	jQuery
状態管理	UI破壊	React/Vue
初回表示	CPU負荷	SSR
JS配布量	通信量	RSC

フレームワークは毎年変わっているのではありません。
解決対象の問題が移動しているだけです。

よくある誤解と注意点

ここでよくある失敗があります。

「新しいフレームワーク＝優れている」

これは正確ではありません。
新しいものは「新しい問題」に強いだけです。

例えば、社内管理ツールにRSCを導入しても効果は薄い可能性があります。
ネットワーク遅延やSEOが問題でない場合、SSRのメリットが小さいためです。

つまり技術選定は流行ではなく、
どのボトルネックを解決したいかで決める必要があります。

最後に

フロントエンドが落ち着かない分野に見えるのは、技術が不安定だからではありません。
むしろ逆で、Webが本格的なアプリ実行環境へ変化している途中だからです。

jQueryもReactもSSRもRSCも、別々の技術ではありません。
全部「同じ問題の延長線」にあります。

新しいフレームワークを追い続けるよりも、
「何を解決するための技術なのか」を理解した方が、結果的に長く使える知識になります。

流行を追うより、ボトルネックを見てください。
フロントエンドはその瞬間の最適解が名前を変えているだけです。