この記事は(React.js Advent Calendar 2015)http://qiita.com/advent-calendar/2015/reactjsの20日目の記事になります。
割とふわっとした感じの記事になるかとおもいます。
なお以下の文章は非Web系な会社で働く僕の実体験による個人的な意見で、Reactやフロントエンドの世界についての誤解に基づく意見が含まれている可能性がなきにしもあらずです。
なるべく気をつけて書いたつもりではありますが、もしも気になるようなところがありましたら指摘していただけると、誤解の流布を防ぐことができ、また僕自身の知見になりますので大変ありがたいです。
Reactが業務アプリケーションの実装に向いている理由
業務アプリケーションと一口にいっても、情シス的な社内システムから、管理ページ、その他にも例えば無線ルーターの設定ページなんかも含んでしまっていいとおもいます。
これらのアプリケーションに共通した特徴には、「入力項目（=状態）の多さ」や「バリデーションの複雑さ」が挙げられるとおもいます。業務アプリケーションのプロジェクトが滞る原因の9割はアプリケーションの状態管理が破綻することにある（俺調べ）ようです。
そしてこの手のアプリというのは、アップデート（というかデプロイというかリリースというか）に必要な儀式の手順の煩雑さや、Web系の知見にうとい人が多いなどの理由で、枯れた技術というか、「とりあえずjQuery」みたいな雑な流れで技術選定がなされることが多いんじゃあないかとおもいます。
jQueryは素晴らしいライブラリでしたが、あくまでユーテリティ集であってアプリケーションの状態管理というレベルの話には一切貢献しません。
この記事は、新しい技術がダブーみたいになっている中で、デメリットを抑えてでもReactを使うべきだよ！ 最初はつらいけどだんだん気持ちよくなるよ！ みたいな感じのことを書くのが目的になります。
セキュリティリスクの軽減
はい。まぁこれはReactに限った話ではなく、MVX的なviewライブラリに共通している話なんですけども。
本業フロントエンジニアじゃない人たちが生半可な知見でjQueryやDOMをいじくると、高確率でXSSだとかいったチョンボをやらかします。少なくとも僕がみてきた限りではそうでした。
Reactを使っていてもあらゆるセキュリティリスクを0にすることは当然無理なのですが、かなり減らすことができます。例えばReactでは表示する文字列は全てエスケープされます。
「フロントエンドは片手間でやるもんじゃねえよ！」みたいなことが界隈の一部で言われて久しいですが、それでも片手間でやらざるをえない我々にとってここら辺の悩みをライブラリに任すことができるのは大変嬉しいです。
ただのViewライブラリである
前述したように、業務アプリケーションを実装する人々というのは往々にしてアップデートに慎重です。「一日ウン十回デプロイするよ！」みたいなことはまず行われません。
そういった中でこの異常なまでに流れの速いJavaScriptフロントエンド界隈の、フルスタックなフレームワークに乗っかるのはできれば避けたいものです。「ver 2のAPIは完全に別物だよ！」みたいなことを言われたところで、乗り換えるモチベーションを持つ人が誰もおらず、サポートが切れてもそのフレームワークを使い続けることになるのが目に見えています。
その点で、ReactはただのComponentを担うライブラリなので（若干デフォルトになりつつはありますけども）、もしもReactが完全に廃れたところで乗り換えはなんとかなります。
また、Reactおすすめのアーキテクチャであるfluxも、ぶっちゃけただのObserverパターンというか、古き良きクライアントアプリケーション時代の由緒正しいMVCと大差ない構造で、それこそ簡単に自作できるレベルです。
各パーツが比較的用意に置き換え可能な状態になっている、というのは一つの利点だといっていいでしょう。
かっちり書くのに向いている
「AngularやVue.jsは素早く実装するのに向いていて、Reactは冗長だけどかっちり作れる」みたいな意見をたまに聞きます。完全に同意はできないのですが、Reactは「状態の管理」というものに大変重きをおいていて、それゆえにちゃんと思想に従ってコードを書けばかなりかっちりとした実装になるという手応えがあります。
Reactを使ったフロントエンドの設計に関する話題も増えていますし、少なくともjQueryオンリーで適当に書いたカオスとは雲泥の差があるでしょう。
業務アプリケーションというのは比較して、おおむね大規模で複雑です。そして、パフォーマンス（主にトラフィックとか）についての制限は緩めです。
Reactの指向する一方向のデータフローや、VirtualDOMの富豪的な思想はこういったアプリケーションを実装するのにうってつけだといえます。
そして、業務アプリケーションにおいて「かっちり書ける」というのは一般的なWebサービスとは全く違った意味をもってきます。
業務アプリケーションは、上述したどれでもほとんどがそうなんですが、政治上、制度上の問題から長く使われることが宿命付けられています。
なので「売れるかどうかすらわからないから高速にプロトタイピングすべし！ でもスケーラビリティ考えると将来系にはかっちりとリファクタリングな」というようなWebサービスと比べて、最初から堅牢に作ることのメリットが勝つわけです。
React + fluxで書くと、かならずデータフローを一巡させないといけなかったりして面倒臭く感じることがなくもないわけなんですが、数日経ってから読み返してもちゃんと流れを追うことができます。これは素晴らしいことです。
それとPropTypesを定義することで、型付き言語並みとまではいきませんが、必要最低限の値の検査をシステムに任せることができます。
コンポーネントの再利用ができる
ぶっちゃけると、汎用的につかえるコンポーネントの定義なんてのは限りなく難しいとおもいます。
しかしです、業務アプリケーションというのは宿命的にページや入力項目が多く、その中には全く同じような構造のものが少なからずあります。
「同一アプリケーション内で」汎用的につかえるコンポーネントの実装、という分には実装の難易度もそれほど高くなく、またかけたコストを十分にペイするだけのメリットを生み出すこともできます。
「入力をsubmitするたびに増えていく表（編集もできる）」、「ラジオボタンに連動した入力制御」etcetc……
外向けに公開できるクオリティかどうかは別として、今僕が作っているものは社内的には共有して使えるような形で実装してあります。
jQueryでもできなくはないんですけども、圧倒的にReactで作る方が楽ですしコードの見通しも良いです。
Reactが業務アプリケーションの実装に向いていないところ
新しすぎる
突然もっといいものが出てきて廃れるリスクだとか、そういった懸念はあります。
それと、人員の確保の問題もあります。ここら辺が好きだったり得意だったりする人はだいたいそっちを本職にしてしまいますので。
しかしまぁ、物事を新しくしていきたくないのならばそもそもWebブラウザをベースにしてシステム作るんじゃねえよ！というお話ですね。
DOMをいじれないので既存のサードパティと相性が悪い
つまり、jQueryPluginだとか、Bootstrapとかとの相性が絶望的によろしくないです。
一応、React対応のウィジェットもいくつかあるにはあるのですが、どれもしっくりきませんでした。
とりあえずjQueryプラグインは捨てよう（良心）。
BootStrapだとかMaterializeだとかもそんな大したことしてない（Rippleエフェクトとかはやたらめんどくさいけど）ので、ちゃんとCSS勉強すればいいじゃん？ と個人的には考えてます。
複雑
ここでいう複雑とは、それなりの体系があるゆえ、jQueryと違ってAPI以外にも覚えることがあるということです。成果物の複雑さを指すものではありません。
JavaScriptワールドに深く足を突っ込むことになりがち
恐らく、React自体はフツーにscriptタグでリロードして、次のscriptタグでグローバルなReactを参照してコンポーネントを作り……というやり方にも対応しているはずです。
が、そういうやり方でReactのコードを書いてるひとは恐らく皆無だとおもいます。
そうなると、gulpがどーだとか、TypeScriptがいやbabelがどうだとか、モジュールの仕組みを使うためにはwebpackがbrowserifyが……そしてbabelを使った場合はstageいくつまで許容するだとか……。挙げ句の果てにisomophicしようぜみたいな話だとか、頭がフットーしそうになります。
ここはマジでしんどいんですけど、必要なしんどさなので諦めましょう。
デファクトのfluxライブラリが存在しない
先ほどの、fluxはシンプルだからオレオレで自作もできるぜ！ という話とは微妙に相反してしまうわけですが、なんだかんだいってこの手のものはデファクトに乗っかるのが安心なわけです。
しかしまぁ泡のように現れては消えていきます。Reduxが最近では流行ってますが、これもいつまでもつのかわかったもんじゃないです。
自社フレームワークは消耗への第一歩ですが、サードパーティよりはオレオレのほうが安定感あるんじゃね、みたいな現状は大いなるデメリットだと言えます。
しかしそこでも「BackboneのviewにReactを使う」みたいなことが出来るのは良いところでしょう。
SPAマジ大変
Reactに限らないですが、MVC系のフレームワークを使うということは高確率でSPAを指向することになります。SPAつらいです。
最低限、戻るボタンを押すと全てが台無しになるようなFlash製豪華UI（笑）を再発明するのは避けたいところです。
SPAってまだ人類には早くないすか？
というかここら辺の知見が世間に驚くほど少ないあたり、そこそこの規模のプロジェクトをReactで実装した例ほんとにあんの？ マジで？ みたいな気持ちになります。もうちょっと英語で情報収集したら違うのかもしんないです。
とりあえず、あまり複雑なことをしないのであればreact-router使っておけば間違いないです。が、早晩何かにハマりそうな予感はしてます。
人の確保
JavaScriptはあるところから急に難しくなります。Reactでアプリケーションを組むにはJavaScriptそのものについてもちゃんと勉強しないとついていけません。業務アプリケーションの実装で、ここら辺が出来る人を確保するのは大変しんどいです。
色々と考えたのですが、なるべくドキュメントや社内のブログに情報を残していくだとか、勉強会を開催して知見を残す。くらいしかおもいつきませんでした。
まとめ
観念的なお話になってしまいましたが、とりあえずまとめです。
きっちり作りやすい（作りやすい）
学習コストはかかる
- そもそも学習コストをかけたくないならブラウザやめたほうがいいのでは
既存のウィジェットみたいなものは再実装することになるかもしれない
UIにこだわるならCSS書けるマンが必要になる
- React-bootstrapとかは一応存在するけど……
気がついたらデメリットの部分にしんどさが表出してますけど、それを相殺しても僕はReactを使ってよかったとおもっています。
jQueryカウボーイが跋扈する生フロントエンドの荒野に比べたら、たとえデスロードでも道が引いてあるReact（や他のフレームワーク）の世界はちゃんと人が住める場所だと感じます。
IEも順調に死につつありますし、我々の未来が明るいことを信じましょう（モバイルブラウザから目をそらしつつ）。
おしまい！
でもReactつらそう……とおもった方に hachibeechan.hateblo.jp
