はじめに
当記事は以下の記事の補足となります。
この記事は、Webアプリ開発に限定して、WebフレームワークやWebアプリに関するライブラリの2000年～2025年までの変遷を整理してみます。この記事で取り上げたフレームワークについては以下の注意点があります。
当記事で採用したフレームワークやライブラリに関する注意点
・他のフレームワークやライブラリに影響を与えたと思われるもの。
・各領域でもっとも利用されていると思われるもの。
・それまでのフレームワークやライブラリになかった特徴を有していると思われるもの。
見出しの年数は、リリースされた年数です。現場で見ていた感じ、実際に流行りだしたのは、リリース年から数年後だと思います。
取り上げたフレームワークやライブラリがある程度の数あるので、先に一覧を掲載します。
フレームワークやライブラリの変遷
１．Struts（2001年）：フルスタックフレームワーク
２．Ruby On Rails（2004年）：フルスタックフレームワーク
３．jQuery（2006年）：DOM操作ライブラリ
４．Flask（2010年）：マイクロフレームワーク
５．Bootstrap（2011年）：CSSフレームワーク
６．React（2013年）：コンポーネントライブラリ
７．Next.js（2016年）：フロントエンドフレームワーク
８．Material UI（2018年）：UIコンポーネントライブラリ
９．Tailwind CSS（2019年）：CSSフレームワーク
１０．Streamlit（2021年）：UIフレームワーク
以下、それぞれについてコメントをしていきます。
Struts（2001年）：フルスタックフレームワーク
まずは、2000年前半にJavaの現場で多く採用されたのが「Struts」です。
Strutsの特徴としてよく指摘されたのが、「MVC」によるモジュールの分割、カスタムタグでHTMLタグに近い形式で動的処理を記載できたことです。今のWebフレームワークの原型のようなものと言えるでしょう。
以下の 「Rubyist Magazine」 で指摘されているように、2000年前半は、Strutsがとても有名なWebフレームワークでした。
Rails が公開されたのは 2004 年である。2004 年の Web アプリケーション開発というのは、一言で言えば Struts の時代だった。 Struts によって、Web アプリケーションフレームワークの世界でも、「MVC」という言葉が広く使われるようになった。
Strutsの特徴
・MVCによるモジュール分割：データ取得をするModel（M）、データの表示を行うView（V）、処理の実行を制御するController（C）にモジュールを分割し、コードの役割を分化、明確化した。
・カスタムタグ：Javaで作成したモジュールをカスタムタグと関連づけて、XMLやHTML内で呼び出せるようにし、設定や画面のコーディングをしやすくした。
・XMLによるバリデーション定義：手続き的なプログラムでバリデーション定義をするのではなく、条件のみをXMLで定義し、簡素化しました。
2025年現在、稼働数はおそらくそこまで多くないと思いますが、Strutsで作られたシステムが稼働しているようです。
ただし、セキュリティホールなどが見つかり、近年、Javaで新しくシステムをつくるときは、SpringBootを使うことが多いと思います。
Ruby On Rails（2004年）：フルスタックフレームワーク
続いては、「Ruby On Rails」(以下、Rails）です。これは今でも有名なフレームワークであり、PHPで有名なWebフレームワークの「Laravel」など他のWebフレームワークに多大なる影響を与えました。
Railsのメリットとなる特徴は以下だと思います。（MVCはRailsだけの特徴ではないので省略します）
Railsの特徴
・DRY（Don’t Repeat Yourself） を実現する機能：DRYとは「同じコード・同じ情報を何度も書かず、1カ所だけに記述する」ことです。たとえば、モデルクラスをコマンドで生成すると、それを元にDBテーブルを作成できます。１つの作業で、いろいろな生成物ができるので便利です。
・CoC（Convention over Configuration：設定よりも規約） ：CoCは、あらかじめRails側でルールを決めており、それに従ってコーディングすればよいことを表します。たとえば、Railsでは、テーブル名は複数形になると決まっています。その他、メソッド名、クラス名などもある程度決めてくれているので、プログラマーが色々考えて設定（設計）することがありません。
・RESTful：REST（Representational State Transfer）は、システムの情報や状態遷移に関する設計原則ですが、Railsはそれに即したシステムを作ることができます。具体的には、HTTPメソッド、ルーティングが、DBなどのリソースの操作方法と対応しており、分かりやすい仕組みになります。
Railsは上記の特徴により、初学者も学びやすく、設計の悩みを減らし、製造やメンテナンスのし易いシステムが製造できます。このメリットがあったからこそ、他のフレームワークへ多大なる影響をあたえ、多くの企業がシステム開発に採用しています。2025年時点でも多くのシステムがRailsで稼働しています。
Railsが普及する背景としては、Javaのフレームワークを代表とする煩雑なフレームワークやオレオレフレームワークがあったのではと個人的に思います。
JavaのWebシステム開発は、XMLでいろいろな設定をすることがあります。また、モジュールも多く、いろいろなコードを書く必要があります。また、コード自体も冗長な印象がありました。もちろん、EclipseやNetBeansなどのIDEで設定やコーディングを楽にすることはできましたが、理解したりそれを設計と絡めるのは大変です。
こうした煩雑なWebアプリ開発を、楽に、そして、分かりやすくしたのがRailsであり、それゆえ現在に至るまで多くのシステムで採用されているのだと思います。また、Rubyも、文法が直感的で、短く書きやすいのがコードの可読性をあげ、コーディングの負荷を減らしたように思います。
jQuery（2006年）：DOM操作ライブラリ
今度は、フロントエンド側のライブラリの「jQuery」です。2025年の現在でも動いているシステムはあるし、使われることもあると思います。
jQueryの特徴
・シンタックスシュガー（糖衣構文）：JavaScriptでDOMの操作をするコードは長くなるが、それを短く、直感的なコードでかける。
・非同期処理（Ajax）の容易さ：フロントとサーバを非同期で通信する処理を少ないコードで実装できる。
※シンタックスシュガー（糖衣構文）は、同じ処理を、短く、分かりやすくした構文です。
ReactやVueなどのコンポーネントライブラリがでるまでは、世界中での多くのWebサイトやWebシステム使われていました。
コンポーネントライブラリが登場してから、jQueryの採用は減り、評価も高くないですが、簡単なDOMの操作であればjQueryの方が手軽だと思います。
jQueryが流行した背景には、フロントエンド側の動的処理が増えてきたことが大きな要因としてあります。社会的に、Webアプリを利用することが多くなり、より利便性をもとめてフロントエンド側の動的処理が増えたと思われます。
Flask（2010年）：マイクロフレームワーク
jQueryの普及の背景には、フロントエンド側の動的処理の増加があります。それに従って、元々、バックエンド側で処理していた画面の処理が、フロントエンド側に移行されました。
これにより、バックエンドの処理はMVCでいえば、Viewの処理を持たなくてもよくなり、シンプルな機能が求められてきました。この機能がシンプルなフレームワークは、「マイクロフレームワーク」と呼ばれます。それと対比して、Railsのような画面の処理も実装したものは、「フルスタックフレームワーク」と呼ばれます。
マイクロフレームワークの中でも有名なのは、「Flask」だと思います。
FlaskはPython製のフレームワークです。Webアプリ開発全体のなかでは、それほど多くはないですが、マイクロフレームワークに限っていえば採用していた現場は多かったように思います。大手企業でも結構採用しているのを見ました。
Flaskの特徴は、以下のようなバックエンド側の最低限の機能を備えていることだと思います。加えて、Python製ということもあり、コードは読みやすい印象があります。
Flaskの特徴
◯リクエストに応じた処理を実行し、データを特定の形式でレスポンスするだけの機能に絞った軽量さ。
・ルーティング：URLを処理モジュールと対応付ける。
・テンプレートエンジン：テンプレートを利用することで与えられた表示形式に簡単にデータを設定できる。
・リクエスト、レスポンス処理：HTTPのリクエストとレスポンスを容易に実装できる。
・セッション管理：Cookieをつかったセッション管理を容易に実装できる。
DBの処理などは、SQLAlchemyなど任意のライブラリを組み合わせて実装していきます。要は必要に応じてアドオンして拡張していきます。
Flaskなどのマイクロフレームワークは、Railsにより普及した、URLとデータ処理を対応づけるRESTfulAPIをより簡単に実装できるようにしました。
マイクロフレームワークは学習コストが少なく、コードは単純なので製造やメンテはしやすいと思います。
Bootstrap（2011年）：CSSフレームワーク
2010年頃になると、Webがビジネスの中で重要な位置を占めるに従って、WebアプリのUIも分かりやすく、見栄えがよくなっていきました。
Webアプリでデザインをよくするには、CSSを利用する必要があります。ただ、CSSの全体設計、部品ごとの定義はかなり煩雑です。
また、2007年にiPhoneが登場してから、Webサイトのデザインにも大きな変化がありました。それは、スマホとPCの両方にデザインを対応する「レスポンシブ」対応です。
アプリ全体でのデザインの統一感、レスポンシブの対応をCSSで作り上げるのはかなり大変です。そこで登場したのが、Twitter（現X）社がリリースした「Bootstrap」というCSSフレームワークです。
リリースしてから長い期間、いろんな現場で使われていたのを覚えています。今でもバージョンアップを続けており、採用しているアプリもあると思います。以下が、Bootstrapの特徴です。
Bootstrapの特徴
・統一されたUIコンポーネント：ボタン、フォームなどのパーツのデザインを簡単に実現できるクラスが用意されている。
・配置、大きさ、形状、装飾、アニメーションなどのユーティリティクラス：配置（レイアウト）、大きさ（サイズ）、形状（形、フォントなど）、装飾（色など）を直感的に、簡単に設定できるクラスが容易されている。
・レスポンシブ対応：ブレークポイントに応じたクラスを指定することでスマホやPCなどの画面に応じたデザインができる。
React（2013年：OSS化）：コンポーネントライブラリ
Reactは、2025年現在、Webのフロントエンドエンジニアで知らない人がいないライブラリだと思います。
私が色々な現場をみている感じ、最も採用が多いと感じます。今となっては、コンポーネントライブラリのデファクトスタンダードといってもよいと思います。
他にも、Vue、Svelte、Angular、HTMX、Alpineなどがありますが、Reactは、2025年時点では最も採用されているライブラリです。Reactの特徴は以下です。
Reactの特徴
・コンポーネントアーキテクチャ：jQueryのようにプログラム内でHTML上の部品（DOM）を扱うのではなく、部品自体をカスタムコンポーネントとして作成します。それをHTMLコード内で、タグとして呼び出します。
・宣言的ビュー：画面で利用する部品は、HTML内にタグとして記載します。処理パラメーターは、タグの属性として設定します。
カスタムコンポーネントの実装部分についても、コンポーネントがどのような値を扱い、何をするのかをクラスメソッド、または、関数で定義し、HTML上の構造をJSXで端的に定義します。「宣言的」と言われるのは、処理の流れを定義するのではなく、どのように振る舞うのかという状態や関係性を端的に記載するためです。
・仮想DOM：画面に描画するDOMをプログラム内に保持し、変更された値と関係があるDOMのみを画面に描画する。jQueryのように画面を作成する処理が実行されるたびに、DOMを読み込むより速く動作する。
・JavaScriptやTypeScriptのコンテキスト内で処理を定義：同じコンポーネントライブラリのVueやAngularと異なる点としては、JavaScriptやTypseScriptのコード内にJSXを用いてHTMLのタグを含めます。一方、VueやAngularはどちらかというと、HTMLをベースにして、そこにJavaScriptやTypeScriptの処理を記載します。Reactの方がプログラマーとしては、言語のコンテキストが変わりにくいためコーディングしやすいと感じる人もいるようです。
SPA（Single Page Application)というアーキテクチャが普及するに従って、フロントエンドで値を保持して、画面の描画を定義することが増えてきました。コンポーネントライブラリは、値の変化によって即時的に描画する処理を少ないコード数で定義することができました。また、画面の部品ごとに処理をまとめて定義できるので他への影響を限定化したり、コードの可読性が良くなりました。
コンポーネントライブラリによって、値と更新対象の部品をパッケージ化することは人間にとっては理解しやすかったので、2025年もなお利用されているのだと思います。
Next.js（2016年）：フロントエンドフレームワーク
Next.jsは、Reactを画面のコンポーネントライブラリとするフロントエンドフレームワークです。Reactはただの部品を作るライブラリに過ぎません。一方、Next.jsは、Reactで作られたコンポーネントのコードファイルの配置、ルーティング、ビルドなど部品を統合して、Webアプリ全体構成します。
Next.jsの特徴
・ファイルベースルーティング：ファイルを配置したらそれがURLのパスと対応する。
・複数のレンダリング指定可能：ビルド時に以下のレンダリング方法を利用できる。
Client Side Rendering（CSR）
Server Side Rendering（SSR）
Static Site Generator（SSG）
Incremental Static Regeneration（ISR）
・モジュールレイアウト：ページ、コンポーネント、レイアウトなどのモジュールファイルの配置場所が決まっている。
・ゼロコンフィグ：事前設定などなくインストールしたらすぐに利用できる。（細かく設定も可能）
フロントエンドフレームワークとしては、他に、Vueに対応するNuxt.js、Sevelteに対応するSvelteKit（前Sapper）などがある。
フロントエンドフレームワークは、コンポーネントライブラリが部品を作るだけのライブラリであるが、それらを統合、ビルドするために利用される。
ちなみに、SPAアーキテクチャが流行り出したころから、フロントエンドでは「ビルド」工程が一般化しました。C言語などのビルドと近いものがあります。Webのフロントエンドのビルドは、JavaScript、TypeScript、CSSをコーディングした後、ブラウザで実行できるコードに変換することを指します。
なぜ、このビルドが必要かというと書きやすいコードが、ブラウザで実行できるコードではできないからです。ですので、一度、人間が書きやすいコードで書いて、ビルドしてブラウザで実行できるようにしています。
Material UI（2018年）：UIコンポーネントライブラリ
フロントエンドでコンポーネントを作ることが一般化してきました。ただ、ゼロからコンポーネントを作り、デザインをするのはやはり大変です。そこで予めUIの部品となるコンポーネントをつかえる、UIコンポーネントライブラリの採用が増えてきました。代表的なものとしては、Material UI、Chakra UI、Next UIなどがあります。
中でもMaterial UIは、特に有名だと思います。Githubのスター数は、2025年2月時点で9.4万あります。ちなみに、Chakra UIのスター数は、3.8万です。
Material UIの特徴は以下です。
Material UI CSSの特徴
・マテリアルデザイン：Googleの提唱するマテリアルデザインでコンポーネントのデザインが統一されている。
・汎用的なコンポーネントセット：よく使われる画面コンポーネントやレイアウトを簡単なコードで実装できる。
・直感的なAPI：呼び出すコードが直感的であり、コードの可読性が高く、学習コストが低くなる。
コンポーネントライブラリを使うことで、部品を製造する工数を削減でき、画面の製造を容易に行えます。プログラマーは、ビジネスロジックの実装に時間を割くことができます。
Tailwind CSS（2019年）：CSSフレームワーク
Reactなどのコンポーネントライブラリで開発することが一般的になると、JavaScript（TypeScript）ベースで作られたコンポーネントのデザインをすることが増えてきました。
処理に応じたデザインの変化などを考慮すると、Bootstrapなどの予めオールインワンで定義されたスタイルより、独自でスタイルを定義したいというニーズも生まれてきました。
このようなニーズに応えるCSSフレームワークとして「Tailwind CSS」があげられます。Tailwind CSSの特徴は以下です。
Tailwind CSSの特徴
・ユーティリティファースト：コンポーネント単位ではなく、スタイルを細かい単位でCSSより直感的に短かく定義したユーティリティクラスがある。コンポーネントのスタイルを定義する場合、ユーティリティクラスを複数組み合わせる。
・必要なクラスのみ利用：ビルドをする際に利用するクラスのみが使われる。そのためデプロイされるコードファイルのサイズが小さくなる。
以上のように、コンポーネント単位で処理に応じて細かくスタイルを定義できるのがTailwind CSSのメリットだと思います。
ただ、CSSよりは分かりやすく、書きやすいですが、ただクラスの組み合わせを考えたりするのはやや面倒だと感じます。
ですので、TailwindUI、daisyUIなど、Tailwind CSSをベースにしたコンポーネント単位のCSSライブラリがあります。
Streamlit（2021年）：UIフレームワーク
コンポーネントライブラリの採用が増えるにつれて、Webアプリは、フロントエンドとバックエンドしたアーキテクチャが増えてきました。
大規模システム開発では、複数人でフロントエンドとバックエンドを分担して開発できるので、作業の煩雑さは少ないです。また、互いに影響を抑えて開発できます。
インフラに関するメリットもあります。フロントエンドとバックエンドは分けている方がよい面もあります。たとえば、フロントエンドはCDNにデプロイし、バックエンドはAPIサーバとして別に配置することで、フロントエンドとバックエンドを１つのサーバで受け付けるよりは、1台当りのサーバ負荷が減ります。AWSなどの従量制のマネージドサービスを利用している場合は、コスト抑制にもなります。
ただ、小規模のWebアプリを作る場合、フロントエンドとバックエンドが分かれているのは作業の負荷が高いです。また、Webのフロントエンドのビルドの準備も煩わしいです。特に、データ解析などを行うPythonプログラマーにとって、JavaScriptやTypeScriptを使うことを避けたいと考える人が多くいます。
そこで登場したのが、PythonだけでWebアプリが作れるUIフレームワークです。特に有名なのが、Streamlitです。Streamlitの特徴は以下です。
Streamlitの特徴
・Pythonだけでコーディング：PythonのコードだけでWebのUIが作れます。もちろん、バックエンドの処理もPythonでコーディングできます。
・Reactコンポーネントを利用：画面のパーツは、Reactでデザイン済みのコンポーネントが使われます。簡単なコードで「モダン」なUIを実装できます。もちろん、Reactでカスタマイズのコンポーネントも作れます。
以上のように、PythonだけでWebアプリのフロントエンドとバックエンドのコーディングしたできます。これは、データ解析など、Webアプリ開発が専門でない人にとってはとても便利なフレームワークです。ちなみに、Pythonだけでなく、RailsやPHPのフレームワークのLaravelでもフロントエンドとバックエンドを分けない開発ができるようになっています。このような技術をHotwireと呼びますが、Rails7以降の公式ドキュメントにHotwireが標準になっていると
Hotwire, the default front-end framework for Rails.
ちなみに、2024年にPythonだけでアプリが作れるライブラリについての記事を投稿しました。
この記事の中でも触れた、Reflexというライブラリは、この記事で触れた技術を使っているがPythonだけでWebアプリが作れます。ちなみに、Next.js、FastAPI、Reactのコンポーネントライブラリ（ChakraUI、Radix）を内蔵しています。Reflexは、Amazon、NASA、DELL、IBM、SAMSUNGなどでも利用されているようです。
今後、Ruby、PHP、Python以外のプログラム言語でもこうしたフロントエンドとバックエンドを分けない、また、一つの言語でWebのUIを作れるライブラリはでてくるのではないでしょうか？
フレームワークやライブラリの変遷の背景
ここまでに言及したフレームワークやライブラリは、他のフレームワークやライブラリへ影響を与えたと思われる著名なものとなります。もちろん、私が現場でみてきたものであり、主観的な評価ではあります。また、ここに掲載していないが広く利用されているフレームワークやライブラリもあります。それについては、本文に少しずつ名前を記載しています。
さて、列挙したフレームワークやライブラリの変遷から、以下のような背景がうかがえます。
技術変遷の背景
・社会的にWebアプリへのニーズが高まり、システムが大規模化したり、様々な立場のユーザーが増えて、ビジネスで利用されることが増えてきた。
・大規模システムを、パーツにわけて開発する必要性が出てきた。
・Webアプリが様々な立場のユーザーに使われたり、Webサイトが商品やサービスの売り込みに使われた。これにより、分かりやすく、訴求力のあるデザインが求められた。
・上記のニーズを満たすために、複雑化したシステム開発をできるだけ簡易化したり、効率化する方法が模索された。
2023年～2025年の技術動向を見ていた感じ、Webのフレームワークやライブラリについてはあまり変化はないように思いました。もちろん、各フレームワークやライブラリ内での変化はありましたが、フレームワークやライブラリ自体の世代交代のようなものはないように思います。
2024年以降は、生成AIによるAI駆動開発に関心が移ってしまったのも変化が見られない要因かもしれません。