次世代UIフレームワークとしてOnsen UI 2を考える――UIフレームワークの変遷とOnsen UI 2のこれから

2016年12月14日

こんにちは、榊原@rdlaboです。
先日、東京にいったついでに五反田で「フロントエンド 日本酒フェス@五反田」を開催しました。フロントエンドを嗜んでいるメンバーでただ飲むだけのつもりだったのですが、私がCTOをしている会社のオフィスが近くにあったので二次会はなぜかLT+「OnsenUI2とは?」という議論に(参加者にOnsenUI2の開発者もいたので)。
そこで見えてきたOnsenUI2の役割は思った以上に夢があるものでしたのでちゃんとまとめておきます。
 
この記事はOnsen UI Advent Calendar 2016の25日目の記事です。
 

本稿の概要

  • UIフレームワークはWebデザインを変えた
  • UIフレームワークは、CSSフレームワークからはじまりデザインの幅を広げていってる
  • WebComponentsを利用したフレームワークであるOnsenUI2は、UIフレームワークの最先端
  • だからこそ、UIフレームワークとしてのポジションを築いてほしい
  • OnsenUI2が今後こういう展開になるといいなぁ
  • 好き勝手いってごめんなさい

1. UIフレームワークの変遷

ペーパーデザイナーが生み出したスキュアモーフィック

UIフレームワーク登場以前は、「webデザイナーになりました!」と言う方の前身は大体は紙面デザイナー出身でした。もしくは、紙面デザインをしていたデザイン会社がwebデザインに手をだしたか。なので、webデザインはスキュアモーフィックからはじまりました(厳密にはダイヤル回線速度を考慮した1990年代独特のデザインもあるのですが割愛します)。
 

 
いい表現では「webにリアルを持ち込んだ」、辛辣な表現では「webデバイスの特徴を考慮せず見た目に走った」などといわれるデザインです。ですので、当時のwebデザインといえば「優れた一点物」であり、「おしゃれで格好いい!」だったわけです。
 

BootStrapが変えた一点物至上主義

Twitter社がCSSフレームワーク「Bootstrap」を発表したのは2011年8月のことでした。

当時日本では、エンジニアは「デザインできなくてもそれっぽいのがつくれる!」、デザイナーは「Bootstrapはそれっぽいけどダサい。使うのは手抜きだ!」みたいな風潮だったのを覚えています。しかしながら、Bootstrapは「簡単にデザインできる」だけではなく、フルオーダーだったwebデザインの世界に風穴をあけたのです。パーツをモジュール化して再利用できるのはひとつのWebの文化だな、と。
 
「Bootstrapはださい?だったら、Foundationはどうだ!」であったり、「Bootstrapは重い?だったら軽量CSSフレームワークだ!」みたいにその後継として様々なCSSフレームワークがでてきましたが、そのどれもがCSSの再利用を前提としているのは時代の流れでみると特徴的です。
 
その結果、Webデザインの世界の中でパーツのモジュール化(再利用する設計)は常識になりました。またこの数年後にフラットデザインが流行りだし、webのデザインルールがある程度確立。それを実現する「Atomic Design」という手法も生まれました。

ポストCSSフレームワーク

CSSフレームワークも「CSSフレームワーク」として時代とともにバージョンをあげ進化を続けておりますが、それとは別の潮流もでてきています。
簡単にいうと「CSSだけでは表現しきれない部分ってあるよね?」とJavaScriptを使いはじめたフレームワークです。BootstrapなどもJavaScriptをつかっていましたが、その目的はモーダルウインドウの開閉であったりと「CSSで表現する部分」「JavaScriptで動作させる部分」がはっきり分かれていましたので、「JavaScriptで表現」することをはじめたのが新しいなぁと思った記憶があります。
 
具体的なきっかけは、GoogleがMaterialDesignを提唱したことです。MaterialDesignでは、ボタンクリック時にeffectが走ります。これを実現しようと思うと、クリックイベントを検知する必要があったからこそ生まれたと思っています。
 
代表的(私が探しきれてないだけなのでまだまだあると思います)なものに、Materializeがあります。ボタンクリックのイベント時に、JavaScriptでDOM操作を行いeffectを表現しています。
 

 
スキュアモーフィックからCSSフレームワークへの変遷(厳密にいうと、CSSフレームワークの隆盛によるデザインのモジュール化。フラットデザインの流行)で表現の幅が制限されたあとに、コンセプト的にではなく、技術的にデザインの幅を広げたのが個人的に面白いなと思っているところです。
 

WebComponentフレームワーク

そして近年、WebComponentsが現実的となってきました。
WebComponentsって何という方は、iframeの進化版と理解すればいい、いいのかなぁ。Facebookのいいねボタンのように、そこにコードを貼り付けたらそこにコードを展開してくれる機能です。
OnsenUI2は、この技術を利用している世界中でみても先進的なUIフレームワークです。
 
例えば、OnsenUI2のons-fabでいえば

<ons-fab position="bottom right">
    <ons-icon icon="md-plus"></ons-icon>
</ons-fab>

と入力すれば、ブラウザで表示する時にJavaScriptによって自動的に

<ons-fab position="bottom right" class="fab fab--bottom__right" style="transform: scale(1);">
    <span class="fab__icon">
        <ons-icon icon="md-plus" class="ons-icon zmdi zmdi-plus"></ons-icon>
    </span>
</ons-fab>

と展開してくれます。コーディング的にも行数が増えないので楽ですよね。自動的に遅延ロードしてくれる機能もあったりと、JavaScriptの恩恵を最大限利用することができます。
 
UIフレームワークとして、見た目だけの「CSSフレームワーク」、そこに一部のeffect表示のためにJavaScriptを使った「ポストCSSフレームワーク」と続きましたが、「WebComponentsを利用して表現幅を大幅に広げつつコーダーの負担を増やさないUIフレームワーク」というコンセプトは、そこから更に一歩歩みを進めた「次世代フレームワーク」といえます。
 
ちなみに、WebComponentsを利用している他のUIフレームワークは、Google謹製のMaterial Design Liteぐらいで、私の感覚値としてはWebComponentsはCSS,JavaScriptがわかった上で様々な対応をしないといけないのでCSSフレームワークのように雨後の筍がごとくどんどん生まれてくることはないのではないかと思っています。
 
そう思うと、OnsenUI2すごい!(のと、実装お疲れ様です・・・)
 

2. OnsenUI2の誤解

敢えて表題を「誤解」としましたが、公式がそう謳ってるので実際には「私個人が何だかなぁと思うところ」と表現すべきかもしれません。
 
それは、公式サイトで「Onsen UIはお好きなJavaScriptフレームワークでご利用いただけます」を推しているところです。

OnsenUI1時代はAngularJSと密結合でしたし、由来としては特徴的です。しかしながら、ぶっちゃけた話、BootstrapもどのJSフレームワークと組み合わせて使えるUIフレームワークなのです。CSSフレームワークとしてはもちろんのこと、有志がつくってるライブラリを組み込んだらModalであろうとAlertであろうとちゃんと動きます。だからこそ、OnsenUI2の本質はそこでない気がしています。
  
Angular2で使うことにメリットは(現状では)弱いですし、「monaca-cliはやめよう!OnsenUI2を使うにはangular-cliではじめた方がいい理由と使い方」を一端として落とし穴は点在しています。
 
それよりは、「WebComponentsを採用したことによって表現の幅が大きく広がったUIフレームワーク」という点こそが本質として光るのではないでしょうか。その上で、JavaScriptフレームワークにも対応していますよ、と。
で、UIフレームワークだからこそ

 
みたいな助言をしてくださるデザイナーの方々をフォローしながら、まずはUIフレームワークとして完成度を高めるという打ち手が選べます。 
 
ちょっと話はそれました。
「Angularを採用するなら、OnsenUI2どう?」ではなく、UIフレームワークとしてのOnsenUI2という見方がいいと思っているのですが、いかがでしょうか(OnsenUI2とIonic2の比較記事書いたあたりからそう思い出した人)
  

3. OnsenUI2のこれから

部外者があーやこーやいう展開が続いて恐縮ですが、OnsenUI2が「UIフレームワーク」としてのポジショニングを強化する上でこんな展開になるといいなぁという部分について書きます。

1. jQueryサポートとCDNでの配信

特に国内においては、デザイナーは、JavaScriptフレームワークどころかnpmも使わない方が多いです。
ですので、OnsenUI2を使うスタートラインは「jQueryで使えるUIフレームワーク」にポジションすべきではないかと思います。現在あるようなnpmでons createしましょう、ではなく、CDNで配信して、それを読み込んでくるだけで簡単にはじめられるという環境が重要ではないでしょうか。
 
headで読み込んできたらまず体験できる、そういう世界になると、OnsenUI2がOSSであるメリットが生まれてくると思います。

2. ドキュメントの整備と見直し

現在、OnsenUI2のリファレンスはhttps://ja.onsen.io/v2/docs/js.htmlとなっているのですが、これではOnsenUI2の機能を俯瞰するのに、クリックしては戻って、クリックしては戻って、を繰り返す必要があります。
属性であったり関連情報であったりはもう一層深くなっていいので、機能は内容まで一覧で見れるようになるともっと使いやすいのではないでしょうか。例えばBootstrapのComponents一覧とか見やすいなぁと思うのです。

3. SCSS対応

OnsenUI2は、Stylusでつくられています。社内で開発する分としては問題ないのですが、参画者が増えるとなるとSCSS対応があるとコミッターの幅ってもっと広がるのではないでしょうか。現在、OnsenUI2のテーマの書き換えみたいなテーマでの議論がないのもデザイナーの参画を阻む要員のひとつだと思っていまして、

  • 開発時点でのSCSSの採用
  • 利用時点でのSCSSの採用(テーマ変数の書き換え)

が実現すれば大変いいなぁと思います。

4. チーム編成の増強

1,2,3によって参画する幅をつくったあとは、次世代UIフレームワークに関わりたいデザイナーでチームができてるといいなと思います。
それは、OSSの特性を活かして無償チームもあっていいと思いますし、作業と責任が付随する有償チームがあるのもありだと思います。有償チームはOSS的には「コアコミッター」という部類になるのですが、デザイン監修的なポジションもあっていいかと思います。
 
誰でも簡単にOnsenUI2をはじめれる環境になったら、次はOnsenUI2に関わる人自体がどんどん増えてくる世界になるのではないでしょうか。「次世代UIフレームワーク開発」として位置づけるなら実績あるしスポンサー企業も普通につくと思うんですよね。
 
また、例えばAngularでいうと、早くからOnsenUI2を試している@ovrmrwさんであったりとか、フレームワーク毎にもチームができるといいな、とか思っています。
 

5.未来の話

モバイルファーストというと本来は「モバイルの画面を設計したあと、Laptopの設計に入る」というモバイルに重点を置いた開発手法のはずです。しかしながら、開発画面がLaptopである影響からか、なぜか「モバイルを意識しながら、Laptopで開発する」という言葉だけが先行した開発スタイルになっているのが現状です。
それを背景にしながら、「今回はモバイルファーストの仕事かぁ」「だったら、Bootstrapじゃなくて、OnsenUI2で開発しよう」という会話であったりとか、モバイルを意識するならまずはOnsenUI2という世界が少なくても国内でつくることができればなぁと思っています。
 
WebComponents × モバイルデザイン
 
の世界におけるUIフレームワークとしてのデファクトスタンダードの位置にOnsenUI2がある、そういう未来が「これから」にあることも決して夢でないのではないでしょうか。
 

4. まとめに代えて

まずは、部外者が好き勝手いって中の人ごめんなさい。
 
いろいろ、「OnsenUI2はこうであってほしい」であったり「参画するための仕組みが必要」ということを書きましたが、最後にOSSとしての目線について書いておきます。
これをお読みの方でOSSに参画してる!という方はどれぐらいいるかというと、あまりいないと思います。というのも、皆さんがふれるようなOSS(Bootstrapであったり、Angularであったり、WordPressであったり)は、次の3つの障壁があります。
 

  • 完成度の壁(完成度めちゃくちゃ高いから、ヘビーユーザじゃないと参画しづらい)
  • 言語の壁(英語でやりとりしてね!)
  • 技術の壁

 
ライトユーザだとまずは「ここをこうした方がいい」ということに気づけない。ふと思いつくレベルは大体実装されてるか、過去コンセプトにあわないと却下されてたりします。で、それを確認しようと思って立ちはだかるのが言語の壁です。英語を読んで書けないと、コミッターとのやりとりはつらいわけです。平坦な英語でいけるよ!というのはわかるのですが、平坦な英語といっても・・・というのはあると思います。
そして最後に技術の壁。「どうやって実装したらいいの?」みたいなめちゃくちゃハイレベルなものが中心にIssueに残されている場合が多く、参画を断念したという方も少なくはないと思います。
 
しかしながら、OnsenUI2は違います。
 

  • 完成度は高くない。使ってると何らかに気づける(中の人ごめんなさい)
  • 国産なので、日本語でのやり取りが可能です
  • CSSレベルでまだまだ改善の余地があり、参画する余地は十分にあります

 
と他のOSSと比べて参画しやすいのが、かなり特徴的です。
例えば、OnsenUIのレポジトリはhttps://github.com/OnsenUI/OnsenUIにあり、Issueは英語のものばかり上げられていますが外国人がIssueを多くあげてるだけで日本語でのIssue立ても問題ないとのことです。
 
なので、私もIssue立ては日本語でやっていますw(例えば
 
実際に使ってみると、「これはこうしたい」「これはこっちの方がいい」「このIssueさっさと片付けろよ。時間あるからやろうかな」みたいなものも出てきており、OSSに関わったことのない方のリソースを少しずつOnsenUI2に使うことができると前述した「未来の話」も夢物語ではなくなるのではないかと思っております。
 
他のOSSより圧倒的に参画しやすいので、ぜひとも考えてみてください!
 
OnsenUI2についての疑問を解消するためにの場としてslackチーム「https://ng-onsenui2.herokuapp.com/」もありますので、ぜひご活用ください。

それでは、また。