2000年ぐらいから現在に至るまでのWebフロント

HTMLタグオンパレード、1ファイルでMVCすべて実装

　2000年ぐらいにWeb開発をはじめた。
　当時は、HTMLで構造も装飾していた。要はほとんどHTMLで完結。
　ちなみに、デザインという考えも正直なところなく、MARQUEEタグというのがあって、文字が右から左に流れたりするものとか、チカチカするBLINKタグとか、今では、デザイン的に「ダサい」というのが普通につかわれていた。

　ちなみに、Googleでこれらのタグを調べると、ちゃんと検索結果もそういった動作をしてくれる（すげーこまかい！）。

▶ MARQUEEタグの検索結果

• 検索件数が右から左に流れます。

▶ BLINKタグの検索結果

= blinkの文字が点滅します。

　当時も、Javascriptの利用はあったけど、SEO対策とかセキュリティとか、デザインを考慮してあまりつかわれてなかった記憶があります。
　そして、スクリプトの中に、HTMLを直接書き込み、MVCの役割文化などソースレベルではあまりなく、1スクリプトファイルにすべての要素がありました。
　もちろん、CSSも使ったり、使わなかったりで構造と装飾を分けるなんて発想もなく。

GoogleのSEOにあわせて、構造（HTML）と装飾（CSS）が別れてくる

　「SEO対策」という言葉がでてきて、Googleの検索にかかり安いHTMLを書こうという風潮が開発者の間でもでてきました。このころから、HTMLとCSSが明確に分かれていった記憶があります。そして、それは今も続いています。

jQueryの登場

　
　2006年あたりから、徐々に、画面も動的な要素をもとめられるようになり、jQueryやprototypeのように、HTMLのノードや装飾を手軽に記載できるシンタックスシュガー的なライブラリーがでてきました。
　このころからJavascriptを画面で使うことが広まってきたのかなという気がします。

CSSプリプロセッサー（CSSメタ言語）

　2006年にSassが登場し、2009年にLESSが登場しました。
　このころから、CSSも変数や関数をつかって、パーツを使いまわしたり、より書きやすい方法を採用する動きが取られるようになりました。

SPAの登場

2010年あたりから、Knockout.jsなどSPAのフレームワークが現れるようになり、徐々に、Javascriptの役割が増してきました。
PCでみるだけでなく、スマホで閲覧することもこれには影響しているかもしれません。

nodeの登場、Javascriptの文法の変化、そして、ビルドツール

　2009年にnodeが登場し、Javascriptをサーバサイドで使うことが少しずう広まると共に、JavascriptもPHPやRubyのように、構造的にプログラムを書く言語として広まっていったように思います。たとえば、import/exportなどの構文をつかって、ソースを分割したり。

　こうした構造的なJavascript開発した成果物をブラウザで使いたいけど、import/exportが対応していないものがあり、browsrifyでJavascriptをビルドするという方法が徐々に取られるようになりました。

　あわせて、ES6の文法など当時のブラウザでは解釈できないけど使いたい文法で書いて、それをブラウザで読み込めるようにするBabelなどのコンパイルをするということも行うようになってきました。

　つまり、nodeの登場あたりから、Javascriptで、モジュール分割し構造的なプログラムを作ると同時に、ブラウザへの対応を念頭にビルドするという開発手法が徐々に一般化してきました。

2019年現在（分割と統合、それを支えるビルドツール）

　現在のWebのフロントは、HTML（構造）、CSS（装飾・視覚効果）、Javascript(データ構造、処理、動的視覚効果）で役割をわけ、更に、CSSやJavascriptの分割・構造的にファイルをわけて、ビルドするというのが一般化しています。

　Typescriptなどもビルドを前提としたAltJSであり、今や、Webフロントに置いて、構成要素は細かく分化し、ビルドツールで統合されるのが一般化しています。

現在(2019年）のWebフロント開発は発展途上？　パーツとルールが揃った段階

　2000年あたりからWebシステムを開発して、なお、今現在も現役でSPA、PWA、はたまた、ElectronやFlutterなどデスクトップアプリなどにかかわっています。

　昔は、開発準備がかからないけど、開発の無駄、完成後のメンテナンスがしにくかったのは確かです。
　けれど、時代のニーズとしても、見た目も動きも大したものはなかったです。

　今は、Webフロントに求めるニーズも高いし、構造化してきているので、構成要素を分割して作成し、いろいろな人とつくっていくのは当然なことです。
　その過程として、ビルドツールは必要だと思います。それだけみたらとてもめんどくさいのですが、他の要素も考えると結果的に現在の流れは理解できます。

　けれど、やはりめんどくさい。手間がかかる。
　
　交通の進化にたとえるなら、やっと道路や車、自転車がでてきて、交通ルールがうまれたような段階でしょうか。パーツが何なのか、それらがどう振る舞うのか、そして、どういったルールでそれを使っていくのか。
　
Webフロントは、パーツとルールができた段階です。それはそれで進歩だと思いますが、いかんせん、アプリケーションをつくるまでに、このパーツとルールを組み合わせて色々と試行錯誤をしないといけないです。

　これは、Webフロントに限らず、GUI全般にいえることかもしれません。

　GUIで部品をはったら、よろしくしてくれるまでいけばもっと楽なのにとか思ったりします。