2016年9月のAngular 2リリースは、2016年のWeb業界で、最も重要なトピックの一つだったと言っても過言ではないでしょう。
本稿では、Angular 2を正式リリース以前から仕事で使い倒していた奥野賢太郎さん︵armorik83︶と、不肖白石が、Angular 2開発を実際にやってみている同士で語り合ってみました。
実際にAngular 2開発で苦労してきた二人のナマ声です。今後Angular 2を仕事で採用しようと考えている方々には必見の内容です︵って、自分が出ている記事を紹介するのも微妙ですが…︶。
編集部注: Angular 2の正式名称は﹁Angular﹂ですが、現状だと﹁AngularJS 1.x﹂のことを呼称していると誤解される可能性が高いと判断し、本稿では﹁Angular 2﹂で統一させていただきます
白石最初は音楽の仕事をされてたんですか！むしろその話に興味があります(笑)。でもまあ、この場ではそこを聞くのは我慢して、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のほかの大きなメリットとしては、やはりコンポーネント指向であることが挙げられるかと思います。
私のときは、コンポーネントのHTMLとコード︵TypeScript︶はエンジニアが、CSSはデザイナーがメンテナンスするという役割分担を行ったのですが、これもうまくいきました。
Angular 2が、コンポーネント同士だけではなく、コンポーネントのマークアップ、プログラミング、スタイリングを自然に分割できるよう設計されているおかげだと思います。
白石確かに、コンポーネント指向は一番のメリットですよね。再利用性も上がるし、何より﹁UIを分割して設計しよう﹂という空気が自然と生まれるのもいい点だと思います。
特にぼくは、コンポーネントごとにCSSがカプセル化されて、他のコンポーネントに影響を及ぼさない点が特に気に入ってます。BEMとかの、長ったらしいクラス名が実は好きじゃないもので…
奥野 わかります。ただ、私たちの場合はAngularJS 1.xからの移行からプロジェクトが始まってしまったので、Scoped CSSはうまく活かせなかったんですよね。そこはしょうがなくBEMを使い続けていました。
白石学習コストの面はよく言われてますよね。TypeScriptに加えて、Angular 2そのものの学習コストも高いですしね。
奥野 付属しているRxJSとかも学習コストはかなり高いですね。
白石あ、それで思い出した。RxJSのドキュメントが腐ってるのはしんどい。
奥野 腐ってる(笑)。
白石腐ってますよ！ナビゲーションしにくいし、不完全だし。ぼくなんかまだRxJS初心者なので、ドキュメント見ないとRxJSのコード書けないんですが、ドキュメントが使いにくくていつもつらい想いをしてます。
ほかにも、Angular 2のツライ点で言うと、ビルドが遅いのにはいつも辟易してます。
うちなんか、コードを直して、自動的にwebpack 2がビルドし直して、ブラウザが自動リロードして、結果が確認できるまでいつも10秒くらいかかってます。
奥野 10秒なんてまだ速い方です(笑) 私たちのチームなんて最初Browserify使ってたのですが、45秒かかってましたから(笑)。
この状況で、(ファイルの変更を) ウォッチ＆再ビルドしてたら、うかつにファイルをセーブすることもためらわれてしまうので、最後はウォッチを無効化して手動ビルドするようにしてました(笑)。
でもこれも、webpackに変えただけでビルド時間が20秒切るようになったんですよね。そういう、ビルド環境の進化とかにも追随していく必要がある。
白石そう、それもけっこう大変なんですよね。うちなんて、 
白石しかし、メジャーバージョンアップが半年ごとというのは普通じゃないですよね。何らかのメッセージを感じる。
奥野 それは、メジャーバージョンアップに伴って﹁後方互換性を壊すかもしれない変更も、ためらうことなく行っていく﹂というメッセージの表れです。
白石ほー、それ、ちょっと詳しく伺ってもいいですか？
奥野 こういう方針になったのは、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はこれからもエキサイティングな場であり続けそうです。
編集部注: 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はこれからもエキサイティングな場であり続けそうです。
