📣：Web開発トレンドへの適応力を高めたい人に向けて書きました ✍️
はじめに🖐️
こちらをご覧ください。JSフレームワークとOSやブラウザの変遷が大まかに確認できるように作ってみました。
3G,4Gなど通信の変遷も大きく関係しているのは見ていて興味深いですよね。
Webアプリケーション開発におけるフレームワークは、時代ごとに変化する課題に対する「解決策」として誕生し、進化を遂げてきました。本記事では、歴史的背景をたどりながら、なぜその技術が必要とされ、どのような問題を解決したのかを明確に示し、現代のフレームワークが持つ思想や特徴をより深く理解していきます。
免責事項
調べた上ですがあくまで私見です。
少し強引さが伺えるかもしれません。
目的 🧠
歴史を理解することで、「なぜこの技術はこのような構造をとっているのか」「なぜこの設計思想が重要なのか」といった背景が明確になり、新たなフレームワークや手法が生まれた際にも、その土台となる文脈を把握していることで、より的確に吸収できるようになるのではないかという考えからこの記事を作成しました。
フレームワークとは
フレームワークとは、Webアプリを作る上での雛形のことです。Next.js、Angular.jsなどWebアプリを作る際にもう当たり前のように使われていますよね。
フレームワークとライブラリの違い
フレームワークは枠組みを提供するのに対し、ライブラリはアプリ開発における一部の機能のみを提供するのが特徴で、図にも示したように、「部品」を再利用できるように集めたものです。
それでは、歴史を振り返りつつ因果関係を見てみましょう🏃♂️
冒頭の画像も見ながらでGo!
静的Webから動的Webへ：CGIの登場（1990年代）🌅
課題: 初期のWeb（1990年代初頭）は、サーバーから返却されるのは静的なHTMLファイルのみで、ユーザーからの入力や操作によってコンテンツを変えられない「受動的」な仕組みでした。これでは、検索機能や掲示板など、動的なサービスを提供することが困難でした。
解決策: CGI（Common Gateway Interface, 1993年頃）は、ブラウザからのリクエストに応じてサーバ側でプログラム（Perlなど）を実行し、生成したHTMLを返す仕組みを確立。これにより、ユーザー入力に応じた動的コンテンツ生成が可能となり、Webが静的な文書配布媒体から簡易的なアプリケーション基盤へと一歩進みました。
https://www.infraexpert.com/study/tcpip16.5.html
大規模開発への対応：JavaサーブレットとJSP（1990年代後半） 📝
課題: CGIで動的化はできたものの、Perlなどのスクリプト言語中心で複雑なビジネスロジックを扱うのは困難でした。HTMLとロジックが混在し、保守が難しく、規模が大きくなるとコードの複雑さが制御不能になりがちでした。
解決策: Javaサーブレット（1997年）が登場し、より堅牢で大規模開発に向く静的型付け言語Javaを用いて、Webアプリケーションの処理ロジックを分割・整理する道が開かれました。しかし、サーブレット単体ではJavaコード内にHTMLを書きこむ必要があり、依然としてロジックとデザインが密結合。
そこでJSP（JavaServer Pages, 1999年）が誕生。HTML側にJavaコードを埋め込むスタイルを導入し、ロジック（Java）と表示（HTML）の分離がしやすくなりました。こうして大規模で複雑なWebアプリにも対応可能な基盤が整い、エンジニアとデザイナーの分業を実現、保守性が大幅に向上しました。
リッチなUIの要求拡大とAjax（2000年代中盤）🎹
課題: ユーザー体験の向上に伴い、ページ全体の再読み込みをせずに一部コンテンツだけ更新する「リッチなUI」が求められるようになりました。GmailやGoogle Mapsのようなアプリが代表例です。しかし、従来は常にページ全体をリロードする必要があり、ユーザー体験が煩雑でした。
解決策: Ajax（2005年頃）技術は、ブラウザで非同期通信（XMLHttpRequest）を行うことで、サーバーから必要なデータのみ取得して部分的に画面を更新できる仕組みを提供。これにより、滑らかなUIが可能となり、Webアプリは「Webページ」から「Webアプリケーション」へと進化を遂げました。
DOM操作の簡略化とライブラリの台頭：jQuery（2000年代後半）🧑💻
課題: Ajaxによりフロントエンドロジックが増大すると、ブラウザ間でDOM操作・イベント処理に微妙な差異が現れ、同じことを実現するのに複雑なコードや互換性対策が必要になりました。開発者は、フロント側でも共通パターンを抽象化し効率化できる道具を求めるようになります。
解決策: jQuery（2006年）は、DOM操作やイベント処理の差異を吸収し、簡潔なAPIで複雑な操作を可能にしました。$(...)記法などの直感的な書き方により、フロントエンド開発の生産性は大幅に向上。しかし、jQueryはアプリ全体を構築する「設計指針」までは提供せず、あくまで「部分的な便利ツール」に留まります。
これでUI操作は簡略化しましたが、大規模アプリケーションや複雑な状態管理への対応が求められる中、さらなるフレームワークが必要となっていきます。
フロントエンドの構造化：Backbone.js、AngularJS（2010年代初頭） 👊
課題: フロントエンドロジックが増大し、View（UI）とModel（データ）の管理が複雑化しました。jQueryベースの命令的なDOM操作では、イベント増加とともにコードがスパゲッティ化し、保守しづらくなります。フロント側でもサーバサイド同様に、MVCやMVVMといった設計パターンによる構造化が求められました。
解決策: Backbone.jsは軽量なMVCパターンをフロントで実現、**AngularJS（2010-2012年頃普及）**は双方向データバインディングを取り入れたMVVMモデルを導入。これにより、UI更新や状態管理がフレームワークによって自動化・整理され、アプリ全体の構造を統一して考えやすくなります。
図. MVCモデル
図. MVVMモデル
しかし、双方向バインディングは大規模化で状態管理が複雑になるケースも出始め、さらなる洗練が求められていきました。
宣言的UIと単方向データフロー：React、Vue.js（2010年代中盤以降）😎
課題: 双方向バインディングは一見便利ですが、変化のトラッキングが複雑化し、状態が不明瞭になる恐れがありました。また、よりパフォーマンスを最適化するための方法も模索されました。
解決策: React（2013年）は、単方向データフローと仮想DOMを用いてUIを「宣言的」に定義。これにより、状態が変化すればUIが自動で再描画され、開発者は複雑なDOM操作やイベント処理の絡み合いから解放されました。
Vue.js（2014年）も、学習コストの低い設計と仮想DOMによって、Reactほど複雑とならずに宣言的UIを実現。両者はコンポーネント指向を強調し、再利用可能なUIパーツを簡潔に組み立てる手法を標準化しました。
これにより、大規模・複雑なフロントエンド開発でも可読性・保守性が飛躍的に向上します。
初期描画、SEO問題とSSR/SSG、脱・仮想DOMへの流れ（2020年代）😈
課題: SPA（Single Page Application）はリッチなUIを実現しましたが、初期描画の遅さやSEO（検索エンジン最適化）の困難さが問題となりました。さらに、巨大化するJSバンドルや、依然存在するパフォーマンス問題が悩みの種に。
解決策: Next.js、Nuxt.jsなどはReactやVueと組み合わせてSSR（Server Side Rendering）やSSG（Static Site Generation）を可能にし、初期描画を高速化すると同時にSEO改善を達成。またSvelteやSolidはコンパイル時に最適化し、仮想DOMを経ずに高速レンダリングを可能とすることで、パフォーマンス課題を一歩先へと解決へ導きます。
WebAssembly（WASM）はネイティブ近い速度で処理を行う手段を提供し、高負荷な計算・画像処理などを効率化。これにより、フロントエンドをより高度な処理基盤へと拡張する道が開かれました。
AI時代の到来：開発プロセス最適化へ（番外的な立ち位置ですが）
課題: フレームワークが多様化する中、適材適所で最適な技術を選定・実装することは、学習コストと判断力を求めます。さらに、複雑化する要件や高速なビジネスサイクルへの対応が難しくなっています。
解決策: AIアシスタント（GitHub Copilot、ChatGPT、CursorなどAI搭載エディタ）が登場し、コード提案や自動補完、設計案の提示を行うことで、開発者は必要な知識やベストプラクティスに素早くアクセスできるようになります。これにより、フレームワーク選定やコード実装が効率化し、人間はより創造的な課題に専念しやすくなります。
しかし一方で、AIによるコード生成は、ロジック内部を意識せずにコードを受け取る「ブラックボックス化」を招く可能性があります。エラー発生時に原因を特定しにくくなるため、問題解決には依然として「なぜその技術が生まれ、どのような課題を解決しているのか」という前提知識が重要です。
こうした歴史的な理解や設計思想に関する知識を備えていれば、AIが提示したコードの意図を正しく把握し、トラブル時にも迅速に対処できるでしょう。
5. まとめ 🤲
静的Web → CGI：動的コンテンツ提供が課題 → サーバサイドスクリプトで解決
CGI → サーブレット/JSP：大規模化と保守性が課題 → Java基盤でロジックとデザインを整理
JSP時代 → Ajax/jQuery：リッチUIとDOM操作の煩雑さが課題 → 非同期通信＆抽象化されたDOM操作
jQuery → Backbone.js/AngularJS：フロントロジック増大で構造化が課題 → MVC/MVVM導入で可読性・保守性向上
AngularJS → React/Vue：状態管理とパフォーマンスが課題 → 単方向データフロー＆仮想DOMでシンプルかつ高速なUI更新
React/Vue → SSR/SSG、Svelte、WASM：初期描画やパフォーマンス、SEOが課題 → サーバサイドレンダリング、ビルド時最適化、ネイティブ近い処理速度で対処
現代 → AI活用：多様な選択肢と設計判断が課題 → AI支援でフレームワーク選定や実装を効率化し、人間はより創造的な作業へ
以上のように、各技術の誕生は常に「現在抱えている課題」への解決策として位置づけられてきました。過去の経緯を知ることで、なぜ今のフレームワークがそのような構造、思想、機能を持っているのかが理解しやすくなります。さらに、これからのAI時代には、これまで以上に柔軟な開発プロセスとフレームワーク活用が求められ、それらを適切に支援する新たな解決策が登場していくでしょう。
6. おわりに🦶
このような歴史を前提として知っておくことで、これから先にどんなフレームワークやパラダイムが登場しても、なぜそれが求められたのかを理解しやすくなります。その結果、新技術へのキャッチアップがスムーズになり、より神エンジニアとして成長する手助けになるでしょう。
と偉そうに言っている自分ですがまだまだひよっ子🐣なので、日々精進です🏃♂️。。
参考/引用