なぜ React か? サービスを成長させるための技術選択

Wantedlyでは、React + Reduxを中心としたWebフロントエンドの技術スタックを導入しました。モバイル版の会社フィードや、このブログを書いているエディタ、企業が使う候補者管理の画面などがこのスタックで実装されています。

導入したスタックの詳細や導入の理由、既存のRails環境への導入方法は以前発表した以下のスライドを参照ください。

また、先日Wantedlyに導入した技術スタックを使った勉強会を開催しました。React + Reduxを使って実際にアプリケーションを構築していく演習になっていますので、ぜひ手元で動かしてみてください。

React + Reduxを使ったWebアプリケーション開発速習会＠Wantedly

今回はこれらの背景にある"なぜReactか？"という判断の背景と"どう技術選択するか？"という話を書きたいと思います。

JavaScript界隈の流れの早さ

フロントエンド、特にJavaScriptフレームワークが次々出てきて何を選べばいいのか分からない

そもそもなぜJavaScriptフレームワークが必要なのか?

jQuery dis、その裏返しのReact disとの空中戦、そしてAngularJSとの三角関係

ここ数年何度も繰り返されてきたこういった話題は、悩ましいながらも楽しいトピックでした。しかしその激しい変化もここ最近収束に向かっているように感じます。

" 一生懸命育てたgruntfile.js -> gulpfile.coffee"

" WebpackとBrowserifyとjspmを試しながら、"sprocketsいらないんじゃないか?"と感じ始めたあの頃"

" すぐに定員が埋まってしまい参加できなかったReact.js meetup #1"

こういった懐かしい思い出は胸にしまい、前に進み出す時期が来たのではないでしょうか。

サービスを成長させるための技術選択

Webサービスを開発し、運営していくのならば技術選択を迫られるタイミングは度々訪れます。

外注で作ったシステムの拡張性に限界が来ている、違うフレームワークで書き直したい

一気にユーザが増えてピーク時のトラフィックが捌ききれなくなってきた

難易度の高い技術を取り入れて他社サービスとの差別化を図りたい

表面化している理由と、そこで必要になる技術は様々ですが、根底にあるのは サービスを成長させる必要があり、それを技術面から解決したい という要求です。

Wantedlyではディレクターのポジションはなく、エンジニアが直接KPIに対してコミットし、施策を考え実行することを求められます。施策の性格は様々で、ユーザ行動の分析に基づいたグロースハックのこともあれば、新たな機能の実装のこともあり、時にはマーケティングの領域に近いものもあります。私達が技術的な選択をする必要があるのは、サービスを成長させる過程で困難な技術課題にぶつかった時です。

Webフロントエンドの"幼年期の終り"

それでは、Reactを採用した背景には、サービスを成長させる上でどのような技術的な課題が発生したのでしょうか?

一言で言えば、 ユーザがUI・UXに求める水準が高くなり、Webフロントエンドで難易度の高い実装を求められるようになったから という事に尽きます。

オライリーから出版されている"入門 React"の冒頭の一文はその状況を端的に表しています。

初期のWebアプリケーションは、サーバーにリクエストを送信して返却されたページを表示するだけだったので、開発者はブラウザでの出来事に気を配る必要がありませんでした。

サーバサイドレンダリングでできたものを"初期のWebアプリケーション"と言ってしまうあたり、かなり切れ味鋭いですね。

"初期のWebアプリケーション"に比べて、近年ではサーバサイドからレンダリングされたビューをJavaScriptで動的に書き換えて動作するアーキテクチャが増えてきました。特にSingle Page Application(以下SPA)の構成ではブラウザのリロードを行う事なく、データの取得・更新を行い、画面を動的に構築していくことで、独立したアプリケーションのような振る舞いを実現します。

そういった実装が求められるようになった要因としては、ユーザが求めるUI・UXのレベルが高くなっていることが挙げられると思います。GmailやGoogle AppsなどのGoogleが提供する各種Webアプリケーションや、リッチなアニメーションが組み込まれたスマートフォンのアプリケーションにユーザが日常的に接しているからです。

しかし"昔のWebアプリケーションは単純で良かった..."と嘆いていてもしょうがありません。変化は既に起きていて、もう後戻りすることはできません。私達がすべきなのは適切な技術を選択して、歯を食いしばりながら前に進んでいくことです。

なぜ React か？

Wantedlyで導入した技術スタックの中で最も重要なのはReactです。Reactは当初 "Just The UI""Virtual DOM" "Data Flow" の3つの特徴をトップページに掲げていました。(ブランディングの方向転換なのか、現在Reactのトップページから記載はなくなっていました)

3つの中でもReactの最大の特徴は"Virtual DOM"です。

例えばBackbone.jsでSPAを実装する場合、毎回全てのビューを再描画していては実用に耐えうる速度は得られません。描画速度の改善のために、ビューを細かく切り分け、ユーザのアクションに対して最低限の差分のみ更新するように実装する必要があります。

しかし、この実装はなかなかの辛さを伴います。ユーザの操作によって画面の状態は複雑に分岐していき、それに伴って画面が部分的に更新されるため、冪等性を確保することが難しいのです。例えばCの動作をした時に画面が変化する場合、A->B->Cの順に操作した時には正常に動くが、B->A->Cの順に操作した時にはViewの整合性が崩れてエラーが発生する、というような状況が機能の複雑さに伴い増えていくことになるのです。

ビューの差分更新の難しさへの解決アプローチがReactでは"Virtual DOM"、AngularJSでは"双方向データバインディング"、Knockout.jsやVue.jsでは"MVVMパターン"ということになります。

私はこれらのアプローチの中で最も問題をシンプルに解決しているのはReactのVirtual DOMだと感じます。開発者は常に画面の最新状態だけ意識すれば良い、という仕組みはSPAに必要な画面の差分更新を"初期のWebアプリケーション"に近い状態まで単純化してくれました。

以前Backbone.jsで書いた機能を、機能追加のタイミングに併せてReactで書き換えた事があります。出来上がったものを動作させると、体感でも明らかにReactで書いた物の方がパフォーマンスが良かったのです。Chromeのデベロッパーツールでレンダリング範囲を確認してみると、Reactで書き換えたものの方が以前のものよりも、再描画の範囲が絞り込まれいることが分かりました。

ビューの分割という職人技で達成していたことが、新しく登場した技術でアップデートされた瞬間でした。Reactの素晴らしさを体感したのと同時に、自分の積み重ねたスキルの一部が不要になった寂しさを感じた瞬間でもありました。