１．1990年～2000年初頭：カオス・黎明期
インターネットが流行り始めた頃は、HTMLに装飾を記述し、CSSに装飾を書くなどの分離はあまり見られなかった。
また、Javascript（以下、Js）の利用も限定的で、画面の要素をJsで作ったり、ましてや、コンポーネントの発想などほぼ見られなかったように記憶している。
見た目のデザインとコード構造もカオスだった時代。
※@error_401さんのコメントにあるように、Javaでのシステム開発が多く、Java Appletによって動的な画面作成もあった。若い人は、Appletの存在はわからないかもしれないけど、少しの間、ブラウザにもその設定があった。
また、AdobeのFlashによる動的コンテンツの作成もあった。Appletよりは長く使われており、Jsでの動的なコンテンツ作成の前には、AdobeのFlashでの開発が多かったと思う。
１－１. この時期のサーバサイド：JavaやASP.NET以外のスクリプトは設計が混沌としていた
この2000年初頭ぐらいは、フロントとバックという意識はあまりなく、サーバサイドでMVCのV:Viewを作り、それをブラウザに返すというものだった。このとき、MVCをごちゃまぜにしたような設計もあったが、テンプレートを使い、ViewとMCを分けたものも徐々に生まれていた。
ちなみにこの時期よくつかわれていたサーバサイドの言語は、Perl、Java、PHPだったように思う。特に、Perlはレンタルサーバを中心によく使われていた。PHPよりも多かったのかもしれない。
Javaは金融など大手企業などのシステムで使わるようになっていった。それまで、COBOLやCなどでつくっていたものをJavaで置き換えるのが始まった時期だと思う。そして、この頃から、「オブジェクト指向設計」が声高に叫ばれるようになっていった記憶がある。
まだこの時期においては、有名なサーバサイドのフレームワークもJavaと後述のASP.NET以外はこれというものがなかったと思う。多くのWebフレームワークの始祖といってもよい、JavaのStrutsは2000年に生まれている。
Windows系のサーバでは、ASP.NET(2002)を使ってサーバサイドを作っていた。AccessをDBにしたシステム開発に携わったことがある。
インフラで言えば、大手はデータセンターに自前のサーバを設置したり、小さい規模であればレンタルサーバに設置するのが多かった。その頃は、「cgi」で動的なサイトをつくることも多かった。今でも使えるが、最近はこの拡張子はあまりみなくなった。そして、サーバにはFTP接続でソースをアップし、FFFTPを使うことが多かった。
２．2000年中期：SEO（サーチエンジン最適化）の普及とHTML/CSSの分離
徐々に、インターネットが生活の中に浸透してきて、ネット検索がビジネス上でも重要だという認識が生まれてきた。
それに伴い、Googleなどのロボット型のサーチエンジンへの最適化（SEO）を考えたコーディングをするようになっていった。ちょうど、この頃、SEO対策をする会社も増えてきた。
これと連動する形で、データ構造と装飾を分けて、検索エンジンが情報を拾いやすい構造にしようとなり、HTMLとCSSを分化した設計が定着してきた。もちろん、米国で先に火がついて、それを日本が真似るという形なので、日米では流行った時期が若干ずれている。
ちなみに、SEOという言葉自体は、1991年には生まれていたそうである。
３．2006年～：jQueryの登場、Jsを使った動的なフロント開発が徐々に広まっていく(DOMライブラリの普及）
2006年にjQueryが登場し、その時期ぐらいから米国を中心にブラウザ上で動的に画面要素を更新したりする作りが徐々に広まってきた。日本でも2010年頃にはこうした流れがみられていたように記憶している。
当時は、jQueryだけでなく、prototype、Yahoo！ Ui LibraryなどDOM操作ライブラリがいくつか乱立していた。まだ、SPA（Single Page Application）という発想は普及しておらず、画面上のDOMを操作することがJsのメインだった。
この頃は、まだ、Jsの設計思想もそれほど定式化したものはなく、HTML内に記述したり、scriptタグで外部リソースを読み込んだり、種々雑多であったように思う。
※@Tanoemon さんのコメントでAjaxについてご指摘頂きましたので、追加です。
３－１. Ajaxによる非同期処理の普及
2006年あたりにAjaxに関する書籍がいくつか出版されていたが、この時期ぐらいからAjaxによる非同期通信処理も広まっていった。技術的には1999年あたりから存在していた（Wiki参照）。
３－２. バックエンドとフロントエンドは未分化
まだこの頃までは、フロントとバックという切り分けはなく、MVC設計で、V：Viewの中にJsは「おまけ」的に付随していた。Struts、CakePHPなどいわゆる、Webのフルスタックフレームワーク全盛の時代である。この頃に、「Ruby on Rails」も生まれた(2004）。
私は当時はPhperだったので、CakePHP(2005)、ZendFramework(2006)、Symphorn(2005)などを使っていた。そして、このぐらいの頃からフレームワークを使って作るのが当たり前になっていた。
４．2010年～：SPA（Single Page Application）の登場、Jsの設計が徐々に定式化していく
2010年頃、MVVMなどの設計をJsに取り込んだAngularJs(2010)、Backbone.js(2010)、Knockout.js(2010)などのライブラリ、フレームワークが生まれた。そして、この頃からSPA（Single Page Application）という設計も普及していったように思う。
ここに来てやっと、Jsの設計方針が共有されるようになり、HTML/CSS/Jsの分離が綺麗にできだしたように思う。
自分が初めてSPAを採用したのは2012年頃。ちょうどiPhoneが登場し(2007年）、世の中にスマホが普及していった頃だった。その頃は、スマホが3G回線でアクセスしており、アクセスするたびに若干の待ち時間があった。それ故、PCのような画面ごとにサーバにアクセスするような設計ではユーザービリティが低かった。
そこで、SPAを採用し、１度のアクセスで１トランザクションの操作リソースは取得しようという方針に決まった。
４－１. Node.jsの登場
ちなみに、2009年にNode.jsが最初のリリースをされており、ここからWebのフロントやバックエンドの開発が徐々に変わってくる。今から思うと、ここがターニングポイントなのかもしれない。
この時期に、次世代言語と言われるプログラム言語が多く生まれている。Go(2009)、Rust(2010)、Nim(2008)など。
４－２．徐々にフロントとバックが分化してくる
SPAの採用が増えた辺りから、フロントとバックの役割が分化してくる。バックエンドは、RESTfulにして、DBからデータを取得して、JSONを返却するだけという構成が徐々に増えてきた。
この辺りからFlask、マイクロフレームワークというフルスタックより軽量なものが徐々に増えてくる。
４－３．CSSプリプロセッサによるCSSの効率的なコーディング、BEMによる統一的な命名
Sass(2006)の利用がこの頃を中心に現場でもよく見られるようになった。CSSも現場ごとに混沌とした書き方が横行していたように思うが、徐々にSassを利用して再利用性を高めたり、BEM(2007)の命名規則を利用して統一的な設計ががされるようになっていった。
５．2013年～：React、Vueの登場でコンポーネント指向が普及
SPAの設計が広まると更に、Jsでの画面設計が細分化していった。なかでも、「コンポーネント」という発想は、画期的だったように思う。それは、再利用性、可読性を向上させた。
その立役者は、React(2013)、Vue(2014)という２つのコンポーネントライブラリだと思う。これらを利用して、HTML/CSSとJsを分離するだけでなく、更に、画面内の部品とデータモデル・処理をパッケージにしたコンポーネントを作るという設計が広まっていった。
５－１.Node.jsを利用してJsをビルドしていくことが普及していく
この頃には今では当たり前の、Jsのビルドというものが徐々に広まっていった。ECMAScriptやNode.jsの文法で記述し、サーバサイド言語のようなコーディングをしながら、Blowserify(2011）、Babel(2014)などのトランスパイラーを使いブラウザで動くようにしていった。
このビルドもまた、Webの設計において大きな転換点をもたらしたものであると思う。なかでも、Webpack(2014)の登場は大きいと思う。
５－２. AWSなど仮想化をベースにしたクラウドインフラを使うことが徐々に広まる
AWSのCloud Computing自体は2006年には始まっていたが、日本の現場でよくみられるようになったのは、RDSがローンチされた2009年よりも後、別の言い方をすれば、「リーマンショック(2008)」の後だったように記憶している。
そして、徐々に、レンタルサーバやオンプレでのサーバ運用からクラウドインフラを前提としたサービスの運用が増加していった。
６．2018年～：HTML/CSS/Jsの分離から、HTML/CSS/Jsのコンポーネントへの統合という変遷
コンポーネントライブラリのReactもVueもコンポーネントファイルに、HTML/CSS/Jsをパッケージするのが一般的である。
特に、Reactについては、JSXでHTMLを、styled-componentなどでCSSをJs内に包摂するのが一般的である。つまり、Reactは、Jsのソースファイルやコンテキスト内に、HTML/CSSを取り込む形になっている。
これは、HTML/CSSの分離してきた歴史をみると、少し逆行しているように見える。
ただ、これはWebアプリの役割やJsの位置づけが変わってきたことが背景にあると思う。
動的に画面を描画することが増えており、Jsでのコーディングが増えている。Jsのコーダーとしては、HTML/CSSという異なるコンテキスト（言語、ファイル）を分割してコーディングするよりは、Jsで管理した方がコーディングがしやすく、可読性が高い。
HTML/CSSでWebアプリはクロージングすることがなく、最終的には動的なJsによってクロージングを迎える。そうであればこそ、Jsへの要素の統合がなされていっているように思う。
Vueについては、Single File Component で一つのファイル内に、HTML/CSS/Jsが共存していますが、それぞれの領域が分かれており、HTML/CSS/Jsの分離を保っているように思われます。厳密な意味では、ReactほどJsへの統合化はしていないので、分離したほうがよい現場にあっては、Vueは有用かもしれない。
６－１．Netlify、Vercel、Firebase、Faunaなどのサーバレスインフラが普及
AWS、GCP、Azureなどのクラウドインフラは多く使われるようになったが、さらに手間を省くためのサービスとして、Netlify(2015)、Vercel(2015)、Firebase(2012)、Fauna(2015)などのフロントやバックエンドのサーバレスサービスが徐々に使われだしていった。
７．2021年～：フロントとバックの統合：Blitzjsのようなフロントとバックを統合したJs(Typescript)ベースのフルスタックフレームワークの登場
SPAの登場により、フロントとバックは分かれたが、2020年頃からBlitz.jsのようにJs（Typescript）をベースにした、フロントとバックを統合したフルスタックフレームワークが登場してきた。
特にBlitz.jsの特徴としては、Zero-APIという、フロントとサーバサイドが分かれていないようにコーディングできる点だと思う。実際は、別れていてもコーディング上はそれを意識させず、RailsやLaravelのようにサーバサイドのフルスタックフレームワークと同じ感覚でコーディングができる。
これにより、今後は、フロントとバックが再統合されるのかもしれない。
以上が年毎の技術変遷である。
以下は、2021年現在のWebのフロントについての考察になる。
８．HTML/CSSなど標準技術からの乖離：エコシステム前提のガラパゴス化
これまでみてきたように、2021年現在、Webのフロントはコンポーネント指向を採用してつくるのが一般化しており、HTML/CSS/Jsをコンポーネントファイルへと統合している。
当然、標準のブラウザでコンポーネントファイルはそのままでは解釈できないがゆえに、Webpackなどのビルドを経て、CSS、HTML、Jsがブラウザで読み込めるように変換される。
最近、Reactでは、Tailwind CSSの要素を取り入れた、Chakra-uiなどが流行っており、ここにくるとCSSの原型はほぼないといっても過言ではない。
つまり、HTML/CSSの標準技術からはかなり乖離がある。コードリーディングにも別途ライブラリの前提知識が必要であり、CSSで活かせる知識はあまりない。ある意味、ガラパゴス化している。
標準技術でないため、ビルドをはじめとする技術が必要であり、より楽をしようとすれば同様のライブラリを見つけてくる必要がある。つまり、ライブラリを使うための「エコシステム」が前提にあり、便利さが享受できる。
逆にいうと、「エコシステム」がない、消えそうなものを採用してしまうと後々メンテナンスが困ってしまう。なので、比較的ユーザー数が多い、開発が活発で体制がしっかりしている技術を採用していくことが前提になる。「ガラパゴス化」しているがゆえに、潰しを効かせにくいともいえ、エコシステムの存在は大きいと言える。
９．プロジェクトの歴史、開発体制、人数、プロダクトの性質によって設計や利用するライブラリが異なる
Webのフロント技術は、みてきたようにいろいろな変遷を経て今がある。そして、実は、今でも一つの設計がすべてを席巻している訳ではなく、それぞれのプロジェクトの歴史、体制によって異なっている。
時々、TailwindCSSとsytled componentのどっちがいいかとか色々と議論はある。おそらく、それはプロジェクトの資産、歴史、チーム体制、そして、個人の好みによっても異なるのだと思う。
９-1. 長い歴史があったりデザイン変更が多いチームはVueの方が適しているかも
2010年以降から開発をしているチームであれば、HTML/CSS/Jsの分離をしているソースコードも多かったり、それに併せたチーム体制かもしれない。(HTML/CSSコーダーとJsプログラマーが分離）
こうしたプロジェクトにおいては、VueのようなHTML/CSS/Jsがコンポーネント内で分かれている方が分業がしやすいかもしれない。
デザインが特殊なチームにあっては、プログラマー不足を考えると、Vueのように、HTML/CSSの標準技術を使えて、分業しやすい方がいいのかもしれない。
９-2. スタートアップで組織が小さい、あまりデザインの変更がないものはReactの方が適しているかも
一方で、2019年以降に立ち上がったプロジェクト、チームで人数が少ない場合、ReactのようにJs内にあらゆるコンテキストを詰め込んだほうが、開発効率は高いかもしれない。
HTML/CSSのコーダーもおらず、デザインもChakra-UIやMaterial-UIをつかって、Jsプログラマーが編集するのであれば、Js内で完結するReactの方が開発効率は高いと思う。
逆に、こうしたReactメインのプロジェクトの場合、HTML/CSSだけの技術では、UIは作れず、自ずとJs、ひいては、ReactやUIライブラリの知識が必要になってくる。チームメンバーのスキルも変わってくる。
UIライブラリ標準でデザインも変えないのであれば、Reactメインの開発は良いが、デザインを変えることが頻繁にあると、Jsプログラマーへの負荷がかかるか、こうしたJsプログラマーの人数を増やしていく必要がある。
１０. 最後に：歴史、要求、チーム体制によって技術は変わる
Webサイトやシステムの技術や設計の変遷をざっくり整理してみた。時代の制約を受けて、設計思想も変わってくる。
特に最近は、設計や技術も多様化しており、どういったプロダクトを誰と作るのかによって、設計も技術も変わってくるように思う。
10年前ぐらいは、「Javaがいい、オブジェクト指向だ！」とかある特定の設計や技術が席巻していたようにも思うが、最近は、Webシステムへのニーズ、チーム体制、技術、そして、知見も多様化しており、１つの技術や設計を採用すればいいというわけでもない。
自分の置かれたポジションに応じて、採用する技術のメリット、デメリットを評価して採用していく時代なんだなと感じる。