モダンフロントエンドまでの歴史
今回は、フロントエンドに興味がある人や、フロントエンドの知識を深めたい人のために、昔から現在に至るまでの「フロントエンドの歴史」を解説していこうと思います。
歴史を知ることで、より大局的に技術を見ることができます。
また、詳しくは後述しますが、歴史を知ることは様々なメリットがあると考えています。
なので、Webができてからモダンフロントエンドに至るまでの歴史を解説していきます。
歴史を知ることのメリット3選
まず、歴史を知ることのメリットを3つ紹介していきます。
1.応用が効きやすくなる
歴史を知ることで、「今使っている技術がなぜ作られたのか」が分かるようになります。
結果として、技術の根底思想も知れるので、深い理解に繋がると考えています。
なので、歴史を知ることで、技術を応用して使えるようなエンジニアになれると思います。
2.今後の流れを予測できる
今までの歴史の流れを把握しておこくことで、今後の動向もなんとなく予測することができます。
他の例で例えると、「チューリップバブルや不動産バブルに酷似しているので、仮想通貨バブルもいつかは弾けるだろう」といった感じ。
なので、未来に向けて知識を仕込んでおくこともできますし、大きな変化が起きた時もそこまで焦らずに対処できると思います。
これは、進化が早いIT業界では必須の能力だと言えます。
なのでこの点から考えても、歴史を知ることはかなり大事だと思います。
3.新しい技術に適応できる
最後のメリットは、新しい技術に適応できることです。
先ほどの例と似ていますが、今までの歴史の流れを分かっていると、新しく出てきた技術がなぜ作られたのかが分かります。
なので、新しい技術が出てきても、焦らずに早く習得することができると考えています。
これら3つが歴史を知るメリットになります。
モダンフロントエンドまでの歴史
歴史を知ることのメリットは十分に分かったと思うので、次は具体的な歴史の詳細を解説していきます。
1.Webの誕生
1991年に、Webで初めてHTMLを使った文章が公開されました。
この時は、まだ学術文書の公開が目的であったため、リッチなデザインなどは必要ありませんでした。
けれど1990年中盤になり、企業もWeb上に情報を載せるようになったため、ある程度のリッチなデザインが求められました。
そして、1996年にCSSと、JavaScript（当時はLiveScript)がリリースされました。
1990年後半では、誰もがWebサイトを持てるようになったため、様々なブラウザやサイトが乱立しました。
ただ、その際にHTMLがグチャグチャなサイトが多かったため、W3CによるHTMLの規格の標準化が行われました。
また、ブラウザによってJavaScriptの仕様の違いがあったため、ECMA InternationalによるJavaScriptの標準化が起こりました。
そのJavaScriptの基本となる仕様が、ECMAScriptとなります。
例えば、2015年にリリースされた仕様はES2015、2020年にリリースされた仕様はES2020になります。
2.JavaScriptの低迷
2000年前半のJSは、意見が割れて標準化が進まなくなったり、脆弱性をつくウィルスが出てきたことなどで、人気を失っていきました。
その当時は、JSよりも軽くて脆弱性の少ないFlashが主流となっていました。
そんな中、2005年にAjaxを使ったGoggle Mapなどがリリースされたり、2006年にjQueryがリリースされ、JSは人気を取り戻し始めます。
また、同じ頃にCSSメタ言語のSassもリリースされたため、CSSやJSでブラウザ間の違いを意識しない開発ができるようになっていきました。
また、2010年前半からSPAという考え方も出てきて、AngularやReactなども作られました。
時を同じくして、2014年にHTML5が、2011年にCSSが発表されました。
そして、フロントエンドの開発体験がかなり向上しました。
けれど、どうもまだ使いづらい点がいくつかありました。
問題1:名前空間の衝突
まず、JavaScriptは名前空間が1つしかなかったため、それが原因のバグが起こっていました。
例えば、A.jsというファイルで"foo"という変数をstringで定義していたのに、B.jsというファイルでnumberで定義し、C.jsで"foo"を文字列で扱おうとしたら、エラーが起こってしまいます。
そんな中、2009年にServerJSというものがリリースされ、JSをバックエンドでも使おうという動きが出てきました。
フロントで使う言語をバックエンドでも使えたら、学習コストも減るわけなので当たり前の動きと言えるでしょう。
けれど、当時はサーバー側で動くためには、機能がいくつか足りませんでした。
その足りない機能を議論するためにできたプロジェクトが、CommonJSです。
そして、そのCommonJSを元にして、Node.jsが2009年に作られました。
そのCommonJSで定義されたモジュールというシステムのおかげで、バックエンドにおいては名前空間の問題が解消されました。
ちなみに、Node.jsは独自の進化を遂げ、CommnoJSのプロジェクトは途中で止まってしまいました。
問題2:依存関係の対応
モジュールで名前空間の問題が解消されたため、色々なパッケージが作られることとなりました。
けれど、そのパッケージは様々な依存関係を持っていたため、それを人力で管理するのはかなり無理がありました。
そんな中、「他の言語でも使われていたパッケージ管理システムをJSでも作ろう」という動きがありました。
パッケージ管理システムは簡単に言うと、パッケージのインストール・更新・削除、依存関係の解決、設定管理を行うためのツールです。
そして2010年に、JS用のパッケージ管理システムであるnpmが作られました。
npmが作られたことにより、JSの大きな問題点を2つともクリアすることができました。
なので、2010年頃から大手の会社でも、node.jsが使われるようになってきていました。
けれど、これは飽くまでバックエンドの話です。
フロントエンドの開発問題
フロントエンドでは、独自の工夫をして色々と対策していましたが、依然同じ問題は残っていました。
例えば、バックエンドでCommonJSというものがありましたが、フロントエンドでも同じようにAMDという仕様が作られていました。
それ元に開発されたRequireJSにより、名前空間と依存関係も解決することはできました。
ただ、フロントエンド向けのパッケージ管理システムは、未だに無いという状況でした。
そんな中、2012年にフロントエンド用のBowerというパッケージ管理システムがリリースされました。
そのような状況でも、以下のような色々な問題がありました。
- AMD形式の構文は、CommonJSの構文と比較して冗長だった
- AMD形式だと依存関係が多い時に、メンテナンスが大変だった
- パッケージの依存関係を手作業で定義する必要があった
3.パラダイムシフト
そんな感じで、フロントエンドは少し行き詰まった状態でした。
そんな中で、ある画期的な発想が生まれます。
「CommonJS形式で書かれたものを、事前にブラウザ向けに変換すれば良いのでは？」
先ほども述べた通り、CommonJSはバックエンド用の仕様なので、フロントエンドでは正常に動作しませんでした。
けれど、開発時にCommonJSで書いて、それをフロントエンド用に変換したものをデプロイすれば問題ありません。
そしてそのために必要な仕組みが、モジュールバンドラーとコンパイラーです。
モジュールバンドラー
まずモジュールバンドラーとは、モジュールの依存関係を解決して、1ファイルに変換するツールです。
例えばBrowserifyは、CommonJS形式で書かれた複数のファイルをブラウザ用の1つのファイルに変換するツールでした。
元々、フロントエンドとバックエンド両方で使いたいパッケージを作るときは、CommonJS形式と、AMDなどのブラウザ用の形式で書く必要がありました。
けれど、バンドラーを使うことで、その問題も解決することができました。
結果として、便利なパッケージがフロントエンドでも大量に使えるようになりました。
そして、Webpackが2012年にリリースされ、CSSや画像もバンドルできるようになりました。
また、ES2015にES ModulesというJS独自のモジュール機能が実装されました。
ただ、IEなど使えないブラウザもいくつかありました。
そんな中webpackを使うことで、その問題を解決することもできたため、徐々にシェアを増やし、バンドラーはwebpack1強となりました。
コンパイラー
そして、コンパイラーとはブラウザで動かないコードを、ブラウザで動くように変換するツールになります。
ES Modulesが追加されたES2015では、それ以外にも様々な仕様が追加されました。
けれどこちらも、IEなど使えないブラウザもいくつかありました。
そんな中、Babelというコンパイラーが作られました。
そのコンパイラを通すことで、ES2015以降に書かれたコードをそれ以前のコードに変換することができます。
なので、開発時は新しい便利な文法を使ってコードを書き、本番環境にはそれをコンパイルしたコードを置くことで、ブラウザ上でも正常に動作させることができます。
このように、「バックエンドと同じような環境で開発を行い、バンドラーとコンパイラーを用いて本番用にコードを変換する」という仕組みを導入することで、フロントエンドの様々な問題を一気に解決することになり、開発体験を大幅に高めることができました。
これが、フロントエンドの歴史にになります。
まとめ
最後に今回の内容をまとめます。
- 1991年にWebが誕生する
- 1990年後半にかけてCSSやJavaScriptも誕生する
- 2000年前半はJSの人気は低迷する
- 2000年後半はJSの人気が盛り返してくるもいくつかの問題が残っていた
- 2010年前後で、バックエンドにおけるJSの開発環境が大きく整備される
- 2010年中盤にかけてパラダイムシフトが起こったことで、フロントエンドの開発環境も大きく整備された
以上になります。
これを知ることで、今使っているツールの見方が変わったのではないでしょうか？
また、「この時代に生まれて良かった」と心から思いませんか？
そして、今後の変化にも適応できそうな気もすると思います。
ぜひ、このことを頭の片隅に置いて、フロントエンドの開発をしていきましょう。
また余裕があれば、モダンフロントエンドになってから現在に至るまでの歴史もまとめようと思います。
宣伝
0からエンジニアになるためのノウハウをブログで発信しています。
また、YouTubeでの動画解説も始めました。 YouTubeのvideoIDが不正です
インスタの発信も細々とやっています。
興味がある方は、ぜひリンクをクリックして確認してみてください！
Discussion