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

本記事は、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 そろそろお時間ですので、これで前半を終わりにしたいと思います。後半も、引き続きよろしくお願いします。

後編に続きます

しかしAngular1.xの最新バージョンである1.5では、Angular1から2への移行をスムーズに行うために、Angular2を見据えたコーディングが行えるようになっています。この記事ではAngular2への移行をスムーズにするための、Angular1の書き方を紹介していきます。

【編集部注】
※この記事は、2016年3月21日に開催された「ng-japan 2016」のセッション「Angular2を書くためのAngularJSの書き方」についての、講演者自身によるレポートです。講演内容に加えて、講演者自身による解説や追記によって、よりわかりやすく詳細な記事に仕上げていただきました。
※本記事では、AngularJSをAngular1、 AngularJSの2系をAngularと表記しています。

セッションの講演資料と動画はこちらになります。

講演資料

講演動画（2:03:46付近から始まります）

Angular1の歴史と背景

Angular1は、今から4年前の2012年6月に、バージョン1.0.0がリリースされました。この4年間に、Windowsなら8->10、Macで10.8->10.11、Androidで4->6、iOSで6->9という変化がありました。バージョンアップが比較的遅いとされるOSでも、4年の間にこれほど大きなバージョンアップが行われているのです。

現在のIT業界では、4年とはこれほど長い期間です。また4年前のWebを振り返ってみますと、当時はBackbone.jsなどのMVCフレームワークが全盛期でした。Angularはリリースされてから大きな人気を博し、世界中の数多くのプロジェクトで採用されました。

しかし月日は流れ、2014年にReactが発表されてからは、Angular1の人気にも陰りが訪れます。コンポーネント指向を採用したReactの優れた設計が広く支持されたこと、Angular1はパフォーマンスがあまりよくないということもあり、Reactを採用するプロジェクトも増えてきました。

そこでパフォーマンスを大きく改善し、アーキテクチャが刷新されたAngular2が今年中にリリースが予定されています。しかしAngular2は変更点が多く、普及には時間がかかることが予想されます。そのため、Angular1.xは当分サポートされることが決定しています。

Angular1とAngular2の違い

Angular1とAngular2の違いは多岐にわたります。その中でも代表的な違いを以下に挙げます。

• 主な開発言語がJavaScriptからTypeScriptへ
• Two-wayデータバインディングを廃し、One-wayデータバインディングへ
• 従来のスコープに代わり、コンポーネントがUIの状態を保持する（コンポーネント指向）
• テンプレートの文法が変更
• 従来のng-routerからコンポーネントルーターに
• 従来の文字列ベースのDI (Dependency Injection)から、型によるDIに

対象ブラウザに関して

Angular1.5は、残念ながらIE8以前では動作しません。IE8以前を対象とする場合は、Angular1.2を利用する必要があります。もしIE8を対象にしなくてよいのであれば、Angular1.5へのアップデートが強く推奨されます。

JavaScriptからTypeScriptへ

Angular2では、メインの開発言語がTypeScriptに変更されました。

簡単に経緯を説明しますと、もともとAngular2を開発する際、JavaScriptのスーパーセットであるAtScriptという言語を同時に開発していました。

AtScriptの実体は、アノテーション付きのTypeScriptと言ってよいものでしたが、開発は難航。2015年3月にTypeScriptが（アノテーションに近い機能である）デコレーターの実装を表明すると、Angular2はTypeScriptへと移行したという流れがあります。

実際には、Angular2にとってTypeScriptは必須ではなく、JavaScriptやDartでも開発は可能です。しかしTypeScriptを利用すると多くのメリットがあるので、TypeScriptの使用が推奨されています。

ちなみに、TypeScriptというのは以下のような特徴を持った言語です。

TypeScriptの特徴

• 型がある
• インターフェースがある
• モジュールインポートがある
• 仕様がしっかりしている
• JavaScriptのスーパーセットである
• TypeScriptはそのままではブラウザでは利用できないのでコンパイル（JavaScriptへの変換）が必要

BrowserifyやWebpackを使おう

皆さん、GruntやGulpと言ったタスクランナーを既に使われている方は多いと思います。Angular1.5 / 2の開発では、TypeScriptのimport文を使用してモジュール間の依存性を記述していくため、こうした依存関係を解決して実行可能なプログラムを生成できるツールが必要です。

そうしたツールにはBrowserifyやWebpack、System.jsなどがあり、import文やCommonJSのrequire()関数などを解釈し、依存関係を解決した上で、ファイルを一つにまとめる機能を持ちます。

TypeScriptからのコンパイルなどもプラグインとして提供されており、今後のAngular開発には必須のツールとなっています。

Angular1.5のコードを眺める

Angular2とAngular1の違いや開発に必要な情報が一通り揃ったところで、実際にAngular1.5のコードを眺めてみましょう。 以下は、画面に「Hello」と表示するだけのプログラムです。

import * as angular from 'angular';

angular.module('app')
.component('app', {
  template: `<div>Hello {{ $ctrl.text }}</div>`,
  controller: class App {
    public text: string;
    constructor() {}
  },
  bindings: {
    text: '@'
  }
});

<!doctype html>
<html>
<body>
  <app text="ng-japan">
    Loading...
  </app>
  <script src="./bundle.js"></script>
  <script>
    angular.bootstrap(document, ['app']);
  </script>
<body>
</html>

Angular1のコードには違いないように見えますが、これまでとは何かが違いますね。

実際上のコードはTypeScriptで書かれており、importやclass、publicなどのアクセス指定子など、素のJavaScriptでは使えない文法が多く使われています。

DirectiveからComponentへ

Angular2から、コンポーネントという概念が登場します。それに合わせて、Angular1.5でもコンポーネントが利用できるようになりました。Angular1のディレクティブに比べて、簡単に作ることができます。

DirectiveとComponentでの設定値の違い

Directiveには先述したComponentと呼ばれるDOMの生成と他にAttributeに設定する処理ng-repeatやng-showなども同じ方法で作成しています。

そのため、Componentを作るには設定が過多気味であり、Angular2へ移行する場合に必要なものと不必要なものをより分けた作成メソッドを新たに追加されました。

以下の表が元々のDirectiveメソッドと追加されたComponentメソッドとの設定の違いとなります。

引用：https://docs.angularjs.org/guide/component

Angular1のパフォーマンス問題

Angular1のパフォーマンスが良くない理由ですが、その原因を挙げてみましょう。

• Two-wayデータバインディングが重い
• 状態の監視に伴うオーバーヘッド
• dirty check
• $digest loop

では、どうしたらよいのでしょうか？以下の様なアーキテクチャが推奨されていますが、Fluxアーキテクチャによく似ています。

では、このアーキテクチャに従ったコードのサンプルを紹介します。

まずはアプリケーションのエントリーポイントとなるHTML（index.html）です。これは、angular.bootstrap()を呼び出しているだけで、特に変わったことはしていません。ただし、list-cmpというタグを使用していることは覚えておいてください。

<!doctype html>
<html>
<body>
  <list-cmp>
    Loading...
  </list-cmp>
  <script src="./bundle.js"></script>
  <script>
    angular.bootstrap(document, ['app']);
  </script>
</body>

以下がサービスのコードです。このサービスは、アプリケーションのデータを保持しており、データの操作を行うことが可能です。

import * as angular from 'angular';

angular.module('app')
.service('StoreService', class Store{
  private datas: Array<string> = [];
  constructor(){
    this.datas = ['angular', 'javascript', 'typescript', 'angular2'];
  }
  getList() {
    return this.datas;
  }
  addData(data:string) {
    this.datas.push(data);
  }
  changeData(index:number, data:string){
    this.datas[index] = data;
  }
  deleteData(index:number){
    this.datas.splice(index, 1);
  }
})

以下は、index.htmlで使用されていたlist-cmpタグ（コンポーネント）の実装です。内部で、さらにlang-cmpというタグ（コンポーネント）を使用しています。

また、Angular1で多用されていた$scopeはもう使われておらず、代わりにコンポーネントのコントローラーの参照である$ctrlが使用されています。基本的には、$scopeはもう使用してはならないものとして考えましょう。

import * as angular from 'angular';

angular.module('app')
.component('listCmp', {
  template: `<ul><li ng-repeat="data in $ctrl.datas">
    <lang-cmp index="$index" lang-data="data"
     lang-change="$ctrl.change(index, data)"
     lang-delete="$ctrl.delete($index)"></lang-cmp>
  </li></ul>`,
  controller: class List {
    private store;
    private datas: Array<string> = [];
    constructor(StoreService) {
      this.store = StoreService;
      this.datas = StoreService.getList();
    }
    change(index: number, data: string) {
      this.store.changeData(index, data);
    }
    delete(index: number){
      this.store.deleteData(index);
    }
  }
});

最後に、lang-cmpタグの実装です。上のコードで指定されていたlang-changeやlang-deleteと言った属性が、langChangeやlangDeleteといったプロパティに対応しています。

import * as angular from 'angular';

angular.module('app')
.component('langCmp', {
  template: `<input ng-model='$ctrl.langData'>
  <button ng-click="$ctrl.change()">変更</button>
  <button ng-click="$ctrl.delete()">削除</button>`,
  controller: class Data {
    private langData:string;
    private index:number;
    private langChange;
    private langDelete;
    constructor() {}
    change() {
      console.log(this.index, this.langData);
      console.log(this.langChange);
      this.langChange({index: this.index, data: this.langData});
    }
    delete() {
      this.langDelete({index: this.index});
    }
  },
  bindings: {
    'langData': '<',
    'index': '<',
    'langChange': '&',
    'langDelete': '&'
  }
})

コンポーネント指向のディレクトリ構造

コンポーネント指向になったことから、コンポーネント単位にまとめると見通しがよくなります。

├─about
│  └─components
│          about.component.e2e.ts
│          about.component.html
│          about.component.scss
│          about.component.spec.ts
│          about.component.ts
│
├─app
│  └─components
│          app.component.e2e.ts
│          app.component.html
│          app.component.spec.ts
│          app.component.ts
│          navbar.component.html
│          navbar.component.scss
│          navbar.component.ts
│          toolbar.component.html
│          toolbar.component.scss
│          toolbar.component.ts
│
├─assets
│  │  main.scss
│  │  _colors.scss
│  │  _variables.scss
│  │
│  └─svg
│          more.svg
│
├─home
│  └─components
│          home.component.e2e.ts
│          home.component.html
│          home.component.scss
│          home.component.spec.ts
│          home.component.ts
│
└─shared
    └─services
            name-list.service.spec.ts
            name-list.service.ts

テストについて

Angular2ではテストの基本セットがJasmineとなっていますので、Jasmineだと学習コストは少なくなります。

ルーティング

Angular1ではngRouteよりもui-routerがよく使われていると思いますが、Angular2では性能と管理が簡単なComponentRouterが登場します。 Angular1.5用のComponent Routerが用意されています。

まとめ

このセッションで学んだことを最後にまとめます。

• Angular1のプロジェクトでもTypeScriptを使おう
• タスクランナーを利用しましょう
• Webpackやbrowserifyを利用しましょう
• DirectiveからComponentに変更しよう
• controllerの廃止
• Scopeは原則利用しないように
• Two-way data-bindingよりOne-way data-binding
• コンポーネント単位でファイルを整理しよう

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

去る3月9日、AngularJSのエキスパートによる座談会におじゃまさせていただきました。この座談会はAngularJS Japan User Groupの佐川 夫美雄さんの呼びかけによるもので、お題はもちろん、現在β版として公開中のAngular2。「ハードル高い」「Angular1と違いすぎる」など、いろんな情報も飛び交う中で、Angular2の魅力と課題について存分に語っていただきました。

Angular2に関心のある方にはもちろんのこと、Angular1しか触ったことのない方、そもそもAngularJSは初めてという方にとっても貴重なご意見が満載！エキスパート同士の会話とあって、さすがにハイコンテキストだったので、注釈も多めに入れてみました。Angularを知り尽くしたエキスパートたちによる会話を、どうぞお楽しみください。

座談会メンバー紹介（50音順）

金井 健一
SIer、Web制作会社を経てフリーランスに。もともとはサーバサイドでJavaメインのエンジニアだったが、サーバサイドからフロントエンドに転向。html5j Web先端技術味見部部長。また、 AngularJS Japan User Group管理人も務め、主催するイベントを通して AngularJSの普及活動を行っている。

佐川 夫美雄
現在、Angularを使ったアプリケーション開発やSIerへのAngular教育など、Angular一色の生活を送っているエンタープライズ系Webエンジニア。COBOLでの生産管理システムの開発を経験後、Javaエンジニア/Oracleデータベースエンジニア/プロジェクトマネージャとしてJavaフレームワーク、品質管理・物流システムの構築を行ってきた。

林 優一
株式会社LIG CTO。ソーシャルゲーム開発会社にてUI/UX開発本部本部長としてフロントエンド設計・開発及びマネジメント業務に従事。その後、LIGに入社。フロントエンド開発・フロントエンドエンジニア育成を担当。デザインからサーバーサイドまで幅広く対応。AngularJSコミュニティに所属。ng-mtgやDevelopers Summitでのスピーカーを務める。得意言語はJavaScript。

吉田 徹生
株式会社トレタにてWebアプリケーションを開発。メインでAngularJSを利用し、どこかでAngular2が使えないかと虎視眈々と狙っている。

モデレーター白石俊平
HTML5 Experts.jp編集長。株式会社オープンウェブ・テクノロジー代表取締役として、Web標準技術に関するコンサルティングや開発に従事。Google社公認Developer Expert (HTML5)、Microsoft社公認Most Valuable Professional (IE) 。著書に「HTML5&API入門」「Google Gearsスタートガイド」など。

Angular2って、ざっくり言うと、なに？

白石 佐川さん、今日はこういう場にお誘いいただいてありがとうございました。今日はAngularJSのエキスパートの方々に、Angular2の魅力や導入にあたっての注意点など、詳しくお聞きしたいと思います。

ではまず最初の質問ですが、まず基本的な事柄から。AngularJS、そしてAngular2とは何ですか？

金井 AngularJSはそもそも、シングル・ページ・アプリケーション（SPA）を構築するためのフレームワークです。そしてその最新版であるAngular2をひと言で表すなら、Angular1のパワーアップ版 と言えるでしょう。Angular1でできたことがほぼ全てできるだけではなく、Angular1の欠点も改善しています。

吉田 Angular1から引き継いだ良い点としては、「フルスタック」であることが挙げられると思います。Protractorなどのテストフレームワークも含め、SPAを開発するために必要なものがだいたい入っている。Angular2になってもそれは変わらない。この「フルスタックである」という点は、他のフレームワーク（例えばReact）と比べても特徴的じゃないかと思いますね。

白石 Angular2になって改善した、Angular1の問題点というのは、具体的には何でしょうか？

金井 まずは処理速度が向上したことですね。一説には、8〜10倍も速度が向上したと言われています。

白石 そういえばこの間、Angular1、2、あとReactを比較したベンチマークなども話題になりました。

佐川 Angular2では、外部プロジェクトの活用も意欲的ですね。そこも改善点といえるんじゃないでしょうか。

金井 そこも大きな改善点ですね。Angular1は独自色が強く、「Angular Way」と揶揄されてきましたが、今回はTypeScriptやSystem.jsなど、外部プロジェクトの成果もうまく活用しています。

佐川 その他の改善点としては、ルーター(※)も大きな改善点だと思います。従来のng-routerや、公式ではないながらも広く使われてきたui-routerに代わり、Angular2ではコンポーネントルーター(※)が採用されました。Angular2は、全体的にコンポーネント指向になっていますので、ルーターもそれに合わせて進化しました。

林 コンポーネントルーターを使ってみると、ルーターがルーティングに専念できるようになったと感じました。今までは様々な処理をルーティングと混在させてしまいがちだったので。ルーターとコンポーネントの境目がきっちり分かれたという印象です。

金井 ちなみに、コンポーネントルーターは1.5でも使えます。1.5は、既存のAngularアプリケーションを2にアップグレードしやすくするため、2の設計の多くを持ち込んでいます。

佐川 この座談会のテーマはAngular2ですが、1.5もコンポーネント指向なので、1を触っている人は1.5にするといいんじゃないかな。2よりも手軽に触れるので。

※ ルーター…AngularJSなどのSPAフレームワークにおいて、UIの状態遷移を実現する仕組み。SPAの場合、UIの状態とURLをひも付けるのが重要な課題となるため、「URLのルーティング」を行うという意味から「ルーター」と呼ばれている。

※ コンポーネントルーター…従来のAngularJSでは、UI状態とテンプレート（とそれに紐づくコントローラー）が紐付いていたが、Angular2ではコンポーネントがUI状態に対応するようになった。

TypeScriptはどうよ？

白石 Angular2では、TypeScript(※)がメインの開発言語になりましたね。

吉田 そうですね。JavaScript（ECMAScript 5）でも書けなくはないですが、ドキュメントが不完全だったりして、あまりよくサポートされているとは言えなそうです。

金井 TypeScriptに重きが置かれているのは、以前行われた開発者向けのアンケート結果を踏まえてのものだと思います。その時のアンケート結果では、TypeScriptの採用を望む声が一番大きかったように記憶しています（編集部注: 1位はTypeScript (45%)、2位はBabel (33%)、ES5は3位 (9%)）。

吉田 TypeScriptでコーディングすると、デコレーター (※)が使えるのはいいですね。コードの見通しが非常に良くなります。あと、型があるおかげで安心感があります。手軽さはなくなっちゃいましたけどね。

林 TypeScriptは型を強制はしないので、敷居はそこまで高くないんじゃないかな。JavaScriptのスーパーセットなので、JSのコードもそのまま動きますし。あと、Angular2のDependency Injection (※)が型をベースとしたものになっているのも、TypeScriptのおかげです。

佐川 import文で、利用しているモジュールだけが取り込まれるのもとてもいいですね。ただ、型がある言語になるとエンタープライズ業界で喜ばれるかと思ったら、今のところ意外とそうでもないんですよね…。

金井 変化が大きいからじゃない？

佐川 そうかも。基本的に、「変化しないとかバージョンアップしない（できない）ってことが正義」っていう雰囲気がなきにしもあらず…な業界ので (笑)。

※ TypeScript…マイクロソフトが開発した言語。厳密な型付けを持つことで大規模開発にも対応しやすくなっているだけではなく、ECMAScriptの先進的な機能を数多く取り込んでいるという特徴を持つ。コンパイルした結果JavaScriptのコードが得られるという、「JavaScriptトランスパイラ」（もしくはaltJS）と呼ばれる言語の一つである。

※ デコレーター…クラスやプロパティ、関数や仮引数などに付加的な情報を付与したり、前処理を行ったりすることができる仕組み。Java言語の「アノテーション」に近い記法を持つが、JavaScriptのデコレーターはシンプルなJavaScript関数に変換されるため、（TypeScriptなどのトランスパイラが変換した結果は）古いブラウザなどでも動作する。

※ Dependency Injection…和訳すると「依存性注入」。依存するクラスのインスタンスを得る手段として、手続き内でnewによって生成するのではなく、外部から「注入」されるように記述することで、クラス間の依存性を疎結合にし、テスタビリティを向上させることができる仕組み。Angular1から使えた仕組みではあるが、Angular2ではTypeScriptの型を利用して依存関係を指定できる。

Angular2のテンプレートはキモい？

白石 TypeScriptについては、エキスパートの皆さんも概ね好意的ですね。では、Angular2で刷新されたHTMLテンプレートについてはいかがでしょうか？

金井 キモいです(笑) 。でも、慣れるしかない。

林 アスタリスクや括弧などの、記号の意味を把握するのに最初は少し苦労しますね (※)。

金井 前は、React（のJSX）のことをキモいと思ってたんですが、肩を並べちゃいました。「お互いキモいよね」という感じで、仲良くしていきたい (笑)。

白石 個人的には、テンプレートをデコレーターに直接書く(※)のも、最初は抵抗ありました。

金井 ぼくはtemplateUrlにテンプレートのURL書く派(※)ですね。

林 ぼくは小さいテンプレートはデコレータの中に、大きめのものは外部ファイルに出す、って感じで使い分けてます。

吉田 デコレータ内に書く場合でも、TypeScriptはES6のテンプレート文字列(※)を使えるのが嬉しいですね。式を埋め込んだり、改行できたりするのがいい。あと、コンポーネントのUIという話で言うと、CSSがコンポーネントごとにカプセル化される(※)のは最高です。

林 そうそう、コンポーネントのカプセル化は嬉しいところです。Angular1のような、スコープの干渉が少なくなったのもすごくいいところだと思います。まあ、1の時みたいな無茶はできなくなっちゃいましたけどね。スコープの親をどこまでも辿っていって…とか。

吉田 まあ、無茶をしたかったらRxJS (※) でやろうと思えば、結構できるんじゃないでしょうか (笑)。

佐川 そういえばRxJSといえば、rx.angular.jsを使うと、Angular1でもRxJSが使えるようになります。ただ、サンプルコードを見ていたら$scope.$applyが入ってなくてちゃんと動かなかったので、修正してプルリク送っときました (笑)。

※ アスタリスクや括弧など…Angular2では、コンポーネントのタグ内に様々な記号を記述していくことになる。例えば、「person.nameというモデルと双方向に紐付いたinput要素をpersonNameという変数で参照できるようにする」と言った場合、<input [(ngModel)]="person.name" #personName>といった具合である。

※ テンプレートをデコレーターに直接書く／templateUrlにテンプレートのURLを書く…コンポーネントのHTMLテンプレートは、@Component({template="文字列"})という形式で書くか、@Component({templateUrl="URL"})という形式で書くかを選択できる。

※ ES6のテンプレート文字列…ES6では、式の埋め込みや改行を行えるテンプレート文字列がサポートされている。詳しくはこちらの記事を参照のこと。

※ CSSがコンポーネントごとにカプセル化される…Angular2のコンポーネントは、@Component({styles=["CSS"]})や@Component({stylesUrl="URL"})といった形式でCSSを指定できるが、こうして指定したスタイルはコンポーネント外に影響しない（カプセル化される）。Shadow DOM（もしくは属性を用いたエミュレート）によって実現されている。

※ RxJS…リアクティブプログラミングを実現するライブラリ(GitHub)。Angular2では、HTTP通信を行うモジュールやイベント処理など、基礎的なAPIで広く採用されている。

Angular1からの移行

白石 Angular1をこれまで使っていた方は、Angular2にアップグレードできると伺いました。

林 私がちょうど今、1.4のシステムを2に上げようと取り組んでいるところです。順序立てて取り組むのが重要ですね。

白石 どのような順序で取り組んでいるんでしょう？

林 私はまず、1.5にアップグレードしました。その後、Babel (※) からTypeScriptに移行しました。その後、ビュー周りとか、ディレクティブとかも全部コンポーネントに置き換えていきました。ここまでは割とすんなりいけます。

ただ、今取り組んでいるルーターの置き換えには少し苦労していますね。ui-routerからコンポーネントルーターに置き換えるところでは、明示的なアップグレードパスが用意されていないので。

でも、ここが終わればあとは2に合わせてテンプレートの記法を書き換えていくだけです。ng-upgradeっていうアップグレード用のモジュールも用意されている (※) ので、それを使って少しずつ置き換えていけます。

白石 ちなみに、どれくらいの期間取り組んでらっしゃるんですか？いつ頃終わりそうですか？

林 始めたのは3月に入ってからですから、まだ1週間くらいです（インタビューしたのは3月9日）。3月21日にng-japan (※) というイベントで発表があるので、なんとしてもそれまでには終わらせたいですね (笑)（※）。

※ Babel…ECMAScriptの先進的な機能を今すぐ利用できるようにしてくれるJavaScriptトランスパイラ。

※ ng-upgrade…Anguar1とAngular2の共存を実現し、2への移行を楽にしてくれるモジュール。Angular1/2どっちで書いても相互にやり取りできるよう仲介してくれる。具体的には、Angular1記法のserviceやcomponentをAngular2から呼び出したり、逆にAngular2のserviceやcomponentをAngular1から呼び出したりできるようにするもので、双方のダウングレード/アップグレード機能を提供する。

※ ng-japan…残念ながらもう終了しているが、HTML5 Experts.jpでは現在、「Angular2実践入門」に関するセッションレポートは公開済み。今後もレポートはいくつか掲載予定。

※ 「なんとしてもそれまでには終わらせたい」…「残念ながらng-japanまでには完了しませんでした！！！！」（林）

Angular2の学習コスト

白石 そろそろこの座談会も時間的に終わりに近づいてきていますが、最後に一つ気になっていることを聞かせてください。Angular2の学習コストはかなり高いのではないかと思うのですが、いかがでしょうか？

金井 仰るとおりです。学習コストは跳ね上がっていると言っていいでしょう。

佐川 TypeScriptも込みなので、教育に時間がかかるようになっちゃいましたね。とはいえ、Angular2のクイックスタートとかは、余計なことを考えずに取り組めば割と簡単だと思いますが。

吉田 ただ、あのクイックスタート「5 minutes」とか書いてあるけど、絶対5分じゃ終わらないですけどね。

佐川 はい、あの内容で講義したら50分使いました(笑)

金井 Angular2を使いこなそうと思ったら、TypeScript（もしくはBabel）、System.js (※)やWebpack (※)などのモジュールバンドラー (※)、RxJSなどを一通り押さえる必要があります。でもまあ逆に考えれば、一旦覚えさえすればモダンなJavaScriptが書けるようになるわけで。

林 ですね。モダンJavaScriptの学習セット だと思えば、楽しく学べるんじゃないでしょうか。

まとめ

白石 ではそろそろ、お時間も遅くなってまいりましたので、お開きにしたいと思います。皆様、一言ずつ頂いてもよろしいでしょうか？

佐川 まずはとにかく触って欲しいですね。気持ちよく触れるフレームワークになっているので、面白いのは間違いありません。

林 1と比べると、ソースが整理されて綺麗に書けるようになるので、特に大きいシステムの場合は嬉しいですね。フルスタックのフレームワークとして、正しい方向に向かっているんじゃないかと思っています。

吉田 1.0が登場した頃に比べると、完全に世界は変わってしまっています。それくらいWeb技術の流れは速いですが、Angular2にしておけば、あと2,3年は古びないシステムが作れるんじゃないでしょうか。ただ個人的には、「バージョンアップ」って感覚ではないですね。完全に別物。Perlが、Perl6になって完全に別物になってしまったような感覚と似てるかもしれません。

白石 Perlの事情は全く知らないのですが、そうなんですか？

吉田 はい。Perl6は、「Perl6っていう新しい言語」ですから (笑)。

金井 パフォーマンスや設計上の問題点など、1の悪かった部分がなくなりました。ハードルは確かに結構高いですが、モダンなJavaScriptにアジャストするという点では、とても良いフレームワークだなと思っています。

白石 皆さん、本日は貴重なお話をお聞かせいただきありがとうございました。とても勉強になりました。

　　　▲今回は、株式会社トレタさんに対談会場のご協力をいただきました。素敵なオフィスでした！

何が変わったのか

以前から言われているとおり、かなり大きく変わっています。これまでのJavaScriptフレームワークではMVCやMVVMと呼ばれるデザインパターンが多く採用されてきました。

しかし、Web Componentsの仕様策定が進んでいる今、この仕様と共存できるようなコンポーネント指向のフレームワークが求められてきています。そういった背景から、MVW(hatever)という思想で開発されていたAngular1に対し、Angular2はコンポーネント指向で設計されています。

Angular2は、以下のような特徴をもっています。

• 処理速度・パフォーマンスの向上
• よりシンプルに、わかりやすく
• クロスプラットフォーム
• Angular1からのシームレスなアップグレード
• 柔軟な開発
• 網羅的なルーティング
• Dependency Injection（DI）
• レガシーブラウザのサポート
• アニメーション（開発中）
• 国際化 (Internationalization:I18N) とアクセシビリティ（開発中）

angular.io – FEATURES & BENEFITS より

これだけだと伝わりにくいので要約すると、

• Angular1での課題の解決
• ES2015/ESNextへの対応
• TypeScriptなどのトランスパイラとの連携
• Web ComponentsやPolymerとの連携
• AndroidやiOS対応
• デスクトップアプリ対応
• サーバサイドレンダリング対応

などが挙げられます。

Angular1の良いところはそのままに、課題については改善していこうという姿勢です。その結果もあり、Angular1で問題となっていたDirty Checkingを解決したことや、サーバサイドレンダリングをおこなえるようになったことで、パフォーマンスが飛躍的にアップしました。Angular2開発当初にパフォーマンスの問題で一時取り止めになっていた双方向バインディングも現在では実装されています。

それに加えて、Angular2では、モバイルやデスクトップアプリでも快適に動作するよう考慮されています。すでにIonicや NativeScriptで、ハイブリッドアプリやネイティブUIモバイルアプリを開発する際も、Angular2を利用することができるようになりました。

これらを見れば、多岐にわたる変更があるだろうことが想像できるでしょう。

Angular2が提供するAPIは一新されていて、Angular1との互換性はありません。しかし、Angular1のディレクティブの設定に似ているため、多少経験がある方であれば理解するのはさほど難しくはありません。

// コンポーネントを作成するサンプル
(function(app) {
  app.AppComponent = ng.core
    .Component({
      selector: 'my-app',
      template: '<h1>My First Angular 2 App</h1>'
    })
    .Class({
      constructor: function() {}
    });
})(window.app || (window.app = {}));

弱点がなくなった Angular2

他のフレームワークと比較すると、Angular1は入力フォームの多い、管理画面などの開発において圧倒的な強みがありました。双方向バインディングや強力なフォームバリデーション機能が備わっていたためです。

Angular2は、それらの機能を備えたままさらに強力になったといえます。管理画面だけでなく、モバイル環境やデスクトップアプリでも問題なく利用できるので、活躍する場が広がっていくでしょう。

サーバサイドレンダリングを利用すれば、SEOが必要なWEBサイトのフロントですら利用することができるようになります。 このように、苦手としていたことの改善によるパフォーマンスが向上したことで、今後は限定的なケースではなく、さまざまなケースで利用されることが期待できます。

他にも、開発する際の自由度があがったことも大きなメリットです。ES5で実装することもできますし、ES2015で実装することもできます。またTypeScriptやBabelなどのトランスパイラも組み合わせて開発することも可能になりました。特に、Angular2自身がTypeScriptで実装されていることもあり、tsdファイルを作成する必要がなくなったことは、TypeScriptユーザにとって嬉しいことではないでしょうか。

Angular2 のこれから

現在、β版にはなり多少は落ち着いたのかなといった印象ですが、今後はAngularユーザやコミュニティによってさらにブラッシュアップされていくことと思います。まだまだドキュメントが少ないことが懸念されますが、これらはAngularの開発チームでも課題になっているので、時間とともに解決されていくでしょう。

最後に気になるv2.0.0のリリース時期について、あくまでも予想ではありますが、 2016/5/4〜6にかけて開催される ng-confでv2.0.0をお披露目したいのではないかと推測しています。（もしかしたら間に合わないかも、ということもありますが…）

連載企画「AngularJS徹底解説」の第3回目は、ControllerとScopeの基礎について解説していきます。

AngularJS は MVW(hatever)!!!

AngularJSはMVC(Model-View-Controller)フレームワークと呼ばれることが多いですが、一部の開発者からは MVVM(Model-View-ViewModel)である、という声もあがっていて、ある時期に「一体どっちなんだ！？」という状態になりました。
そこで、そういった経緯に対してAngularJSチームが、そこについての議論は本筋ではないとして、AngularJSはMVW(Model-View-Whatever)である、と明言しています。

今回解説するControllerは、このWhateverの役割にあたる機能です。実際に「Whatever = 何でもいい」とはいっても、”Controller”という名のとおり、MVCパターンとして見れば M-V-“Controller”にあたる機能ですので、その概念から外れることはありません。

Controller の基本

コントローラは以下のように記述します。他にもいくつか書き方があるのですが、今回はこの書き方で解説していきます。

まず、myAppアプリにmyCtrlというコントローラを作成してみます。

angular.module('myApp', [])
  .controller('myCtrl', ['$scope', function($scope){
    // ここにコードを書いていく
  }]);

以下の意味になります。

...
  .controller.('コントローラ名', ['依存サービス', function(依存サービス){
    // ここにコードを書いていく
  }]);

$scopeについては、 ビューにデータなどを渡したり、ビューから発生したイベントを監視するなど、ビューとのやり取りを行うことができる特別なオブジェクトです。（AngularJSでは直接DOM操作をすることは推奨されていないため、この$scopeを通じて行います。そのためほとんどのケースでコントローラを記述する際に定義することになります）

また複数依存するサービスが複数ある場合は、

...
  .controller.('コントローラ名', ['依存サービス1', '依存サービス2' ... , function(依存サービス1, 依存サービス2 ...){
    // ここにコードを書いていく
  }]);

このように、配列に追加していく形で定義することができます。

先ほどの$scopeを利用して、ビューにモデルの値を引き渡します。
テンプレート(HTML)箇所については、前回までに解説した通りです。

<!DOCTYPE html>
<html lang="ja" ng-app="myApp">
<head>
  <meta charset="UTF-8">
  <title>Controller</title>
  <script src="https://ajax.googleapis.com/ajax/libs/angularjs/1.4.3/angular.min.js"></script>
</head>
<body ng-controller="myCtrl">
<div>筆者：{{myName}}</div>

<div>
  エキスパートたち
  <ul>
    <li ng-repeat="expert in expertList">{{expert}}</li>
  </ul>
</div>

<div>
  {{author.name}} ( twitter - {{author.twitter}} )
</div>

<script>
angular.module('myApp', [])
  .controller('myCtrl', ['$scope', function($scope){
    // Model の初期化 ①
    var myName = 'can.i.do.web';
    var expertList = ['Shumpei', 'komasshu', 'yoshikawa_t'];
    var author = { name: 'きゃない', twitter: 'can_i_do_web' };
    // View にバインディング ②
    $scope.myName = myName;
    $scope.expertList = expertList;
    $scope.author = author;
  }]);
</script>
</body>
</html>

$socpeを利用することで、ビューとやりとりすることができます。①で様々な形式のモデルの初期化、②で$scopeにプロパティを追加していくかたちで、 ビューに値を渡すことができます。
上記のほかにも複雑なオブジェクトや、関数などもバインドすることが可能です。

Controller の適用範囲

コントローラに限らず、ではあるのですが、AngularJSのディレクティブには適用範囲があります。
それは、そのディレクティブを定義したDOMの範囲とイコールです。

...
<body>
  <div ng-controller="myCtrl">
    myCtrl内: {{name}} <!-- ① -->
  </div>
  myCtrl外: {{name}} <!-- ② -->
<script>
angular.module('myApp', [])
  .controller('myCtrl', ['$scope', function($scope){
    $scope.name = 'can.i.do.web';
  }]);
</script>
</body>

①のようにng-controller="myCtrl"と定義したdivタグの内部のみ、初期化されたnameを表示（取り扱う）することができます。 ②はng-controller="myCtrl"が定義されているdivタグの外側にあるため、myCtrlで定義したnameにアクセスすることはできません。

このように、AngularJSではそれぞれの コントローラなどのディレクティブがお互いに干渉しないよう、適用される範囲のみでそれぞれの機能を果たします。そうすることで個々の機能が疎結合になり、保守性が高くなります。

Controller の分割

最初に挙げたサンプルのように画面全体に対して1つのControllerで運用していった場合、かなり多機能なコントローラになってしまいます。

例えば以下のケースだとどうなっているか見ていきましょう。

...
<body ng-controller="myCtrl">
  <header>
    ... <!-- header -->
  </header>
  <main>
    ... <!-- main -->
  </main>
  <footer>
    ... <!-- footer -->
  </footer>
<script>
angular.module('myApp', [])
  .controller('myCtrl', ['$scope', function($scope){
    // いろいろな機能のコード
  }]);
</script>

上記はbody全体に対してのみのコントローラとなっています。ヘッダやフッタに関しては、一般的なアプリケーションでは共通的な機能と言えるでしょう。

それに対して上記の場合は、画面ごとにヘッダやフッタのデータやイベント等の振る舞いを毎回記述しなくてはなりません。先述したとおり、保守性を高めるために、 コントローラを分割すると良いでしょう。

...
<body ng-controller="myCtrl">
  <header ng-controller="headerCtrl">
    ... <!-- header -->
  </header>
  <main ng-controller="mainCtrl">
    ... <!-- main -->
  </main>
  <footer ng-controller="footerCtrl">
    ... <!-- footer -->
  </footer>
<script>
angular.module('myApp', [])
  .controller('myCtrl', ['$scope', function($scope){
    // 画面全体に渡るコード
  }])
  .controller('headerCtrl', ['$scope', function($scope){
    // headerで必要な機能のコード
  }])
  .controller('mainCtrl', ['$scope', function($scope){
    // main で必要な機能のコード
  }])
  .controller('footerCtrl', ['$scope', function($scope){
    // footer で必要な機能のコード
  }]);
</script>

上記のようにコントローラを分割することで、機能の塊を小さくできます。headerCtrlやfooterCtrlを切り分けることによって、アプリケーション全体で共通的なヘッダ、フッタの機能として利用することもできます。

また、メインコンテンツ内も機能的に煩雑になっているようであれば、さらにコントローラを分割して運用していくとよいでしょう。

Scope

スコープはビューとコントローラの間に立って、モデルをビューにバインディングしたり、ビューから発生したイベントを受け取って何かしら振る舞う、といった役割を持ちます。$scopeはそれを実際に行なうためのオブジェクトです。

スコープはDOMツリーと同様ツリー構造になっていて、ng-appを基点にDOMツリーに沿うように構成されます。そしてng-controller と記述している箇所でng-appの子スコープとして新たなスコープが生成されています。Chrome DevToolsなどで該当するDOMを見てみると、ng-scopeというクラス名が自動的に付与されているため、これを元に確認することができます。

最初のサンプルの場合、ng-repeatでも新しくスコープを生成するため、expertListの<li>にも同じように付与されています。

“Controllerの適用範囲” で解説した内容はこのスコープのツリー構造と関わっています。

以下の例を見てみましょう。

...
<body ng-controller="myCtrl">
<p>①親スコープの'name' -> {{name}}</p>
<p>②親から見ようとした 'twitter' -> {{twitter}}</p>

  <div ng-controller="myChildCtrl">
    <p>③myChildCtrl の 'name' -> {{name}}</p>
    <p>④myChildCtrl の 'twitter' -> {{twitter}}</p>
  </div>

<script>
angular.module('myApp', [])
  .controller('myCtrl', ['$scope', function($scope){
    $scope.name = 'can.i.do.web';
  }])
  .controller('myChildCtrl', ['$scope', function($scope){
    $scope.twitter = 'きゃない';
  }]);
</script>

実行してみると、このように表示されます。

スコープはツリー上に構成されるため、スコープの親子関係が生まれます。
原則、子スコープから親スコープの値は参照できますが、その反対はできません。
親であるmyCtrlで定義された、nameというプロパティは、子であるmyChildCtrlのnameとして参照することができるため、表示されています。
反対に、親スコープから子スコープのプロパティを参照できないため、②では何も表示されていません。

子スコープが新たに生成されるタイミングは、コントローラを定義する（ng-controller）など、一部の（ビルトイン）ディレクティブ などを定義した場合です。
どのディレクティブ が新しくスコープを生成するかや、詳細な挙動については、AngularJS にかなり慣れている必要があります。
しかし、はじめから完璧に理解する必要は全くありません。スコープという概念があり有効範囲や親子関係がある、ということを頭の片隅においておくと良いでしょう。

Controller 間でデータ共有

親子コントローラ間でデータを共有するためには以下のように記述しましょう。

...
<body ng-controller="parentCtrl">

  <div>
    <p>親スコープ</p>
    <input type="text" ng-model="autor.name">
  </div>

  <div ng-controller="childCtrl">
    <p>子スコープ</p>
    <input type="text" ng-model="autor.name">
  </div>

<script>
angular.module('myApp', [])
  .controller('parentCtrl', ['$scope', function($scope){
    // 親スコープ
    var author = {};
    author.name = 'Kanai';
    // bind
    $scope.autor = author;
  }])
  .controller('childCtrl', ['$scope', function($scope){
    // 子スコープ
  }]);
</script>

これまでのサンプルとの違いは、$scope.autor.nameのように、直接$scope.nameとしていない点です。
このように$scopeとバインドしたいプロパティとの間に、オブジェクトを挟むことで、親子間でデータを共有することができます。

こうすることで、親子スコープのどちらのinputでも、片方の入力値を書き換えれば、もう一方のデータも書き変わります。
先述してきたサンプルの場合は、JavaScriptのプロトタイプチェーンの都合上、親子関係が破綻してしまいます。そのため、値を書き換えても相互にデータの書き換えを行なうことができません。
データの書き換えや参照が思ったようにうまくいかない場合は、このことを覚えておくとよいかもしれません。

まとめ

今回は、ControllerとScopeの基礎を解説しました。
特にスコープについては複雑な概念や実装になっていますので、いきなり全てを把握することは難しいです。AngularJS の経験を積むとともに徐々に学んでいきましょう。
次回はサービスについての解説を予定しています。

特集企画「アプリケーションアーキテクチャ最前線」では、さまざまな視点からアプリケーションアーキテクチャをエキスパートたちに語っていただきます。今回は、今話題のAngularJSなどのJavaScript MVCフレームワークの台頭と進化、そして新しいアーキテクチャであるFluxとそのフレームワークであるReactなどについて、既に先行して学んでいるエキスパートたちにその知見を聞いてみました。

今回はフレームワーク対決ということで、エキスパートたちがAngularとReactという陣営に分かれ、それぞれのフレームワークについて疑問点をぶつけたり、議論したりする仮想パネルディスカッションという形式でお伝えします。単なるパネルディスカッションとは違って、キーワードは「プロレス」です。まさかりの投げ合い、disり合いOKという形で、NGワードは「適材適所」「ケースバイケース」などです。白熱した議論をお楽しみください！

　　▲議論が白熱する選手たち。左から、久保田光則さん、金井健一さん、増井雄一郎さん、小林徹さん

選手入場（自己紹介）

白石：さて、それではプロレスを始めていきましょうか（笑）。まずは、皆さんの簡単なプロフィールと一押しのフレームワークなどを教えてください。

（React陣営）
小林：小林徹（@koba04）と申します。前職でソーシャルゲームを作っていました。そのときはBackboneとかAngularとかを使っていて、今はReact.jsに興味があって、業務でも使っていこうかと思っています。　　　　　　　　

　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　
増井：増井雄一郎（@masuidrive）です。一押しのフレームワークは、ReactとFluxなんですが、ReactはViewのライブラリなので、Fluxになるのかなと。複雑なことをやるのは嫌いなので、なるべくシンプルに書けるということでReactとFluxの組み合わせは気に入っています。あとは自由度が高いという点も気に入っています。

（Angular陣営）
金井：金井健一と申します。フリーランスで、AngularJS Japanユーザーグループの管理人をしています。一押しはAngularですね。Angularは何がいいかというと、フルスタックなところで、悪い面もありますが良い面のほうが多いんじゃないかと思います。学習コストが高いというのもよく言われますが、それだけ機能が多岐に渡っているということなので、いったん使いこなせればすごくいいフレームワークだと思います。

久保田：久保田光則と申します。アシアルという会社でエンジニアをやっています。会社ではOnsenUIというフレームワークを作っています。3年か4年くらい前からずっとJSとかフロントエンドばっかりやってきていて、ちょっと前はKnockoutJSがいいなと思っていたんですけど、気がついたらずっとAngularJSばっかり書いていました（笑）。Angular2は野心的な方針で、いろんなものを取り込んで最高のものにしていこうという気概が感じられるので注目していかないとなと思っています。

お互いのフレームワークへの疑問点など

白石：このパネルディスカッションの今後の流れとしては、僕のほうからは何かコントロールするということはないので、レフェリーみたいなものだと思ってください（笑）。自由にやっていただければと思います。それでは、今回の本題ということで、お互いのフレームワークについて疑問点だったり、disったりということをお願いします。

小林：Angularは、1.04ぐらいのときに使っていて、実際にプロダクトに使ったんですが、結構情報がなくて辛かった思い出があります。DirectiveってよくわからないのでシンプルにControllerとかScopeとかで頑張ってやったという印象がありますね。

金井：当時は、結構そうかも。ただ今は、ドキュメントも充実してきているので今はさほど辛くはないかなと思いますね。Reactはルーティングとかバインディングとかその辺はどこまでできるんですか？

増井：React自体はほんとにViewだけなので、まったくそこはケアしないですね。Fluxは考え方なので、実はすごい小さいんですよ。Dispatcherだけなので数百行ぐらいしかない。あとそこにどうやってルーティングをやるかというのは、React Routerとか外部のコンポーネントを組み合わせて使うので、標準では持っていないです。そこは大きく違いところだと思います。

僕はAngular使っていないんですが、会社（トレタ）のほうでは、PC向けの機能は全部Angularで作ってるんです。でもそこの中の人に聞くと、CRUDみたいなよくあるアプリケーションは結構楽にできて、Angularがなかったら短期間では作れなかったと思うと言われました。ただ、そういうパターンからはずれてしまうとすごい書きにくいかもしれなくて、拡張していくとき、パターンが複雑化してきたときに本当に耐えうるのかが不安と聞きました。そういう傾向ってどうなんですかね？

久保田：何もかもScopeとかで管理しようとすると結構はまりどころ多いなというイメージがありますね。細かいインタラクションとか、例えばドラッグ＆ドロップを直接使いたいときって、結局DOMを触るしかなくて、DOM触るにはDirectiveっていうものが用意されています。Directiveは、ある程度DOMに対してのいろんな機能を追加するとか、細かいDOMの操作を担当するものなんですよ。全部Controllerで管理しようとするとすごいぐちゃぐちゃになったりするんですけど、ちゃんと自分でDirectiveを作って管理すると扱いやすいと思います。

増井：なるほど。あと、Angular1系と2系ってはたから見てると、2系が年末だか来年だかに出て、結構互換性がないっていう話で、1系は捨てちゃうっていうことを聞いてそこはちょっと怖いかなっていう印象はありますね。

金井：2系が主流になって、1系が減ってこない限りはサポートするという話ですね。なので、そこは早いうちにアップデートしないといけないかもしれません。

増井：でもアップデートってまるまる書き直しなんですよね？

久保田：ng-japanでもアナウンスされてましたが、Angular2とAngular1を共存する方法はあって、1系のコードと2系のコードを混在させることができるようですね。

今からフレームワークを採用するとしたらどちらを使う？

増井：今から新しくプロジェクト始めるときにどのフレームワークで作ろうかみたいなときに、実際に作る人は悩むんですかね。

白石：実際、今作ろうと思っているものがあるんですが、悩みますね。

金井：なんでそこはAngularじゃないんですか（笑）。

白石：Angularはでかくて複雑すぎて怖いんですよね。しかもAngular2が迫っているという。この今のタイミングで採用するのはちょっと怖い。

増井：そういう意味では、僕はReact.jsがなくなっても、React.jsと同じものを書ける自信があるんですよ。FluxとReact.jsをまるっとFacebookがやめました、明日からReactはありませんと言われたときに、僕はReact全体をメンテナンスできる。まるっと同じものを作れっていわれたら、まあ頑張って作れる。Angularは作れる気がしない。

金井：作れる気はしないですね（笑）。

増井：僕は結構そこが怖くて。なので、大きいフレームワークは採用しにくいっていう面があります。あと、MVCの上にMVCを乗っけるというのは、その考え方はすごくToo Muchかなと。サーバーサイドは、サーバーサイドでMVCを作っていて、さらにクライアントサイドでMVCを作るわけじゃないですか。MVCの2階建てはアーキテクチャとして本当にいいのかっていうのはすごく思っていますね。

そもそもモデルをデータベースから作って、ちゃんとAPIにしているはずなのに、それをさらにもう一回モデルとして扱う、あんまり効率的じゃないんじゃないかっていう。Reactだけに限ると、MVCのVしかないので、そもそも書いて読んだJSONをそのままViewで表示するってことをやったりするんです。だけど、実はAPIが揃ってると結構なWebアプリケーションで、そもそもモデルまでおこさなくてもいいんじゃないかっていう気がするんですよ。

金井：JSONをとってきて出すっていうのはAngularでもできるので、それはアプリの設計によるのかなという気がしています。Angularの場合は、さらにそこから変更もできるという利点があります。

増井：それにしてはToo Muchすぎるんじゃないかと。

金井：それだけしたい場合には確かにそうですね。

増井：結構なケースがそれで済むんじゃないかっていう気はしていて。実はクライアント側でMVCが必要なほど複雑な処理するケースってそんなに多いのかなと。

久保田：まあでも実際には、もちろんアプリの要件によると思います。ハイブリッドアプリって結局JSでなんでもやるので、API叩けばそれで終わりというわけじゃなくて、むしろJSのほうでいろんなことを書かなきゃいけないって感じになるので、API叩けばそれで終わりっていう感じにはならないですよね。

APIってネットワーク越しにやるんでそれってすごく重たいし、あんまりやりたくないっていうのはモバイルアプリだと多いです。そもそもモバイルアプリだとネットワーク繋がらないってこともあるので、それを解決するにはローカルのほうでデータを保持して、繋がったら同期をとるっていう感じになるので、モデルがないとちょっと辛いという感じになりますね。

JSXは気持ち悪い？

白石：JSXがキモいんですけど…。

増井：あれは気持ち悪いんですよ実際（笑）。キモいっていうのはまったく異論ないんですけど、あれはあれで理にかなっていると思っています。DOM操作がなんで難しいかっていうとそもそもこのDOMをみたときに、これがいつどこで書き換わるかわからないし、さらにこのボタンを押したときにどこで何が起こるかわからない、イベントは1個じゃなくて100個でも張れるので。っていうのに対してJSXの場合はそういうのを一応ビューとロジックを同じところに書くことで、さらにイベントリスナーを1対1にすることによって、そういう複雑性を省きましょうという考え方なので、気持ち悪いことは認めつつ、理にはかなっているかなと。

1番の問題は、HTMLしか書けない人がこれを触れないっていう。コーダーと分離ができないっていう点ですよね。ただこれはもっと根本的な問題で、Reactは画面の一部をコンポーネントとしてスコープを作りましょうっていう考え方で、HTMLを切ってるんじゃなくて、プログラミングスコープを切ってるんですよ。それって見た目のデザインとはちょっと違って、アーキテクチャのデザインの話なので、見た目とロジックを切り離すっていうところに、そもそも無理があるじゃないかっていうことですね。

金井：そこらへん（画面の一部をコンポーネントとしてスコープを作る）は、Angularも目指すところは同じかもしれないですね。

増井：そのやり方が違うってだけなんでしょうね。

久保田：ちょっといいですか。別にJSXって気持ち悪くなくないですか。

小林：私も全然違和感ない（笑）。

白石：人によるんだ。

増井：僕も去年からReactを知ってたのに触ってなかったのは、JSXです（笑）。あれで毛嫌いして触らなくて、でもあんまり話題になってるので去年の年末年始から本格的に触ってみたというのがあります。あれは僕個人も気持ち悪いです（笑）。

小林：ぱっと見たときに、あれ（JSX）がやりたいフレームワークなのかなと思っちゃうんですよね。

増井：日本でのReactの評価は、Virtual DOMっていう技術キーワードとJSXという見た目にすごく左右されている印象がありますね。

Virtual DOMって本当に早いんですか？

白石：Virtual DOMって本当にそんなに早かったりするんですか。ぱっと考えると差分をComputeとする計算処理も必要だし、フロントのDOMと仮想DOMって2つ持っているメモリも喰いそうだなと思うんですけど、実際はどうなんですか？

小林：実際は何が一番早いかっていうのはやっぱりDOMを直接触るのが一番早いっていうのは間違いなくて、でもそれってコードとしても複雑になるじゃないですか。モデルのデータの変更された部分だけをどういう風に反映するのかっていうところが煩雑になる。Virtual DOMだと、ひとつの状態をもっておいて、パっと更新すると差分だけを綺麗に反映してくれるので、DOMを直接触るよりは遅いですが、該当部分のDOMを全部入れ替えるよりは早いという感じです。最速ではない。

白石：最速ではないと。わりとプログラマーがいい加減な処理をしてもいいってことですね。

増井：Reactはとりあえずざっくり書けば、そこそこ速いっていうような考えですね。

久保田：最近、Atomで内部でReact使ってたけどパフォーマンスのために削除したっていう話がありましたね。

白石：え、そうなんですか。もう使わなくなっちゃったんだ。

小林：最初のやつがちゃんと構造化されていなくて遅かったのをReactにして、ちょっと速くなって。そこをベースにDOM職人が頑張ってやったらさらに早くなったっていう感じですね。

Angularは謎のルールが多い

白石：Angularを触ったり調べたりしたときに僕的には謎のルールがすごい多くてとっつきにくかった。例えば、$変数が多すぎ。何々のときは$なんとかが多くて、なんだこれはっていう（笑）。

金井：あれ何なんでしょうね。$$とかあるしね（笑）。

白石：Dependency Injectionを実装したのはいいんだけど、まず引数の名前で当てるからminifyしないでねとか、minifyしてもいいように別の書き方も発明したよとか配列で指定できるようになったりとか。なんかもう歴史上の問題かもしれないんですけど、謎ルールが多すぎる感があるんですけど。そこらへんはどうなんでしょう？

久保田：やっぱりそこは気持ち悪いなと思います。でも昔からずっと実務上の必要からそういうのが増えてきたのかなと思いますね。あとから来た方がどうしたもの洗練されたものになっていくので…。

増井：Angularっていつできたんでしたっけ？

金井：結構前で、2009年ですね。

増井：そんなに前なんだ！

金井：Angular1が2012年ぐらいなので、そこで注目された感じですね。2009年にできたフレームワークが5年くらい経って実用になりつつも、辛くなってきたということでAngular2を開発しているということだと思います。Angularのいいところっていうのは、その時々で結構先のことを見据えてやろうとしていて、1系だとWeb Componentsを実装したくてDirective作ったりしてるし、Object.observe()欲しいよねっていって2way bindingを実装してみたりとか。どんどん攻めてるんですよね。

増井：そういうイメージはありますね。

実はReactは大きい

白石：ちなみにフレームワークの大きさでいうとどうなんでしょう。

増井：ReactってViewのライブラリだけのくせにすごいでかいんですよ。へたしたらjQueryよりでかい。

金井：フレームワークのサイズが大きいと、モバイルのユースケースで叩かれませんか、重いとか。Angularは相当叩かれた覚えがあります（笑）。

増井：とはいっても画像ひとつ分ぐらいですからね。Reactも実際よくあるReactのダメなところに「でかい」っていうのはいろいろ言われていて、でも現実ユーザーからそういう話があがってるわけではなく、数字で見てっていう部分があります。あと、Reactはサーバーサイドレンダリングを持っているので、ファーストビューはサーバーサイドで出しちゃって、その後にJS読み込むっていうことができるので、そういう意味では十分早いですね。面倒くさいですけど、やろうと思えばできます。

白石：今、ダウンロードしてみたんですけど、Angularがminify時で126KBで、Reactが121KBという結果に。

増井：しかも、AngularはMVCで、ReactはVだけで、ですからね（笑）。

金井：やれること全然違う。（Angularは）ルーティングからバインディングからすべてできるのに（笑）。

検索可能にするサーバーサイドレンダリング

増井：Reactのひとついいところは、サーバーサイド生成ができるのでぐぐったときに引っかかるんですよね。クローラーは基本的にはJSを実行しないので、みんなテンプレートにはじめから引っかかりそうなキーワードを入れたりとかして頑張るんですけど。でもReactはサーバーサイド（Node.js）でReactエンジンを実行してHTMLを生成することができるんですよ。そうすると例えば、基本的な部分をファーストビューで表示すると、JSが実行されなくてもHTMLで画面が見えて、JSが実行されると残りの部分が表示されるという段階的にできるですよ。

そうすれば、検索エンジンに引っかかるし、JSがもし（ブラウザで）動作しなくても本文はちゃんと読めるというメリットがあります。といってもそれをやるには、それなりに考えて書かなきゃならなきゃいけなかったり、その実行エンジンをいろいろセットアップしなきゃいけないので、手放しでできるっていうわけでもないんですが。

小林：海外はやっぱりReact導入してるところは、サーバーサイドレンダリングもやっているところが多いですね。海外のほうがサーバーにNode.jsを使うのは結構一般的で、日本だとあんまりないから意外なんですけど。サーバーサイドレンダリングできるからReact採用してるっていうとこも結構ありますね。BBCとか。

増井：ぐぐれるっていうのはでかいですからね。

白石：なるほど。じゃあAngularのほうは、どうですか？

久保田：まあAngular2に期待ですね。Angular2のレンダリングのアーキテクチャについて設計文書が公開されていて、その中でVirtual DOMを使いますと言っています。

小林：Ember.jsも次のバージョンでHTMLbarsとsimple-domを組み合わせてサーバーサイドレンダリングできるようになる予定で、これからのフレームワークはサーバーサイドレンダリングはついてきそうな気がしますね。

久保田：あと、ちょっと面白いと思ったのがサーバーサイドレンダリングだけでなく、Viewの処理をWeb Workerでやりたいっていう点ですね。

増井：Web WorkerはReactでもやるっていってますね。そんなに進んでないですが。

白石：確かに仮想DOMは、本物のDOMじゃないからWorkerでいじれるし、間のメッセージングにコストがかからなければ割と早そうですね。

増井：そこ（Reactの仮想DOM）の差分の計算までWorkerでやってしまうので、それなりの速度がでるはずですね。ChromeもServiceWorkerとか機能を強化してるのでたぶんそういうのに合わせてるんだろうなと思います。

開発速度・生産性の比較

小林：たぶんReact使っても開発速度って上がらない。書く量も結構増えますね。

増井：むしろ下がります（笑）。プログラムでひとつ大事なところは、1年後に触れるかどうかだと思っていて、よくプログラムは書くより読む時間、回数のほうが多いので読むことを考えて書くべきだって言う考えがありますよね。時間がかかっても読みやすく書いて、それによってコード量が増えるのはプログラムとしてしょうがないんじゃないかっていう考えがあって、Reactはそういう考えに近いですね。なので記述量は減らないし、同じの書いたら5〜10倍ぐらいになっちゃっていう話もあって、あきらかにめんどくさいです。

金井：AngularJSは、預ける部分が大きいので、勝手にやってくれる。コード量は圧倒的に減りますね。なのでCRUD系作るときはすごく早いです。

おわりに

このように議論はすごく白熱して、興味深いトピックスが目白押しでした。楽しんでいただけましたでしょうか。今回は「議論は平行線だった」ということで終わりたいと思います。

おはようございます。編集長の白石です。

昨日（2015年4月30日）、isomorphic tokyo meetupに参加してきました。

というのも実は近々、HTML5 Experts.jpでは「Webアプリケーション・アーキテクチャ」に関する特集を行う予定なのですが、そこでキーワードとして挙げられていたのがisomorphic。 サーバサイドとクライアントサイドでコードの共有を促進するのが主な目的の一つ、というところまでは理解できたのですが、実際のところ、アーキテクチャはどう変わるのか？ それを探りたいと思っていたところ、ちょうどよくイベントの開催がアナウンスされていたので、急遽取材させていただきました。

取材を快く受け入れてくださった、主催のYosuke FURUKAWAさん、本当にありがとうございました。

この記事では、トップバッターで講演されていたkoichikさんの講演内容を中心にご紹介して、isomorphicに触れるきっかけとなる記事を目指します。

なお、本日の講演者の皆様による資料はこちらになります。

isomorphic tokyo meetupの発表資料

「Isomorphic Survival Guide」(by koichik)

Isomorphic Survival Guide

「Isomorphic Web development with Scala & Scala.js」(by TanUkkii)

Isomorphic web development with scala and scala.js

「実践isomorphic (+ Electron)」(by mizchi)

実践Isomorphic(+ Electron)

「Unified Interface on Isomorphic JavaScript」 (by axross)

Unified Interface on Isomorphic Javascript

「やみくも isomorphic から抜け出すために足りてないもの」 (by Jxck_)

※資料は後日公開だそうです。

今日のスライドがちょっと片手間すぎるので、公開はいろいろ直してからにします。 #isomorphic_meetup

— Jxck (@Jxck_) 2015, 4月 30

koichikさんによる「Isomorphic Survival Guide」つまみ食いレポート

koichikさんの「Isomorphic Survival Guide」は、まずIsomorphicという言葉の語源からでした。ギリシャ語で「同じ」という意味を表す「isos」という言葉と、「形」という意味を表す「morphe」という言葉を合わせたものだそうです。

isomorphicの語源

同じ成り立ちの言葉として、「metamorphic」や「polymorphic」があるとのこと。オブジェクト指向の世界で頻繁に用いられる「ポリモーフィック」という言葉が、isomorphicと同様「-morphic」で終わる単語だと気づいたのはこの時が初めてで、ハッとしました。

“-morphic”で終わる言葉はほかにも

で、isomorphicが語られるときには、「クライアントとサーバの間でのコード共有」や「フロントエンドとバックエンドの間でのコード共有」と紹介されることが多いですが、そもそもクライアントとフロントエンド、サーバとバックエンドが同じ意味の単語なのか、そこには人による解釈の違いもあれば、指している意味合いの違いもある、と指摘。

クライアント・サーバという用語とフロントエンド・バックエンドという用語は同一ではない

この講演においては、クライアントとサーバはネットワークの「こちら側」と「あちら側」、フロントエンドとバックエンドは情報の入出力を「人間相手に行う」のか「ストレージ相手に行う」のか、という意味で取り扱う。

本講演における用語の定義

例えば90年ごろの「C/Sシステム」（いわゆる「クラサバ」）は、クライアントのWindowsマシン上で「人間向け」（フロントエンド）の処理も「ストレージ向け」（バックエンド）の処理も行われていました。このように、クライアント＝フロントエンド、サーバ＝バックエンドという対応関係は時代によって変遷してきており、J2EEが提唱した三層アーキテクチャやRIAなど、様々なアーキテクチャと製品が模索されてきました。

C/Sシステム

フロントエンドとバックエンドの変遷

isomorphicに挑戦してきた様々なフレームワーク

こうした中、少しでも開発から無駄をなくすために、クライアント／サーバ、フロントエンド／バックエンドの間でコードを共有できないかという可能性が探られてきました。

「isomorphic」という単語は、筆者としては最近になって聞くようになったのですが、実は2011年にリリースされた 「Flatiron」というフレームワークが提唱した概念だったそうです。4年近くも前から使われていた用語だったのですね。

Flatiron

しかし、Flatironはそれほど普及することなく現在に至ります。その後もYahoo!の「Mojito」や、一時期大きな話題になった（今でもアクティブに開発されていますが）Meteorなど、様々なプロダクトがisomorphicなアプローチにチャレンジしてきました。しかしこれらがあまり大きく普及しなかった要因は、「（プロダクト利用者にとっての）どんな課題を解くのか」が不明瞭だったり、ニッチ過ぎたり、先進的すぎたりしたことにあると指摘。

どんな課題を解くのかが重要

そんな中、Airbnbが2013年に公開した「Rendr」 は、SPA (Single Page Application)の「初期表示が遅い」「SEOが弱い」という課題を解決すべく生み出されたもので、 かなり実用的でした。

Rendr(Airbnb)

RendrはBackbone.jsを拡張してisomorphicな環境を実現するものでした。Rendrは、以下のように様々な可能性を切り開きました。

• サーバサイドにおけるフロントエンドレイヤをJavaScriptで提供することで、クライアントとサーバのコード共有を実現しやすい
• サーバサイドにおけるフロントエンドレイヤがセッション管理を行うことで、バックエンドのAPIをステートレスに保つことができる
• サーバサイドにおけるフロントエンドレイヤがAPIゲートウェイとしてデータ変換を行ったり、様々なバックエンドAPIを組み合わせて フロントエンドに提供する（オーケストレーション）ことを可能にする
• 上記のことから、（サーバサイドにおける）フロントエンドとバックエンドの疎結合な関係や、バックエンドの実装をJavaScript に縛られず自由に開発できるようになり、ステートレスなマイクロサービスが協調して一つのサービスを作り上げるという構成を構築しやすい

Rendr的なIsomorphicの可能性

Reactの波に乗れ！

ですが、Rendrがリリースされた時期はAngularJSが人気を獲得した時期と重なっており、残念ながら大きな話題にはなりませんでした…。しかし今、「仮想DOM」というキャッチーなキーワードを引っさげ、Reactが登場するや、非常な人気を博して今に至ります。

Reactの仮想DOM

しかしReactはあくまでビューだけに特化したライブラリ。アプリケーションアーキテクチャとしては、Facebookが 「Flux」を提唱していますが、公式な実装が提供されたのはFluxの一部分 のみであったため、独自実装が乱立する事態となっています。

Flux

Fluxを用いたアプリの基本的な構成は以下のようになります。 フロントエンド部分に限ってみると、処理の流れが綺麗に一方向（unidirectional）になっているのがわかります。

Flux的アプリの基本要素

そして何よりReactが期待されているのは、仮想DOMの仕組みを応用したisomorphicなアーキテクチャ。クライアントでは仮想DOMを実際のDOMツリーに変換しますが、サーバサイドでは仮想DOMからHTML文字列を出力するようにできるので、クライアントとサーバのどちらでも同様のコードが実行できるわけです。

Reactに関係するisomorphicなライブラリには、以下の様なものがあります。

Reactに関係した、Isomorphicなライブラリ

Flummoxも期待のライブラリ。

Flummox

Yahoo!が開発中のFluxibleは、比較的重量級なアプローチの、isomorphicなFluxアプリケーションコンテナ。

Fluxible

Fluxibleが使用する「Fetchr」は、バックエンド（の窓口となるWeb API）へのアクセスを、クライアントサイドとサーバサイドで同様のコードを用いることを実現します。正しくセットアップしていれば、Fluxアプリケーションのisomorphic化を促進できると期待されています。

Fetchr

まとめ

isomorphicなアーキテクチャは長い間模索されていましたが、これまでいまいち波に乗り切れていませんでした。しかし今はReactが非常に人気を博し、isomorphicなアーキテクチャの実現に対して、多くの人々が注力しています。

マイクロサービスとの相性も非常に良いと考えられ、今後大きな潮流になっていくのは間違いないでしょう。

まとめ

Reactの波に乗り遅れるな！

この記事は、Angularをテーマとした日本初のカンファレンス 「ng-japan」のイベントレポート（第6回目）です。ng-japan特集最後は懇親会でのQ&Aの模様をレポートします。

AngularカンファレンスQ&A

Q1. Angular 2を開発するに当たって、React.jsのアーキテクチャや考え方から影響を受けていますか？

一定の影響はありました。よく聞かれる質問としては「Virtual DOMについて」ですが、我々はこのVirtual DOMがパフォーマンスを上げるために必ずしも必要となるものではないと考えています。それよりも「unidirectional data flow」という考え方のほうが役に立つのではないかと考えています。

プレゼンテーションの中でも「Immutable Infrastructure」については触れましたが、これについてはReactのチームともディスカッションを始めているところ。この分野についてはReactチームとAngularチームのコラボで行っていけるのではないかと考えています。

Q2. GoogleのプロダクトでAngularはどのぐらい利用されていますか？

Googleプロダクトの約2,000のアプリケーションで、Angularを使っています。特にGoogleが提供するクラウドでは、ほとんどのUIがAngularで書かれています。AngularチームというのはGoogle内でもいろいろな組織が存在していますが、その中に広告のグループであるAdsのチームがあり、ここでもAngularが使われています。その他にもGoogle内部だけで使われるような、内部プロセス用のアプリケーションについてもAngularが利用されています。

すべてのアプリケーションがAngular 2に移行するとは考えていませんが、Angular 2を使った方が簡単ものもありAngular 2を使う価値があるものについては移行をします。

Q3. Angular 1系のサポートはいつまで行っていきますか？

一時期Angular 1のサポートはいつまでで、Angular 2はいつからといった区切りを設定する予定でした。例えば、Angular 1のサポートを2016年末で終わりますと言って、Angular 2が2016年末に出てきたら、まったく移行の期間がなくなります。プレゼンテーションでも様々なお話をしたようないろいろなシグナルを見て今開発をしている人は、自分の位置がどのあたりにいて、今後どうなるのかを把握する必要があります。そして移行期間が作れるように、段階的に終了していくというのが正しい方向ではないかと考えています。

そして、GoogleだけがAngularに投資を行っている企業ではなく、Googleの外にもコアなチームメンバーがいて、彼らは彼らでAngularの開発にあたっています。なので我々としてもサポートをしっかりしていくということが重要でありオープンソースにとっても重要だと考えています。とは言うもののAngular 2を魅力的なものにし、しかもマイグレーションし易いものにし、誰もがAngular 2に移行した利用したいといった素晴らしいものに創りあげたいと考えています。

Q4. Angular 2の新しい機能に対してServiceとかFilterとか変な名前を付けてないか確認したい

まだ名前の付け方が得意じゃないけど、なるべく混乱のないような名前をつけていきます。でも、もう既に新しいRouterに対して、「NewRouter」という名前を付けてしまってゴメンナサイ。

Q5. Angularで検討されている機能で「Component Helper」というのがあるようですが、Angular1.4でリリースされる予定はありますか？

他のコンポーネントとの兼ね合い、Angular 2の機能の一部をAngular1.4に入れていることもあり、もしかするとAngular1.5でリリースされるかもしれません。十分な時間をかけて検討していきたいと考えています。

このAPIというのはベストプラクティスとなっていくものです。「Component Helper」の仕様を一旦決めてしまうと後になって開発者が変えていくことは大変な労力が必要になるため、じっくり考える時間を設ける。「Component Helper」はAngular1.5に入れることを検討しています。

Q6. New RouterでControllerを指定するようになっていますが、Component Directiveのようなものを指定するようにはならないでしょうか？

我々がしようとしていることは、まさにそういったComponentを指定するということです。しかし、まだAngular 1系ではComponentを使うことはできない。いまはどうすれば、Angular 1とAngular 2とで整合性が保たれるか、Componentを導入できるかを検討しています。

Q7. Angular 2でEvent Emitterの仕組みは導入されますか？

Event Emitterの機能は、Angular 2ではありません。しかし、それに変わる別のやり方が提供されます。Angular 2では各パーツ間のコミュニケーションのやり方が変わっていきます。

その変わりに使えるものが2種類あります。

• DOM Event
• サードパティ・ライブラリ

この変更に対してどこにアドバンテージがあるのかというと、いろいろなケースを考えると今のAngularイベントを使っていった場合、さまざまなところでタイポが発生し、イベントの名前が間違ってしまうことがあります。するとイベント名が有効でなく一体何が起こったのが開発者がわからないという状況になりますので、問題を解決するために「Event Injection」を入れました。そうすることでダイレクトにイベントが伝わるようになります。

最後に（編集後記）

ng-japanの様子を余すことなく書き下ろしましたが、いかがだったでしょうか？

Angular1.4の内容やNewRouterの機能、Angular 2に関すること、Angular 1からAngular 2へのマイグレーションなど盛りだくさんの内容だったと思います。Angularはあまり大規模なアプリケーションを作るのには不適という話もありますが、Angularチームが目指すところは規模に関わらず作りやすく、よりメンテナンスビリティの良いフレームワークを目指しているのではないかと思います。

AngularはGoogle社の閉じた世界観で作られているのではなく、Google社外のコミッターとの連携やReactチームとのコラボレーションもあり健全なオープンソースの道を歩んでいるのではないかと考えてます。しかも我々がAngularと関わりたいと思えばGitHubでissueを書くこともpull requestも送ることもできます。より関わることで、Angularが我々開発者にとって良いものになるのではと思います。

そのための一歩としてまずは、Angularを「触ってみる」ということも重要だと思います。「AngularJS Japan User Group」では各地で初心者向けハンズオンや、中上級者向けのハッカソン、ナイトセミナーも実施しておりますので、機会がありましたら足を運んでいただけたら幸いです。

最後に多くの方に来場いただき、感謝するとともに、多くのスポンサー様にご協力いただききました。この場をお借りし御礼申し上げます。

セッション動画

当日のセッションはYouTubeで公開されています。是非ご覧ください！

この記事は、Angularをテーマとした日本初のカンファレンス 「ng-japan」のイベントレポート（第5回目）です。

はじめに

Angular 2の発表があり、大きく様変わりするのではないかと懸念され、話題にもなりました。そして、AtScriptからTypeScriptへの変更など、話題にことかかないAngular 2ですが、彼らがなぜ、そのような変更を行っているのかが理解できるセッションとなりました。

Angular 2 – Igor Minar

Angularは、私たち開発者のWebアプリ開発の手法を変え、生産性を向上してくれました。今度は我々のニーズに合わせて、Angularが変化をする番です。このセッションでは、何が変わり、なぜそのような変更が必要なのかをお話します。

まずは、Angular 2の3つのポイントについて。

• なぜAngular 2を作ることにしたのか
• Angular 2はどういうものにあるのか
• いつ出てくるか

なぜAngular 2を作ることにしたのか

5年前にAngular 1の開発を始めたわけですが、これはWebアプリケーションの生産制を上げるために始めました。自分だちだけで閉鎖的に作るのではなく、様々な人にも見てもらいので、オープンソースにしました。その結果、多くの人に気に入ってもらえたと思います。そして気に入ったということだけではなく、実際に使い、コントリビューションしてくれました。

実際、世の中にどのくらいAngularが使われているかはよくわかりませんが、類推できる統計値はいくつかあります。例えば、今回のカンファレンスがほぼ満席になっているということが挙げられますね。とても嬉しいことです。そして毎月100万の開発者が、Angularについて学ぼうとしサイトにやってきます。

Googleの外の世界で、Angularがどう使われているのか計り知ることは難しいですが、Googleの中ではヘビーに使っています。現在Googleの中では2,000のアプリケーションが構築されています。このような数字が何をもの語っているかというと、多くの人がAngularを信頼されているということです。しかし、信頼されているということは、責任が増すとも言えます。

5年間で徐々にAngularを育ててきた中で、次の段階ではもっとよりよいものにしたいと考え、Angular 2を作ることにしました。Angular 2がどういうものになるのかが気になるところだと思いますし、指針は重要かと思います。

Angularを、よりシンプルな一貫性のあるものにしたいと考えています。なぜそれが実現できたかというと、どう使われて、どう開発されてきたかわかっているので、どう最適化すればいいのかも見えてきたからです。そしてAngularを気にいっている人からは、とても柔軟性があるからと言われています。こうした柔軟性も、Angular 2に盛り込みたいと考えています。

私たちがAngular 1で経験できていなかった部分として、パフォーマンスが挙げられます。より大きなプロジェクトを行っているうちに、パフォーマンスが重要であることに気づきました。そして、最後の要素が生産性の向上になりますが、Angular 2でも生産性の向上を行っていきます。

Angular 1とAngular 2は似たようなものにあるか？

APIとシンタックスは異なる部分は多くありますが、Angularの中に入れば基本的な概念は似たようなものが多くあります。Angular 1で好んで使ってくれたData Bindingなどは、Angular 2でも利用することができます。

Angular 2は、より使い勝手がよくシンプルにし、よりパワフルにしました。そして新しい強力な機能を追加しました。

• Viewports
• New languages
• Web Components
• New template syntax
• Unidirectional data flow
• Ultra-fast change detection

Productivity

Angular 2の中で盛り込んでいくテーマについてもいくつかありますが、その中で2つ話をします。

• 生産性向上
• パフォーマンス向上

Angular 2においては、Angular 1のさらにその先をいくことを考え、それがtoolsを活用することができるということです。いま提案された、開発が終わってない、ブラウザでも実装されていないものに対しても、コードを書くことができるということです。そして開発者にとって役に立つこととして、タイプミスを防ぐことをしています。この新しいテンプレートシステムによってエラーやタイプミスがないかを抽出することができます。TypeScriptのチームとパートナーシップを組むことでそれを進めることができました。

TypeScriptを利用する重要なことの一つは、ECMAScript 6でも使うことができるようになることです。つまりTypeScriptをオプションとして、使うことができます。異なるチームに分散した大きなプロジェクトのときに、コントラクトを表すことができます。

もう一つTypeScript 1.5に含まれることにアノテーションがあります。アノテーションのお陰でコードを書く量を減らすことができます。これらの機能を標準化しJavaScriptに入れていくことを考えています。ChromeのV8チームやTypeScriptのチーム、その他のチームと連携しています。

将来的にはこれら機能がJavaScriptの中に含まれていくと思います。そういうことになると将来的には変換ということが必要ではなくなります。もちろんこれらは長く時間がかかるものですが、時間をかけてやっていくことには意義があると思います。

Angular 2はTypeScriptが使われていますが、一般の開発者がTypeScriptを使わないといけないのかという疑問があるかと思います。答えとしては自由に選択することができます。みなさんが自由にどの言語を使って、Angularアプリケーションを書くか、ECMAScript 5やECMAScript 6などどれを使ってもいいです。ただこうしたアプリケーションのツールを使いたいときは、TypeScriptを使うのがよいと思います。

標準化

言語の拡張と標準の話をしてきました。しかし、このAngular 2の大きなテーマとしては、標準化が好きだということがあります。Angular 1を作り始めた頃は、まだ使えないようなAPIを持ってきて、Angular 2の中に盛り込みました。よい例としては、Shadow DOM、Templateエレメントなどを使っています。

パフォーマンス

Angular 1.3のときに、パフォーマンスの改善を試みたというのがわかると思います。パフォーマンスを語るときに、難しいのは速いというのはどういうことなのかという定義です。この答えとして、ツールを作りました。パフォーマンスを信頼性の高いものにするためBenchmarksというのを作りました。

一連のベンチマークテストとして、世の中でやっているいろいろなベンチマークを行いました。その一つがDeep Treeです。Deep Treeでは深く複雑にネスティングしているものをベンチマークすることができます。結果的にAngularでは複雑な画面に対して、どのくらいパフォーマンスがあるのかを知ることができます。

Angularが速いのか遅いのかを知るために、ベースマークを作りました。それにはJavaScriptをAngularを使わずに作り、様々な工夫してベースマークを作りました。ポイントは、とにかく速く走るというプログラムなので通常書くようなロジックではありません。同じベンチマークでAnguler 1を作りました。

このベンチマークでは、ベースラインと比べると8倍時間がかかります。しかし、他に出ているソリューションとでは、ほとんど変わらないものになっています。もっと改善できるというはずだということで、Angular 2で試した結果としては3倍時間になりました、もっと速くすることができると考え、結果としては改善することができました。

Angualar 2の中にはView Cacheがあり、DOMエレメントを再利用することができ、この機能を使うことでパフォーマンスを上げていくことができます。

特にナビゲーションの中で2つのViewを行ったり来たりする場合、高い効果がありました。もちろんパフォーマンスについて注目しましたが、ガベージコレクションも気になるところです。

アプリケーションの様々な操作によってメモリーに関する事象が異なりますが、モバイル・アプリケーションのようなメモリーに制限のあるものについてはいろいろと効果することがあります。パフォーマンスというのは速度だけが重要なのではなく様々な要素で出てきます。一つパフォーマンスの中で注目しているのが、変更検知を取り入れた時に、どのくらい影響があるのかに興味がありました。

幸いなことに、Angular 2では柔軟な変更検知ができます。変更不可能なデータ構造がエキサイティングなのはなぜかというと、絶対に変わることがないとわかっていますので、変更検知の中で活用していくことになります。いくつかのシナリをの中で、使っていくことができます。バーチャルスクローリングが、それにあたります。

Angular 1の場合には変更検知を行っていくための時間というのは、データのサイズに比例して増えていきました。Angular 2の場合には改善されほとんど気にする必要のないくらいの速度になります。

Angular 2

Angular 2がどういうものかご紹介します

いつAngular 2が使えるか

いまAngular 2はアルファバージョンになっていますので、大きな変更はあります。なぜ、安定してないものを紹介しているかというと、我々がどのようなな開発をしているかを示したいからです。オープンソースにし、Angular 2の初期の段階で、様々なフィードバックを受けたいという想いから公開しています。

すべてのコードはgithubに公開していますので、issueやコメントを入れてください。どういうアイデアがこれまでインプリされているかは、ドキュメントを見ていただきたいと思います。

2月にアルファを出したが、3月に行われたng-confでAngular 2のデモを行い、多くの反響をいただきました。正確にいつリリースされるか、日付は発表されてはいませんが、Googleのあるチームは5月には使いはじめ、マイグレーションを行っていきます。そして、このGoogle内部のチームからのフィードバック、コミュニティからのフィードバックでロードマップが決まってきます。

Angular 1を使う人は、angularjs.orgのサイトも使っていると思いますが、Angular 2に特化したサイトも立ち上げました。多くのAngular 2のドキュメントは、angular.ioに掲載されます。

では、Angular 1はどうなるかというと、多くの方がAngular 1を使っていると思いますので、ほとんどの方がAngular 2に移行したというまでは、Angular 1をサポートし残しておく方針です。より移行が簡単になるようAngular 2を開発していく予定です。そのマイグレーションが進む中で1.5や1.6を出していきます。

数週間前のng-confでのビデオがありますので、見ていただけたらと思います。

プレゼンテーション資料

今回取り上げたプレゼンテーションの資料は以下のとおり公開されています。合わせてご覧ください。

セッション動画

当日のセッションはyoutubeで公開されています。逐次通訳付きなので、是非ご覧ください！

この記事は、Angularをテーマとした日本初のカンファレンス 「ng-japan」のイベントレポート（第4回目）です。

はじめに

昨年秋に、Angular 2はAtScriptというaltJSで開発するといったアナウンスがありました。しかし、今年3/5に急遽、Angular 2はTypeScriptで開発するという変更がなされました。このニュースはGoogle社とMicrosoft社が手を結んだということでも大きなニュースになり、今年一番の出来事かもしれません。

そのTypeScriptとカレントバージョンであるAngular 1.3を利用した開発ポイントを、株式会社トップゲートのエンジニアであり、TypeScriptマスターでもある@vvakame氏に講演していただきました。

TypeScript+Angular 1.3 – vvakame

AtScriptからTypeScriptに移行される旨がアナウンスされたため、TypeScript自体の話を少しと、現行のAngular 1.3とTypeScriptを組み合わせて開発する方法についてお話します。

「AtScriptの近況と将来」の話をしようと思いましたが、3月頭に必要なくなったようなのでタイトルを変えました。「TypeScript+Angular 1.3」というタイトルでお話させていただきます。

Angularを取り巻く開発言語

ECMAScriptとは

ECMAScriptに関して整理します。

• JavaScriptの元となる仕様のこと
• DOMの仕様は入っていない
• 最近のブラウザはECMAScript 5をサポート
• そろそろ6の仕様が確定（現在RC2

AtScriptとは

AtScriptとは何だったのかを振り返ってみます。

• AtScript=ES6+A (A=Annotiosion, AnnotationはES6に含まれない)
• Super set of TypeScript

AngularチームがAngular 2を開発するために策定したTypeScriptより、優れているaltJSということでした。

TypeScriptとは

では、TypeScriptの特徴はどういうものかを整理します。

• TypeScriptはJavaScriptを拡張した言語
• 静的型付け
• ECMAScript6規格の文法を取り込み中
• 読みやすい変換後JavaScript
• Java, C#とかにやさしい言語仕様

TypeScriptは、Microsoftが出してきたということで当時注目されました。特徴の一つである静的型付けの特徴をまとめます。

• 静的解析で多くの整合性検証が可能
• 不整合があった場合、コンパイルエラー
• 大規模、大人数になるほど有利
• Java, C#が有名

通常のJavaScriptでは、バグに関して実際に動かしてみて初めて分かりますが、TypeScriptのような静的型付けを用いると、静的解析でより多くの整合性検査が可能です。なるべくコンパイルした段階で、エラーが出力されるところが良い点の一つです。

例えば次の文はエラーになります。

var foo: number="bar";

TypeScriptは、ECMAScript 6のスーパーセットになると考えられています。既存の資産を活用したいという要望も当然あります。そうした要望を満たすため、TypeScriptに様々なJavaScriptライブラリの型を定義した型情報を用意する必要があります。例えば、次のようなものがあります。

• jQuery
• Angular
• mocha
• etc

DefinitelyTyped

型定義ファイルというものがあります。現在は1,000個以上あります。既存JavaScriptに型を後付けというのはわかりづらいとは思います。

Angularの例を見てみます。

declare var angular: angular.IAngularStatic;

// Type definitions for Angular JS 1.3+
// Project: http://angularjs.org/
// Definitions by: Diego Vilar 
// Definitions: https://github.com/borisyankov/DefinitelyTyped


/// 

declare var angular: angular.IAngularStatic;

// Support for painless dependency injection
interface Function {
    $inject?: string[];
}

// Collapse angular into ng
import ng = angular;
// Support AMD require
declare module 'angular' {
    export = angular;
}

///////////////////////////////////////////////////////////////////////////////
// ng module (angular.js)
///////////////////////////////////////////////////////////////////////////////
declare module angular {

    // not directly implemented, but ensures that constructed class implements $get
    interface IServiceProviderClass {
        new (...args: any[]): IServiceProvider;
    }

    interface IServiceProviderFactory {
        (...args: any[]): IServiceProvider;
    }

    // All service providers extend this interface
    interface IServiceProvider {
        $get: any;
    }

実際にこれを使ってコードを見てみます。JavaScriptとあまり変わりがないので読みやすいのではないかと思います。

module App {
	"use strict";

	angular.module(
		"app",
		["ngRoute", "app.hello"],
		($routeProvider: ng.route.IRouteProvider, $locationProvider: ngILocationProvider)=> {
			$routeProvider
				.when("/sample", {
					templateUrl: "/template/sample.html"
				})
				.otherwise({
					templateUrl: "/template/main.html"
				});
			$locationProvider.html5Mode(true);
		}
	)
		.run(($rootScope: ngIRootScopeService, $routeParams: ng.route.IRouteParamsService)=> {
			false;
		})
	;

	angular.module(
		"app.hello",
		[],
		()=> {
			false;
		}
	)
		.service("sampleService", Service.SampleService)
		.controller("SampleTestController", Sample.TestController)
	;

Angular 2とTypeScript

2015年3月5日に、Angular 2はTypeScriptで作ることになるという記事が出てきました。AtScriptからTypeScriptに変えた理由がいくつかあり、AngularチームとTypeScriptチームの調整がうまくいったのではないかと考えられます。

• TypeScriptに必要な機能が入る
• Angularチームが作りたいのは、AtScriptではなくAngular本体である
• TypeScriptのスーパーセットを作るのが困難

TypeScriptのスーパーセットを作るという話でしたが、TypeScript自体の開発スピードがかなり早く、しかもその間にECMAScript 6の仕様も出て、短期間の内にAtScriptを開発するためには、人的にもコスト的にも難しい状況だと考えられます。

話をまとめると、Angularを使うという観点からも、今からTypeScriptを使う必要があると言えます。

TypeScriptのSyntax

TypeScriptの独自Syntaxはあまりなく、JavaScriptとそれほど変わるものではありません。TypeScriptですが、だいたい2日もあれば書けるようになると思われます。

Type Annotations

Type Annotationsを具体的に見てみます。

var str1:string = "string";
var str2:number = "string"; // エラー
var str3 = "string"; // 初期化子から型推論されstringを指定したのと等価
str3 = 1; //エラー

var b: boolean = true;
var n: number = 1;

var a: any = true;
a = 1; // anyは何でもOK

Classes

ECMAScript 6からは、クラスの宣言ができるようになりました。TypeScriptの例を見てみます。

class Hoge {
	name: string;
	
	constructor(name: string) {
		this.name = name;
	}
	
	hello(): string{
		return "Hello, " + this.name;
	}
}

var obj = new Hoge("world");
window.alert(obj.hello());

Interface

TypeScriptで定義したInterfaceは、実行時には消えてしまいます。型だけの定義です。

interface Hoge {
	str: string;
	num: number;
}

var obj: Hoge = {
	str: "string",
	num: 1
};

window.alert(obj.str + obj.num);
window.alert(obj.hello());

Allow Functions

Allow Functionsは、最近話題になっています。メリットとしては、functionというキーワードが必要なくなるところです。これはECMAScript 6でも標準化されますので、TypeScriptを通して今のうちから慣れるのもよいかと思います。

var hello = (word: string) => console.log("Hello, " + word);
hello("TypeScript");

// 返り値の型を明示する
var hello2 = (word: string): void => console.log("Hello, " + word);
// 参考：今まで通りの書き方 1
var hello3 = function (word: string) { console.log("Hello, " + word); };
// 参考：今まで通りの書き方 2
function hello4(word: string) { console.log("Hello, " + word); }

internal modules

今までのJavaScriptでは、モジュールの定義するというのは存在していませんでした。TypeScriptではモジュールが定義されています。今は過渡期でこうした書き方ですが、ECMAScript 6だと書き方があるので、なくなると思われます。

module app {
	export class Sample {
		hello(word = "TypeScript") {
			return `Hello, ${word}`;
		}
	}
}
var obj = new app.Sample();
console.log(obj.hello("AngularJS"));


var app;
(function (app) {
    var Sample = (function () {
        function Sample() {
        }
        Sample.prototype.hello = function (word) {
            if (word === void 0) { word = "TypeScript"; }
            return "Hello, " + word;
        };
        return Sample;
    })();
    app.Sample = Sample;
})(app || (app = {}));
var obj = new app.Sample();
console.log(obj.hello("AngularJS"));

Generics

Genericsは非常に便利です。

class Container {
    constructor(public data: T) { }
}

var a = new Container("str");
var b = new Container(1);

a.data.charAt(0);
b.data.toExponential();

はじめてみよう – Angular-typescript

@vvakameのgithubにあるので是非見ていただき、TypeScriptを始めてもらえたらと思います。

開発する際、利用するツールは次の通りです。

• node.js
• grunt
• bower
• TypeScript ** tslint ** typedoc ** dtsm (tsd)
• LESS
• unit test ** mocha ** power-assert
• karma
• protractor
• その他

Angular 1.3と組み合わせる

あまり考えなくてよく、TypeScriptと重ねることは特別なことはないです。TypeScriptはJavaScriptの延長線上にあり、JavaScriptのベストプラクティスがそのまま利用することができます。

その中で覚えなければならないのは

• 型の名前
• 使いたいメソッド（angularのドキュメントを読むより型定義ファイルを見たほうが早い）
• 使いたいDIオブジェクト名

その中で次のことに注意すれば、問題なく記述することができます。

• tsc –noImplicitAny
• 型注釈を書く

プレゼンテーション資料

今回取り上げたプレゼンテーションの資料は、以下のとおり公開されています。合わせてご覧ください。

セッション動画

当日のセッションはYouTubeで公開されています。是非ご覧ください！