ReactとAngular、使うならどっち？ JavaScriptギークが6つの視点で徹底比較
Reactか、Angularか。どちらを選ぶか悩ましいものですが、エキスパート2人がそれぞれのポイントを徹底解説します。
ReactとAngular、どちらを選ぶべきか？
使用するJavaScriptフレームワークを選ぶ際、この2つはよく比較対象に挙がります。しかし、両者の特徴をよく理解していなければ、選定は困難でしょう。
今回は、両フレームワークが具体的にどんな強みを持っているのかを、Reactの専門家 小林徹さんとAngularの専門家 稲富駿さんに解説してもらいました。両フレームワークの設計思想から使用において考慮すべき点、今後実装される予定の機能まで、利用者が気になるポイントを網羅しています。
JavaScriptギークである2人のノウハウ、ぜひ選定の参考にしてください！
- 小林徹（こばやし・とおる）
- 受託開発やゲーム開発を経て、サイボウズにてプロダクトを横断したフロントエンド開発に取り組む。React本体や関連するOSSに対するコントリビュートも積極的に行なう他、React.js meetupも主催する。
- 稲富駿（いなとみ・すぐる）
- 日本Angularユーザー会代表。Angularへのコントリビューターとしても活動しており、コミュニティの運営やイベントの主催、ドキュメントの翻訳なども行っている。現在はフロントエンドエンジニアとして株式会社Kaizen Platformに所属。
- 【比較ポイント(1)】フレームワークの設計思想
- 【比較ポイント(2)】動作速度やminify時のファイルサイズ
- 【比較ポイント(3)】得意なこと、苦手なこと
- 【比較ポイント(4)】学習のハードル
- 【比較ポイント(5)】セットで使われるライブラリ
- 【比較ポイント(6)】これから追加予定の機能
【比較ポイント(1)】フレームワークの設計思想
──両フレームワークのベースとなっている設計思想は、どのように異なっていますか？
小林 Reactはアプリケーションレベルのコンポーネントを作ってくれるフレームワークです。DOMのレイヤーの上にアプリケーションレベルのコンポーネントを構築します。これを実現するために、Virtual DOMと呼ばれる、JavaScript上でDOMの構造を再現してその差分を実際のDOMに反映する機構を持っているのです。
フロントエンド開発をやったことのある方は分かると思うんですが、DOMは注意して書かないとパフォーマンスが出なかったり、各ブラウザごとに挙動の違いがあったりして、うまく扱うのが大変なんです。こうした部分をReactがラップすることで、DOMを意識せずアプリケーションのコンポーネントをエンジニアが開発できるようになります。
──Angularはどうですか？
稲富 小林さんの話で出てきたように、DOMの操作って複雑なので普通に操作するとなかなか泥臭いテクニックが必要で。パフォーマンスを落とさずバグを踏まないようにDOMに触るのは大変です。だから、それをラップする抽象化層がコンポーネントであるという考えはAngularもReactも一緒です。ただ、ラップを実現するアプローチが違います。
Reactは処理の最後までDOMが出てきません。JavaScript上でDOMツリーを作り終わってからDOMを描画するという流れです。
一方Angularは、1つのコンポーネントが1つのDOM要素と結びついています。MVCの流れを踏襲しているというか、AngularがDOMのコントローラーなんです。DOMをコントロールする抽象化レイヤーがコンポーネントであるという考え方をしています。
ただし最近は、両者の違いはそれほどなくなってきています。なぜなら、実際にはDOMをコントロールしない方がすっきりした設計になるからです。要するに、Reactのようにコンポーネントを「ビューを作る関数」と定義した方がきれいに収まることの方が多い。だから、モダンな設計をすると、結局似たような作りになるというのは最近の潮流としてはあります。
SPA1の開発って、最終的に重要になるのは「状態」とどう戦うか、です。だからコンポーネントの設計においては、可能な限り状態を持たないシンプルな作りにすることがキモになります。
【比較ポイント(2)】動作速度やminify時のファイルサイズ
──動作速度やminify時のファイルサイズなど、パフォーマンス面はどうですか？
小林 「Reactはファイルサイズが大きい」と言われることが多いです。確かに過去のバージョンではそうでした。しかし、バージョン16ではrollupを用いてReactを1つのモジュールとしてバンドルし配布する形になったため、ファイルサイズはこれまでよりも小さくなりました。
また、過去バージョンのReactにはIE8やIE9などをサポートするためのコードがけっこうありました。新しいバージョンではそれらのブラウザをサポートしなくなったため、コードがスリムになったんです。
──Angularの方はどうですか？
稲富 動作速度について言うと、AngularとReactは大差がないです。だから、ランタイムのスピードは選定の基準にはなりません。
minify時のファイルサイズに関しては、Angularはローカル開発時とデプロイ時にJITコンパイルとAOTコンパイルを切り替えられるため、前者と後者のコードにかなりギャップがあります。
ローカル開発時はJITコンパイルのため、ブラウザ上でAngularがアプリケーションを都度コンパイルするんですけど、サーバーデプロイ時はそれがAOTコンパイルになり事前コンパイルで生成されたコードだけをbundleに含めるんです。そのためデプロイの際にはソースコード容量がかなり少なくなります。
稲富 なぜデプロイ時にそれほど圧縮できるかというと、Angularはモジュールがかなり細分化されているのと、Angular CLIというAngularに最適化された公式ビルドツールが提供されているからです。そのビルドツールに、デッドコードやAOT後コードの不要な部分を取り除くオプティマイザーが用意されていて、効率的にコードを圧縮できるんですね。
さらに言えば、今年の4月にリリースされるAngularのバージョン6では、ビルドの方法が変更になりコードを前バージョンよりもさらに圧縮できるようになります。
どれくらい違うかというと、公式推奨のbundle手順を使った場合、バージョン5のAngularではHelloWorldのコードがファイルサイズ100KBを切るぐらいだったものが、バージョン6ならば最小で3KBくらいにできるんです。
上記のツイートを見るとファイルサイズ低下が実感できる。
──ReactはAngularのように、さらにファイルサイズを小さくするための施策を実施する予定はありますか？
小林 Reactは、バージョン16から公式にカスタムレンダラーをエンジニア自身で実装できるようになりました。ReactのDOMのレンダラーは相互互換性や各ブラウザの挙動差異などをケアしているため、ある程度のサイズがあります。でも、それを自分自身でカスタマイズできると、軽量化できる可能性がかなり広がるはずです。
【比較ポイント(3)】得意なこと、苦手なこと
──得意なことと苦手なことは？
小林 明らかに苦手なのは、Railsを使ってレンダリングしたHTMLに動きをつけるなど、別のコンポーネントが作ったDOMをReactでも操作することです。ただし、Reactをサーバーサイドでも動作させることで、サーバーサイドレンダリングを行うことは可能です。あと、ゲームなどパフォーマンスクリティカルなサービスにはあまり向いていないと思います。
──Angularはどうですか？
稲富 基本的に、ReactとAngularで得意不得意はそれほど大きく変わらないと思います。
Angularも、他の要素がDOMを同時に操作する場合には不具合が起きやすくなります。例えば、AngularとともにjQueryプラグインが動いており、DOMが勝手に書き換えられてしまうなどのケースです。
ゲームについては、60FPS以上を求められるハイパフォーマンスなものに導入するのは難しいです。Angularはコンポーネントを作ってそれをDOMに転写してという順で動作するので、そのオーバーヘッドが響いてくると思います。
また、今後は変わってくるかもしれないですが、ブログやWebメディアのように静的なテキスト情報を掲載することを目的としたサービスも苦手です。クローラーはJavaScriptを実行できないので、SEO的な観点で見るとそういったサイトはなるべく静的HTMLである方がいいからです。
サーバーサイドレンダリングをすれば静的HTMLとして出力することはできますが、いずれにせよひと手間必要になるので、得意とは言えない印象です。
あとは、強いて言えば小規模なサービスでAngularを使うのはオーバースペックになる可能性はあります。逆にReactは単体ページでも使いやすいので、それは強みですね。結局、SPAかどうかが大事だという感じがしますね。AngularはSPAならば得意です。
【比較ポイント(4)】学習のハードル
──学習の大変さは？
小林 自分はReactの初心者向けハンズオンをやったことがあるんですけど、そこで感じたのはReactというより、そもそもES2015（ECMAScript 2015）やJavaScriptの仕様でつまずく人が多そう、ということです。
Reactの場合、テンプレートのようなDSLではなく実装もJavaScriptベースなので、それが苦手だと大変かもしれません。その上で、メンテナブルなコードを書こうとすると、関数型言語のような考え方が必要になってきます。
さらに言うと、Reactは他のライブラリと組み合わせて使うことが前提なので、チーム内に一定以上のスキルを持ったエンジニアがいないと収拾がつかなくなる可能性はあります。だから、開発メンバーのスキルレベルによって導入の向き不向きがあるのかな、という感じですね。
稲富 初心者向けAngularハンズオンを何度か行いましたが、Angularを理解する上でハードルとなる技術は大きく3つあると思います。1つ目はTypeScript。この構文に慣れないと、型の概念を理解するのが大変です。2つ目はRxJSで、Angularのコアの部分がこのライブラリに依存しています。3つ目はXHRやPromiseなど、一般的なJavaScriptの非同期処理です。
これらを習得できれば、あとはラクかなと思います。一度レールに乗ってしまえば、その後の学習コストが低いのが特徴です。もしかしたら、上級者は物足りなく感じるかもしれませんが、メンバーが中級者ばかりでも使いやすいのもAngularのポイントと言えます。
【比較ポイント(5)】セットで使われるライブラリ
──開発現場で、よくセットで使われるライブラリはありますか？
小林 Reactの場合は汎用性が高いというか、結構バラバラですね。絶対に一緒に使われているのはBabelとwebpackくらいじゃないでしょうか。Reduxも必須というわけではないので。また、最近ではBabelではなくTypeScriptを使う人も増えています。
稲富 Angularの場合、デザインコンポーネントやルーター、HTTPクライアントなどさまざまな機能を公式が提供しています。SPAに必要な機能としてはすべて揃っているので、特別に他のライブラリをセットで使うことはほとんどありません。
小林 Reactは、初期の頃は公式で提供しているライブラリもたくさんありました。でも、最近はそれらを徐々に切り離してシンプルな機能のみを提供する形になってきています。
稲富 そこは真逆ですね。Angularが公式で提供する機能は増えていく一方です。
──その文化の違いがあるのはどうしてですか？
小林 ReactはFacebook社が提供しているフレームワークなんですが、彼らはなるべく自分たちがプロダクトで使うもの以外はメンテナンスしない方針なんです。だから、機能をできるだけそぎ落としていっているんですよ。
Reactが出たばかりの頃は、利用者のコミュニティがまだ形成されていなかったので、公式が提供する必要があったんだと思います。今はだいぶエコシステムが構築されてきたので、コミュニティに任せる方針にシフトしたのではないでしょうか。その結果、コミュニティからも面白いアイデアが出てきています。
──一方のAngularは、公式がたくさん機能を提供しているのはなぜ？
稲富 Angularはフルスタックであること。つまり「Angularが公式で提供しているものを使えば、安心してアプリケーションを作れる」という世界観を目指しているからです。
機能もパフォーマンスも、すべて公式が面倒を見る。Angularを利用するエンジニアには、自分が開発するサービスのことだけに集中してもらえる環境を作る、という思想なんです。
【比較ポイント(6)】これから追加予定の機能
──今後、両フレームワークに追加される予定の機能はありますか？
小林 Reactはバージョン16で内部実装が完全に変わって、非同期なレンダリングが可能になったのが一番大きな変更ですね。バージョン17で非同期レンダリングがデフォルトで有効化されるのですが、それに伴い、非同期レンダリング関連の機能は今後どんどん拡充されていく予定です。
例えば、Reactで問題と考えられている事象として、ユーザーが画面のテキストボックスに入力している際、非同期レスポンスなどに起因するレンダリングで入力が一時的にブロックされる、というものがあります。
それを防ぐため、ユーザーの入力を高優先度として処理して、その後に他の更新を低優先度として処理する、ということができます。
また、APIリクエストや動的なComponentの読み込みといった、非同期処理に対するUIへの反映を、より簡単かつ柔軟に書けるようにするための仕組みも追加される予定です。
──Angularはどうですか？
稲富 Angularには次期バージョンに取り込むための機能を実験するプロジェクトの集合であるAngular Labsというものがあります。そのなかに、Web Components仕様のCustom ElementsをAngularから作る。要するにHTMLのいち要素レベルにAngularを落とし込むことを目的としたAngular Elementsというプロジェクトがあります。プロジェクトに関してはこちらの動画が参考になると思います。
Angular Elementsが実用化されると、jQueryプラグインのようにウィジェットとしてAngularを置くことができる、という世界が実現するかなというのがありますね。今そのプロジェクトに最も力が入っていて、今年中には実現できそうな見込みになっています。
Angularの最新動向は稲富さんのブログにも詳しい。
アプリケーションを作るという意味でのAngularはほぼ完成しています。でも、サービスって当然、SPAを用いるものだけではありません。誰かが書いた静的なテキストをシンプルに画面に表示するだけのブログやCMSなどもあります。そういったサービスに、今後はAngularを適用できるようにしていく方針です
そうすると、小規模なサービスにも使用できる、軽くて速く動く「パーツとしてのAngular」が実現できるのではないでしょうか。
──JavaScriptギークである2人の意見、とても参考になりました。どうもありがとうございました！
取材・執筆：中薗昴（サムライト）／写真：鈴木智哉
技術監修：尾崎翔太
JavaScriptを使って画面遷移やデータのやり取りなどを実装をするアーキテクチャ↩
