ガジェット通信 GetNews

見たことのないものを見に行こう
「ジャスティス・リーグ」特集サイト

「React.js × React Native」―メリット・デメリット、将来はどうなる?【前編】

DATE:
  • ガジェット通信 GetNewsを≫

React・React Nativeをテーマにパネルディスカッション

3月16日、リクルートテクノロジーズで、React.js meetupとReact Native meetupによる合同勉強会が開催された。

今回の勉強会はWeb開発において急速に普及しつつあるReact、そしてその書き方をベースにネイティブアプリがつくれることで注目を集めているReact Nativeに関することが学べるということで、多くのエンジニアが集まった。

今回の勉強会は大きくパネルディスカッションとLTの2部で構成。最初のパネルディスカッションでパネラーを務めたのは次の4人。

古川陽介さん(@yosuke_furukawa
Node.JS日本ユーザグループ代表を務める。リクルートテクノロジーズのシニアエンジニア。会社ではReactとReduxを使ったWebアプリケーションフレームワークの開発とその活用をサポートしている。React Nativeの技術獲得をチームで実施中。

小林徹さん(@koba04
TOLOTで、Reactを使ったSingle Page Applicationを開発している。ウェブアプリケーションエンジニア。React.js meetupの運営や、HTML5 Experts.jpメンバー。React Nativeは趣味で触っている程度。

吉田俊明さん(@yositosi
トゥギャッター代表。8年ぐらい前に趣味でトゥギャッターを開発し、今は会社として運営している。React Nativeを1年前に採用してアプリをフルリニューアルした。

高木健介さん(@janus_wel
キュア・アップ CTO。キュア・アップはソフトウェア医療機器『治療アプリ』を開発している。同アプリの開発にReact Nativeを採用している。

そして、React Native Meetupを主催するフリーランスエンジニアの中田一成さん(@besutome)が司会を務めた。

React Nativeとはどんな技術?

まずはReact Nativeとはどんな技術か、高木さんが簡単に紹介した。React Nativeのメリットは3つある。
ユーザーに対しては、ハイブリッドアプリながらネイティブ体験を提供できること。
開発者に対しては、Reactで得られた知見・経験を生かしてネイティブ開発に移行できること。
ネイティブ開発者に対しては、今までのネイティブ体験を継承しつつ開発スピードを上げられること。

実際に今までのハイブリッドアプリで、ネイティブのコンポーネントを再実装するというアプローチをとっていたが、そのやり方ではネイティブの体験をユーザーにそのまま届けることは難しかった。

しかもプラットフォームのアップデートに追従することも難しく、開発コストもかかっていた。そしてこれらの課題はReact Nativeなら解消できる。

また一度学んだらどこでも書ける。Facebookの開発者はJavaのような「Write Once、Run Anywhere」ではなく、「Learn Once, Write Anywhere」を目指した。

ネイティブのように、書き換えてはコンパイルを繰り返すというようなストレスもなくなる。React NativeならWebと同じようにファイルを保存してリロードすれば、結果が確認できる。それもメリットとなっている。

React Nativeに注目したきっかけ

中田:リクルートテクノロジーズでは、React Nativeの技術獲得をチームで実施しているそうですね。React Nativeに注目したきっかけについて教えてください。

古川:React Nativeは1~2年前から注目していました。そのきっかけは2つ。まず、リクルートテクノジーズではReactの開発者が増えていくという予測があったこと。の一方でネイティブの開発者は足りていない。

あるメンバーがWebアプリケーションをReact Native化したものを見せてくれたのですが、その完成度が高かったことも技術開発に取り組むきっかけになりました。

中田:すでに導入している吉田さんと高木さん、導入した経緯を教えてください。

吉田:Webサービスとして提供してきたため、JSエンジニアやフロントのエンジニアなどWebに強いエンジニアはいますが、Android、iOSのネイティブアプリの開発者はいませんでした。

そういうメンバー構成の中で、ネイティブのアプリを出したいとなったとき、Titaniumという選択肢もあったのですが、React Nativeに注目していました。

React NativeがAndroidに対応した1年半前、3~4カ月かけて開発。結果的にほとんどネイティブを触ったことのなかったエンジニア2人で、iPhone、Android両方ネイティブアプリを出しています。

高木:うちはそもそも2年半の会社で、私は2代目のCTO。1代目はJavaScriptが好きで、既存のアプリはTitaniumで作っていましたが、開発者の確保に難があり他の方法を探していたところReact Nativeに行きついた。

昨年のFacebookの開発者会議「F8」で、WindowsとTizen OSもサポートするという発表がなされたこともあり、私たちも本格的にReact Nativeに触ってみることにしました。

簡単なアプリを作成し、コミュニティで使ってもらったところ感触も良かった。開発速度も悪くないし、アニメーションの動きも60fpsと悪くない。そこでこれはいけると考え、去年の5月に正式採用。2カ月ぐらい、2.5人で1つアプリを作ってリリースしました。

React NativeはLearn Once, write anywhere????

中田:React Nativeは「Learn once, write anywhere」と言われますが、実際、ネイティブの実装するブリッジのところはネイティブのコードを書かないといけないと思うのですが。

高木:実際にブリッジまで書いてプロダクションに投入したことがないので、なんとも言えませんが、仕組みを調べたところ、それほど問題はないのではないかと思っています。

React Nativeはネイティブ層を薄く、例えばデバイス固有の機能であるカメラや加速度センサーなどを上位に渡すだけのインターフェースを切り、それを上位のJavaScript層でスクリプティングしましょうという思想で作られている。

このような方法だと、ネイティブの経験が少ない人でも、デバイスの機能が初めてでも作れてしまう。Reactから入った人には敷居が高くないと思います。

中田:トゥギャッターは広告部分とかで苦労したという話を聞きました。

吉田:Togetterのアプリをダウンロードすると、最初にFacebookの広告が流れますが、そのブリッジ部分は検索しても存在していなかったので、自分たちで作らなければいけなかった。

しかし、すでにあるアドセンスを表示するライブラリは参考に見よう見まねでやったらちゃんと動くものができました。

共通化はどこまでできる?

中田:古川さんにAndroidとiOSの共通化についてお伺いします。

古川:write anywhereだけど、write onceではないことがわかっていたので、そこは期待していなかった。

ある程度共通化できるという目論見はできるんですが、やはりAndroidとiOSのデザインのベストプラクティスは全く違うので、書き換えないといけない部分もある。ただ、Reactさえ知っているなんとなく困らず書けるのがうれしいですね。

中田:React Nativeにどんな印象を持っていますか。

小林:React Nativeは、Webと同じように書けるというのはメリットだと思っています。さらにReact Native Webというものもある。TwitterモバイルなどはReact Native Webで書かれているそうなので、その辺も今後はどうなっていくのか気になっています。

中田:React Native WebはReact Nativeの書き方でWebページが書けるというものですが、React Nativeでどこまで共通化できるのでしょうか。

高木:画面レベルのReactコンポーネントは切り分けないといけない。React Nativeだと、index.ios.js、index.android.jsというようにエントリーポイントが異なるので、それぞれで最適な画面、最適なエクスペリエンスを作っていくことになる。古川さんも言っていましたが、UIなど部品レベルのコンポーネントは共通化できます。

吉田:うちのアプリの場合、iOSっぽいUI、AndroidっぽいUIに寄せていくことはできていません。どちらでも同じように見える。したがってほとんどコードは同じ。1つのコードベースで英語対応のiPhone、Android版、日本語対応のiPhone、Android版と4本リリースしました。つまり全部共通化している。少しやり過ぎた感じはありますね。

古川:iOSとAndroidの共通化はあると思うのですが、Webとネイティブの共通化はどう考えています?

吉田:さすがにWebの見た目とJSの部分を共通しようとは思っていません。他のプロダクトでAdobe PhoneGapを使い、ワンソースでiPhone、Android、Webの生成を行ったが、やめようと思った。

JSON返すだけのAPIを作り、UIに関するパラメータもJSON(API)に入れておくと、サーバが変えると見た目も変わる構造になっているので、それがWebの資産を生かせることかもしれない。

高木:React Native Webの採用も考えています。ネイティブアプリだとデバッグがしにくいので、シミュレータをWebアプリで組むとか。実際、やった方に話を伺ったところ、うまくいきそうな気がしています。

古川:あれはギャグかなと思った(笑)。ボタンなどのコンポーネントは共通化できることが多いかなと思っています。

パフォーマンスは十分か?

中田:リクルートテクノロジーズで検証したReact Nativeのパフォーマンスはいかがですか。

古川:パフォーマンスについてはほぼ十分で、見た目も良い。Webよりはするする動く。実際、Swiftで書いたものとReact Nativeを書いたものを比べると、そんなに大差はないかと。

中田:React v16のその印象については?

小林:v16の注目の機能はFiberに内部実装が置き換えられること。しかしバージョンを上げただけでは現在のStackのrendererと同じ挙動なので、Fiberのメリットはあまり受けられない。

今の問題点は、Webの場合は複雑なビューの構造になったときに、全てを同期的に処理していくため、複雑なビューの場合にブロックしてしまうこと。それをFiberでは非同期に処理することができる。v16だとデフォルトは同期モードで動作するようになっているが、v17ではデフォルトで非同期になる。

16へのバージョンアップはFiberに変わる部分よりも、React.createClassやPropTypesが別パッケージになるなど、いろいろなモノがなくなることの方がインパクトは大きい。機能が減っていくので、覚えることも減っていくのは嬉しいことかもしれない。

React・React Nativeの技術的賞味期限

中田:Reactの寿命について。この領域は更新が早いですね。

吉田:Reactを使っていないので、Reactの状況がわからないけど、React Nativeはそんなに寿命が長くなくてもいいかなと思っています。うちは開発のスピード感を買ってReact Nativeを採用しているから。

スピーディーにプロダクションを出せて、ユーザーから反応をもらえました。React Nativeでネイティブアプリを出したことで、ユーザーの滞在時間、閲覧ページが3倍になったとかがわかりました。

高木:Reactは宣言的にビューを書けるツールだと思っています。React、React Native、React Native Webはその考え方を使うためのツールというイメージなので、React、React Nativeともに技術的な賞味期限は同じような感じですね。

古川:もしかして数年後にはReact Nativeはないかもしれないが、それでもやる価値はあると思っています。

React Native使うことによって、ネイティブ化する体験を開発者が得ることができる。それは勉強にもなるし、奥で何が行われているかという技術を深堀の経験になるから。技術開発する価値は大きいですね。

小林:React Nativeはオープンソースであり、React本体のコアコントリビュータはFacebook社内のエンジニアが中心ですが、React NativeのコアコントリビューターはFacebook以外にもいて、盛り上がっています。FacebookがReact Nativeをやめても続いてく感じはあるんじゃないかな。

中田:Reactの賞味期限がReact Nativeによって延びることもあるのではないでしょうか。いろいろなフレームワークでアプリが作れるようになってきましたが、実績を考えるとReact Nativeが現実的な選択肢になるかなと思っています。

React Nativeが使えることで、WebでもReactを使う理由になります。アプリとWebにReactを採用すると、サーバもアプリもWebもフルJSで書くことになるので、それをどう評価するかですね。

高木:私たちが開発するアプリは、患者さんに寄り添うような賢い感じのフロントエンドが求められています。そのロジックをそれぞれのフロントエンドで作り込んでしまうと、タスクが多くなり手に負えない。

そこでDDDという設計手法を採用し、ドメインモデルという形でビジネスロジックを閉じ込めています。1回治療に関するドメインを組んで、それをサーバとフロントエンドで使い回す。ユニバーサルJavaScriptのような考え方です。

本当にロジックを全体に使い回すということで恩恵を受けています。スタートアップもあるので、開発者も少ない。だから使う技術を狭められるのは大きなメリットとなっていますね。

中田:リクルートでReact、Redux、Node.jsでフレームワークを今作っているそうですが、その開発経緯について教えてください。

古川:サーバはバックエンドのためのものではなくて、フロントエンドからもサーバをいじれた方が、いろいろやり取りがやりやすいだろうということで、最近流行りのバックエンドforフロントエンドというアーキテクチャと似た形で、フロントエンドのためのバックサーバを建てようとしています。

そこにNode.Jsを使っている。何が良いかというと、JavaScriptを共通言語にしておくことで、フロントエンドの人もサーバーサイドが書けるようになっていくことですね。

今後もReact Nativeを使っていく?

中田:React Nativeやりますか?

古川:やっていこうかなと思っています。前職のDeNAでは、ngCoreというライブラリ開発ツールセットを用意していました。これは今考えるとほぼReact Nativeなんです。

ngCoreの野望は頓挫しましたが、それをReact Nativeは解消できるのではと期待している。React Nativeが覇権を握るためには、ネイティブ開発者側にいかに歩み寄れるか。ネイティブ開発者のフローにどれだけ近づけるかだと思います。そこが一番、気になっているかんじです。

高木:私はAndroid、iOS両方書いていたことがありますが、それらに比べると今のwebの文脈は難しい。これがクリアできれば、React Nativeをやるメリットは非常に大きい。開発速度やリリース速度に対して、React Nativeのようなブリッジ系の技術はアドバンテージがある。Facebookもそれを見越してこれを開発している。

昨年はReactを触っていた人がネイティブアプリを作れることで話題になっていましたが、今年は逆方向で、ネイティブアプリを作成していた方が採用していくという盛り上がりがあるのではと考えています。

古川:今年その流れがこなかったら、React Nativeも衰退していくのではという懸念は残りますね。

小林:私の場合、会社にはAndroidやiOSのネイティブのエンジニアがいて、がっつり作っているので、React Nativeをどんなタイミング、どんな経緯で導入できるのか、いろいろ難しい。さらに、ネイティブのエンジニアにReactを学んでもらう必要もあります。

特に難しいと感じているのは、技術的なことではなく、人的側面。新規プロダクトにReact Nativeを採用していくのはいいが、既存プロジェクトに採用するのはかなり難しい問題になると思われます。

高木:React Nativeを考えている企業はこれから増えていくんじゃないでしょうか。

古川:ホットコードプッシュはどうでしょうか。

高木:Microsoftが出しているコードプッシュは、まだアウトでもセーフでもないという感じ。Appleもその辺は悪用しなければOK的なスタンスだと聞いています。

本番用に審査だけ通して、あとからコンプライアンスに触れるようなコードの差し替えはNGだが、バグ修正や即時性が求められるものについては、使ったという事例もあるという。今後も事例が出るかどうかで、可能性は見えてくると思います。

React Nativeを社内に浸透させる方法

中田:すでにReact Nativeを採用しているトゥギャッターとキュア・アップではどういうふうにしてReact Nativeを浸透させていったんですか。

吉田:エンジニアの方から、React Nativeを触りたいというモチベーションが出てきたことがきっかけです。

高木:スタートアップなので、JavaScript一本に絞りたかった。ただ、Reactの寿命が来る前に、次の選択肢があるか検討すると思います。今はまだ右肩上がりの時期なので、React Nativeを使っていこうかと。当社はコードベースを用意することで、浸透させてきました。コンポーネントはそれを見ながら作ることができるので。

中田:ReactやReact Nativeに関心を持った方がいらしたら、ぜひ会社でやりたいと声を上げ、プロトタイプを作ってみてはいかがでしょう。そうすることが採用される一歩になると実感しました。

⇒【後編】React.js, React Nativeに関するLTレポートに続く

(取材・執筆・撮影:中村仁美)

カテゴリー : デジタル・IT タグ :
CodeIQ MAGAZINEの記事一覧をみる ▶
  • 誤字を発見した方はこちらからご連絡ください。
  • ガジェット通信編集部への情報提供はこちらから
  • 記事内の筆者見解は明示のない限りガジェット通信を代表するものではありません。