デザイナはWeb Componentsに夢を見るのか


2015年の今、Web制作のエンジニアに限らずデザイナも動向が気になるのは、次の2つでしょうか。なぜか。それは、どちらも、その以前と以後で「CSSの前と後」くらいのインパクトをWeb業界に与えるからです。

- Web Components
- モジュール (あるいは、ECMAScript 6)

いや、単にここのところ考えることが多かったので、忘れないうちにアウトプットしときたいだけかも。

## コンポーネント

まだ現時点のブラウザ対応はないものの、「コンポーネント(=独自タグ)」は既定路線で、HTMLのビューを組む場合の方法論として確立しつつあります。

- [AngularJS](http://facebook.github.io/react/)
- [React](http://facebook.github.io/react/)
- [Polymer](https://www.polymer-project.org/)

いずれも「コンポーネント」志向です。ただ、Angularが独自の世界観で突っ走ったのに対し、ReactはいくらかWeb Componentsに寄り添った方向、PolymerはWeb Componentsそのもの(polyfills)と、アプローチは大きく違います。

Web Componentsの仕様自体もほぼ煮詰まってきました。ちょっと煮詰まりすぎのきらいもあり、このまま業界に受け入れられるかは不透明です。もちろん、策定メンバーも[XSL](http://www.w3.org/Style/XSL/)等の失敗を念頭に、仕様の単純化に腐心しているはずですが...。そのような状況なので、Polymerも当然Beta段階。現在の、Web標準は「実装が先」なので、Polymerが実際に威力を発揮するのは、標準化が次のステップに進んだとき、ということになります。

人類は、Backboneで途方に暮れて、Angularでもがき苦しみました。それにWeb Componentsは形を与えようとしています。(適当)

### 標準路線

標準仕様に則る方向では、Polymerを筆頭にいくつかの実装が存在します。

- [Polymer](https://www.polymer-project.org/) *
- [X-Tag](http://x-tags.org/docs) *
- [Bosonic](http://bosonic.github.io/)

※ Polymer, X-TagはPolyfillとして[webcomponents.js](https://github.com/WebComponents/webcomponentsjs)を使用

Bowerに登録されているWeb Componentsを検索できるサイトもできているので、眺めてみると面白いですね。

- [Custom Elements](http://customelements.io/)

ですが、まだこれらは未来の技術。仕事で使うのはまだちょっと先のお話。

### 独自路線

標準仕様の動向と別に、「コンポーネントが良さそうだ」という大筋同意は取れていて、目下、実装として何を使うかが悩みどころです。AngularなのかReactなのか...。EmberやKnockoutは、もう少し広い領域をカバーするフレームワークですが、コンポーネント的な書き方もできます。

- [AngularJS](http://facebook.github.io/react/)
- [React](http://facebook.github.io/react/)
- [Ember](http://emberjs.com/guides/components/) - [参考](https://gist.github.com/wycats/9144666b0c606d1838be)
- [Knockout](http://knockoutjs.com/documentation/component-overview.html)

最近は、ほかにもいろいろ。Riotについては先日も[これ](http://qiita.com/cognitom/items/fb1295f3f93911e9e92d)とか、[これ](http://qiita.com/cognitom/items/eb6d56485fe517ccd9ee)とか書きました。

- [Ampersand.js](http://ampersandjs.com/) - 2014年後半・ポストBackbone.js
- [Aurelia](http://aurelia.io/) - 2015年1月登場・Knockoutからの流れ
- [Riot 2.0](https://muut.com/riotjs/) - 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](https://angular-ui.github.io/)が「イケテない」のを見ればデザイナのコミットが足りないのは明白です。

かといってReactはというと、完全にJavaScriptの世界で「エンジニア以外お断り」です。辛うじて、[react-templates](http://wix.github.io/react-templates/)を使えば、協業の可能性がありますが、`.bind(this)`をテンプレート内に書き散らさないといけないのが辛いところ。(デザイナは間違いなく拒否ります)

Polymerは、その点HTMLの延長なので、AngularやReactよりはかなりマシですが「未来の技術」なので、今使うことができません。

そんな中、デザイナにとって「[Riot 2.0](https://muut.com/riotjs/)」はいくらか吉報でした。不穏な名前(riot = 暴動・反乱)にギョッとするかもしれませんが、転じて「面白いこと・ひと」という意味合いもあるようです。Riotのとった戦略は、PolymerとReactの中間です。Web Componentsの書き方を配慮しつつもこだわり過ぎず、現存のブラウザで楽に実装できるラインを狙っています。ベースは、あくまでもHTMLであり、その中にコンポーネントのためのJavaScriptを一緒に書けるようにしたことで、非常にシンプルな見た目(と実装)になっています。

良し悪しは別として、「jQueryユーザ」が手を出せる初めての「コンポーネント実装」がRiot.jsだと言ってよさそうです。

### フレームワーク移行の現実味

フレームワークは、基本ロックインします。移行なんて夢物語です。とはいえ、1週間で移行可能なら、やってみる価値はあるかもしれません。

最近触った範囲で、標準に近い順に並べてみました。HTMLの移行だけなら、ReactよりAngularの方が楽チンです。でも、JavaScript部分は諦めるほか...。ちなみに、4番から3番の移行は単純作業でできました。3番から2番も、同じくらいの手間。6はHTML(テンプレート)が鬼門、7はJavaScriptが鬼門です。

1. Web Components
2. Polymer
3. Riot
4. React + react-templates
5. Ampersand + Handlebars
6. React + JSX
7. AngularJS

※順番には多分に主観が含まれます m(_ _)m

## AMD、CommonJS、そしてES6

Rubyには[gem](https://rubygems.org/)があり、Nodeには[npm](https://www.npmjs.com/)があり、PHPには[Packagist](https://packagist.org/)があります。フロントエンドにも[Bower](http://bower.io/)がありますが、肝心のブラウザ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](http://nodejs.org/)、[io.js](https://iojs.org/)はすでにES6に対応しており、あとはブラウザの対応を待つだけというところまで来ました。

Angularは、当時選択肢がなかったためモジュールシステムを内製しましたが、今となっては足枷でしょう。Angular 2.0はES6とWeb Components対応になるとのことなので、大きな仕様変更は避けられません。1.0と2.0の連続性はあまりないはず。Reactは、その点、npmとの親和性が高いのでBrowserifyやWebPackを(まともに)使うことができるので、EC6のインパクトはそれほどありません。もしエンジニアが、今はじめて手をつけて、すぐに結果を出さなければならないなら、Reactは有力な選択肢です。

でも、ちょっと冷静になりましょう。作りたいアプリケーションは、壮大なスケールが必要なものですか? 学習コストに見合うものですか? 去年までは、他に選択肢がないという意味で、AngularかReactか(あるいはBackboneか)を選ばざるを得なかったけれど、今の時点だと、新興フレームワークがいくつも出ています。

- [Ampersand.js](http://ampersandjs.com/) - 優等生
- [Mithril](http://lhorie.github.io/mithril/) - 軽い速い
- [Mercury](https://github.com/Raynos/mercury) - 渋い
- [Aurelia](http://aurelia.io/) - ES6対応・フルスタック
- [Riot 2.0](https://muut.com/riotjs/) - お手軽・必要なものだけ

ここで、何を基準にするか。戦略はふたつ。

- 長いものに巻かれる
- シンプルなものを使う

私は後者で行きたいです。なぜなら、2,3年後には確実に違うものを使っているから。

### パッケージマネージャの不在

フレームワークもですが、JavaScriptはパッケージマネージャも混沌としています。

[npm](https://www.npmjs.com/)が最大勢力です。最近2.0になり、エンタープライズ向けの対応や、キャッシュサーバを立てやすくなったりなど、成熟の感があります。ただ、ブラウザ向けの対応についてnpmからは話が聞こえてきません。まあしないような気がします。今後、JavaScriptモジュールを開発段階でなくブラウザレベルで読み込むようになると、それを一体どこのCDNが負担するんだろう...。

- [npm](https://www.npmjs.com/): サーバサイド、手元開発はこれでOK
- [Bower](http://bower.io/): 立ち位置が微妙、ES6向けの対応を打ち出せるのか...?
- [Duo](http://duojs.org/): [component.js](https://github.com/componentjs/component)からの流れ
- [spmjs](http://spmjs.io/):  static package manager for browser
- [jspm](http://jspm.io/): よく知らない...

まだしばらくは、ブラウザから直接じゃなくBrowserify/WebPackでビルドして使う派ですが、先行きが気になります。


## 結語

Web ComponentsもES6も、実のところ数年前からの動きです。コンポーネントについては、むしろWeb Components陣営以外からの動きが加速した点を、注目すべきかもしれません。

さて、あまりの混沌に、近づきたくない言語の筆頭に挙げられるJavaScriptですが、時代はますますの戦乱に突っ込みます。個人的には、しばらく[Riot 2.0](https://muut.com/riotjs/)に寄り添っていこうと思います。昨日、ひとつ[プルリクエスト](https://github.com/muut/riotjs/pull/319)を送りました。

戦乱の世は、下克上のチャンスです。今のうちに頑張って、コミッターにのし上がりましょう。ガンガン、コードで殴り合いをしたら良いと思います。あー、私はデザイナーなのでヤサシクシテクダサイ。