2015年のWebクライアントサイドの温度感
この3~4年間でJavaScriptとかWebクライアントサイドを取り巻く温度感も大きく変わった。これからはHTML5だぜイエーイと騒いでいたのも随分過去の話になったように思う。だけど、このあたりの温度感はそんなに掴みやすいものでは無い。別に放っておいてもいいんだけど、放っておくと10年20年経たないと誰も書かなんてのも割とよくある話。でも、そこまで待ちたくは無い。なにとなしに説明してみようと思う。
だいたい2011~13年ぐらいはHTML5がバブルっていた。今からすると「バブルだった」というのが一番説明しやすい。Node.jsあたりが世の中に認知を拡大していたのもこの時期だし、スマートフォンのシェアの伸びに合わせて、クロスプラットフォームで出せるWebにみんな夢を見ていた。MVCだの設計だの何だの言い出したのも、だいたいこのくらいの時期だし、Single Page Applicationという概念が提唱され始めたのもこのくらいの時期だった。
この頃はまだまだ牧歌的な時代だったと思う。これからはHTML5で何でもいけるんだ、という牧歌感・楽天的な雰囲気があった。「俺たちがたとえバカでもHTML5なら簡単に書けるんだぜ」みたいな時代感。オレオレMVなんとかフレームワークで覇権を争っていたときも、その温度感は間違いなく存在していた。他のアプリケーション設計論をかじったことのある人が、なんとかしてjQueryと折り合いをつけつつも、それっぽいコードを統治していくにはどうするかを悩んでいた時代。sassやlessなどが出てきたし、Makefileで依存関係を上手にconcatする人もいたけど、割と先端の技的関心やエッジな芸であった。この時期の終盤にはGruntやgulpが出てきて、CSSやJSのビルドの概念が認識されてきたけれども、せいぜいがsassやCoffeeScriptの変換とconcatとminifyとかがほとんどの関心ごとであった。
そんなんだから、Webフロントエンドと呼ばれる領域はとても曖昧だった。この時期に採れたコンセンサスは「CSSコーダー・Webデザイナー・マークアップエンジニアと呼ばれた人たちの上位職」という程度の扱い。会社によってはサーバーサイドをやってたアプリケーションエンジニアを配置転換してる。そんな感じの扱いなので、Webフロントエンドエンジニアと一口に言っても幅が非常に広くなってしまった。同じフロントエンドエンジニアという肩書でも、人によってはCSSがすごく書ける一方でjQueryプラグインのコピペで済ませる人がいるし、逆にCSSほとんど書けないけどBackbone.jsとかものすごい頑張ってる人がいたりもした。ちなみにNode.jsは、この時期はまだまだサーバーサイドの文脈。Gruntなどに「転用された」ものの、文化圏的にはそこまでクロスオーバーしてるわけでもなかったはず。
いずれにせよ、こういう盛り上がりがあった中でHTML5バブルははじけた。古いブラウザと機種互換性（たとえばAndroid 2.3の断片化）への対処、あるにはあるけど総合すると使い難いAPI（ApplicationCache、history API）、コミュニティの練度、そもそもネイティブアプリケーションエンジニアが増えてきた、期待の裏返し、etc。デスクトップWebの時みたいに端末の性能向上に対しての要求が緩やかというわけでもなかったし、そもそも使えるメモリの量も違うし、OSとブラウザが紐付いているくせに、ブラウザのQAの質も違った。それでいてコンテンツはwebkit prefix付きが多いから、ユーザーはFirefoxやOperaに逃げても相互運用性は期待できないし、そもそもWebViewで作ってるアプリなんだからユーザーがブラウザを変えても意味が無い。組み込みSDKとして転用できるWebViewをGeckoで出そうかとMozillaが検討し始めたのが2013年の半ばぐらいでバブル晩期も晩期。逃げ足の速い人は「ネイティブアプリじゃないと、やっぱり当面は無理じゃね？」とか思い始めてた時期。結論から言えば、HTML5バブルが、Webクライアントサイドへのトドメを刺したと言ってもいいと思う。
さて、時は移ろい2014年になると、状況が変わってくる。
標準化の舞台はExtensible Webが志向されるようになる。高レイヤーなAPIを作っても実際に使い難いと意味が無いので、まずは低レイヤーなAPIを用意し、できることを増やすというあたりから始めるという方向性。これはまずまず正しいと思う。高レイヤーAPIというのは、ある種のセンスと時代の巡り合わせなので、一度足したら消せない標準化の舞台でそういう不確定要素に頼らなくなったというのは安全だし、最低限これは必要と思しきものから順次作っていくというのも正しい。
コミュニティ的な2014年の変化は、静的言語的なアプローチが全面的に導入されるという変化。静的解析系のツールが出揃って来る。ESLintとかは典型だし、browserifyもモジュール単位の依存関係を静的に解析し結合するという意味でlinkerでしかない。ReactのJSXもつまるところ準静的なテンプレートをJSとして生成するものだし、TypeScriptあたりも静的解析。Closure Compilerはだいぶ前からやっていたけれども、それがコミュニティの方向性になったというところ。GolangやScalaの躍進を考えると、プログラミング言語の進化としては、トレンドを押さえているし、2012年ごろからesprima一党をやっていたAriya HidayatやYusuke SUZUKIらは正しかったと言える。
これが2015年になると、モジュールから構文から何から何まで10年近く必要とされてた基盤を取り込んだES6（ES2015）というベースラインが整うことになったので、瑣末な問題で悩むことはなくなった。使えるかはともかく、少なくとも言語の方向性がハッキリと見えるようになった。
facebookが設計論（Fluxと名付けたGUIアプリケーションベストプラクティスの一端）だったりReactでコミュニティを回してはいるのも変化だし、React一派のチュートリアルがCommonJS + browserifyベースで書かれていたので、巨大単一フレームワークよりもnpmの単機能〜中機能パッケージを組み合わせる方が良くね？というのも変化だろう。
それと、HTML5のバブルの失敗の結果、コミュニティも標準化も、いい意味でなりふり構わなくなった。昔は「HTML5なら私たちがバカでも簡単に〜〜できるんですよ」という温度感がどことなくあったと記憶しているが、バブルが弾けて現実を見るようになったのと、その手の「簡単にできる」営業トークをする人がだいぶ減ったので、「まともにアプリケーションを作るには、俺たちはバカのままでは居られない」という温度感に移行することになった。
こういう具合にWebクライアントサイドは、すっかりJavaScriptの上で何をするか？という世界になっているのが、2015年末の現況と言ったところ。
なので、たとえばHTML5バブル晩期から継続されているWeb ComponentがHTMLベースなのは、2014年以前に開始された仕様だから、とも言える。HTML Import辺りは典型。一方、2015年はJavaScriptありきの時代なのだから、今作業しているならwhatwg loaderの上に作り直してしまえというRyosuke Niwaさんあたりの意見は正しいと思う。
斯くのように、Webフロントエンドと呼ばれる領域は、すっかりクライアント側のアプリケーションエンジニアリングの話になりつつあるし、a11yも何もかもの要素が、それをどうやって踏まえていくかの話になる。
いろいろ散漫になってしまったけど、まあ、こんな感じかな。
追記
書いたつもりで書いてなかった2014年〜2015年の変化をいくつか。
静的解析について。これは別にJavaScriptに限った話ではなく、CSSでもpostcssと呼ばれる一党が出てきた。だいたいesprimaとやっていることは近い。
かつて雨後のタケノコのように出てきたAltJSは、この頃にはだいたい勝敗がつくようになってきた。構文という瑣末な問題ではなく、別言語で書くことに対して本質的な付加価値をつけるものが生き残ることになる。TypeScriptの静的型検査とかは典型。構文の問題はES6で結構片付いたというのも大きい。CoffeeScriptが示した便利構文の一部はES6に入ったし。静的解析基盤に載せられない上に、構文以外に本質的な価値を提供できない道具は役に立たなくなった、と表現するのが正しいかもしれない。変換後のJavaScriptにLintかけるのなんてバカバカしいしね。
browserify/webpackなどのlinkerの一般化と、古いブラウザ（主にIE9未満）の多くが消えてきたことによって、重厚長大なフレームワークや互換層の必要性も薄れることになった。どうせならnpmの資産を再利用できたほうがいいよね、モジュールを見れば依存関係がわかるといいよね、みたいな感じ。IEとその他大勢のDOMの互換ライブラリ+色々だったjQueryは徐々に避けられることになる。グローバルスコープに何かを生やすライブラリは、せめてPolyfillくらいにしておきたい、というのが最近のノリだと思う。jQueryっぽい書き方がJavaScriptの作法とされたのも過去の話。
Node.jsのstreamパッケージあたりも時期の話が大きく絡む（はず）。あれができた時期のJavaScriptコミュニティにとっては、ES6 PromiseもRx.Observableも注目の外にいた。だから、ああいう独特の感じになった面はあるはず。また、Node.jsのcoreは、コールバックからPromiseに移行することでの速度面を気にしているのか、あんまりPromise化をやりたがっていないように見える。従来通りなコールバックベースの低レイヤーと、Promise（とObservable）で包んだ中レイヤーあたりに上手い具合に分かれてくれると嬉しいけど、それはそれで面倒くさそうなのでどうだろね。