JavaScriptフレームワークの歴史と2026年の現在地 — 仮想DOMからシグナルまでの4つの転換点
JavaScriptフレームワークの歴史は、流行の移り変わりというより「UIの更新をどこで、どう計算するか」という問いへの答えの変遷です。整理すると転換点は4つあります。(1) DOM操作の抽象化、(2) コンポーネントと仮想DOM、(3) サーバーへの回帰、(4) コンパイラとシグナル。そして2026年10月現在、利用状況のランキングはほぼ動いておらず、論点は「どれに乗り換えるか」から「どのレンダリング方式を選び、サポート期間の中でどう更新し続けるか」に移っています。歴史を押さえる意味は、この判断軸を手に入れることにあります。
第1期:DOM操作を抽象化した時代(2000年代後半〜2012年ごろ)
最初の課題はブラウザ間のDOM API の差異でした。jQuery はその差異を吸収し、セレクタとメソッドチェーンで「要素を取ってきて書き換える」書き方を標準化しました。続いて Backbone.js や AngularJS が、データとビューを結びつける構造(MVC/MVVM)を持ち込みます。AngularJS の双方向データバインディングは「状態を書き換えれば画面が追従する」という発想を広めた一方、更新の経路が追いにくいという課題も残しました。なお AngularJS は Angular の v1.x 系列を指す呼び名で、現在の Angular(v2 以降)とは別物として扱われています。
第2期:コンポーネントと仮想DOM(2013年〜2019年ごろ)
2013年の React 登場以降、UI を「状態を受け取って描画結果を返す部品」として記述するモデルが主流になります。React は状態が変わるたびに描画結果をJavaScriptのオブジェクト(仮想DOM)として作り直し、前回との差分だけを実DOMに反映する方式を採りました。Vue.js も同様のモデルを採用し、Angular は 2016年の v2 で TypeScript 前提の全面刷新を行います。2019年の React Hooks は、クラスを使わずに状態やライフサイクルを扱う書き方を定着させました。この時期にSPA(単一ページアプリ)とバンドラ中心のビルドが当たり前になります。
第3期:サーバーへの回帰(2019年〜2024年ごろ)
SPA が普及すると、初回表示の重さとSEO・配信コストが課題として浮上します。ここで伸びたのがメタフレームワーク、つまりルーティング・レンダリング・データ取得までを引き受ける上位レイヤです。Next.js、Nuxt、SvelteKit、Astro が、SSR(サーバーサイドレンダリング)やSSG(静的生成)を既定の選択肢にしました。React 本体も2024年12月5日公開の React 19 で Server Components と Actions を安定版に入れ、「どのコードがサーバーで動くのか」を言語仕様に近いレベルで扱うようになります。
第4期:コンパイラとシグナル(2023年〜現在)
直近の潮流は、仮想DOMの差分計算そのものを減らす方向です。State of JavaScript の編集者は、シグナル(値の変更を購読して必要な箇所だけ更新する仕組み)の普及に Solid の作者 Ryan Carniato が大きく寄与したと指摘しています。Svelte 5 は runes、Angular はシグナルを中核に据え、v21(2025年11月19日)で Zone.js に依存しない変更検知を新規プロジェクトの既定にしました。React は手動のメモ化を肩代わりする React Compiler を 1.0 に到達させ、Next.js 16 で正式サポートしています。Vue も仮想DOMを介さずDOM操作へ直接コンパイルする Vapor Mode を開発中で、2026年後半時点では安定版前の段階と報じられています。採用を検討する場合は公式リポジトリで最新の状況を確認してください。
2026年10月時点の現在地
State of JavaScript 2025(2025年11月調査・2026年2月公開)の結果は、ここ数年で最も「動きのない」ものでした。フロントエンドフレームワークの利用率順位は Alpine.js と HTMX の入れ替わり以外に変動がなく、回答者が職業人生で使ったフレームワークは平均2.6個です。満足度では Solid が利用率10%ながら5年連続で首位。一方メタフレームワークでは Next.js が利用を伸ばしながら満足度を落とし、首位の Astro との差は39ポイント、満足度自体も68%から55%へと最大の下落幅を記録しました。不満点の上位は「過度な複雑さ」で、SSR、デプロイ、ロックインが続きます。
リリース体制も節目を迎えています。Angular は v22(2026年6月3日)以降、それまでの6か月周期からメジャーリリース12か月周期へ移行し、サポートは各メジャー24か月(Active 12か月+LTS 12か月)となりました。v2〜v19 はすでにサポート対象外です。Next.js は 16(2025年10月21日)で Turbopack を既定バンドラにし、16.4(2026年10月6日)で Cache Components をすべてのアプリに推奨する段階へ進め、Next.js 17 での既定化を予告しています。同リリースには React 19.3 が同梱されています。
歴史から導ける選定と運用の指針
以上を踏まえると、2026年の技術選定で見るべき点は次の4つに絞れます。
- 人気順ではなくレンダリング方式から決める。コンテンツ中心なら静的生成+部分的な動的化、更新頻度の高い業務画面ならシグナル系の細粒度更新、というように、画面の性質に合わせて選ぶ。フレームワーク間の機能差は以前より小さく、差が出るのはこの設計判断です。
- サポート期間を前提に更新計画を作る。Angular のように支援期間が明文化されている場合、EOL から逆算して年1回の更新枠を確保しておくほうが、数年分をまとめて移行するより安全です。
- 利用率と満足度の乖離をコストとして読む。Next.js への不満の中身が「複雑さ」「デプロイ」「ロックイン」である以上、採用する場合はキャッシュ戦略とデプロイ先の方針を設計段階で決めておく必要があります。逆に Solid のような高満足度・低利用率の選択肢は、採用人材と周辺ライブラリの確保が実務上の論点になります。
- 移行は段階適用を前提にする。Angular の zoneless は既存プロジェクトでは任意、Vue の Vapor Mode はコンポーネント単位、Next.js の Cache Components は移行支援ツールつき、というように、最近の大きな変更はいずれも部分適用できる形で提供されています。全面書き換えを待つより、影響範囲の小さい箇所から試すほうが現実的です。
フレームワークの歴史は、仮想DOMという一つの前提が絶対ではなくなり、選択肢が「どこで計算するか」で分かれていく過程として読めます。まずは手元のプロジェクトについて、利用中のバージョンのサポート期限と、主要画面のレンダリング方式を書き出すところから始めると、次の一手が判断しやすくなります。既存サイトのフレームワーク移行や、レンダリング方式を含めた設計の相談先をお探しの場合は、お問い合わせからご連絡ください。
