JavaScriptおれおれAdvent Calendar 2014 – 24日目

個人的に、こんな感じで認識してますって話。書くにあたりあんまり精査してないので勘違いありそう。やさしく教えてください。

もちろん個々人では先取りしてあれやこれややってる人もいて、そういう人たちは特に今でも第一線で頑張っているように思う。

原初

  • 設計なし
  • DHTML (Dynamic HTML)
  • NoScript

設計なしに書いていた時代。

もちろん個別のアルゴリズムとかはあったんだけど、アプリケーションというよりはウィジェットとかそういう規模のもの。

あれよあれ、マウスカーソル追っかけるやつとかそういうの。もちろんまともに考えられたものもあったけど、少数派。JavaScriptといえば「よくわからない派手で邪魔なもの（を作るやつ）」という認識。ブラウザーの設定やプラグインでスクリプトの実行を停止している閲覧者も少なくなかった時代。

中にはJavaScript偏重のウェブアプリケーションもあった。そういうのは設計されていたけれど、他の世界（だいたいJava）の世界観をそのまま持ち込んだみたいな感じだった。

第一世代

  • 模索中
  • DOM, jQuery
  • Ajax
  • hashchange, Hash Bang

Ajaxバブルの時代。（なんだそれ。）　気取って「モダン」とか言い始めた頃。

HTMLを動的に操作

jQueryの出現及びAjaxの発見により、画面を動的に変化させるという発想が広まった。よくわからない派手な動きから、堅実で便利なUIへ。

それに従いウェブアプリケーションのクライアント側の比重が大きくなる。ここでクライアント側の設計という作業工程が発生。

リッチでモダンな素敵アプリ

モダンなウェブアプリのはしりはGoogle Maps（2005年）。実際はAjax（XHR）ではなかったが、画面表示後にサーバーと通信して情報を更新するというパターンが大流行。設計しよう、ないとしねるっていう気になってきた。

またURLフラグメント識別子、いわゆる「ハッシュ」を操作して画面状態をURLに保存できるようにもなった。後のHistory APIへの系譜。全ページで共通のリソースを用い、URLから判断してクライアント側で画面を構築する。SAP: Single Page Applicationの始まり。

手探り

とはいえ、設計としてはまだ手探り。各人で諸々設計して実装していて、それぞれ妥当性はあるんだろうけど、共通認識としての設計パターンはまだ構築されていなかった（あるいは普及していなかった）。

第二世代 ←イマココ

  • MVx
  • HTML5, CSS 3
  • エンジニアリング
  • 黒い画面
  • 試験
  • 携帯端末

フロントエンドエンジニアの台頭、エンジニアリングの推進。

要求の肥大化

HTML5でJavaScriptでできる事が圧倒的に増え、CSS 3で表現の幅が飛躍的に高まる。その分要求も大作志向に。

設計しないとしねる。

MVx

AngularJS（2009年）あたりがなんだかんだで中心となって設計の共通認識が進む。MVCとかそういうの。

Ruby on Rails（2004年）もサーバー側でMVCとか言ってたのも含め単語の混乱が起こる。「お前のMVCはMVCじゃない」みたいな言説が乱立。結局何が真のMVCなのか未だによくわかんないや……。

黒い画面

設計の必要性が認識されたあたりで、HTML以外の言語出身のガチ勢（要はプログラマー）が増えてくる。良い開発環境作りに腐心。タスク実行、パッケージ管理、リソースの結合と縮小、

様々な便利ツールが出現し、黒い画面を前にPhotoshop出身のJSerが悲しい顔をするようになる。

試験環境も整備がすすみ、試験のないライブラリーはすべからく地獄の火の中に投げ込むべしみたいな風潮。熟知すべし。

エンジニアリング

CSS 3で視覚表現が豪勢になった分マシンパワーを要求するようになり、ちゃんと動くよう調整する必要が出てくる。ので、開発者ツールを使って重い処理を検出したり描画コスト高い箇所を判断したり。

第三世代

  • Web Component
  • カスタム要素
  • Virtual DOM
  • Worker

来たるべき近未来。

認識間違ってる可能性が他の項より高いのでアレなら教えてください、やさしく。

カスタム要素

勝手に好きな要素を作れる仕組み。

例えばタブUIとかそういうのは全部カスタム要素にして、それぞれの画面用の情報（タブのラベルとか本文とか）を与えて画面に出すっていうのができる。

雰囲気はjQueryプラグインみたいに「作る人」と「使う人」に分かれそう。

Virtual DOM

高速に画面更新するための、裏側の仕組み。内部的にはModel-Viewに分かれていて、Model変更時のView更新を最小限に抑える事で描画を高速化する。

MVxでは視覚情報と論理情報を綺麗に分割していたが、逆に結合してひとつのモジュールとして管理し、モジュールを組み合わせて大きなモジュールを構築する。

物理と論理が小さく結合しているあたり、カスタム要素と相性良さそう。

Worker

非同期に処理を行う仕組み。処理時間が長くなってしまうものをバックグラウンドで実行する事できる。

Workierからは諸事情によりDOMを触れないけどVirtual DOMなら触れる、てのはどうでしょう。あんまり関係ないか。

頑張ろう

最後雑になった。全体的に色々省略しました、短い方が良いかなって。

しかしやっぱり未来予測とか無理だ……。