Web制作してると、また新技術が出たのかと思うと、気づいたら「新常識」が増えてたということに頻繁に出会います。

タスクランナー、SCSS、LiveReload、SPA、PWA、ハイブリッドアプリ。そういった近年のキーワードを一気に体験できるUIフレームワーク「Ionic 2」が先日リリースされましたので、ご紹介します。

編集部注: Angular 2の正式名称は「Angular」ですが、現状だと「AngularJS 1.x」のことを呼称していると誤解される可能性が高いと判断し、本稿では「Angular 2」で統一させていただきます

記事の内容が古くなってたので、2017年8月11日に更新しました

Ionic 2の概要

Ionic2は、アメリカのIonic社が中心となって開発しているオープンソースのモバイルフレームワークです。 Angular 1上に構築されたIonic 1の後継プロダクトとなり、当時の経験が反映され、とても完成度が高く仕上がっています。 つい先日の2017年1月29日に正式リリースされました。

Drifty Coがデモアプリとして、Ionic 2 Conference Applicationを公開していますので、ぜひアクセスしてみてください。モバイルアプリのデモですので、スマホからアクセスするのがいいかと思います。Ionic 2の世界観とデフォルトデザインの完成度の高さがよくわかるデモとなっています。

このデモでわかる操作性・UI以外にも、Ionic2には

• ターミナルにコマンドを4行入れるだけで開発をはじめることができる
• Webはもちろんのこと、iOS/Android/WindowsPhoneアプリとしてもリリースできる
• ブラウザにPush通知を送ったり、オフライン対応することも可能
• Angular 2上に構築されているので高速

という特徴があります。 Web最前線の現場で使われてる技術を体験するために、ぜひとも一度使ってみてください！ 　

4行で高速開発環境構築

Ionic 2でどのような体験ができるかをご紹介するために、実際にプロジェクトを立ち上げてみます。以下は、Node.js(6以上)をインストールされている環境を前提にしていますので、未インストールの場合は https://nodejs.org/ja/ からインストールください。

最初に、ターミナル（Windowsの場合はコマンドプロンプト）を立ち上げ、以下のコマンドを入力します。これで、Ionic 2を構築するためのIonic CLIというパッケージをインストールします。

npm install -g ionic cordova

次に、プロジェクトを作るフォルダに移動して、以下のコマンドを入力します。するとProjectNameという名前のフォルダが作成され、2-3分でプロジェクトが作成されます。

ionic start ProjectName --v2

最後に、ProjectNameというフォルダに移動し、ionic serveという開発を開始するためのコマンドを入力します。

cd ProjectName
ionic serve

すると、自動的にブラウザが立ち上がり、画面が表示されます。URLがhttp://localhost:8100/になっていると思いますが、これはIonic CLIが自動的に開発用サーバを立ち上げてくれたためです。（実際にアクセスしているのは、www/フォルダの中です）

4行のコマンドで開発の準備が完了しました！

5分でIonic 2の開発を体験！

早速開発してみましょう。Ionic 2は、様々な機能が実装されているためにいろいろな設定ファイルやフォルダが用意されていますが、最初はsrc/とwww/の中をさわれば事足ります。

ProjectName/
├── src/
　　├── app/
　　├── assets/
　　├── pages/
　　　　├── about/
　　　　├── contact/
　　　　├── home/
　　　　└── tabs/
　　├── theme/
　　└── index.html
└── www/

では、まずsrc/pages/の中を見てみましょう。

4つのフォルダが、画面のそれぞれのComponentに対応しています。例えば、Home画面だと以下の通りです。 メインコンテンツはhome/home.htmlが、タブのエリアはtabs/tabs.htmlがテンプレートになっています。

試しに、home/home.htmlをログインフォームにしてみましょう。home/home.htmlの中身を以下に差し替えて見てください。

<ion-header>
  <ion-navbar>
    <ion-title>Home</ion-title>
  </ion-navbar>
</ion-header>

<ion-content padding>
  <ion-list>
    <ion-item>
      <ion-label fixed>Username</ion-label>
      <ion-input type="text" value=""></ion-input>
    </ion-item>

    <ion-item>
      <ion-label fixed>Password</ion-label>
      <ion-input type="password"></ion-input>
    </ion-item>
  </ion-list>
  <button ion-button block>Login</button>
</ion-content>

そして保存すると、自動的にブラウザが更新されて、ログインフォームが表示されます。 LiveReloadという機能で、一回いっかい更新ボタンを自分で押す必要がないので、複数ディスプレイで作業してる時とても捗ります。

見慣れないタグ。これって何？

home/home.htmlのタグをみると、ion-headerやion-contentと見覚えのないタグが使われていることに気づくと思います。これは、Directiveを使って定義づけているカスタムタグで、Ionic 2オリジナルのものです。 例えば、<button ion-button>Login</button>だと、これをJavaScriptが以下のように展開します。

<button block="" ion-button="" class="button button-md button-default button-default-md button-block button-block-md">
    <span class="button-inner">Login</span>
    <div class="button-effect" style="transform: translate3d(392px, -91px, 0px) scale(1); height: 240px; width: 240px; opacity: 0; transition: transform 552ms, opacity 386ms 166ms;">
    </div>
</button>

複雑なHTMLであったり、多くのclass名であったりをいちいち書かなくてもいいようにIonic 2が処理してくれますので、開発コードがとても可読性の高いものとなります。 Ionic 2が用意しているComponentsは、公式のサイトから一覧で確認できます。

Ionic 2を使っていると、最初は「ドキュメントにあるコンポーネントをコピペしていく」だけで大部分のUIデザインが完了します。ですので、ワイヤーフレーム段階からがしがし作っては捨てるタイプの小さく回す開発が可能です。

Ionic 2のUI

Themeを書き換える

Ionic 2は、CSSを拡張したSCSSを採用しています。変数などが使えるので、!importantを使わずにThemeの変更をすることが可能です。 実際に、SCSSの変数機能を利用して、Themeを自作してみましょう。

src/theme/variables.scssを開いてみてください。現在設定されているThemeの変数を入れ替えたり、上書きするための設定ファイルです。

この$colorsで設定されているprimaryがdefaultの色となります。試しにこの色をredに変更して保存してみてください。正常にLiveReloadが動作していれば、自動的に以下のようにThemeが変更されます。

他にも、様々な設定変数がIonic2には用意されています。試しにツールバーの背景色を変更してみましょう。 $colorsの下に、以下の値を入力してください。

$toolbar-background : yellow;

そしてリロードすると、ツールバーの背景色が黄色になるのを確認できます。これらの設定変数はOverriding Ionic Sass Variablesに書いてありますので、ここを見ながら変数を作っていくと、簡単にオリジナルThemeを作ることができます。

プラットフォームチェック

Ionic 2は、それぞれのモバイルOSの文化に寄り添ったデザインで表示されるようになっています。上記はChromeで表示しているのでマテリアルデザインとなっていますが、iOS SafariでみるとiOSのデザインに自動的に変更されます。

それぞれのモバイルブラウザでどのように表示されるかを見比べる機能があるので使ってみましょう。http://localhost:8100/ionic-labにアクセスしてみてください。先程の表示画面がそれぞれのモバイルプラットフォーム毎にどのように表示されるのか見比べることができます。

UI,UXを考える上で、それぞれのユーザのプラットフォームの文化に寄り添うのはとても重要な要素ですので、とても重宝する機能です。

Ionic 2をコンパイルする

iPhoneアプリとしてコンパイルする

作ったWebアプリを、iOS/Android/Windows Phoneのアプリとしてコンパイルすることができ、それぞれのプラットフォーム上でのアプリストアで販売できます（このように作られたアプリをハイブリッドアプリといいます）

コンパイルは、とても簡単です。例えば、Xcodeをインストール済みのMacでしたら、以下のコマンドを入力するだけでコンパイルが行われ、iOSアプリとしてのプレビューが行われます。

ionic cordova emulate ios

Webがオフラインでも表示できるようにする

Ionic 2は、Googleが提唱しているService WorkerというWebサイトをアプリとして使うための技術を積極的にキャッチアップしています。Service Workerには様々な機能がありますが、Ionic 2はデフォルトでオフライン対応が実装されています。

オフライン対応を有効するのはとても簡単で、src/index.htmlの17-24行目のコメントアウトを外すだけです。

<script>
    if ('serviceWorker' in navigator) {
      navigator.serviceWorker.register('service-worker.js')
        .then(() => console.log('service worker installed'))
        .catch(err => console.log('Error', err));
    }
  </script>

ただ注意事項が2点ありまして、1つはServiceWorkerはSSLでしか動かないです。もうひとつは、現行ではiOS非対応ですので、iPhoneでの確認をすることはできません。ご注意ください。

リリース版をコンパイルする

Ionic 2のコンパイルは、serve/cordova emulateとnpm run build --prodのに分かれます。簡単に違いをいうと、前者はLiveReloadをストレスなく行うために実環境のパフォーマンスを落としていて（Just in Time Compile）、後者はコンパイル時に時間こそがかかるものの、それ以降はとても高速に動作します（Ahead of Time Compile）。ですので、開発環境では前者を、本番環境では後者を使います。 Ahead of Time Compileのコマンドは以下ですので、お気をつけください。

npm run build --prod

ionic cordova build ios --prod

ionic cordova build android --prod --release

なお、Compileの違いの詳細に興味がある方は、Angular AoTガイドをご覧ください。

終わりに

ここまでは、入門的HowToをご紹介してきました。冒頭でもふれたとおり、近年のフロントエンドのキーワードをまとめてさわるにはとても優れたモバイルフレームワークです。しかしながら、実案件に入るとAngular 2ベースのComponents開発であったり、SPA文化であったり、開発に入る前にもっと触れておいた方がいい知識があります。そこで、次の入り口として、3つをご案内して結びにかえさせていただきます。

公式のチュートリアルでもっと学ぶ

Ionic 2では、初心者向けのチュートリアルを用意しています。英語なので少し大変かもしれませんが、大変わかりやすく書かれてありますのでおすすめです。Ionic 2を使う前提でしたら、Angular 2のチュートリアルをする前にぜひこちらを試してみてください。

Ionic 2 Tutorial

日本語コミュニティあります

今では随分改善されましたが、Ionic 2はリリース前（特にβ版時代）はとても日本語情報が少なかったので、知見を共有するためにslackのオープンチャンネルを開設しました。分かる方がいれば有志が回答する形ですのでレスポンス速度はあまり高くありませんが、ご活用いただけましたら幸いです。

Ionic 2 slackチーム

編集部注: Angular 2の正式名称は「Angular」ですが、現状だと「AngularJS 1.x」のことを呼称していると誤解される可能性が高いと判断し、本稿では「Angular 2」で統一させていただきます

Angular 2のコードを10万行書いた

白石奥野さん、今日はよろしくお願いします。奥野さんの、Angularとの関わりを教えていただけますか？

奥野 私はもともと関西で音楽の専門学校を出て、音楽関係の仕事をしていたんですが、それだけじゃ食っていけなくて、Web制作のバイトをしていたんです。 それでそのうちAngularJS 1を触るようになり、関西にAngular専門のコミュニティがなかったので、ng-kyotoってコミュニティを立ち上げて…っていうのが馴れ初めです。

白石最初は音楽の仕事をされてたんですか！むしろその話に興味があります(笑)。でもまあ、この場ではそこを聞くのは我慢して、Angularとの関わりの話を続けてください。

奥野 で、東京に出てきて就職した企業で、そこは大規模なWebサービスを運営しているのですが、AngularJSを採り入れてみるというプロジェクト開発を行っていたんです。 ただ、サービスが巨大すぎたためパフォーマンスが全然出なくて困っていたところに、Angular 2がβバージョンに到達したというニュースが舞い込みまして。 もともとAngular 2も個人的には触っていたので、Angular 2でやってみたらどうかと提案したら通りまして、そこからAngular 2を仕事で書きまくる日々が始まりました。

白石βになったタイミングが良かったんですね。ちなみにぼくのAngularとの関わりを言うと、実はAngularJS 1.xはあまり触っていないんです。あんまり好きになれなくて。 でも、TechFeedというエンジニア向けニュースアプリを自社開発している中で、次はモバイルアプリをWeb技術で使いたいと思った時に、Angular 2が選択肢に挙がりまして。

ぼくらはモバイルアプリのUXを重視したかったので、そのタイミングで「モバイルを想定して、パフォーマンスを重視した」というAngular 2が出てきたのは、タイミングが良かったんですね。 モバイルアプリ向けのUIフレームワークであるIonicもAngular 2をベースに書き直され始めていましたし、AngularJS 1.xのちょっとごちゃごちゃした感じが綺麗に整理されてもいたので、 当時βバージョンではありましたが、全面的に採用することにしました。

白石ちなみに奥野さん、Angular 2関連のコードはどれくらい書かれたんですか？

奥野 そうですね、GitHub上のコードカウントから大雑把に言うと、だいたい10万行くらいです。

白石10万行！？すごいですね！

奥野 はい、書きまくりました(笑)。私一人が書いたコードがそれくらい。最終的には6名くらいのチームで、かなりの量のコードを書きましたね。

実際に使ってみて感じたAngular 2のメリット

白石じゃあそろそろ、Angular 2開発をやってみたナマの声を読書の方々に届けるという、本題に入りますか。奥野さんは、Angular 2のメリットと言われてぱっと思いつくのはなんですか？

奥野 そうですね、さっきも言いましたけど、やはりパフォーマンスの良さですね。

白石ぼくは1をほとんど使っていないのですが、そこまで違いますか、やっぱり。

奥野 はい、1に比べると段違いです。 コンポーネントの状態が変更されたことを検知する、ChangeDetector という仕組みがやはり素晴らしい。 非同期処理や、ブラウザ上のイベントを検知して、ChangeDetectorが状態をチェックします。Angular JS 1.xだと、($scopeの)変更検知はループ処理で行っていたのですが、ずいぶん効率が良くなりました。

（筆者注: 「非同期処理や、ブラウザ上のイベントを検知」する処理は、Zone.jsというライブラリで行う。AngularはZoneのイベントを受けて、ChangeDetectorがコンポーネントの変更検知を行う）

白石ChangeDetectorのコードを動的に生成するというのも、Angular 2のパフォーマンスを向上させていますよね。VMフレンドリーと言われている。

（筆者注: Angular 2は、コンポーネントの変更検知処理をライブラリとして一括で行うのではなく、コンポーネントごとに専用のChangeDetectorを自動的にコード生成する。 生成されたChangeDetectorはほぼ静的なコードとなるため、JavaScript VMにとって最適化しやすいと言われている）

あと、先ほど「6名くらいのチームで」とおっしゃってましたが、TypeScriptはよく言われているように、チーム開発に向いていましたか？

奥野 はい、それは間違いなく。ミスも減らせますし、複数人で書いたコードの統合もしやすいです。また、一つの大きな機能を複数人で作る時に、インターフェースだけ先に決めておき、モックを活用して並行開発するというのもやりやすかったです。 こういう開発は、型がないJavaScriptよりもずっとうまくやれると思います。

白石「インターフェースに対してプログラミングする」というやつですね。

奥野 Angular 2のほかの大きなメリットとしては、やはりコンポーネント指向であることが挙げられるかと思います。 私のときは、コンポーネントのHTMLとコード（TypeScript）はエンジニアが、CSSはデザイナーがメンテナンスするという役割分担を行ったのですが、これもうまくいきました。 Angular 2が、コンポーネント同士だけではなく、コンポーネントのマークアップ、プログラミング、スタイリングを自然に分割できるよう設計されているおかげだと思います。

白石確かに、コンポーネント指向は一番のメリットですよね。再利用性も上がるし、何より「UIを分割して設計しよう」という空気が自然と生まれるのもいい点だと思います。 特にぼくは、コンポーネントごとにCSSがカプセル化されて、他のコンポーネントに影響を及ぼさない点が特に気に入ってます。BEMとかの、長ったらしいクラス名が実は好きじゃないもので…

奥野 わかります。ただ、私たちの場合はAngularJS 1.xからの移行からプロジェクトが始まってしまったので、Scoped CSSはうまく活かせなかったんですよね。そこはしょうがなくBEMを使い続けていました。

Angular 2アプリ開発で苦労した／している点

白石では、今回の目玉（？）である、Angular 2の「しんどい点」について話しましょうか(笑)。

奥野 はい、ぜひ。ただ…実は私、Angular 2は結構気に入ってまして、すぐには欠点が思いつかないんですよね…白石さん、なんかあります？

白石確かに、ぼくも気に入っちゃってるので、あんまり思いつかないですね。

奥野 ただ思い返してみると、AngularJS 1.xからAngular 2に移行するのはしんどかったですね。

白石そうか、それはぼくがわからない苦労だ。それは大変そう(笑) 規模が大きいと特に。

奥野 移行するときは、3〜4万行くらい(のAngularJS 1.xのコード)だったと思います。コンポーネント数とかはよく覚えていて180コンポーネント、90サービスです。 これを移行するのにだいたい3〜4人月かかったかな、という感じです。しかももともと私たちはTypeScriptでAngularJS 1.xを使っていたので、元がJavaScriptの場合は、もっと移行に時間がかかると思います。

白石それはしんどい。

奥野 でも移行したときに最初に思ったのは、「あ、ほんとにできるんだ」っていう驚きでしたけどね(笑)。その時の移行パスについては、ng-japanのカンファレンスで発表しました。Angular 2.0.0がリリースされるより前の資料なので少し古いですが、考え方は変わっていません。 あと、苦労した点で思い出したのですが、最初の学習コストが高いという問題はありますね。TypeScriptに慣れていない、JavaScriptしか触ったことのないエンジニアにとっては、型がある言語って最初は扱いにくかったみたいです。

白石学習コストの面はよく言われてますよね。TypeScriptに加えて、Angular 2そのものの学習コストも高いですしね。

奥野 付属しているRxJSとかも学習コストはかなり高いですね。

白石あ、それで思い出した。RxJSのドキュメントが腐ってるのはしんどい。

奥野 腐ってる(笑)。

白石腐ってますよ！ナビゲーションしにくいし、不完全だし。ぼくなんかまだRxJS初心者なので、ドキュメント見ないとRxJSのコード書けないんですが、ドキュメントが使いにくくていつもつらい想いをしてます。 ほかにも、Angular 2のツライ点で言うと、ビルドが遅いのにはいつも辟易してます。 うちなんか、コードを直して、自動的にwebpack 2がビルドし直して、ブラウザが自動リロードして、結果が確認できるまでいつも10秒くらいかかってます。

奥野 10秒なんてまだ速い方です(笑) 私たちのチームなんて最初Browserify使ってたのですが、45秒かかってましたから(笑)。 この状況で、(ファイルの変更を) ウォッチ＆再ビルドしてたら、うかつにファイルをセーブすることもためらわれてしまうので、最後はウォッチを無効化して手動ビルドするようにしてました(笑)。

でもこれも、webpackに変えただけでビルド時間が20秒切るようになったんですよね。そういう、ビルド環境の進化とかにも追随していく必要がある。

白石そう、それもけっこう大変なんですよね。うちなんて、 angular-cliとかができる前に自前でビルドスクリプト作っちゃってたので、ずっとそれを自分たちでメンテナンスしてます。 そのコストもバカにならない。

奥野 そうそう。そういう、ぬか床をずっとメンテナンスするみたいな人が必要になっちゃいますよね。

白石 ぬか床キーパー(笑) 。ちなみに、angular-cliは使ったほうがいいですか、やっぱり。

奥野 公式に推奨されてるので、使ったほうがいいでしょうね。

白石前に使おうかと思ったんですが、ビルドスクリプトがかなり複雑で、理解するのがしんどそうだな、と思って敬遠しちゃったんですよね。 ブラックボックスとして扱えばいいんでしょうけど、うちはCordovaも使ったりしているのでビルド時に求められることがかなり複雑なんです。 きっと手を入れないわけにいかない。

奥野 プロジェクトを続けていくと、ビルドプロセスをいじりたくなることはきっとあるでしょうし、中身の理解は必要になってくるでしょうね。 ただ、最初はブラックボックスとして簡単に使い始められるのと、ビルドツールの進化に追随していってくれるのはありがたいです。

白石確かに、ビルドツールの進化に付いていくのも一苦労だしなあ…移行、考えようかなあ…

Angular 2から探る、今後のWebアプリ開発の展望

白石では対談の締めに、Angular 2から今後のWebアプリ開発の展望を探ってみたいと思います。 Angular 2のリリースは、Web業界にとっては間違いなく大ニュース。そこから、今後のWeb開発のヒントが得られるのではないかと思って、こういうトピックを最後に持ってきてみました。 まず、Angular 2は今後半年ごとにメジャーバージョンアップを行っていくそうですね？

奥野 そうですね。次のリリースは2017年の3月で、バージョンは4になる予定です。 @angular/routerというパッケージだけ、バージョンが現在3になってしまっているので、次のバージョンアップでメジャーバージョン番号を合わせるために4になります。

白石しかし、メジャーバージョンアップが半年ごとというのは普通じゃないですよね。何らかのメッセージを感じる。

奥野 それは、メジャーバージョンアップに伴って「後方互換性を壊すかもしれない変更も、ためらうことなく行っていく」というメッセージの表れです。

白石ほー、それ、ちょっと詳しく伺ってもいいですか？

奥野 こういう方針になったのは、AngularJS 1.xの反省があるわけですね。 AngularJS 1.xは後方互換性を保ったまま、小幅な変更を繰り返しながら5年以上開発が続いていたわけですが、その間にWebの環境が大きく変わってしまい、追随できなくなってしまっていた。 そうしたツケを払ったのが、今回のAngular 2へのバージョンアップです。全てを1から作り直さなくてはいけなかった。 そのため、「後方互換性を損なってでも、Webの進化についていく」という方針を明確にしつつ、メジャーバージョン間の破壊的変更を最小化しようというわけです。

白石なるほど！そういう方針であれば、Webの進化に対して、フレームワークが置き去りにされることもなさそうですね。 例えば今は、コンポーネントのカプセル化にはShadow DOMのエミュレーションがデフォルトですが、Shadow DOMに対応したブラウザが広まった暁には、Shadow DOMをデフォルトにするという変更も行える。 普通はそういう変更は、かなり影響範囲が大きいのでフレームワークとしては慎重にならざるをえないですが、「メジャーバージョンアップだから」という理由で、そういう変更も大胆に行えるわけですね。

奥野 そうですね。他にも例えばWeb Workersをデフォルトにするとかもあり得ますよね。それに実際には、ある機能が廃止されるとしても、まずは「非推奨」になってから、次のメジャーバージョンアップで削られる。 メジャーバージョンアップ2回分、つまり1年間の猶予があるので、実際には破壊的変更に対しても追随はそこまで難しくないと思います。

白石Webの進化に合わせて、どこまでも進化していくフレームワークということですね。ならば、正式名称からバージョン番号を外して「Angular」にしたというのも頷けます。 Angularを開発しているGoogleは、Webの標準化においても影響力は大きいですし、Webの進化とAngularの進化が両輪で進んでいくというわけですね。Webはこれからもエキサイティングな場であり続けそうです。

本記事は、2016年9月に開催されたTechFeed Live#2 「React vs Angular 2」の模様をお伝えする記事の後編です（前編はこちら）。 TechFeed Live#2とは、「TechFeedを地上に出現させる」ことをコンセプトとした、テクノロジーの最新トレンドをエンジニア向けに紹介するというイベントです（TechFeedとは、「最先端が、ここにある。」をキャッチコピーとしたエンジニア向け情報収集アプリです）。本イベントは、ReactとAngularをより楽しく深く学ぶため、現代のWebアプリに求められる各種要件についてそれぞれを比較する…というアプローチを取りました。 （私は本イベントの企画と対談のモデレーターを務めました）

読み応えバッチリ、勉強になること間違いなし。今回はライブ感を重視し、あえてイベントでの（砕けた）口調も可能な限り再現してみました。 では皆様、どうぞお楽しみください！

かなりの熱気でした

トークバトル参加者（順不同、敬称略）

（編集部注: 本記事では登壇者の皆様の希望により、以下ハンドルネームで呼称させていただきます）

React Side

• koba04 (小林 徹)
• yosuke_furukawa (古川 陽介) (Node.js 日本ユーザグループ代表)

Reactサイド。左がkoba04、右がyosuke_furukawa。

Angular2 Side

• laco (稲富 駿)
• 83 (奥野 賢太郎) (ng-kyoto代表)

Angular2サイド。左がlaco、右が83

モデレーター

• shumpei (白石 俊平) (HTML5 Experts.jp編集長)

また今回、フレームワークを比較するための項目を以下のように洗い出してみました。基本的にこの流れに沿って進めたいと思いますが、脱線は大歓迎ですので、皆様ご自由にご発言いただいて構いません。（編集部注: 後半は「スタイリング」から）

• 開発⾔語
• アーキテクチャ
• ビルドツール
• ルーティング
• テンプレート
• スタイリング
• コンポーネント以外の処理
• ツールサポート
• テスト
• パフォーマンス
• サーバサイドレンダリング

スタイリング

shumpei 次はスタイリングについてお話いただきたいと思います。コンポーネントにスタイルを当てる云々の話、ですね。 では、Reactサイドから伺いましょうか。ReactのCSSサポートの現状といったところからお聞かせ願えるとありがたいです。

yosuke_furukawa CSS in JSとかそういったあたりの話ですね。CSSをJSの中にimportして、JavaScriptのオブジェクトかのように、コンポーネントにスタイルを当てることができる機能があります。 厳密なCSS in JSは、style属性に直接値をぶち込みます。そうすると、上からのCSSの影響を相当受けにくくできる。 そこまでいかなくても、CSS Modulesというのがあって、クラス名をuglify（難読化）してかぶらないようにして、中ではそのuglifyされたクラス名を使ってスタイリングを行い、外からの変更を受けにくくするというやり方もあります。

そういう感じで、CSSとJSを一体化して扱うということは、React界隈ではわりとやられています。

shumpei React本体はスタイリングとかに関する機能とかは持っていなくて、外のライブラリを使って実現するという感じなんですね。

koba04 はい、React本体としては、CSSは属性の一つ(style属性)なので、特別なサポートはそれほどありません。オブジェクトで値を指定できたり、幅や高さの単位を省略して指定できたりするくらいです。 あとはwebpackとかの外部のエコシステム上で、それぞれ好きにやっているという感じです。

shumpei では、Angular 2サイドはいかがでしょうか？

laco Angular 2は、@Componentデコレータの中にstylesという属性があって、そこに書いたスタイルはコンポーネントの中にしか効かないようになっています。Shadow DOMと同じ動きをするようにエミュレートされています。

yosuke_furukawa どうやってエミュレートするんですか？

laco えーと、BEMみたいなのを自動的に生成します。それでかぶらないようにする。まあ、CSSをインポートすることはしないですが、文字列で指定してるので結局インポートしてるのとあまり変わらないというか…あんまり変わらないですね(笑)やりたいことは(Reactと)一緒です。

だけど違うのは、設定を一つ変えるとネイティブのShadow DOMを使えるように変えられます。現在のデフォルトはエミュレーションになってますが、将来的にShadow DOMに対応したブラウザが増えた時に、さくっと変えられるようにはなっていますね。

koba04 この辺 (スタイリング) は結構、開発メンバーの中にデザイナーさんがいるのかとか、JSがメインの人ばかりでやるのかとかで、どうCSS書くのかが変わってくると思うので、選択肢がいろいろあったほうがいいんじゃないかな、とは個人的には思っています。

副作用を伴う処理

shumpei では次に行きましょう。APIコールなど、副作用を伴う処理をどう扱うかは、フレームワークごとにかなりアプローチが異なってくるところだと思いますが、そこら辺の事情を伺わせてください。

laco まずAPIコールでいくと、Angular 2だとHttpというライブラリがあって、それを使うという話になります。

koba04 今「ライブラリ」という言葉が出ましたが、(APIコールをするのに)外部のライブラリを使うという話なんですか？

laco npm的には別パッケージになってるんですが、Angular 2の一部という扱いです。サブパッケージと言ってもいいです。

koba04 そこをフレームワークが直接サポートする必要って何かあるんですか？

laco (Httpライブラリ内で) DIをガリガリ使っているというのと、Angularはフルスタックなフレームワークなので、アプリケーションを作るのに必要なものはとりあえず揃えておくというポリシーですね。

83 あと、Angular 2のHttpをDIで使っておくとテストが楽、モックのAPI Callを自分でガリガリ書いたりする手間が省けるというのが利点かなと思います。

shumpei ちなみに個人的には、Reduxをちょっと調べた時にミドルウェアでAPIコールをしているのが「難しいな」と思ってしまったんですが、ああいうのは慣れれば全然問題なくなるもんなんでしょうか。

yosuke_furukawa そこで難しいな、と思っちゃうのはまだReduxに慣れてない証拠です。

shumpei ほう。

yosuke_furukawa Reduxっていうのは基本的に副作用をどんどん外していってるんです。APIからGETして取ってきたデータをステートに反映するというのは、これは副作用そのものなんです。 で、こういう副作用をどこでやるかと言ったらミドルウェアでやる、というのがReduxの基本的な考え方なんです。 そこに慣れると、みんなミドルウェアで書くっていうのがなんとなくわかる。そこに慣れてない人は、Reduxをフレームワークだと思って使っちゃうんです。

shumpei なるほど、基本的な思想がちゃんと理解できていなかったんですね、ぼくが。

yosuke_furukawa あとReduxミドルウェアと言ってもいろいろあって、redux-promiseだ、redux-thunkだ、redux-observableだ、redux-sagaだと、ぼくはredux-effectsっていうのを使ってるんですけど。 要は、副作用が必要なときに副作用を発生させる方法っていうのはたくさんあるし、非同期の処理の仕方一つ取ってもたくさんあるわけです。 ES6のジェネレーターでやるっていうのがredux-sagaだし、そうじゃなくてPromiseでいいんじゃないの、っていう人はredux-thunkだとかredux-promiseだとかを使う。

そうじゃなくてもうちょっと高次元なことをしたい、複数のイベントを包括的に扱ったりしたいという場合はObservableが必要になってくる、と。 それはどこまでデカい規模のものを作るかによってミドルウェアの選定をしなくてはならなくて、そこをツライと言ってしまうとちょっと(Reduxを使うのは) 厳しいかもしれません。

フレームワークなのかライブラリなのかという話でいくと、昔あったAngularJSのMVWhateverだったりなんだったりっていうものをReduxの何かで置き換えられるかというと、あんまりそんなことやってくれないんですよね。 結構薄いライブラリなので。フレームワークじゃないとぼくがずっと言っているのはそういうことです。

何かおまかせできるわけじゃなくて、自分たちでシンプルなAPIをたくさん作って、やってくれるのは状態の管理とイベントの管理だけ、というのがReduxの思想というか。 で、副作用を徹底的に省いてくれる。

でもみんな気になってるのは、その副作用をどうやってやるの、というところで、フレームワークを使いたいと思っている人にとってはそこにミスマッチがあるんじゃないかと思っています。

テスティング

shumpei では、テスティングについてはいかがでしょう？

yosuke_furukawa コンポーネントのテスト書くか書かないか、って話があるんですが。書くか書かないかをまずはお聞きしたい。 書くとすると、こちらはenzymeっていうツールを使ってます。

laco こっちはKarmaっていうのを使います。KarmaはAngularチームが作っているテストフレームワークです。なので、KarmaがAngularと一番相性のいいテストフレームワークとして使ってますね。

あと、Angularがテスティング用のAPIを内包しているおかげで、コンポーネント単位でのテストができるようになってます。 たぶんenzymeとそんなに変わらないと思います。

koba04 そうですね、enzymeはいろいろラップしていて、DOMにマウントしたコンポーネントに対するテストとか、renderToString()で書き出したHTML文字列に対するテストとか、対象のComponentだけを浅くrenderするShallowRendererなどを提供しています。

そういうのを提供するために、ReactはTestUtilsというアドオンを提供しています。最近だとTestRendererっていう、ツリー構造をただのJSONで返してくれて、それに対してテストするみたいなのもあります。なので、テストは書きやすいかな。 あと、Reactのコンポーネントって多くはただの関数で、状態を持たない。入力を与えたら、React Elementのオブジェクトが返ってくるというただの関数なので、テストも簡単に書けるという感じです。

Reduxとか使うと、そのただの関数の部分がReducerだったりと増えてくるので、より簡単に書けるとは思います。 あとShallowRendererだったらDOMにも依存しないので、JSDOMなどを使う必要ないし、NodeとかでMochaとかPower Assertとか使って簡単にすぐかけるというのはいいところかなあと思います。

laco 書くか書かないか問題で行くと、Angular 2の場合は書かないとまずいんですよね。テンプレートが間違ってた時に本番でぶっ壊れるので、テンプレートがコンパイル可能かというのを、コード生成可能なテンプレートになっているかというのをテストしないとまずくて。JSXの場合はコンパイルエラーになってくれるけど、Angular 2のテンプレートはただの文字列なので、実行するまでわからないというのがあって。

yosuke_furukawa ただ、そもそもビューのところって変更が一番多いところだと思うんです。そこってテスト書いちゃうと、ROI (投資対効果) 的にというか、コストがペイしないんじゃないかとぼくは思っていて。なので、基本は「書かない」がいいんじゃないかと思ってます。

laco コンポーネントの中のプロパティのテストとかですか？

yosuke_furukawa そう、それとか…。

laco だったら、基本やんないですね、あんまり。

yosuke_furukawa lacoさんの言っているテストっていうのは、テンプレートがコンパイル可能かどうかの(最低限の)テストってことですか。

laco そう、それは全コンポーネント通しておかないと夜も眠れない(笑)。

yosuke_furukawa それは、たしかに(Reactは)JSXはコンパイル時にわかる。

laco それに、一口でコンポーネントっていいますが、そっちは関数ですが、こっちはステートを持つやつなんで、性質が全く違います。

shumpei AngularのほうはDIでテスタビリティを向上させている。一方でReactにはDIとかそういうのはないけど、Reactのコンポーネントはただの関数なことが多いからテストしやすいと。

yosuke_furukawa Reactのコンポーネントは基本的にステートを持たないから、そこ（DIとか）に関心がない。性質の違いですね。

パフォーマンス

shumpei 次はパフォーマンスです。これって議論になるのかな？

laco 今はもう、あんまり(どちらのフレームワークのパフォーマンスも)変わらないですよね。Angularのほうが初期ロードはちょっと遅いかもしれないけど、動き始めてからはあんまり変わらない。

83 これ、AngularJSでアプリ作ってて、Angular 2でもアプリ作ってて、って経験から言うと、AngularJSだから遅い、ってAngularのせいにできたんですよね。「ここ遅いのなんで？」って言われた時にAngularJSのせいです、って言っちゃえるという甘えがあったんですけど。

最近Angular 2とReactほとんど差がないんで、自分の書いてるコードが酷い可能性のほうが高い。自分の書いたコードを疑えって言う。最近パフォーマンスというか、自分がどれだけ最適化されたコードを書けるかとか、遅かった時にどう測定してどこを最適化していくか、っていうところにかかってるんじゃないかなと思います。

laco (Reactは)たぶん、ミドルウェア書けば書くほど遅くなりますよね。Angularも、いろいろやればやるほど遅くなる。DOMの書き換えパフォーマンスはどちらも変わらないと思います。

yosuke_furukawa ただ、DOMの書き換え周りって、仮想DOMとか変更検知のアルゴリズムとかも関わってくる話ですよね。変更検知については、Angular1の頃は、自分でイベントループみたいの持っててそこでダーティチェックしてたけど、2はどうなってるんですか？

laco Zone(.js)の話になるんですけど…Zoneの話長いんで(笑)。 ざっくりいうと、windowをモンキーパッチして、

yosuke_furukawa モンキーパッチ！？(笑)

laco setTimeout()とかXHRとか非同期イベントが起きた後は必ずAngularのイベント呼ぶようになってる。

yosuke_furukawa マジかよ…めちゃEvilじゃないか…！(笑)

laco でもそれがTC39にZoneとして提案されていて、すでに（ステージ）0にもなってるんですよ(笑)。 (編集部注: ECMAScriptの仕様策定は、アイデアレベルの提案がステージ0に始まり、成熟するに従ってステージを登っていく）

だから…あれ、何の話だっけ。ああそうか、変更検知のイベントループの話だ。(Angular)1の頃はループガンガン回してたけど、それはもうないです。何も起きてないときは何も動かない。何かしらクリックしたとかがあったら、イベントが走って、windowからAngularにお知らせが来る、というふうになってるんです。

koba04 パフォーマンスっていう意味で言うと、Reactは基本やることが少ないし、やることが明確なので、チューニングはしやすいのかなあと思います。 react-addons-perfとか使って計測して、パフォーマンスチューニングのポイントもshouldComponentUpdateを実装するか、renderの中をちょっと見直すとかなので。

laco しかし、仮想DOMは速かったけど、Angularも追いついちゃいましたね。しかも仮想DOMなしで。結局仮想DOMってどうだったのかなあ…と。「ポイント、そこじゃなくない？」っていう(笑)。 (筆者注: ここ、lacoさんがイベントを盛り上げるため煽ってくれてます)

koba04 まあ、仮想DOMだからこそ、ただの関数みたいな形でコンポーネントを簡単に作れるようになったので…。

laco でも、最近Pure Componentって入ったじゃないですか。Shallow Rendererとか。 あれってどうなんですか？この間ものすごく疑問に思って。Pure Componentにすると、オブジェクトの状態を自動で見て、自動で変更検知してくれるってやつですよね。 あれって、Reactがやりたかったことなんですか？

koba04 あれは、オブジェクトツリーがでかくなると仮想DOM比較のコストもバカにならないので、その比較すらも飛ばしたい時に使うっていう感じです。

laco 仮想DOMのアルゴリズムが敗北したってことじゃないですか？(笑)

shumpei 煽る煽る(笑)。

koba04 基本的にはそこまで必要とするものでもなくて、よっぽどパフォーマンスが求められる場面で使われるものかなと思っています。

yosuke_furukawa ぼくとしては、パフォーマンスのチューニングポイントが増えたって話だと思ってます。仮想DOMの敗北については、次のサーバーサイドレンダリングでぼくが話をするんで、まあここはこれくらいでいいんじゃないかなと(笑)。

会場 (笑)

サーバーサイドレンダリング

shumpei じゃあ、サーバーサイドレンダリング(SSR)について、yosuke_furukawaさんどうぞ(笑)。

yosuke_furukawa そうですね、実際にSSRでもコンポーネントのツリー構造を作って、そのツリーに対してReact DOMのIDを割り振るっていうような「仮想DOMを構築する処理」が入るわけなんですが、それって普通のテンプレートエンジンだとまずやらない処理なんですよね。普通のテンプレートエンジンはHTML生成すればいいだけだから。効率化されているんです。

そこをReactのrenderToString()とかでやると、まあ、そこまで効率化されていない。 もしかしたらキャッシュとか持って、効率化する余地はあるのかもしれないんだけど、今のReactだとそこまで効率化されていないので、やっぱりテンプレートエンジンとしてのスピードを見るとそこまで速くないんです。 そこがちょっとね、どうしたもんかね、と。

ぼくが今やってるやつだと、1レンダリングするのに50ミリ秒とかかかっちゃって、しかも50msecかかった時に、Node.jsなんでイベントループが止まっちゃってるんですよね。だから由々しき問題、由々しき事態なんです。 だからそこは、非同期処理にしてイベントループを止めないようにするか、キャッシュですごい速くするか、そもそもDOMツリーを構築するところをなんとかするかと言ったことが必要なんですけど。

koba04 そういう意味では、Reactってサーバーサイドレンダリングできるんですけど、正直あれなんで入ってるのかぼくはよくわかってなくて(笑)。Facebook自身も使ってないですしね。 中のアルゴリズムを見ると、クライアントのDOMを作るときと同じコードを使っているので、それは当然文字列作るのと比べれば効率悪い。 そこはもしかしたら新しいアルゴリズムが入ることで効率化するのかもしれないけど、たしかに今だとパフォーマンスが問題になるのは明白な感じの実装にはなってます。

yosuke_furukawa Netflixとか、いろんな企業が実際にサーバサイドレンダリングはやってるんですけど、初期表示のレンダリングするところだけサーバサイドレンダリングして、 あとはスクロールするたびにちょっとずつクライアントサイドレンダリングしてたりする。それって地獄じゃねえのか、と(笑)。 そういうことが簡単にできるライブラリとかが別途あればいいんだけど、今のところまだないから、そういう意味だと、仮想DOMは敗北に近いかなと。サーバサイドレンダリングするなら。

shumpei Angular 2のサーバサイドレンダリング事情はどうですか？

laco Angularのサーバサイドレンダリングは…たぶんあんまり変わらないですよ。基本的に遅い。ただ何がいいかって、ルーティングとかHttpとか、Node上でも動くように全部パックされてるという、フルスタックならではの安心感はありますね。

ルーティングが済んだ状態のSSRも簡単にできるし、SSRするときに最初にAjaxが必要だったら、Node上で動く@angular/httpみたいな、ユニバーサルなやつが提供されている。それを使えば、変更検知された状態のSSRがちゃんと出ます。全部レールに乗ってるっていう、そこらへんの安心感はありますね。

ライブラリか、フレームワークか

shumpei はいでは、お時間も迫ってまいりましたので、そろそろ終わりにしたいと思います。

83 あ、一ついいですか？ちょっとこのイベント自体に苦言を呈したくて。

会場 (笑)

shumpei え、なんでしょう？

83 ReactとAngularっていうのを比べるのって、みんな大好きですよね。でも、ほんとはこれって比較できるもんじゃないんですよ。型が一致しないものは比較できないんですよ。

会場 (笑)

83 で、比較できないものを比較しているというのは、こういう項目を挙げてやっているっていうのは、フレームワークの相互プレゼンテーションみたいな感じで、Reactはこうですよ、Angular 2はこうですよ、という感じでやってるんですけど、ほんとにそれがみんな聞きたい話なのか？って思うんです。

私はlacoのほうからオファーを受けて呼んでもらったんですけど、こんだけすごいパネラーが揃ってて、順番にフレームワーク・ライブラリ紹介合戦みたいになってて。これじゃないでしょ、って思ってるんですよね。 もっと、フロントエンドのエンジニアとして、Web APIがどういうものがあって、いつ何を使うか、どう組み合わせるかっていうのがやっていくべきことなのに、何年かしたらすぐ廃れるようなライブラリの議論なんてのに、似非プロレスなんてのをやっていても、これは違うんじゃないかなあ、と思うんですよね。

shumpei すいません、、反省します。

83 いえいえ、これ、言っとかないと終わってしまうな、と。すいません。

yosuke_furukawa いえいえ…最高です(笑)。

前編もあります

こんにちは、編集長の白石です。

本記事は、2016年9月に開催されたTechFeed Live#2 「React vs Angular 2」の模様をお伝えする記事の前編です（後編はこちら）。 TechFeed Live#2とは、「TechFeedを地上に出現させる」ことをコンセプトとした、テクノロジーの最新トレンドをエンジニア向けに紹介するというイベントです（TechFeedとは、「最先端が、ここにある。」をキャッチコピーとしたエンジニア向け情報収集アプリです）。本イベントは、ReactとAngularをより楽しく深く学ぶため、現代のWebアプリに求められる各種要件についてそれぞれを比較する…というアプローチを取りました。 （私は本イベントの企画と対談のモデレーターを務めました）

読み応えバッチリ、勉強になること間違いなし。今回はライブ感を重視し、あえてイベントでの（砕けた）口調も可能な限り再現してみました。 では皆様、どうぞお楽しみください！

当日のイベントは大盛り上がりでした。

React vs Angular 2対決開始！

shumpei 本日は、多くのお客様にご参加いただいて、大変うれしく思います。 今回のTechFeed Liveは、「React vs Angular 2」と題しまして、今をときめくコンポーネント指向のWebアプリケーション・フレームワーク2つを比較して学べる会を目指しています。

そのために、それぞれのフレームワークのエキスパートの方々にお集まりいただきました。

トークバトル参加者（順不同、敬称略）

（編集部注: 本記事では登壇者の皆様の希望により、以下ハンドルネームで呼称させていただきます）

React Side

• koba04 (小林 徹)
• yosuke_furukawa (古川 陽介) (Node.js 日本ユーザグループ代表)

Reactサイド。左がkoba04、右がyosuke_furukawa。

Angular2 Side

• laco (稲富 駿)
• 83 (奥野 賢太郎) (ng-kyoto代表)

Angular2サイド。左がlaco、右が83

モデレーター

• shumpei (白石 俊平) (HTML5 Experts.jp編集長)

また今回、フレームワークを比較するための項目を以下のように洗い出してみました。基本的にこの流れに沿って進めたいと思いますが、脱線は大歓迎ですので、皆さんご自由にご発言いただいて構いません。（編集部注: 前半は「テンプレート」まで）

• 開発⾔語
• アーキテクチャ
• ビルドツール
• ルーティング
• テンプレート
• スタイリング
• コンポーネント以外の処理
• ツールサポート
• テスト
• パフォーマンス
• サーバサイドレンダリング

では早速始めましょう！

開発言語

shumpei まずは開発言語について語っていただければと思います。Reactから聞いてみたいと思いますが、Reactを使った開発は基本的にどんな言語を使うのでしょうか？

koba04 基本的にはBabelを使って、ES6以降のコードをES5に変換しつつ開発しますね。でも、TypeScriptを使う人もいます。Babelの作者はFacebookにいたりするので、基本的にはBabelだと楽ですね。

shumpei なるほど。Angular 2のほうはいかがですか？

laco 基本的には開発言語はJS, TypeScript, あとDartがあります。

会場 (笑)

laco いや、Dartは笑いどころじゃないでしょう(笑)。 公式に推奨されているのはTypeScriptです。ES6書いてBabelでもいいし、ES5でも書けることは書けますが、結構キツイんで、基本的にはTypeScriptで書くのがデファクトになってます。

83 ちょっと待って下さい。結局なんの言語で書きますか、というのが重要で。Reactだったらどの言語、Angularだったらどの言語、っていう 質問がおかしい 。

shumpei そうですか…すいません。

83 大きいものだったらTypeScriptのほうがいいし、小さいものだったらAngular 2でもES6とBabelのほうがサクサク作れます。Angular 2はTypeScript専用だよね、ということはよく言われますがそれは違うと思います。

shumpei ちなみに、BabelでAngular 2を書くというのは全然ありなんでしょうか？

laco 全然ありですよ。そのためのプラグインも、 Shuhei Kagawaさんという方が作ってます 。Flowの記法とか使って、型があるように書けます。

あ、一つReactサイドに聞きたかったんですが、JSXってみんながみんな使うもんなんでしょうか？

yosuke_furukawa そうだと思います。ぼくもJSXなしでやってみようと思ったこともあるんですけど… 結論としては、(JSXが) ないとダメだなと (笑)。 結局HTMLっぽく書きたくなるんですよ。

ちなみにさっきの言語の話を少し深掘りしたいんですけど、言語は規模で決まるというのは確かにそのとおりだと思うんですが、一方でエコシステムとかを見ると、BabelをES6じゃない言語で書いてエクスポートしてる例ってあんまりないんですよね。

例えばTypeScriptでライブラリ書いてエクスポートしてるなんてあんまりない。なので、エコシステム全体としては、どっちの言語がより慣れているかという度合いはあるのかなと。そういう意味では、ReactはBabelでAngular 2はTypeScript、というのはあるんじゃないかと思います。

83 そうですね、そういう意味で言うと、(Angular 2も)公式サイトのチュートリアルとかも全部TypeScriptで書かれていたりするので、そういう住み分けとかは色がはっきりしているかなと思います。 ちなみにReact陣営に聞きたいんですけど、TypeScriptは「GoogleがMicrosoftと手を組んだ」なんてよく言われてますが、(React開発元のFacebookが開発している) Flowってどうなんですか？

yosuke_furukawa 実際、React自身はあんまりFlowでっていう話はないです。(Reactコンポーネントの) propTypesを、Flowで書けるようにしよう、って話は進んでるみたいですが。

「propTypesで型チェックをしていく」というのがあんまり綺麗じゃないというか、書き方として洗練されている気がしない。なのであれをFlow側に寄せていこうという活動はあるみたいです。

koba04 FacebookがFlowを強制してくるってことは全然ないですね。propTypeを置き換えるときも、FlowかTypeScriptか、好きなのを使えばいいという感じです。 そこは、フレームワークが特定の型システムに依存する必要はないので、好きに使っていけばという感じです。

shumpei ちなみに、ご存じない方もいらっしゃるかもしれないので、Flowってなんでしょうか？

koba04 Flowは、静的な型チェックをするためのライブラリです。まあ、思想としてはもっと踏み込んでいて、JavaScriptでハマりがちなコードとかを静的解析して、静的な型付け以外のチェックをやっていこうと。

そういう意味では、ESLintとかもカブる部分がありますね。例えばnullチェックをしているかどうかとかも確認できたりとか。静的型付け以上に、JavaScriptでハマりがちなエラーをチェックするためのツールという面が大きいかなと思います。

shumpei コードそのものは、JavaScriptで書くということですね。

アーキテクチャ

shumpei 次の話題はアーキテクチャについてですが、アーキテクチャというとぼんやりしてますね…。これぼくなんでこのお題を出したんだっけな。えーと…、あ、思い出した。Fluxとかの話をしようと思ったんだった。FluxやReduxなど、アーキテクチャに関してちょっとご説明をお願いしてもいいですか？

yosuke_furukawa 基本的にReactだけだと、イベントや状態を管理する仕組みがないんです。ReactってViewのライブラリなので。Webアプリって、APIサーバを叩いてデータをもらってきてそれをレンダリングするとか、そういうのが普通ですよね。そういうことをしようと思ったら、Reactだけじゃ厳しいんです。そういう時に、イベントを管理する仕組み、あと状態を管理する仕組みっていうのが必要になってくる。そういう時に必要になってくるのがFluxであったり、Reduxであったりというライブラリです。

Fluxはライブラリというよりは「思想」というか、デザインパターンに近いですね。イベントを管理するための、Observerパターンを言い換えたというか。あれねえ、何がすごいかって、名前を付けたのがすごいですよね。カッコいいですよね。名前の勝利です(笑)

そういう (Fluxという) 考え方が浸透してきたところにReduxっていうのが出てきて、今一番流行っているライブラリです。

ただひとつ間違えちゃいけないのは、ReactとFlux、ReactとReduxを組み合わせたからといって、Angularほどの「フレームワーク」といえるかというとそこまでいってない。 ただライブラリを組み合わせただけのものでしかなくて。さらに、その上で自分のレールを作っていく必要があるんじゃないかなとは思います。

shumpei なるほど、ReactはReactだけで完結しないと。一方Angular 2のほうは「One Framework」だそうですね。

83 Angular 2の話をする前に、AngularJS(AngularJS 1)のほうに一旦戻ろうかなと思うんですが。そもそも1のころは、エコシステムが「Angular World」だったと。

まだ今あるようなES6のモジュールとかがなかった時に、それでもモジュールの仕組みが欲しいとか、そういう要望があったと。なので、angular.module()の中に書いていくというのがあったんですね。

で、それがあったからAngularはエコシステムに乗っていない、一方でReactは乗っているというような分断が起きはじめました。 それ自体は2年前くらいは正しかったのですが、そのイメージをAngular 2になっても引きずっている方がまだおられるんじゃないかというのが気になっています。

83 私はAngular 2を「フレームワーク」と言われることは好きじゃなくて、Angular 2は「ライブラリ」だと思っているんですよね。なんでかっていうと、Angular 2にデータを保存しておくものだったり、データのやり取りをするためのものっていうのが、別にAngular 2にはないんです。

Angular 2の特徴ってテンプレートとDIとかあると思うんですけど、実際にはAngular 2だけで全て事足りるかというとそうでもないし、そこは結構割り切ってAngular 2は好きなフレームワークと組み合わせられるようにもなっている。

その上で、Angular 2をどうやって使うかというと、RxJSがよく出てくると思います。RxJSはストリームやイベントを扱うためのライブラリで、FluxのObservableパターンと同じく、何か変化があるまでは動かない。 何か変化がemitされたときにsubscribeしてる側で値を書き換える。それでテンプレートの描画が変わると。そういう意味では、今時代の変化が、Observableパターンに来てるんじゃないかなと思います。

shumpei ちなみにこれ、ご存知だったらでいいんですけど、Angular 2とReduxを組み合わせてみた、みたいな話もあるんですけど、そうしたことをする利点とかってなんなのでしょうか？

83 私は実際それをやってみて、別のイベントで発表したこともあるのですが、ぶっちゃけそのときは相当disりまして(笑)。 Reduxをdisったわけじゃないんです。Angular 2とReduxという組み合わせをdisったんです。Reduxは中立なライブラリとは謳われているのですが、実際にはReactを前提として作られたライブラリなので、まあそうなるわな、という感じでした。

Angular 2とReduxの組み合わせがなぜいけてないかというと、DIとの相性が悪いんです。 ReactにはDIという考え方が全くないし、ReduxもDIを全く無視している設計になっている。

なので、Angular 2はDIできるのに、Reduxと組み合わせると、ReduxのReducerの中では一切DIできない。 何のためにDIができるAngular 2の中でReduxを使うのか。そこだけ別世界に飛ばされるような感じでした。

laco ざっくり言うとReduxにしてもFluxにしても、シングルトンなステートがあって、ステートの変更を検知してコンポーネントがデータを受け取って、コンポーネントがデータを書き換えて…っていうのをくるくるやるわけじゃないですか。

で、シングルトンってAngular 2だとDIで実現するんですよ。なので、Reduxいらないんですよね。仕組み、レールがすでにあって、あとはステートを持つやつを書くだけで、あとはDIでどうとでもなる。 だから、Angular 2は結局、DIでどうとでもなります。

shumpei Reduxと組み合わせたみたいな記事をたまに見かけるんですが、それはAngular 2に足りないものがあって、Reduxがそれを補うのかなとかって勝手に想像していたんですが、別にそんなことないよ、って感じでしょうか。

laco たぶんバズワード組み合わせただけじゃないかな、と(笑)

shumpei なるほど(笑)。ちなみに例えば、ReactとRxJSを組み合わせる、みたいなバズワードの組み合わせ方とかはないんでしょうか。

koba04 もちろんそこは自由にできて、ReduxとRxJSを組み合わせるためのredux-observableというのをRxJSの作者が作ってたりします。RxJSを使いたい場合はそういう選択肢もある。

ただ、APIからデータ取ってくるだけだったらObservable (RxJS) 使う必要もなくてEventEmitterで事足りるかもしれないし、そこは自由に選んでくださいという感じですね。

ビルドツール

shumpei 次はビルドツールですね。ここは意見を戦わせるところでもなくて、ただ紹介するだけでいいのかなとも思いますが、暴走や脱線は大歓迎です。 まずReactでは、ビルドツールには主に何を使いますか？

yosuke_furukawa 主にwebpackやBrowserifyですね。エコシステム全体がBrowserifyやwebpackを前提として作られたりしますので、それを使うのが普通です。コンポーネント志向なんで、コンポーネントを作ってexport/importするのが当たり前の世界になってます。

shumpei Angular 2サイドはいかがですか？

laco ここは何も変わらないですね。webpack使えますし、バンドル (編集部注: 複数のJavaScriptモジュールを1ファイルにまとめること) しないとブラウザでは使えないし。 そういえば、最近npmリポジトリから落ちてくる（npm installでインストールされる）のが、ESモジュールになったんですよ。(requireではなく) import / exportがそのまま書かれている。 なので、webpack2やRollupを使うとTree shaking (編集部注: 不要なコードを「振り落とし」、バンドルサイズを小さくすること) できるというのはありますね。

shumpei SystemJSっていうツールの存在も聞きますが。

laco (笑)

shumpei 笑っちゃうんですかw

laco ごめんなさい、ちょっと失笑です。あれはまだちょっと人類には早いって思ってます(笑)。

会場 (笑)

shumpei どこらへんが人類には早いんでしょう？

laco あれは世界がHTTP/2になるのを待って、出直してきてほしいツールです。importごとにリクエスト飛んだら、(HTTP/1だと)遅すぎて話にならないです。残念ながら。

shumpei 1ファイルにバンドルする機能とかはないんでしょうか？

laco ありますけど、それならwebpackのほうがエコシステムが育っているので、そちらでいいんじゃないかな。プラグインとか、Loaderとか。

yosuke_furukawa SystemJS待つくらいなら、ES Loader待ったほうがいい(笑)。

shumpei JSPMっていうのがあるみたいですが…、JavaScript Package Managerでしたっけ。

laco あー。あれ、いつまで存在してるんですか？

yosuke_furukawa その質問誰に聞いてるんですか(笑)。

shumpei なるほど、その程度の扱いということで(笑)。では、SystemJSは人類には早すぎるということで、Angular 2やってる方もwebpackやBrowserifyがいいんじゃないかなということですね。

laco Plunkerみたいなオンラインエディタ上でやるぶんには、SystemJS割と便利なんですけどね。ブラウザ上ではバンドルできないので。ただ、プロダクションでは使う用途ないですよね。

ルーティング

shumpei では次は、細かい話が混じって申し訳ないですが、ルーティングとかに関して言いたいことがあればお聞きしたいのですが。

yosuke_furukawa これは…Angularサイド圧勝じゃないですか？

shumpei そうなんですか？

yosuke_furukawa React完敗ですね。

laco ほんとか？？(笑)

yosuke_furukawa そもそもルーティングって、React本体には機能がないんです。で、デファクトスタンダード的に使われているReact Routerっていうのがあるんですが、これみんなdisってる(笑) 。 とりあえず使ってみて、「これクソ使えねえな」みたいな話になるんですけど(笑)。

何が使えないかって言うと、ルーティングの時に最初にやってほしいことって「アクションを発火してほしい」んです。 APIを呼び出してデータを取ってくる、ということをしたいとみんな思うと思うんですが、そういうことをやってくれるような感じになってなくて、まず最初にコンポーネントをマウントしちゃうんです。コンポーネント指向なんで。

でも普通みんながやりたいのって、アクションだと思うんですが、それを書くための記法は今のところない。 なのでしょうがないから、真っ白なコンポーネント出してそこでイベント発火させて(データを)取りに行く…みたいなことをみんなやってるんじゃないかな。あんまりよくないです。

なので、ぼくの頭のなかではReact Routerは決定版にはなっていない。決定版になってないがゆえに、デファクトスタンダードとはさっき言ったけど、みんな野良ルーターみたいの作っちゃって、結果今あんまりよくない状態になっている。 …というところが「圧敗」ですね(笑)。

shumpei 圧敗(笑) では、圧勝側のご意見も聞きたいです。Angularサイドはいかがですか？

laco 今の話をすると、Angular 2もパスとコンポーネントを結びつけるものだという考え方は変わらないです。 ただ、コンポーネントがマウントされるときに呼び出されるフックポイントがあって、そこでリクエストを飛ばして、その結果を持ってマウントができるという仕組みがある。 あと、「ルーティングしてもよいかどうか」というcanActivateみたいな仕組みもあって、出ていくときの仕組みもあって。 そうしたイベントが全部RxJSに乗っていて、ルーティングが起きるときにはまずイベントが発火するので、使いやすくはなっています。

yosuke_furukawa そういう意味でいくと一応onEnterみたいなのはあるんだけど、そこでデータを拾いに行くのは、推奨しないってことになってまして…(笑)。

laco 今のAngular 2のルーターはとてもよくできているので、今のところは言うことない、っていうくらいの完成度になりました。

koba04 ぼくは個人的にルーティングにこだわりはないんですが、基本的にはここもライブラリに依存しなくてもいいんじゃないかな、とはずっと思っています。汎用的ないいルーターが出てこないのかな、とは思ってるんですが、あんまり出てこないですね。

laco 確かに。イベントだけ発火してくれればそれでいいですからね。

koba04 そう。ライブラリと関連しているところではないので。誰か作るチャンスだと思います。

shumpei ReactやAngularに関係ないルーティングのライブラリがあればいいのに、ということですね。

テンプレート

shumpei 前半最後のトピックになりそうですが、次は「テンプレート」です。これ盛り上がるのかな…お互いの記法がキモい、とかってdisりあっていただいてもかまわないんです(笑)。

83 JSXもキモい、Angular 2テンプレートもキモい、気に入ったキモいほう使え、って感じですね(笑)。

laco でもまあ、Angular 2のテンプレートはギリギリHTMLなので、既存のHTMLツールチェインには乗れるわけです。ちなみにJSXってファイル分けられるんですか？「.jsx」みたいなファイルあるんですか？

yosuke_furukawa 一応あります。Angular 2は分けられるんですか？

83 テンプレートの文字列を直接ソースコード中に書くのも、URLで外部ファイルを指定するのも、どちらも可能です。URLを指定した場合はAjaxで取ってきます。

yosuke_furukawa そこの通信（コスト）はいいんだ？

laco それはwebpackのプラグインで、URLをrequire()に変換してくれるやつがある（angular2-template-loader）ので、ありがたく使わせてもらってます。 あとひとつ気になるのは、JSXってXSSのサニタイズとかやってくれるんですか？

yosuke_furukawa …えっとですね。…Angularの圧勝です。

会場 (笑)

yosuke_furukawa 普通にpタグやdivタグの中に入れる文字列はサニタイズしてくれるんだけど、例えばaタグのhref属性とかに対しては、別に何もしてくれません。なので、(属性値に)javascript:〜とかやろうと思えばできちゃう。

laco innerHTMLぶち込みとかも？

yosuke_furukawa そうです。だから、innerHTML使うときとか、URLをセットする場合とかは、注意しなくちゃいけない。 (URLから)javascript:を省いてやる必要とか、XSS対策についてはケアが必要です。

shumpei React本体でそこら辺を対応しようという動きはないんですか？

koba04 JSXって結局ただのオブジェクトに展開されるんですけど、Symbolとかを使って、外から知らないタグを差し込まれたりはしないようになってます。なので、渡された文字列をそのままReact Elementsとして展開するということは出来ないようになっていますけどね。

laco あ、あともう一つ。Web Components対応ってどうなってるんですか？

koba04 一応Custom Elementは書けるようになっています。あとは、DOMComponentに不正な属性を渡すと警告が出るようになっていて、それはCustom Elementをサポートするための布石です。なので、この後何らかの対応が入ってくるとは思います。

shumpei そろそろお時間ですので、これで前半を終わりにしたいと思います。後半も、引き続きよろしくお願いします。

後編に続きます