2015年の今、Web制作のエンジニアに限らずデザイナも動向が気になるのは、次の2つでしょうか。なぜか。それは、どちらも、その以前と以後で「CSSの前と後」くらいのインパクトをWeb業界に与えるからです。
- Web Components
- モジュール (あるいは、ECMAScript 6)
いや、単にここのところ考えることが多かったので、忘れないうちにアウトプットしときたいだけかも。
コンポーネント
まだ現時点のブラウザ対応はないものの、「コンポーネント(=独自タグ)」は既定路線で、HTMLのビューを組む場合の方法論として確立しつつあります。
いずれも「コンポーネント」志向です。ただ、Angularが独自の世界観で突っ走ったのに対し、ReactはいくらかWeb Componentsに寄り添った方向、PolymerはWeb Componentsそのもの(polyfills)と、アプローチは大きく違います。
Web Componentsの仕様自体もほぼ煮詰まってきました。ちょっと煮詰まりすぎのきらいもあり、このまま業界に受け入れられるかは不透明です。もちろん、策定メンバーもXSL等の失敗を念頭に、仕様の単純化に腐心しているはずですが...。そのような状況なので、Polymerも当然Beta段階。現在の、Web標準は「実装が先」なので、Polymerが実際に威力を発揮するのは、標準化が次のステップに進んだとき、ということになります。
人類は、Backboneで途方に暮れて、Angularでもがき苦しみました。それにWeb Componentsは形を与えようとしています。(適当)
標準路線
標準仕様に則る方向では、Polymerを筆頭にいくつかの実装が存在します。
※ Polymer, X-TagはPolyfillとしてwebcomponents.jsを使用
Bowerに登録されているWeb Componentsを検索できるサイトもできているので、眺めてみると面白いですね。
ですが、まだこれらは未来の技術。仕事で使うのはまだちょっと先のお話。
独自路線
標準仕様の動向と別に、「コンポーネントが良さそうだ」という大筋同意は取れていて、目下、実装として何を使うかが悩みどころです。AngularなのかReactなのか...。EmberやKnockoutは、もう少し広い領域をカバーするフレームワークですが、コンポーネント的な書き方もできます。
最近は、ほかにもいろいろ。Riotについては先日もこれとか、これとか書きました。
- Ampersand.js - 2014年後半・ポストBackbone.js
- Aurelia - 2015年1月登場・Knockoutからの流れ
- Riot 2.0 - 2015年1月登場
この中で、React, Riot, Ampersandあたりに共通する動きは、フルスタックでないこと。これも、今後の生き残り条件になってくるかもしれません。
双方向バインディングから仮想DOMへ
Reactの人気は「秀逸な仮想DOM」につきます(加えるなら、サーバサイドレンダリングも)。現時点で、ブラウザ実装がない以上、
- コンポーネント表現として、JavaScriptのオブジェクトが必要
- ビューを頻繁に書き換えるのに、DOMを直接操作するのは負荷が高い
という要請のなか、軽量の仮想DOMを変更して、それをDOMと同期する戦略が取られました。ここで、問題になるのは、DOM側で書き換えが起きた場合です。つまり、モデル <-> 仮想DOM <-> DOM と3つのレイヤーを考えなきゃなりません。もう考えるのイヤッと、一連の操作を一方通行にしたのがReactの割り切りです。これは、サーバサイドでWebを作ってきた人間には受け入れられやすい発想でした。ただし、Reactを使うなら、jQueryと決別する必要があります。
とはいえ、インタラクションさせる気がないなら、そもそも全部サーバサイドレンダリングで良かったわけです。みんな、もっとDOMと仲良くなろうよ。(爆)
DOMとの距離の取り方が、それぞれの陣営の性格を表していますね。React路線か、双方向バインディングにこだわってDOMべったりか、あるいはその中間か。
コンポーネントを作るのは誰か
これは、UIデザイナの仕事です。目下フレームワーク論争は「エンジニア」の中で起きてますが、コンポーネントをデザイナが作れないなら、そのプロダクトの先に未来はありません(多分ね)。ただ、すべてのWebデザイナが今後コンポーネントを作るようになるかというと、そこはまだ不透明です。
Material Designを見ているとわかるように、「本気」のコンポーネントはデザイナ的な発想とエンジニア的な発想を要求される、案外高度な作業です。この路線の究極は、デザイナはコンポーネントの配置だけをする世界です。例えば、
- Mateial Design派
- Bootstrap派
- Foundation派
などの少数の、流派の中で、一種のOSのようにコンポーネントが標準化され、デザイナは基本それを使うかハックするだけ。現在も、「アプリケーション」的であればあるほど、そういった面は見られます。
一方で、それを「足枷」と感じるデザイナーも多いはずです。フラットデザインが当たり前になったとしても、「デザインは並べるだけじゃないんだ!!!」
デザイナにとってのコンポーネント
エンジニアによって諸手を挙げて(?)受け入られつつある「コンポーネント」。デザイナにとってはまだ扱いにくい代物です。Angularの方がまだ手を出しやすいとはいえ、AngularUIが「イケテない」のを見ればデザイナのコミットが足りないのは明白です。
かといってReactはというと、完全にJavaScriptの世界で「エンジニア以外お断り」です。辛うじて、react-templatesを使えば、協業の可能性がありますが、.bind(this)をテンプレート内に書き散らさないといけないのが辛いところ。(デザイナは間違いなく拒否ります)
Polymerは、その点HTMLの延長なので、AngularやReactよりはかなりマシですが「未来の技術」なので、今使うことができません。
そんな中、デザイナにとって「Riot 2.0」はいくらか吉報でした。不穏な名前(riot = 暴動・反乱)にギョッとするかもしれませんが、転じて「面白いこと・ひと」という意味合いもあるようです。Riotのとった戦略は、PolymerとReactの中間です。Web Componentsの書き方を配慮しつつもこだわり過ぎず、現存のブラウザで楽に実装できるラインを狙っています。ベースは、あくまでもHTMLであり、その中にコンポーネントのためのJavaScriptを一緒に書けるようにしたことで、非常にシンプルな見た目(と実装)になっています。
良し悪しは別として、「jQueryユーザ」が手を出せる初めての「コンポーネント実装」がRiot.jsだと言ってよさそうです。
フレームワーク移行の現実味
フレームワークは、基本ロックインします。移行なんて夢物語です。とはいえ、1週間で移行可能なら、やってみる価値はあるかもしれません。
最近触った範囲で、標準に近い順に並べてみました。HTMLの移行だけなら、ReactよりAngularの方が楽チンです。でも、JavaScript部分は諦めるほか...。ちなみに、4番から3番の移行は単純作業でできました。3番から2番も、同じくらいの手間。6はHTML(テンプレート)が鬼門、7はJavaScriptが鬼門です。
- Web Components
- Polymer
- Riot
- React + react-templates
- Ampersand + Handlebars
- React + JSX
- AngularJS
※順番には多分に主観が含まれます m(_ _)m
AMD、CommonJS、そしてES6
Rubyにはgemがあり、Nodeにはnpmがあり、PHPにはPackagistがあります。フロントエンドにもBowerがありますが、肝心のブラウザJavaScriptには「モジュール」の仕掛けがありませんでした。が、それも今年まで。夏以降、事態は動きます。
詳しい記事は、いくらでもあるので、略。混沌としたJavaScriptにきっと秩序をもたらすでしょう。
| 種類 | 呼び出し | 定義 |
|---|---|---|
| AMD | requirejs.config({ backbone: 'path/to/file' }) |
define(['backbone'], function (Backbone) {/* */}) |
| CommonJS | var Backbone = require('backbone') |
module.export = function() {/* */} |
| ES6 | import { hello } from 'somemodule' |
export function hello {/* */} |
でも、JSフレームワークは2,3年しかもたない
「今は時期が悪すぎます」。でも、きっと来年も再来年も、ずっと時期は悪いです。
- ECMAScript6 (勧告は2015年6月ごろ予定)
- Web Components
をひかえて、フレームワークの動向は混迷を極めています。
ES6(ECMAScript6)は、JavaScript史上最大のアップデートで「モジュール」に初めて対応するバージョンになります。Node.js 0.12、io.jsはすでにES6に対応しており、あとはブラウザの対応を待つだけというところまで来ました。
Angularは、当時選択肢がなかったためモジュールシステムを内製しましたが、今となっては足枷でしょう。Angular 2.0はES6とWeb Components対応になるとのことなので、大きな仕様変更は避けられません。1.0と2.0の連続性はあまりないはず。Reactは、その点、npmとの親和性が高いのでBrowserifyやWebPackを(まともに)使うことができるので、EC6のインパクトはそれほどありません。もしエンジニアが、今はじめて手をつけて、すぐに結果を出さなければならないなら、Reactは有力な選択肢です。
でも、ちょっと冷静になりましょう。作りたいアプリケーションは、壮大なスケールが必要なものですか? 学習コストに見合うものですか? 去年までは、他に選択肢がないという意味で、AngularかReactか(あるいはBackboneか)を選ばざるを得なかったけれど、今の時点だと、新興フレームワークがいくつも出ています。
- Ampersand.js - 優等生
- Mithril - 軽い速い
- Mercury - 渋い
- Aurelia - ES6対応・フルスタック
- Riot 2.0 - お手軽・必要なものだけ
ここで、何を基準にするか。戦略はふたつ。
- 長いものに巻かれる
- シンプルなものを使う
私は後者で行きたいです。なぜなら、2,3年後には確実に違うものを使っているから。
パッケージマネージャの不在
フレームワークもですが、JavaScriptはパッケージマネージャも混沌としています。
npmが最大勢力です。最近2.0になり、エンタープライズ向けの対応や、キャッシュサーバを立てやすくなったりなど、成熟の感があります。ただ、ブラウザ向けの対応についてnpmからは話が聞こえてきません。まあしないような気がします。今後、JavaScriptモジュールを開発段階でなくブラウザレベルで読み込むようになると、それを一体どこのCDNが負担するんだろう...。
- npm: サーバサイド、手元開発はこれでOK
- Bower: 立ち位置が微妙、ES6向けの対応を打ち出せるのか...?
- Duo: component.jsからの流れ
- spmjs: static package manager for browser
- jspm: よく知らない...
まだしばらくは、ブラウザから直接じゃなくBrowserify/WebPackでビルドして使う派ですが、先行きが気になります。
結語
Web ComponentsもES6も、実のところ数年前からの動きです。コンポーネントについては、むしろWeb Components陣営以外からの動きが加速した点を、注目すべきかもしれません。
さて、あまりの混沌に、近づきたくない言語の筆頭に挙げられるJavaScriptですが、時代はますますの戦乱に突っ込みます。個人的には、しばらくRiot 2.0に寄り添っていこうと思います。昨日、ひとつプルリクエストを送りました。
戦乱の世は、下克上のチャンスです。今のうちに頑張って、コミッターにのし上がりましょう。ガンガン、コードで殴り合いをしたら良いと思います。あー、私はデザイナーなのでヤサシクシテクダサイ。