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

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

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

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

コンポーネント

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

• AngularJS
• React
• Polymer

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

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

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

標準路線

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

• Polymer *
• X-Tag *
• Bosonic

※ Polymer, X-TagはPolyfillとしてwebcomponents.jsを使用

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

• Custom Elements

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

独自路線

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

• AngularJS
• 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が鬼門です。

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があり、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に寄り添っていこうと思います。昨日、ひとつプルリクエストを送りました。

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