このページの本文へ

あのスタートアップ企業がReactをフロントエンド開発に選んだ理由

2017年04月24日 19時43分更新

文●Chris Lienert

  • この記事をはてなブックマークに追加
本文印刷
乱立するフレームワーク/ライブラリーをどう選ぶか? あるスタートアップ企業がフロントエンド開発フレームワークを選択するプロセスをケーススタディとして紹介。

シンガポールを拠点とした福利厚生サービスを提供するスタートアップ「CXAグループ」(日本版編注:CNETの記事を参照)のコアWebプラットホームを評価するにあたって、時代遅れとなった既存のアーキテクチャをお払い箱にすることにし、イチからフロントエンドを再構築することにしました。課題は、CXAグループが進出しているアジアにある12の対象国のどこでも機能するWebアプリケーションの開発です。

プロジェクトの納期がタイトであることを考慮しつつ、さまざまなフロントエンドJavaScriptフレームワークを評価しました。企業の大型プロジェクトでこれほどの改変をする機会はめったにないため、評価プロセスは可能な限り詳細に詰めました。

フレームワークを選択する過程で失敗しそうなこともしばしばありました。事業が指数関数的に成長している中でミスは許されません。また、検討しているフレームワークを、チームの誰一人して使った経験がほとんどないという事実を考慮することも必要でした。

分野を絞る

新しいフレームワークが日々生まれているため、検討対象としてたくさんあるフレームワークの選択肢を絞るためにメタ分析をしました。聞いたことのある、または評判のよいフレームワークを含め、最終的に、聞いたことのあるAngular 2とAurelia、評判のよいVue.jsとReactに絞りました。

フレームワークが主要な要件を満たすかをショートリストでチェックし、順位がどうなるかを確認しました。フレームワークの一部は、プロジェクトに必要なソリューションがありましたが、実現したことを先取りしているフレームワークもありました。

柔軟性

さまざまな構成オプションがあり、比較的簡単にカスタマイズできるフレームワークを選ぶ必要があります。突き詰めていくとアーキテクチャの考え方に行き着きます。アーキテクチャに基づいて決断をしてしまうか、決断ができる可能性をしっかり残しておきました。

Angular 2はすべての選択肢(ステートサーバー、ルーター、ハンドラー)があるフレームワークの1つであるにすぎません。Angular 2のメリットは簡単にすばやくセットアップができて実行ができることです。一方、モジュールが自分の思いどおりに動かないデメリットも想定されますが、これは避けようがありません。

Aurelia、Vue、ReactはAngular 2とは真逆に位置し、必要であればモジュールを取り替えられます。AureliaやVueはセットアップに設定可能なボイラープレートがある点でReactより優れています。

Vueと同様に、React自体はプロジェクトに必要なものをほんの少し提供するにすぎません。そのため、プロジェクトの問題可決のために決定しなければならないことはかなりやっかいです。Reactがはじめてローンチされて以来、Reactを導入しやすくするためにさまざまなボイラープレート(React BoilerplateCreate React App)が開発されています。

Reactテストプロジェクトでは、特定のボイラープレートを使わずに、Reactを直接試すことにしました。コードを参照するときに多少のボイラープレートを使った程度です。このテストは確かに難しかったですが、Reactスタックの1つ1つのコンポーネントについてたくさんのことを学び、最終結果にかなり自信を持てるようになりました。

VueやAureliaは相対的に習熟曲線が低いため使いやすく、モジュラー構造が小さいためこのテストを勝ち抜きました。Reactの柔軟性はある程度認められますが、他と比べて使い始めは非常に難しいと評価されました。

オフラインサポート

Service WorkersのようなAPIを使うと、Webアプリケーションは安定した、または不安定なインターネット接続でも使える可能性は高くなります。プロジェクトのチームはこの分野に関する経験はまだないので詳しくは言及しませんが、評価対象のフレームワークがなんらかのオフラインサポートを提供することは確認しています。

軽量

バイト単位のコードをクライアントに送るとき、帯域幅と処理時間の両方でブラウザーのパフォーマンスに大きな差が生じます。カスタムコードやサードパーティライブラリが追加されると、バイト単位のコードを小さくするのがさらに難しくなります。CXAグループの対象市場はデータ送信のコストが高い国々なのでコードをできるかぎり小さくして送ることが不可欠です。

生成構成を表す大きなデータではなく、コアライブラリーのサイズを調べ、直面しそうな問題を推測しました。実際の生成サイズは表示されているものよりも大きいのです。

Vueはあらゆる手段を使いコアライブラリーをなんと23KBまで縮小しました。ReactやAureliaはその中間で(約42KBと64KB)、Angular 2では143KB(状態管理のRxJSを含め)と重いままです。

実際、Vue、Aurelia、Reactの生成ビルド機能は均衡しているため、検討の価値があります。Angular 2は先ほど説明したように、突出して低い評価です。

サーバーレンダリング

初期のシングルページアプリケーション(SPA)フレームワークはすべてのコードをクライアントに送るモデルを採用していました。つまり、ページの初期レンダリングはクライアント側に任せるということです。結果としてページの初期ローディングは遅くなります。一方、サーバー側でページをレンダリングするSPAの考え方は、初期レンダリングでサーバーに負荷をかけるため、初期レンダリング後もすべての要素が遅延ロードとなります。

VueやReactはプラグインを使ってサーバーレンダリングを追加します。現在、Angular 2はさまざまな共通(Universal)機能を組み込んでいますが、VueやReactの機能にマッチしていません。Aureliaはサーバーレンダリングを開発中の機能として位置付けていますが、ほかのパフォーマンス改善機能を隠し持っていたとしても、実装までのスケジュールが不確定です。

成熟度

企業向けWebサイトのフレームワークを選択する場合、幅広いコミュニティのサポート、安定性、適した人材がいるかどうかが非常に重要な要素です。3年後に特定のフレームワークが引き続きサポートされているかを予測するのは困難ですが、現時点で問題がないことを調べて判断するか、またはこれまで説明してきた各要素から判断することになります。

フレームワークの最初の公式リリース日から、そのフレームワークの堅牢さがある程度分かります。少なくとも理論的には、ライブラリのリリース日が古いほど機能が豊富で深刻なバグも少ないです。

Reactは2013年3月に最初に公式リリースされており、比較するほかのフレームワークに勝ります。Vueは2015年10月にはじめてリリースされましたが、2016年9月にバージョン2がリリースされるまで大きな注目は集めていませんでした。Aureliaは2016年8月にバージョン1がリリースされたばかりの新製品です。

Angular 2は特徴があります。バージョン2はバージョン1から大幅に変わっており、最初のリリースは2016年9月でした。

このような視点で評価をする場合、ライブラリーのリリース日だけでなく、ライブラリー開発の歴史も検討する必要があります。開発の歴史が長く、持続していれば、たとえそれがベータ版だとしても、信頼感は高くなります。

多くのチームメンバーが一定期間、採用候補のフレームワークの歴史を検討してきましたが、どのフレームワークもそれぞれ少なくとも一定の安定性があるように感じられました。検討したすべてのフレームワークの中でAngular 2の開発の歴史は大きな互換性を破る変更や不明瞭なリリース日などの問題点で際立っています。Angular 2は最終的に最終版リリースまで漕ぎ着けましたが、それまでの過程ではいろいろなことがありました。

これまで説明したことも含め、成熟度を高めるため最終的に重要になるのは経験豊富なスタッフです。私たちのチームは評価したフレームワークに対しての経験が乏しく、納期に追われていることを考慮すると、技術に精通した経験豊富な開発者を雇っていれば良かったと反省しています。

特定の経験がある人を雇うのはなかなか難しいですが、私たちが取り組んだような大きなプロジェクトでは大きな差が表れます。Angular 2はこれまで説明してきたように多くの要件を満たさなかったため、この時点で不採用としました。

残りのフレームワークに関しては、さまざまな求人サイトで、フレームワークごとに求人をしました。AureliaとVueは応募がまったくなく、人材は見つかりませんでした。他のフレームワークに比べるとReactへのオファーが多く、優秀な人材の応募も多くありました。

そのほかの機能

まだ紹介していない開発ツールやテストに関して、すべてのフレームワークで試す必要があります。しっかりした開発者ツールの利用なしにデバッグはほぼ不可能ですし、ユニットテストは私たちが作成するような企業水準のアプリケーション開発には不可欠と言っても過言ではありません。

ハンズオンで評価する

論理が実務経験に勝ることはありません。これまでの経緯を踏まえて、私たちはほとんどの要件を満たした2つのフレームワーク、AureliaとReactを選び、並行してコーディングを開始しました。この段階でVueを省いたのに特別な理由はありません。評価する時間が十分にとれなかっただけです。

作業は既存のアプリケーションの基本的な機能に合わせた認証画面の構築です。具体的には、ログイン、APIのコール、セッションの構築です。2人のチームメンバーはそれぞれフレームワークを割り当てられ、どのようなものが構築できるか1週間の猶予を与えてテストしました。

Aureliaのデモは、セットアップ手順が簡単だったことで、完成度の高いものとなりました。セットアップが終わって各部品を選択した後は、Reactスタックにはなにがあるかをより良く理解できたように感じました。Aureliaはセットアップの容易さでは飛び抜けていました。

実際にコーディングをするだけでは重要な結論を導きだせません。ただ、驚いたのは、それぞれのコードがよく似ていたことでした。両方のフレームワークが利用するECMAScript 6に導入されている構造的な変化のおかげでしょう。

結果

最終的にReactを選択しました。フレームワークとしての堅牢性、コミュニティサポート、そのほかのすべての機能との比較、そして人材の採用が容易であることが理由です。Reactは私たちの基準をすべてクリアし、比較した他の競合フレームワークと比べてもクオリティが非常に高かったのでした。

VueとAureliaはどちらも良い競合でしたが、私たちの要件に一歩及ばないことが分かりました。Vueはより完成度の高い機能があるため、Aureliaよりわずかに優れていますが、どちらも要件を完全に満たすことができませんでした。時間があれば、人材の採用に関してはそれほど重要ではなく、実務で試す対象をVueまで広げていたでしょう。

Angular 2は選択の基準のほとんどをクリアできず残念でした。メリットがあっても私たちに不向きなことは明らかです。

Reactを選択し、プロジェクトの構築を開始したので、同様の評価テストを近々に実施する可能性はあまりませんが、どのような採用基準をリストに加えるか考えてみてください。

※本記事はStuart MitchellRalph MasonVildan Softicが査読を担当しています。最高のコンテンツに仕上げるために尽力してくれたSitePointの査読担当者のみなさんに感謝します。

(原文:How to Choose the Right Front-End Framework for Your Company

[翻訳:中村文也/編集:Livit

Web Professionalトップへ

WebProfessional 新着記事