CodeIQ MAGAZINE

【AngularJS vs React.js】どっちがどう使える？JavaScriptフレームワークの最新事情 #html5j

2015.05.29 Category：勉強会・イベント Tag：AngularJS ,HTML5 ,html5j ,JavaScript ,React.js

最近話題となっているJavaScriptフレームワーク「AngularJS」と「React.js」。
とはいえ、日ごろの仕事に追われキャッチアップできていない人も多いのでは？

第56回HTML5とか勉強会では、この2つのフレームワークの最新事情をセッションとパネルディスカッションで紹介。
その模様をレポートします！ by 馬場美由紀（CodeIQ中の人）

JavaScriptフレームワーク「AngularJS 1.x」とは

第56回HTML5とか勉強会（JavaScriptフレームワーク最前線-AngularJS、React.js-）、最初のセッションは金井健一氏による「Angular 1＆2」。

▲金井氏はAngularJS Japan User Groupの運営に携わっている。著書に「AngularJS」がある

まずは「AngularJS 1.x」について。このバージョンのAngularJSでは、シングルページアプリケーションを開発する際に必要としていた以下のキーワードが包括的に扱えるようになっている。双方向データバインディングが特徴だ。

（Two-way）Data Binding
Template Engine
Ajax Support
Routing
Test
Security

Viewの構文は図のとおり。

見ればわかるとおり、HTMLの中に　

1行目：ng-app
2行目：ng-controller
3行目：ng-react
4行目：ng-click

とng-***で始まっているところが、Angularのディレクティブである。

既にAngularJSで用意しているディレクティブをビルトインディレクティブと呼ぶ。金井氏いわく、ng-app="myApp"は、「myAppを使いますというおまじないだと思ってください」とのこと。

HTML同様、最初に宣言して書いていくのが、AngularJSの特徴である。最後の行のng-clickは、クリックイベントに反応して、属性の値の関数が実行される操作が書かれている。

一方、コントローラ側の構文はどうなるか。つまり「JavaScript側の話」。「これも1行目はおまじない」なんだとか。

2行目はコントローラの設定で、View側のng-repeat="item in list"のlistが

2行目：($scope){￢
3行目：var listに対応している。

これはボタンを定義しただけだが、ng-repeatとあるところはリストの中身が表示されるようになっており、ボタンを出すとアラートが出るようになっている。

AngularJSの特徴

AngularJSと他のフレームワークとの違いは、フルスタックであること。そしてHTML拡張であることだ。HTML拡張なので、テンプレートをhtmlファイルに書ける。React.jsではJavaScriptファイルに書くので、ここが大きな違いと言える。

さらに、Angularはバリデーションの機能が豊富だ。ng-modelはモデルの宣言で、これだけでAngularJSの場合は、強力なバリデーション機能を付けることができるという。バリデーションの状態の取得は、formとinputのnameを使う。

HTML5にもバリデーションの機能があるが、ng-をとるとほとんど同じ機能になっている。つまりAngularJSは、HTMLの基本的な情報や標準的な機能を拡張して作っている。

また、Custom Directiveという独自要素と独自属性が、Web Componentsとほぼ重なるところ。

ディレクティブの作り方は図の通り。

「先ほどJSの中に書くなと言ったが、これは思いっきりJSの中に書いている」というツッコミに、会場からは笑い声が。

このコードでは3行目のmydirectiveはキャメルケース（一つづり）になっているのが、実際に使うときはmay-directiveとハイフンでつないで小文字にする。これがAngularの制約の一つである。

AngularJS自体、Web標準技術をどんどん取り入れていっている。ブラウザに実装していない技術にもチャレンジしているのもAngularの特徴だ。

先述したmy-directiveの記述の仕方については、

独自要素はx-foo
独自属性

というのが筋だろうと言われたことがあるそうだ。基本的には下記いずれの書き方でも大丈夫だが、<my-directive>～と書く人の方が多いとのこと。

<my-directive></x-my-directive>￢
<x-my-directive></x-my-directive>￢

Angular1系の現在の最新版は、1.4.0-rc.1。1.3が安定版、1.4が最新版となっている。最新版の最大の機能が、new Routerである。

Angularはこれまで非常にシンプルなルーティング機能しか持っていなかった。しかしサードパーティー製のUI Routerが高機能だったため、そちらを使っていた。そんな課題を、v1.4から利用できるnew Routerによって解決を図っている。

「new Routerができることは、従来のUI Routerとほぼ変わらず、書き方も変わらないと言われている。しかし使い方の名前が変わったりしているので、今はまだプロダクトに採用するのはリスクがあると思う」と金井氏。

そのほかにも改善・強化されたポイントはある。例えば$http（外部リソースにアクセスする機能）も改善をしており、Angular2.0の$httpではWebsocketをサポートしようとしている。この$httpはv1.xでも利用しようとしていることから、「そのうちv1.xでもWebsocketが使えるようになるのでは」と期待を込める。

Pluralization and GenderのPluralizationは、数値別によってテンプレートを切り替えるような機能で、例えばFacebookの「いいね」を付ける機能を作るのに向いている。

一方のGenderは性別のみのテンプレートの切り替えに使う機能だそう。

Angular2の開発コンセプトとは？Angular2でできること

Angular2の基本的なコンセプトは1系と同じだが、時代に合わせてよりコンポーネントベースになっている。

コンセプトを表すキーワードは以下の通り。

Components based
ES6
TypeScript
Object.observe（ES6では実装していない。ES7）
Shadow DOM・・Webコンポーネンツの一つ。この仕様が実装されると、ようやくWebでUI部品として実装できるようになる。
Virtual DOM

Angular2では、バーチャルDOMのような変更検知システムが搭載される。Angular2ではコンポーネントベースとなることで、スコープがなくなり、コンポーネンベースのツリー構造となる。

さらに、React.jsと同じような変更検知システムになるので、この辺に関しては、AngularJSとReact.jsとあまり違いが見えなくなる。

では1系から2系で何が変わるのか。まずは「DOM操作の処理速度が、v1.xよりも2～3倍速くなる」という。

第二に、Angular2ではデータバインディングが一方向になる（双方向データバインディングはしない）。データバインディングは一方向になる。またコントローラと$スコープなどがすべてなくなり、ディレクティブの書き方ができなくなる。「唯一、残るのはコンポーネンツのタグ」とのこと。

さらに詳しく知りたい人は、以下のサイトを参照しよう。

Angular1&2 from Kenichi Kanai

Facebookが作ったJavaScriptのUIライブラリ「React.js」とは

続いては、小林徹氏によるReact.jsについてのセッション「Building Apps with React.js & Flux」。

▲小林氏はAdvent Calendar形式で「一人React.js Advent Calendar」を25日分書いている。

React.jsは、Facebookが作ったJavaScriptのUIライブラリである。

その特長は次の3つ。

JUST THE UI：MVCでいうところのVだけを持っているライブラリ。Backboneと組み合わせたり、Angularと組み合わせたりもできる。
VIRTUAL DOM：React.jsは仮想的なDOMの構造をJavaScriptのオブジェクトで持つ。そこを開発者が更新し、差分はReact.jsが計算するので、パフォーマンスの劣化が少なくなる。DOMに依存していないので、サーバサイドでNode.jsなどでHTMLを生成して返したりすることで、SEOやシングルページアプリケーションの初期ロードのスピードが改善される。さらにDOMではなくネイティブのビューを書くというアプローチも取れる。
DATA FLOW：一方向のデータバインディング。これはコードの複雑性を避ける、見通しがよく設計ができるようにするため。

React.jsは開発元であるFacebookのコメント部分など、インタラクティブな箇所に使われている。

最近、Facebookでmessenger.comというWebアプリが提供されているが、これはすべてReact.jsのコンポーネントで作られているという。

またinstacram.comも同様だ。そのほか、NeflixやBBC（ユーザーが見える部分）、Atlassian（HipChatのWebクライアントをReact.jsとFluxで再構築）などの事例がある。

なぜReact.jsを作ったか。「それは複雑なユーザーインタフェースを構築するためだ」と小林氏。つまり開発効率の向上ではなく、Reliability（信頼性）を確保することが目的なのだとか。

React.jsの構造

ここで小林氏は「ES6で書いた」と語り、Hello WorldをReact.JSを用いるとどうなるか、構造例を示した。

JSXはどういう働きをするかのか。先の構文のままではSyntaxエラーとなるので、React.js.createElementというただの関数に変換する。JSX TransformerでJSに変換するか、React.js-tools、BabelなどのES6の変換ツールを使って変換するのだ。

外のテンプレートエンジンだと独自のEach構文やif文を覚えなければならないが、JSXではJavaScriptをそのまま使うことができる。つまり、JSXを使うことでJavaScriptの表現力と馴染みのあるHTMLの構文を両立することができる。

React.jsの最大の特徴は、コンポーネントにある。表示要素を各コンポーネントに分割し、その中にふるまいと見た目をまとめている。

「コンポーネントを見ればそのコンポーネントの振る舞いや見た目などすべてわかるように、凝集度を上げて、結合度を下げる実装にすることが重量」と小林氏は説明する。

次にステートレスについて。React.jsでは各コンポーネントに状態を持たせるのではなく、親コンポーネントが状態を管理する。「サーバサイドレンダリングと同じようなもの」だそうだ。

状態が変わったら、親のコンポーネントからすべてのコンポーネントを再度作り直す。しかしそうするとパフォーマンスが劣化する可能性もある。そのためVirtual DOMで差分だけをDOMに反映する。こうすることで「パフォーマンスが落ちない」と小林氏は語る。

各コンポーネントの流れは、次のようになる。

続いて説明は、Prop&Stateへ。Propはコンポーネントのインタフェースとなるもの。つまりコンポーネントが外部とやり取りするためのインタフェースになる値。

外からもらう値なので、コンポーネントの中では変更はできない。変更したい値を持つ場合は、「Stateで持つことになる」。それを図で表すと次のようになる。

詳しくは、以下の神資料を見てほしいと、URLを紹介した。

React.jsの書き方

React.jsの概要を解説した小林氏は、実際の適用例を紹介。「HackerNews Stories」一覧を、右上にある窓でフィルターできるというアプリをどう作っているかを紹介した。

InputFilterのソースは以下の通り。Inputタグがあり、React.jsがネイティブで実装している。

HNStoriesのソース。

ステートは持っていない。コンポーネントの実装はマークアップだけになっている。

React.jsにはコンポーネントライフサイクルがあり、DOMに追加されたときや親からもらったPropが更新されたときなど、いくつかのライフサイクルメソッドがあるという。

この例の場合、StoriesのIDの一覧、および各記事のデータを取得し、ランクなどのインデックスをSetStateというメソッドで新しい一覧に追加していくという方法を採っている。その中には「DOMがどうなるかなどは一切書いていない」と小林は説明する。

またHandleFilterのソースは次のようになる。

GitHubのサンプルページ

コンポーネントが複雑になっているアプリケーションについて。propsがバケツリレーするような場合は、「Fluxアーキテクチャを導入した方がよい」とのこと。

この図で重要なのは、「片方の矢印で回っているところ」と小林氏は強調する。Fluxとはアーキテクチャ。実装ではない。Unidirectional　Dataflow(一方向なデータの流れ)になっており、Component->ActionCreator->Dipatcher->Store->Componentという流れになる。

先ほどのアプリをFluxにすると、ComponentからのAPIアクセスはActionCreatorを呼ぶだけになる。

InputもActionCreatorを呼ぶだけになり、ActionCreatorはActionを発行してDispatcherに渡す。

Dispatcherはそのままインスタンス化し、すべてアクションを受けて全てのストアに渡すだけだ。

import {Dispatcher} from 'flux';
const AppDispatcher = new Dispatcher();

StoreはDispatcherに登録する形となる。すべてのアクションを受け、必要なモノだけを処理する形となる（PDF　P50）。

StoreはEventをコンポーネントとやり取りし、データはAction経由で更新されるべきなので「setterは作ってはダメ」と小林氏。

コンポーネントはStoreの層からデータをもらう。Storeからデータを受け取り、Eventを受けて更新する。

これを図で表すと次のようになる。

「Fluxはアーキテクチャの名前で、MVCをさらに細かく役割で区切って、名前を付けたようなもの。新しい何かというわけではない」（小林氏）

FluxについてもGitHubに資料があるので、参考にしてほしい。

最後に小林氏は次のようにまとめ、セッションを終えた。

「React.jsがやりたいことはコンポーネントによるカプセル化。親から子への明確なデータの流れ、複雑なユーザーインタフェースの単純化、わかりやすさを重視している。コードをメンテしやすくするための思想になっている。一番ややこしかったDOMが状態を持ってしまうこともないので、開発者が開発しやすいようになっている。ぜひ、試してほしいですね」

「Angular vs React」パネルディスカッション

続いては、「AngularJS」と「React.js」それぞれの陣営に分かれてのパネルディスカッション。

パネラーは、「AngularJS」から金井氏とhtml5jのスタッフであり、Angularのユーザー会の一員でもある佐川夫美雄氏、「React.js」側からは小林氏と先ほどの神資料を作った外村和仁氏。

▲左から、佐川夫美雄氏、金井健一氏、外村和仁氏、小林徹氏

そしてモデレータを務めたのが、html5j運営スタッフのおなじみ若狭氏だ。

▲html5j運営スタッフの若狭正生氏

なぜ、Virtual DOMに行き着いたのか

若狭：AngularJS、React.jsともにVirtual DOMみたいなものを実装している。ここに行き着いた理由をどう考えているか聞かせてください。

金井：直接、DOMを触るのはつらいという課題があり、何かを介してDOMの変更を管理しましょうという方向だが、全部変えるとパフォーマンスが悪い。そこで影響のあるところだけ差し替えようというのが、Virtual DOMの流れ。React.jsが実装されたのはそれが理由。AngularJSの2系では、Reactと同じことができるようにしたいということ。そこでVirtual DOMみたいなものを採用している。

佐川：個人的にも、DOMを操作するのは難しい印象がある。そこでmarionetteのようなものを乗せたりしてきた。その流れでAngularが生まれ、もう一度DOMのやり方を見直そうということでVirtual DOMが生まれた印象がある。

小林：Webアプリを作っていても思うのが、DOMのところで開発工数がかかってしまうこと。特にモバイル向けゲームアプリの場合、パフォーマンスが遅くなるとダメなので、Chromeのデベロッパーツールのタイムラインを見ながらやっていくというひたすらつらい作業があった。普通のデバッグだとそこまで必要ないが、雑にやり過ぎるとそこが問題になってくる。そこの現実的な落としどころとしてReact.jsのVirtual DOMの実装があると思っている。

外村：Backboneをずっと触っていた者からすると、Backboneの一番つらいところはイベント検知してDOMを変更しないといけないときに、その変更を手で書かないといけないところ。

AngularJSなどのデータバインディング系が出てきてそこは解決された。次にVirtual DOMという別のアプローチが登場したことで、全体をざくっと更新し、差分だけ変更するという方向へ流れるのは必然。

近い将来には、Virtual DOMがさらに洗練され、パフォーマンスも改善されていると、主流のアーキテクチャになると考えている。さらなる将来では、ブラウザのネイティブにそのような仕組みが組み込まれてくることが期待される。HTMLをDOMレベルで更新すれば、ブラウザがそこの変更を検知し、Virtual DOM同程度の速度がでるということができると嬉しいですね。

金井：Angular2やReact.jsもそうかもしれないが、Workerを使って裏で実行しようとしてパフォーマンスを上げようとしているのがわりと近い未来。そこでパフォーマンス改善はされるはず。

デザインするために配慮すべきことについて

若狭：HTMLのデザインで、こういうことをされるとへこむということがあれば、教えてください。

外村：ひと言で言うとコンポーネントを意識した組み方をしてほしいですね。コンポーネントとはWebのUI。大きさはそれぞれバラバラだけど、各部品を組み合わせてページを作っていくことを基本思想としているので。同じような部品なんだけど、微妙に違うとかそういうのが多くなるとつらくなると思います。

小林：先日、開催されたReact.js Meet upで、Photoshopのレイヤー情報からコンポーネントを自動的に作るというセッションがあった。そういう意味ではレイヤーとかでコンポーネント指向をある程度意識してやっているのではないかなと思う。

佐川：話は少し変わるかもしれないが、いろんなところでハンズオンをしていると、デザイナーさんと出会うことも増える。AngularJSはテンプレートがHTMLでできているので、デザイナーさんにすんなり受け入れてもらいやすい気がする。

若狭：デザイナーさんとエンジニアの役割についてはどうですか。コンポーネントを意識したHTMLをデザイナーさんからもらってエンジニアがコンポーネントを作っていくのか、デザイナーさんにコンポーネントをHTMLに組んでもらうべきなのか。

金井：チームの状況によると思う。マークアップ得意な方がいると、コンポーネント単位でのHTMLでお願いする。絵が得意な方であればこちらで作るという風になっているのが現状です。

若狭：デザイナーさんとの役割分担で、AngularJSとReact.jsで違いはある？

外村：AngularはHTMLを直接書くので、デザイナーさんでも触りやすい。一方、React.jsの方は金井さんもきもいと言っていたJSXの中にJSを書いたりするので、触りづらいと思う。ただ、そこは技術の進化と合わせて考える必要がある。

以前の静的なHTMLの場合、デザイナーさんがCSSを含めて書けた。しかしコンポーネント指向になり、コンポーネントがJSを含めた振る舞いを持つようになると、そこはエンジニアが書くのが自然だと思います。

サーバサイドとJavaScriptのフレームワークのつなぎ込みについて

若狭：このフレームワークを使ったから、サーバサイドの実装も変わってくるということはありますか。

金井：サーバはJSONを返してくれればいいという風になっているのが今の主流。最近、Isomorphicというキーワードが出ている。これはバリデーションチェックなどをサーバサイドと同じ資源、同じコードでチェックしようというもの。つまりJavaScriptのサーバとJavaScriptのフロントエンドとを共有できるパーツをうまく使っていくという構成になるかもしれません。

小林：Isomorphicもそうだが、最近、microservicesというワードも話題。NodeJSでDBへのアクセスなどを全部書くというのはつらいので、誰もやりたくない。しかしフロントにNode.jsのサーバを置き、それが後ろのRailsなどのサーバにHTTPを投げるというアーキテクチャにすると、その作業が解消される。このようなアーキテクチャにReact.jsはマッチすることも、広まる一因になっていると思う。

若狭：サーバサイドで素のHTMLを先に吐きだし、後からJavaScriptで更新をするところがうまく書けるというのがReact.jsの良いところですね。一方のAngularは？

金井：2系でサーバサイドレンダリングをやりたいと言っている。ただ現状、成果が出ているわけではない。

若狭：やはりそういうトレンドにはなってきている？

金井：React.jsがやれることがみんなのやりたいことなので、これから出てくるフレームワークはみんなその方向になっていくと思う。

外村：Angular2はReact.jsに寄ってきているという感じがしますが。

金井：まさに。Angular2を勉強したとき、すごくReact.jsに似ているなと思っていた。ゴールが一緒でアプローチが違うというだけになってきているというのがここ最近の印象ですね。

小林：Ember.jsも次のバージョンでVirtual DOMでサーバサイドレンダリングできるようになるので、方向性は同じです。

佐川：ただAngular2のng-clic以降を、（）で書くのは、ちょっと気に入らないのですが。

外村：それよりもJSXの方がキモいんだけど（笑）。

金井：今までのAngularはstringで渡し、stringの中で解析をしてそれぞれの振る舞いをしていた。そこがパフォーマンスとしてつらかった。それを改善するために明確に分かっている物に対しては、囲んで分けるという形になった。Design Dockにその履歴があるので、興味のある人は見てください。楽しめると思う。

若狭：JSXは単純に、JavaScriptの中にべたっとHTMLを貼り付けるのが、気持ち悪いと思うのですが。

金井：実際そうですね。template-stringsというES6の仕様を使えばいいのにと思う。JSXでがんばるなら、そこをサポートするようにしてほしいですね。

外村：テンプレートリテラル(template strings)をなぜ使わないのかというと、JSXの公式サイトのトップにその理由が書かれているので、詳しくはそれを読んでほしい。簡単に紹介すると、template stringsで書いても、変数展開などは中でやらないといけないので、汚いくなる。JSXと同じような感じになるからだそうだ。

エディターで構文解析について

若狭：エディタだと構文を解析しにくいと思うのですが。

外村：最近はエディタにJSX対応の機能などがついているので問題ない。

小林：ESLintなどのツールもプラグインを使うことでJSXを解釈してくれるので、よく使いますね。

SEO対策について

若狭：サーバサイドでのHTML生成は、SNSなどのSEO対策で必要だからしているのか、スピードがほしいために行っているのか。

小林：両方です。スピードも必要だし、SEOの適用できる幅も広がりますから。ただ、Facebook自体はサーバサイドレンダリングをしていないけど。

外村：スピードはサーバサイドで書かなくてもなんとかなると思うので、SEO対策というかマシン読めることの方がモチベーションとしては強いと考えている。

AngularJSとReact.jsどちらかがよいか

ここで会場の参加者にAngularJSとReact.js、どちらが面白そうかを聞いた。Angularが面白そうだと言う人はかなり少なめ。React.jsの方が少し多かったが、一番多かったのはどっちもでもいい派。

若狭：Angularは管理画面などに向いていて、React.jsは普通のページとかサーバサイドで作るモノに適しているという傾向はあるのか。

外村：Angularが管理画面に適していると言われているのは、APIと通信してその結果をHTMLに書いたテンプレートに反映してくれるから。それぐらいのアプリケーションだと素早く書ける。一方、React.jsはユーザーイベントがバリバリ来て、それで変更したり、メンテナンスしないといけない複雑なアプリケーションに向いている。そういう使い分けができる。

金井：最近のフレームワークは同じようなことができるようになっている。Angularが強いのは管理画面やクラフト系のアプリ作成。これらは他のフレームワークよりかなり早く実装できると言い切れる。それ以外の場面ではReact.jsの方が良い、Angularの方が良いという差は出てこないと思う。

外村：実体験から話すと、AngularJSで複雑なアプリケーションを作ったときに直面した問題は、ディレクティブ自体がスコープを持ったり、コントローラがスコープを持つと、そのスコープは親のスコープからも継承することができるので、自分のディレクティブが持っている情報は自分だけが持っているのでは無くて、親から継承したものもある。

自分のスコープを変えたつもりが親に伝わるとか、親に伝えたいのに伝わらないとか、複雑になってつらかった。React.jsの場合はそういう問題が起こらなかった。というのはReact.jsは状態を持たないから。そういう面ではReact.jsの方が作りやすい。

金井：その辺はスコープがなくなるAngular2が解決してくれる。Angular1を使っていて同じ問題を抱えている人は、Angular2に期待するしかない。またスコープを使わないと方法もある。

小林：巨大な道に乗りたいかどうかという気持ちの部分も大きい。AngularだとAngularの中ですべて完結できるので、その世界でずっといると平和。React.jsだと基本的にそれだけだと作れない。例えばコンポーネントをどうまとめるのかはBrowserifyを使うのかなど、いろいろ選択肢がある。そこを楽しいと思える人はReact.jsが合うと思う。

外村：今のJavaScriptはライブラリの進化が早いので、スコープは小さいライブラリを組み合わせていくことで、その小さい部品だけを取り替えれば、常に最新の状態についていけるようにすると良いと思う。特にどちらがよいというわけではないが。