React – HTML5Experts.jp

React VRでここまでできる！VRでジオラマを作ろう

原一浩 — Mon, 31 Jul 2017 01:30:45 +0000

連載： React VR (4)

今回は、こんなVRジオラマをつくるぞ！

前回、3Dプリミティブオブジェクトを使って、レイアウトやライティングの仕方について一通り試しました。前回扱わなかったコンポーネントに、3DモデルのためのコンポーネントModelがあります。Modelコンポーネントを使うと「obj」形式の3Dモデリングデータを読み込み、VR空間に配置することができます。

3Dのモデリングデータを使うと、リアルな物体だったり、複雑な形状を持ったオブジェクトを自由にVR上で扱えるため、VR空間における表現力が飛躍的に高まります。実際VRコンテンツを作る際に使うのはBoxやCylinderではなく、Modelコンポーネントになるでしょう。

今回は、3Dのモデリングデータを読み込み、ジオラマを作ってみましょう。子どもの頃、作ったプラモデルに顔を近づけて遊んだ経験はないでしょうか。VRでは、巨大な物体を目の前に表示させるのもお手のものです。

新規プロジェクトの作成

既に本連載の読者であれば何度か行ってきていることですが、今回もサンプルを作るにあたって新規プロジェクトを作成し、プロジェクトディレクトリへ移動します。HelloDioramaというプロジェクト名で進めることにします。

$ react-vr init HelloDiorama
$ cd HelloDiorama

ジオラマに必要なものは何でしょうか? 一つは飾る対象物です。これはロボットなのかもしれないし、戦車かもしれないし、船かもしれません。3Dモデリングデータさえあれば、そしてそれをReact VRで読み込めさえすれば、なんでもジオラマにすることができます。

ちなみに「React VRで読み込めさえすれば」と書いているのは、Webで公開されている3Dモデリングデータの中には何故か表示できないものがあります。表示はできるけど変な形状になったりするものもあります。これはきっと時間と共に解決されていくタイプのものでしょう。気になることがあればReact VRのGitHubリポジトリでIssueを立てるとよいです。

続いてジオラマに必要なもう一つのものは何でしょう? それは雰囲気を与えてくれる背景です。緻密なモデルをさらに引き立ててくれる背景は、ロボットなら宇宙船の内部かもしれないし、船なら海上かもしれません。こちら背景は、今回は3Dプリミティブオブジェクトを利用してそれっぽいものを作ってみます。

用意するもの

ジオラマコンテンツを作るにあたって、用意するものは以下となりました。

配置する対象物としての3Dモデリングデータ
背景の壁と床のテクスチャ

まずは、配置する対象物としての3Dモデリングデータから用意しましょう。

1930年代に使われたソ連製のトラックのモデルデータ

今回ジオラマとして、シーンに配置するのは、GAZ-AAという1930年代に使われたソ連製のトラックにしてみました。筆者は、このトラックを好きだったわけではないですが、様々な3Dモデルを探す中でふとこのトラックを見かけ、素朴な中にも車両全面に漂う気品を魅力に感じ、採用した次第です。

このトラックは、ポリゴン数が4,380と、そこそこ複雑な形状をしており、テクスチャなどを含んでいてなかなかにリアリティがあります。

下記より、objフォーマット形式のものをダウンロードしましょう。もし他の3Dデータで試す場合、ライセンスについてチェックしておきましょう。

GAZ- AA furgon-Bread free VR / AR / low-poly 3D Model MAX OBJ 3DS FBX MTL

ちなみに、上記ダウンロードサイトでは、ユーザー登録が必要です。なので、ほかのものを用意できる人は好きな3Dデータを利用してOKです。「gaz-aa_bread OBJ.zip」をダウンロード、解凍したら、下記のディレクトリにそれぞれ配置します。

static_assets/gaz_aa/gaz-aa_bread.mtl
static_assets/gaz_aa/gaz-aa_bread.obj
static_assets/gaz_aa/gaz-aa_bread_cabin.jpg
static_assets/gaz_aa/gaz-aa_bread_detail.jpg
static_assets/gaz_aa/gaz-aa_bread_frame.jpg
static_assets/gaz_aa/gaz-aa_bread_furgon.jpg
static_assets/gaz_aa/gaz-aa_bread_wheel.jpg
static_assets/gaz_aa/gaz-aa_bread_wing.jpg

上記ファイルのうち、実は「gaz-aa_bread.mtl」については変更する必要があります。

テキストエディタなどでファイルを開き、「D:\Program Files\Autodesk\3ds Max 2009\scenes\GAZ-AA free models\gaz-aa_bread_3ds_max*.jpg」となっているところを「*.jpg」に書き換えましょう。これはきっと作ったときそのままのローカルのパスが入ってしまったのですね。公開する際の要注意ポイントと言えそうです。

ジオラマの背景に必要な素材は、角となる2面分の壁用のテクスチャと、床に使うテクスチャです。前回使ったPanoコンポーネントで、6面にテクスチャを貼り、部屋状にしてしまうこともできますが、それだとリアルな空間になりすぎ、ジオラマっぽくなくなるからです。3面しか壁を用意しないことで、後ろには漆黒の空間が広がる感じになり、なんだか超現実的な世界になります。

背景の壁のテクスチャ

床のテクスチャ

壁と床のテクスチャは以下からダウンロードしてください。

diorama

ちなみに、壁と床のテクスチャは、僕がそのへんで適当に撮ってきたものなので、フリーでお使いいただいて構いません。

ダウンロードしたら、「プロジェクトディレクトリ/static_assets/diorama」以下に「floor.jpg」と「wall.jpg」を配置しましょう。

STEP 1. まずは、ジオラマのベースづくりから

早速トラックを配置したいと、はやる気持ちを抑えてまずはジオラマのベースとなる背景の壁と床を作るところから始めましょう。床は、1000 x 1000の大きさを持った板を想定しました。これは、Panoコンポーネントで作った空間と同じ大きさとなります。そして、奥の壁は床から500の高さを持つ平面です。これにテクスチャをつけることで、リアリティを持たせます。では、具体的な作業をしましょう。

「index.vr.js」のViewの中を一旦空にし、下記のように修正します。

それと、importも変更しておきましょう。この先に使うModelコンポーネントやライティング関係のコンポーネントも加えておきます。

import {
  AppRegistry,
  asset,
  View,
  Plane,
  Model,
  DirectionalLight,
  PointLight,
  AmbientLight,
} from 'react-vr';

Viewコンポーネントが入れ子になっているのは、内側のViewは、ジオラマの背景セットで、セット全体を変形させたい場合はこのように入れ子にしておくと、壁や床を一つの塊として扱えます。ここではジオラマのセット全体をちょっと回転させています。というのも、最初に表示したときに部屋の中央ではなく、部屋の角を見せたいためです。

ジオラマのセット自体を回転させずに、カメラを回転させるという表現方法もありますが、普通ジオラマというのは、インテリアの側面もあり、一番かっこいいポジションで飾るものだと思います。そこで、View自体をY軸に対して-20度回転させました。

さらに細部を見ていきましょう。3つのPlaneが、内側のViewコンポーネント内に配置されていますが、先頭2つのPlaneコンポーネントは壁として配置してあります。位置を遠くに置いたのと、Y軸方向に90度回転させて垂直にそれぞれのコンポーネントが交わるようにしています。

Planeコンポーネントに関わらず、3Dプリミティブコンポーネントは、テクスチャを設定することができます。テクスチャはtexture属性で設定します。

ここではtexture属性に、「diorama/wall.jpg」を指定しました。これによりのっぺりとした壁が質感のある壁となりました。ちなみに、この壁は近くの公園の壁を撮影したものです。

一番最後のPlaneは、床として配置しています。X軸方向に-90度回転させ、テクスチャを貼りました。これは海に行った時の砂岩の岩肌です。深い意味があるわけではないですが、オフロードっぽい印象になる写真が見つからなかったので、こちらを採用しました。

$ npm start

を実行し、ブラウザでURLを開いてみましょう。ただし、こんどは「http://localhost:8081/vr/?hotreload」で開いてみてください。「?hotreload」を付けてブラウザから開くと、ホットリロードが可能になります。これで、エディタで編集したコンテンツが自動でブラウザ側に反映されるようになります。

配置した背景

3方向のみPlaneを配置しただけの簡素なジオラマセットですが、VRで角のほうを見るとなかなかどうして迫力がありますね。

STEP 2. 3Dモデリングデータを配置しよう!

続いて、お待ちかねの3Dモデルの読み込みです。3Dモデリングデータの読み込みには、Modelコンポーネントを使います。Modelコンポーネントには、source属性を記述することができます。渡す内容は、objとmtlというキーを持ったオブジェクトで、それぞれobj形式のファイルとmtl形式のファイルへのパスを渡します。

今回であれば、「配置するモデリングデータ」で保存しておいた「static_assets/gaz_aa」以下にあるobjファイルとmtlファイルが対象になります。

Modelコンポーネントは、「index.vr.js」の入れ子の内側のView以下に配置します。サイズは小さめにし、位置調整とrotateYプロパティを修正して、若干の回転を加えます。これは、ちょうど左前に向いた形がきれいだからです。コードは下記のようになります。

これで、ブラウザをリロードしてみてください。3Dモデルが表示されるはずです。

まだ光が当たっていないので真っ黒

ただし、真っ黒なシルエットになってしまっていますが。ということで、続いて光源を用意して、明るくしていきましょう。

STEP 3. ライティングしてトラックを美しく!

ライティングは、前回3Dプリミティブオブジェクトで遊んだ際に試したのを思い出してください。メインの明かり、部分的な明かり、ちょっとした調整です。今回も同じような感じで進めます。

実は、React VRで使われている3DライブラリのThree.js本体には、ライティングに関する様々なヘルパー機能が用意されています。例えば、照明の向き、範囲などを視覚的に表示して微調整をする機能などです。ただ、現時点のReact VRではもっと限定的なサポートとなっているのでそこまで細かくは扱いません。

「index.vr.js」にDirectionalLightとPointLight、AmbientLightコンポーネントを配置しました。これで、トラックが綺麗に表示されるでしょうか。

トラックがちゃんと表示された！

ブラウザをリロードしてトラックを再表示してみましょう。明るくなったでしょうか。

STEP 4. トラックをゆっくりと回転させてみる

以上で一旦はジオラマは完成しましたと言ってもいいかもしれません。ただ、今まで物体を空間に置いてみて歯がゆかったのは、その物体の裏側がどうなっているのか、それが見えないということでした。ということで、アニメーションの練習がてらトラックを回転させてみましょう。

回転に関しては、ピッタリのサンプルが公式のリポジトリに用意されています。

react-vr/Examples/ModelSample at master · facebook/react-vr

このサンプルを参考にトラックのアニメーションを作ってみます。ちょっとサンプルと異なるのは、Reactのコンポーネントとして作るというのと、細かなロジックを修正した点です。Reactコンポーネントとして、回転速度を定義するspeed属性と、表示位置や大きさを定義するstyle属性を渡せるように作っておきましょう。「src/component/GazAa.js」として下記のように作成します。ちょっと長くなるので、細部の話は置いておいて、まずは一気に掲載してしまいます。

import React from 'react';
import {
  asset,
  View,
  Model,
} from 'react-vr';

export default class GazAa extends React.Component {

  constructor() {
    super();
    this.state = {
      rotation: 0
    };
  }

  componentDidMount() {
    this.rotate();
  }

  componentWillUnmount() {
    if (this.frameHandle) {
      cancelAnimationFrame(this.frameHandle);
      this.frameHandle = null;
    }
  }

  rotate(timestamp) {
    const delta = timestamp - this.lastUpdate || 0;
    this.setState({rotation: this.state.rotation + delta / this.props.speed});
    this.lastUpdate  = timestamp;
    this.frameHandle = requestAnimationFrame(this.rotate.bind(this));
  }

  render() {
    return (
              
            
    )
  }
}

ポイントは、GazAaコンポーネントのローカルステートとそれを変更するためのrotate関数、そしてそこで使われているrequestAnimationFrame関数とcancelAnimationFrame関数です。

GazAaコンポーネントは、シーンに配置した瞬間、つまりコンポーネントがマウントされた時から回転を始めます。逆にコンポーネントをアンマウントすると回転をやめる処理をします。回転の状態はコンポーネントのローカルステートとして定義されているrotationです。

rotationは、3DモデルのrotateYとしてY軸方向にどれだけ回転するかという値として使われることになります。その値をコントロールしているのがrotate関数です。requestAnimationFrame関数は、ブラウザの再描画のタイミングでrotate関数を呼び出すことになるので、呼び出すたびに前に呼び出された時間からの回転をrotationに反映していきます。requestAnimationFrame関数から返った値は、アニメーションをキャンセルするときにcancelAnimationFrame関数にて使われます。

requestAnimationFrame関数について一つ知っておきたいことは、この関数はもともとブラウザに実装されていますが、ブラウザによってはサポートされていないことがあります。そこで、React VRでは、requestAnimationFrame関数のpolyfillとして用意されています。

これで大体のGazAaコンポーネントの仕組みが理解できたでしょうか。今はこういうスタイルでアニメーションを実現したりしますが、将来的にはもっと洗練されたアニメーション機構が用意されていくのだろうと推測します。

では、先ほど作ったGazAaコンポーネントを使っていきましょう。「index.vr.js」で使うので、まずはインポートします。ファイルの先頭あたりにimport文を書きます。

import GazAa from './src/component/GazAa'

続いて、入れ子になったViewコンポーネントの内側に、GazAaコンポーネントを配置します。プロパティとしては、回転速度を定義するspeed属性と、表示位置や大きさを定義するstyle属性を渡しています。これら属性は、GazAaコンポーネント内のthis.props.XXXにて受け取ることが可能です。これらを記載したコードが以下になります。

以上で、トラックが回転するジオラマの完成です。ブラウザをリロードして、じっくり見てみましょう！

完成したVRジオラマ

もし興味があれば、React VR×360度画像！Web上でパノラマVR表示を試すを参考に、GearVRで眺めてみましょう。子供の頃叶わなかった、巨大サイズのジオラマを見ることができますよ。

React vs Angular 2ガチ対決！エキスパートたちによるハイレベル対談 (2 / 2) ー TechFeed Live#2レポート

白石俊平 — Tue, 13 Dec 2016 01:54:04 +0000

こんにちは、編集長の白石です。

本記事は、2016年9月に開催されたTechFeed Live#2 「React vs Angular 2」の模様をお伝えする記事の後編です（前編はこちら）。 TechFeed Live#2とは、「TechFeedを地上に出現させる」ことをコンセプトとした、テクノロジーの最新トレンドをエンジニア向けに紹介するというイベントです（TechFeedとは、「最先端が、ここにある。」をキャッチコピーとしたエンジニア向け情報収集アプリです）。本イベントは、ReactとAngularをより楽しく深く学ぶため、現代のWebアプリに求められる各種要件についてそれぞれを比較する…というアプローチを取りました。（私は本イベントの企画と対談のモデレーターを務めました）

読み応えバッチリ、勉強になること間違いなし。今回はライブ感を重視し、あえてイベントでの（砕けた）口調も可能な限り再現してみました。では皆様、どうぞお楽しみください！

かなりの熱気でした

トークバトル参加者（順不同、敬称略）

（編集部注: 本記事では登壇者の皆様の希望により、以下ハンドルネームで呼称させていただきます）

React Side

koba04 (小林徹)
yosuke_furukawa (古川陽介) (Node.js 日本ユーザグループ代表)

Reactサイド。左がkoba04、右がyosuke_furukawa。

Angular2 Side

laco (稲富駿)
83 (奥野賢太郎) (ng-kyoto代表)

Angular2サイド。左がlaco、右が83

モデレーター

shumpei (白石俊平) (HTML5 Experts.jp編集長)

また今回、フレームワークを比較するための項目を以下のように洗い出してみました。基本的にこの流れに沿って進めたいと思いますが、脱線は大歓迎ですので、皆様ご自由にご発言いただいて構いません。（編集部注: 後半は「スタイリング」から）

~~開発⾔語~~
~~アーキテクチャ~~
~~ビルドツール~~
~~ルーティング~~
~~テンプレート~~
スタイリング
コンポーネント以外の処理
ツールサポート
テスト
パフォーマンス
サーバサイドレンダリング

スタイリング

shumpei 次はスタイリングについてお話いただきたいと思います。コンポーネントにスタイルを当てる云々の話、ですね。では、Reactサイドから伺いましょうか。ReactのCSSサポートの現状といったところからお聞かせ願えるとありがたいです。

yosuke_furukawa CSS in JSとかそういったあたりの話ですね。CSSをJSの中にimportして、JavaScriptのオブジェクトかのように、コンポーネントにスタイルを当てることができる機能があります。厳密なCSS in JSは、style属性に直接値をぶち込みます。そうすると、上からのCSSの影響を相当受けにくくできる。そこまでいかなくても、CSS Modulesというのがあって、クラス名をuglify（難読化）してかぶらないようにして、中ではそのuglifyされたクラス名を使ってスタイリングを行い、外からの変更を受けにくくするというやり方もあります。

そういう感じで、CSSとJSを一体化して扱うということは、React界隈ではわりとやられています。

shumpei React本体はスタイリングとかに関する機能とかは持っていなくて、外のライブラリを使って実現するという感じなんですね。

koba04 はい、React本体としては、CSSは属性の一つ(style属性)なので、特別なサポートはそれほどありません。オブジェクトで値を指定できたり、幅や高さの単位を省略して指定できたりするくらいです。あとはwebpackとかの外部のエコシステム上で、それぞれ好きにやっているという感じです。

shumpei では、Angular 2サイドはいかがでしょうか？

laco Angular 2は、@Componentデコレータの中にstylesという属性があって、そこに書いたスタイルはコンポーネントの中にしか効かないようになっています。Shadow DOMと同じ動きをするようにエミュレートされています。

yosuke_furukawa どうやってエミュレートするんですか？

laco えーと、BEMみたいなのを自動的に生成します。それでかぶらないようにする。まあ、CSSをインポートすることはしないですが、文字列で指定してるので結局インポートしてるのとあまり変わらないというか…あんまり変わらないですね(笑)やりたいことは(Reactと)一緒です。

だけど違うのは、設定を一つ変えるとネイティブのShadow DOMを使えるように変えられます。現在のデフォルトはエミュレーションになってますが、将来的にShadow DOMに対応したブラウザが増えた時に、さくっと変えられるようにはなっていますね。

koba04 この辺 (スタイリング) は結構、開発メンバーの中にデザイナーさんがいるのかとか、JSがメインの人ばかりでやるのかとかで、どうCSS書くのかが変わってくると思うので、選択肢がいろいろあったほうがいいんじゃないかな、とは個人的には思っています。

副作用を伴う処理

shumpei では次に行きましょう。APIコールなど、副作用を伴う処理をどう扱うかは、フレームワークごとにかなりアプローチが異なってくるところだと思いますが、そこら辺の事情を伺わせてください。

laco まずAPIコールでいくと、Angular 2だとHttpというライブラリがあって、それを使うという話になります。

koba04 今「ライブラリ」という言葉が出ましたが、(APIコールをするのに)外部のライブラリを使うという話なんですか？

laco npm的には別パッケージになってるんですが、Angular 2の一部という扱いです。サブパッケージと言ってもいいです。

koba04 そこをフレームワークが直接サポートする必要って何かあるんですか？

laco (Httpライブラリ内で) DIをガリガリ使っているというのと、Angularはフルスタックなフレームワークなので、アプリケーションを作るのに必要なものはとりあえず揃えておくというポリシーですね。

83 あと、Angular 2のHttpをDIで使っておくとテストが楽、モックのAPI Callを自分でガリガリ書いたりする手間が省けるというのが利点かなと思います。

shumpei ちなみに個人的には、Reduxをちょっと調べた時にミドルウェアでAPIコールをしているのが「難しいな」と思ってしまったんですが、ああいうのは慣れれば全然問題なくなるもんなんでしょうか。

yosuke_furukawa そこで難しいな、と思っちゃうのはまだReduxに慣れてない証拠です。

shumpei ほう。

yosuke_furukawa Reduxっていうのは基本的に副作用をどんどん外していってるんです。APIからGETして取ってきたデータをステートに反映するというのは、これは副作用そのものなんです。で、こういう副作用をどこでやるかと言ったらミドルウェアでやる、というのがReduxの基本的な考え方なんです。そこに慣れると、みんなミドルウェアで書くっていうのがなんとなくわかる。そこに慣れてない人は、Reduxをフレームワークだと思って使っちゃうんです。

shumpei なるほど、基本的な思想がちゃんと理解できていなかったんですね、ぼくが。

yosuke_furukawa あとReduxミドルウェアと言ってもいろいろあって、redux-promiseだ、redux-thunkだ、redux-observableだ、redux-sagaだと、ぼくはredux-effectsっていうのを使ってるんですけど。要は、副作用が必要なときに副作用を発生させる方法っていうのはたくさんあるし、非同期の処理の仕方一つ取ってもたくさんあるわけです。 ES6のジェネレーターでやるっていうのがredux-sagaだし、そうじゃなくてPromiseでいいんじゃないの、っていう人はredux-thunkだとかredux-promiseだとかを使う。

そうじゃなくてもうちょっと高次元なことをしたい、複数のイベントを包括的に扱ったりしたいという場合はObservableが必要になってくる、と。それはどこまでデカい規模のものを作るかによってミドルウェアの選定をしなくてはならなくて、そこをツライと言ってしまうとちょっと(Reduxを使うのは) 厳しいかもしれません。

フレームワークなのかライブラリなのかという話でいくと、昔あったAngularJSのMVWhateverだったりなんだったりっていうものをReduxの何かで置き換えられるかというと、あんまりそんなことやってくれないんですよね。結構薄いライブラリなので。フレームワークじゃないとぼくがずっと言っているのはそういうことです。

何かおまかせできるわけじゃなくて、自分たちでシンプルなAPIをたくさん作って、やってくれるのは状態の管理とイベントの管理だけ、というのがReduxの思想というか。で、副作用を徹底的に省いてくれる。

でもみんな気になってるのは、その副作用をどうやってやるの、というところで、フレームワークを使いたいと思っている人にとってはそこにミスマッチがあるんじゃないかと思っています。

テスティング

shumpei では、テスティングについてはいかがでしょう？

yosuke_furukawa コンポーネントのテスト書くか書かないか、って話があるんですが。書くか書かないかをまずはお聞きしたい。書くとすると、こちらはenzymeっていうツールを使ってます。

laco こっちはKarmaっていうのを使います。KarmaはAngularチームが作っているテストフレームワークです。なので、KarmaがAngularと一番相性のいいテストフレームワークとして使ってますね。

あと、Angularがテスティング用のAPIを内包しているおかげで、コンポーネント単位でのテストができるようになってます。たぶんenzymeとそんなに変わらないと思います。

koba04 そうですね、enzymeはいろいろラップしていて、DOMにマウントしたコンポーネントに対するテストとか、renderToString()で書き出したHTML文字列に対するテストとか、対象のComponentだけを浅くrenderするShallowRendererなどを提供しています。

そういうのを提供するために、ReactはTestUtilsというアドオンを提供しています。最近だとTestRendererっていう、ツリー構造をただのJSONで返してくれて、それに対してテストするみたいなのもあります。なので、テストは書きやすいかな。あと、Reactのコンポーネントって多くはただの関数で、状態を持たない。入力を与えたら、React Elementのオブジェクトが返ってくるというただの関数なので、テストも簡単に書けるという感じです。

Reduxとか使うと、そのただの関数の部分がReducerだったりと増えてくるので、より簡単に書けるとは思います。あとShallowRendererだったらDOMにも依存しないので、JSDOMなどを使う必要ないし、NodeとかでMochaとかPower Assertとか使って簡単にすぐかけるというのはいいところかなあと思います。

laco 書くか書かないか問題で行くと、Angular 2の場合は書かないとまずいんですよね。テンプレートが間違ってた時に本番でぶっ壊れるので、テンプレートがコンパイル可能かというのを、コード生成可能なテンプレートになっているかというのをテストしないとまずくて。JSXの場合はコンパイルエラーになってくれるけど、Angular 2のテンプレートはただの文字列なので、実行するまでわからないというのがあって。

yosuke_furukawa ただ、そもそもビューのところって変更が一番多いところだと思うんです。そこってテスト書いちゃうと、ROI (投資対効果) 的にというか、コストがペイしないんじゃないかとぼくは思っていて。なので、基本は「書かない」がいいんじゃないかと思ってます。

laco コンポーネントの中のプロパティのテストとかですか？

yosuke_furukawa そう、それとか…。

laco だったら、基本やんないですね、あんまり。

yosuke_furukawa lacoさんの言っているテストっていうのは、テンプレートがコンパイル可能かどうかの(最低限の)テストってことですか。

laco そう、それは全コンポーネント通しておかないと夜も眠れない(笑)。

yosuke_furukawa それは、たしかに(Reactは)JSXはコンパイル時にわかる。

laco それに、一口でコンポーネントっていいますが、そっちは関数ですが、こっちはステートを持つやつなんで、性質が全く違います。

shumpei AngularのほうはDIでテスタビリティを向上させている。一方でReactにはDIとかそういうのはないけど、Reactのコンポーネントはただの関数なことが多いからテストしやすいと。

yosuke_furukawa Reactのコンポーネントは基本的にステートを持たないから、そこ（DIとか）に関心がない。性質の違いですね。

パフォーマンス

shumpei 次はパフォーマンスです。これって議論になるのかな？

laco 今はもう、あんまり(どちらのフレームワークのパフォーマンスも)変わらないですよね。Angularのほうが初期ロードはちょっと遅いかもしれないけど、動き始めてからはあんまり変わらない。

83 これ、AngularJSでアプリ作ってて、Angular 2でもアプリ作ってて、って経験から言うと、AngularJSだから遅い、ってAngularのせいにできたんですよね。「ここ遅いのなんで？」って言われた時にAngularJSのせいです、って言っちゃえるという甘えがあったんですけど。

最近Angular 2とReactほとんど差がないんで、自分の書いてるコードが酷い可能性のほうが高い。自分の書いたコードを疑えって言う。最近パフォーマンスというか、自分がどれだけ最適化されたコードを書けるかとか、遅かった時にどう測定してどこを最適化していくか、っていうところにかかってるんじゃないかなと思います。

laco (Reactは)たぶん、ミドルウェア書けば書くほど遅くなりますよね。Angularも、いろいろやればやるほど遅くなる。DOMの書き換えパフォーマンスはどちらも変わらないと思います。

yosuke_furukawa ただ、DOMの書き換え周りって、仮想DOMとか変更検知のアルゴリズムとかも関わってくる話ですよね。変更検知については、Angular1の頃は、自分でイベントループみたいの持っててそこでダーティチェックしてたけど、2はどうなってるんですか？

laco Zone(.js)の話になるんですけど…Zoneの話長いんで(笑)。ざっくりいうと、windowをモンキーパッチして、

yosuke_furukawa モンキーパッチ！？(笑)

laco setTimeout()とかXHRとか非同期イベントが起きた後は必ずAngularのイベント呼ぶようになってる。

yosuke_furukawa マジかよ…めちゃEvilじゃないか…！(笑)

laco でもそれがTC39にZoneとして提案されていて、すでに（ステージ）0にもなってるんですよ(笑)。 (編集部注: ECMAScriptの仕様策定は、アイデアレベルの提案がステージ0に始まり、成熟するに従ってステージを登っていく）

だから…あれ、何の話だっけ。ああそうか、変更検知のイベントループの話だ。(Angular)1の頃はループガンガン回してたけど、それはもうないです。何も起きてないときは何も動かない。何かしらクリックしたとかがあったら、イベントが走って、windowからAngularにお知らせが来る、というふうになってるんです。

koba04 パフォーマンスっていう意味で言うと、Reactは基本やることが少ないし、やることが明確なので、チューニングはしやすいのかなあと思います。 react-addons-perfとか使って計測して、パフォーマンスチューニングのポイントもshouldComponentUpdateを実装するか、renderの中をちょっと見直すとかなので。

laco しかし、仮想DOMは速かったけど、Angularも追いついちゃいましたね。しかも仮想DOMなしで。結局仮想DOMってどうだったのかなあ…と。「ポイント、そこじゃなくない？」っていう(笑)。 (筆者注: ここ、lacoさんがイベントを盛り上げるため煽ってくれてます)

koba04 まあ、仮想DOMだからこそ、ただの関数みたいな形でコンポーネントを簡単に作れるようになったので…。

laco でも、最近Pure Componentって入ったじゃないですか。Shallow Rendererとか。あれってどうなんですか？この間ものすごく疑問に思って。Pure Componentにすると、オブジェクトの状態を自動で見て、自動で変更検知してくれるってやつですよね。 あれって、Reactがやりたかったことなんですか？

koba04 あれは、オブジェクトツリーがでかくなると仮想DOM比較のコストもバカにならないので、その比較すらも飛ばしたい時に使うっていう感じです。

laco 仮想DOMのアルゴリズムが敗北したってことじゃないですか？(笑)

shumpei 煽る煽る(笑)。

koba04 基本的にはそこまで必要とするものでもなくて、よっぽどパフォーマンスが求められる場面で使われるものかなと思っています。

yosuke_furukawa ぼくとしては、パフォーマンスのチューニングポイントが増えたって話だと思ってます。仮想DOMの敗北については、次のサーバーサイドレンダリングでぼくが話をするんで、まあここはこれくらいでいいんじゃないかなと(笑)。

会場 (笑)

サーバーサイドレンダリング

shumpei じゃあ、サーバーサイドレンダリング(SSR)について、yosuke_furukawaさんどうぞ(笑)。

yosuke_furukawa そうですね、実際にSSRでもコンポーネントのツリー構造を作って、そのツリーに対してReact DOMのIDを割り振るっていうような「仮想DOMを構築する処理」が入るわけなんですが、それって普通のテンプレートエンジンだとまずやらない処理なんですよね。普通のテンプレートエンジンはHTML生成すればいいだけだから。効率化されているんです。

そこをReactのrenderToString()とかでやると、まあ、そこまで効率化されていない。もしかしたらキャッシュとか持って、効率化する余地はあるのかもしれないんだけど、今のReactだとそこまで効率化されていないので、やっぱりテンプレートエンジンとしてのスピードを見るとそこまで速くないんです。そこがちょっとね、どうしたもんかね、と。

ぼくが今やってるやつだと、1レンダリングするのに50ミリ秒とかかかっちゃって、しかも50msecかかった時に、Node.jsなんでイベントループが止まっちゃってるんですよね。だから由々しき問題、由々しき事態なんです。だからそこは、非同期処理にしてイベントループを止めないようにするか、キャッシュですごい速くするか、そもそもDOMツリーを構築するところをなんとかするかと言ったことが必要なんですけど。

koba04 そういう意味では、Reactってサーバーサイドレンダリングできるんですけど、正直あれなんで入ってるのかぼくはよくわかってなくて(笑)。Facebook自身も使ってないですしね。中のアルゴリズムを見ると、クライアントのDOMを作るときと同じコードを使っているので、それは当然文字列作るのと比べれば効率悪い。そこはもしかしたら新しいアルゴリズムが入ることで効率化するのかもしれないけど、たしかに今だとパフォーマンスが問題になるのは明白な感じの実装にはなってます。

yosuke_furukawa Netflixとか、いろんな企業が実際にサーバサイドレンダリングはやってるんですけど、初期表示のレンダリングするところだけサーバサイドレンダリングして、あとはスクロールするたびにちょっとずつクライアントサイドレンダリングしてたりする。それって地獄じゃねえのか、と(笑)。そういうことが簡単にできるライブラリとかが別途あればいいんだけど、今のところまだないから、そういう意味だと、仮想DOMは敗北に近いかなと。サーバサイドレンダリングするなら。

shumpei Angular 2のサーバサイドレンダリング事情はどうですか？

laco Angularのサーバサイドレンダリングは…たぶんあんまり変わらないですよ。基本的に遅い。ただ何がいいかって、ルーティングとかHttpとか、Node上でも動くように全部パックされてるという、フルスタックならではの安心感はありますね。

ルーティングが済んだ状態のSSRも簡単にできるし、SSRするときに最初にAjaxが必要だったら、Node上で動く@angular/httpみたいな、ユニバーサルなやつが提供されている。それを使えば、変更検知された状態のSSRがちゃんと出ます。全部レールに乗ってるっていう、そこらへんの安心感はありますね。

ライブラリか、フレームワークか

shumpei はいでは、お時間も迫ってまいりましたので、そろそろ終わりにしたいと思います。

83 あ、一ついいですか？ちょっとこのイベント自体に苦言を呈したくて。

会場 (笑)

shumpei え、なんでしょう？

83 ReactとAngularっていうのを比べるのって、みんな大好きですよね。でも、ほんとはこれって比較できるもんじゃないんですよ。型が一致しないものは比較できないんですよ。

会場 (笑)

83 で、比較できないものを比較しているというのは、こういう項目を挙げてやっているっていうのは、フレームワークの相互プレゼンテーションみたいな感じで、Reactはこうですよ、Angular 2はこうですよ、という感じでやってるんですけど、ほんとにそれがみんな聞きたい話なのか？って思うんです。

私はlacoのほうからオファーを受けて呼んでもらったんですけど、こんだけすごいパネラーが揃ってて、順番にフレームワーク・ライブラリ紹介合戦みたいになってて。これじゃないでしょ、って思ってるんですよね。もっと、フロントエンドのエンジニアとして、Web APIがどういうものがあって、いつ何を使うか、どう組み合わせるかっていうのがやっていくべきことなのに、何年かしたらすぐ廃れるようなライブラリの議論なんてのに、似非プロレスなんてのをやっていても、これは違うんじゃないかなあ、と思うんですよね。

shumpei すいません、、反省します。

83 いえいえ、これ、言っとかないと終わってしまうな、と。すいません。

yosuke_furukawa いえいえ…最高です(笑)。

前編もあります

React vs Angular 2ガチ対決！エキスパートたちによるハイレベル対談 (1 / 2) ー TechFeed Live#2レポート

白石俊平 — Tue, 13 Dec 2016 01:39:21 +0000

こんにちは、編集長の白石です。

本記事は、2016年9月に開催されたTechFeed Live#2 「React vs Angular 2」の模様をお伝えする記事の前編です（後編はこちら）。 TechFeed Live#2とは、「TechFeedを地上に出現させる」ことをコンセプトとした、テクノロジーの最新トレンドをエンジニア向けに紹介するというイベントです（TechFeedとは、「最先端が、ここにある。」をキャッチコピーとしたエンジニア向け情報収集アプリです）。本イベントは、ReactとAngularをより楽しく深く学ぶため、現代のWebアプリに求められる各種要件についてそれぞれを比較する…というアプローチを取りました。（私は本イベントの企画と対談のモデレーターを務めました）

当日のイベントは大盛り上がりでした。

React vs Angular 2対決開始！

shumpei 本日は、多くのお客様にご参加いただいて、大変うれしく思います。今回のTechFeed Liveは、「React vs Angular 2」と題しまして、今をときめくコンポーネント指向のWebアプリケーション・フレームワーク2つを比較して学べる会を目指しています。

そのために、それぞれのフレームワークのエキスパートの方々にお集まりいただきました。

トークバトル参加者（順不同、敬称略）

（編集部注: 本記事では登壇者の皆様の希望により、以下ハンドルネームで呼称させていただきます）

React Side

koba04 (小林徹)
yosuke_furukawa (古川陽介) (Node.js 日本ユーザグループ代表)

Reactサイド。左がkoba04、右がyosuke_furukawa。

Angular2 Side

laco (稲富駿)
83 (奥野賢太郎) (ng-kyoto代表)

Angular2サイド。左がlaco、右が83

モデレーター

shumpei (白石俊平) (HTML5 Experts.jp編集長)

また今回、フレームワークを比較するための項目を以下のように洗い出してみました。基本的にこの流れに沿って進めたいと思いますが、脱線は大歓迎ですので、皆さんご自由にご発言いただいて構いません。（編集部注: 前半は「テンプレート」まで）

開発⾔語
アーキテクチャ
ビルドツール
ルーティング
テンプレート
スタイリング
コンポーネント以外の処理
ツールサポート
テスト
パフォーマンス
サーバサイドレンダリング

では早速始めましょう！

開発言語

shumpei まずは開発言語について語っていただければと思います。Reactから聞いてみたいと思いますが、Reactを使った開発は基本的にどんな言語を使うのでしょうか？

koba04 基本的にはBabelを使って、ES6以降のコードをES5に変換しつつ開発しますね。でも、TypeScriptを使う人もいます。Babelの作者はFacebookにいたりするので、基本的にはBabelだと楽ですね。

shumpei なるほど。Angular 2のほうはいかがですか？

laco 基本的には開発言語はJS, TypeScript, あとDartがあります。

会場 (笑)

laco いや、Dartは笑いどころじゃないでしょう(笑)。公式に推奨されているのはTypeScriptです。ES6書いてBabelでもいいし、ES5でも書けることは書けますが、結構キツイんで、基本的にはTypeScriptで書くのがデファクトになってます。

83 ちょっと待って下さい。結局なんの言語で書きますか、というのが重要で。Reactだったらどの言語、Angularだったらどの言語、っていう 質問がおかしい 。

shumpei そうですか…すいません。

83 大きいものだったらTypeScriptのほうがいいし、小さいものだったらAngular 2でもES6とBabelのほうがサクサク作れます。Angular 2はTypeScript専用だよね、ということはよく言われますがそれは違うと思います。

shumpei ちなみに、BabelでAngular 2を書くというのは全然ありなんでしょうか？

laco 全然ありですよ。そのためのプラグインも、 Shuhei Kagawaさんという方が作ってます。Flowの記法とか使って、型があるように書けます。

あ、一つReactサイドに聞きたかったんですが、JSXってみんながみんな使うもんなんでしょうか？

yosuke_furukawa そうだと思います。ぼくもJSXなしでやってみようと思ったこともあるんですけど… 結論としては、(JSXが) ないとダメだなと (笑)。 結局HTMLっぽく書きたくなるんですよ。

ちなみにさっきの言語の話を少し深掘りしたいんですけど、言語は規模で決まるというのは確かにそのとおりだと思うんですが、一方でエコシステムとかを見ると、BabelをES6じゃない言語で書いてエクスポートしてる例ってあんまりないんですよね。

例えばTypeScriptでライブラリ書いてエクスポートしてるなんてあんまりない。なので、エコシステム全体としては、どっちの言語がより慣れているかという度合いはあるのかなと。そういう意味では、ReactはBabelでAngular 2はTypeScript、というのはあるんじゃないかと思います。

83 そうですね、そういう意味で言うと、(Angular 2も)公式サイトのチュートリアルとかも全部TypeScriptで書かれていたりするので、そういう住み分けとかは色がはっきりしているかなと思います。ちなみにReact陣営に聞きたいんですけど、TypeScriptは「GoogleがMicrosoftと手を組んだ」なんてよく言われてますが、(React開発元のFacebookが開発している) Flowってどうなんですか？

yosuke_furukawa 実際、React自身はあんまりFlowでっていう話はないです。(Reactコンポーネントの) propTypesを、Flowで書けるようにしよう、って話は進んでるみたいですが。

「propTypesで型チェックをしていく」というのがあんまり綺麗じゃないというか、書き方として洗練されている気がしない。なのであれをFlow側に寄せていこうという活動はあるみたいです。

koba04 FacebookがFlowを強制してくるってことは全然ないですね。propTypeを置き換えるときも、FlowかTypeScriptか、好きなのを使えばいいという感じです。そこは、フレームワークが特定の型システムに依存する必要はないので、好きに使っていけばという感じです。

shumpei ちなみに、ご存じない方もいらっしゃるかもしれないので、Flowってなんでしょうか？

koba04 Flowは、静的な型チェックをするためのライブラリです。まあ、思想としてはもっと踏み込んでいて、JavaScriptでハマりがちなコードとかを静的解析して、静的な型付け以外のチェックをやっていこうと。

そういう意味では、ESLintとかもカブる部分がありますね。例えばnullチェックをしているかどうかとかも確認できたりとか。静的型付け以上に、JavaScriptでハマりがちなエラーをチェックするためのツールという面が大きいかなと思います。

shumpei コードそのものは、JavaScriptで書くということですね。

アーキテクチャ

shumpei 次の話題はアーキテクチャについてですが、アーキテクチャというとぼんやりしてますね…。これぼくなんでこのお題を出したんだっけな。えーと…、あ、思い出した。Fluxとかの話をしようと思ったんだった。FluxやReduxなど、アーキテクチャに関してちょっとご説明をお願いしてもいいですか？

yosuke_furukawa 基本的にReactだけだと、イベントや状態を管理する仕組みがないんです。ReactってViewのライブラリなので。Webアプリって、APIサーバを叩いてデータをもらってきてそれをレンダリングするとか、そういうのが普通ですよね。そういうことをしようと思ったら、Reactだけじゃ厳しいんです。そういう時に、イベントを管理する仕組み、あと状態を管理する仕組みっていうのが必要になってくる。そういう時に必要になってくるのがFluxであったり、Reduxであったりというライブラリです。

Fluxはライブラリというよりは「思想」というか、デザインパターンに近いですね。イベントを管理するための、Observerパターンを言い換えたというか。あれねえ、何がすごいかって、名前を付けたのがすごいですよね。カッコいいですよね。名前の勝利です(笑)

そういう (Fluxという) 考え方が浸透してきたところにReduxっていうのが出てきて、今一番流行っているライブラリです。

ただひとつ間違えちゃいけないのは、ReactとFlux、ReactとReduxを組み合わせたからといって、Angularほどの「フレームワーク」といえるかというとそこまでいってない。ただライブラリを組み合わせただけのものでしかなくて。さらに、その上で自分のレールを作っていく必要があるんじゃないかなとは思います。

shumpei なるほど、ReactはReactだけで完結しないと。一方Angular 2のほうは「One Framework」だそうですね。

83 Angular 2の話をする前に、AngularJS(AngularJS 1)のほうに一旦戻ろうかなと思うんですが。そもそも1のころは、エコシステムが「Angular World」だったと。

まだ今あるようなES6のモジュールとかがなかった時に、それでもモジュールの仕組みが欲しいとか、そういう要望があったと。なので、angular.module()の中に書いていくというのがあったんですね。

で、それがあったからAngularはエコシステムに乗っていない、一方でReactは乗っているというような分断が起きはじめました。それ自体は2年前くらいは正しかったのですが、そのイメージをAngular 2になっても引きずっている方がまだおられるんじゃないかというのが気になっています。

83 私はAngular 2を「フレームワーク」と言われることは好きじゃなくて、Angular 2は「ライブラリ」だと思っているんですよね。なんでかっていうと、Angular 2にデータを保存しておくものだったり、データのやり取りをするためのものっていうのが、別にAngular 2にはないんです。

Angular 2の特徴ってテンプレートとDIとかあると思うんですけど、実際にはAngular 2だけで全て事足りるかというとそうでもないし、そこは結構割り切ってAngular 2は好きなフレームワークと組み合わせられるようにもなっている。

その上で、Angular 2をどうやって使うかというと、RxJSがよく出てくると思います。RxJSはストリームやイベントを扱うためのライブラリで、FluxのObservableパターンと同じく、何か変化があるまでは動かない。何か変化がemitされたときにsubscribeしてる側で値を書き換える。それでテンプレートの描画が変わると。そういう意味では、今時代の変化が、Observableパターンに来てるんじゃないかなと思います。

shumpei ちなみにこれ、ご存知だったらでいいんですけど、Angular 2とReduxを組み合わせてみた、みたいな話もあるんですけど、そうしたことをする利点とかってなんなのでしょうか？

83 私は実際それをやってみて、別のイベントで発表したこともあるのですが、ぶっちゃけそのときは相当disりまして(笑)。 Reduxをdisったわけじゃないんです。Angular 2とReduxという組み合わせをdisったんです。Reduxは中立なライブラリとは謳われているのですが、実際にはReactを前提として作られたライブラリなので、まあそうなるわな、という感じでした。

Angular 2とReduxの組み合わせがなぜいけてないかというと、DIとの相性が悪いんです。 ReactにはDIという考え方が全くないし、ReduxもDIを全く無視している設計になっている。

なので、Angular 2はDIできるのに、Reduxと組み合わせると、ReduxのReducerの中では一切DIできない。何のためにDIができるAngular 2の中でReduxを使うのか。そこだけ別世界に飛ばされるような感じでした。

laco ざっくり言うとReduxにしてもFluxにしても、シングルトンなステートがあって、ステートの変更を検知してコンポーネントがデータを受け取って、コンポーネントがデータを書き換えて…っていうのをくるくるやるわけじゃないですか。

で、シングルトンってAngular 2だとDIで実現するんですよ。なので、Reduxいらないんですよね。仕組み、レールがすでにあって、あとはステートを持つやつを書くだけで、あとはDIでどうとでもなる。だから、Angular 2は結局、DIでどうとでもなります。

shumpei Reduxと組み合わせたみたいな記事をたまに見かけるんですが、それはAngular 2に足りないものがあって、Reduxがそれを補うのかなとかって勝手に想像していたんですが、別にそんなことないよ、って感じでしょうか。

laco たぶんバズワード組み合わせただけじゃないかな、と(笑)

shumpei なるほど(笑)。ちなみに例えば、ReactとRxJSを組み合わせる、みたいなバズワードの組み合わせ方とかはないんでしょうか。

koba04 もちろんそこは自由にできて、ReduxとRxJSを組み合わせるためのredux-observableというのをRxJSの作者が作ってたりします。RxJSを使いたい場合はそういう選択肢もある。

ただ、APIからデータ取ってくるだけだったらObservable (RxJS) 使う必要もなくてEventEmitterで事足りるかもしれないし、そこは自由に選んでくださいという感じですね。

ビルドツール

shumpei 次はビルドツールですね。ここは意見を戦わせるところでもなくて、ただ紹介するだけでいいのかなとも思いますが、暴走や脱線は大歓迎です。まずReactでは、ビルドツールには主に何を使いますか？

yosuke_furukawa 主にwebpackやBrowserifyですね。エコシステム全体がBrowserifyやwebpackを前提として作られたりしますので、それを使うのが普通です。コンポーネント志向なんで、コンポーネントを作ってexport/importするのが当たり前の世界になってます。

shumpei Angular 2サイドはいかがですか？

laco ここは何も変わらないですね。webpack使えますし、バンドル (編集部注: 複数のJavaScriptモジュールを1ファイルにまとめること) しないとブラウザでは使えないし。そういえば、最近npmリポジトリから落ちてくる（npm installでインストールされる）のが、ESモジュールになったんですよ。(requireではなく) import / exportがそのまま書かれている。なので、webpack2やRollupを使うとTree shaking (編集部注: 不要なコードを「振り落とし」、バンドルサイズを小さくすること) できるというのはありますね。

shumpei SystemJSっていうツールの存在も聞きますが。

laco (笑)

shumpei 笑っちゃうんですかw

laco ごめんなさい、ちょっと失笑です。あれはまだちょっと人類には早いって思ってます(笑)。

会場 (笑)

shumpei どこらへんが人類には早いんでしょう？

laco あれは世界がHTTP/2になるのを待って、出直してきてほしいツールです。importごとにリクエスト飛んだら、(HTTP/1だと)遅すぎて話にならないです。残念ながら。

shumpei 1ファイルにバンドルする機能とかはないんでしょうか？

laco ありますけど、それならwebpackのほうがエコシステムが育っているので、そちらでいいんじゃないかな。プラグインとか、Loaderとか。

yosuke_furukawa SystemJS待つくらいなら、ES Loader待ったほうがいい(笑)。

shumpei JSPMっていうのがあるみたいですが…、JavaScript Package Managerでしたっけ。

laco あー。あれ、いつまで存在してるんですか？

yosuke_furukawa その質問誰に聞いてるんですか(笑)。

shumpei なるほど、その程度の扱いということで(笑)。では、SystemJSは人類には早すぎるということで、Angular 2やってる方もwebpackやBrowserifyがいいんじゃないかなということですね。

laco Plunkerみたいなオンラインエディタ上でやるぶんには、SystemJS割と便利なんですけどね。ブラウザ上ではバンドルできないので。ただ、プロダクションでは使う用途ないですよね。

ルーティング

shumpei では次は、細かい話が混じって申し訳ないですが、ルーティングとかに関して言いたいことがあればお聞きしたいのですが。

yosuke_furukawa これは…Angularサイド圧勝じゃないですか？

shumpei そうなんですか？

yosuke_furukawa React完敗ですね。

laco ほんとか？？(笑)

yosuke_furukawa そもそもルーティングって、React本体には機能がないんです。で、デファクトスタンダード的に使われているReact Routerっていうのがあるんですが、これみんなdisってる(笑) 。とりあえず使ってみて、「これクソ使えねえな」みたいな話になるんですけど(笑)。

何が使えないかって言うと、ルーティングの時に最初にやってほしいことって「アクションを発火してほしい」んです。 APIを呼び出してデータを取ってくる、ということをしたいとみんな思うと思うんですが、そういうことをやってくれるような感じになってなくて、まず最初にコンポーネントをマウントしちゃうんです。コンポーネント指向なんで。

でも普通みんながやりたいのって、アクションだと思うんですが、それを書くための記法は今のところない。なのでしょうがないから、真っ白なコンポーネント出してそこでイベント発火させて(データを)取りに行く…みたいなことをみんなやってるんじゃないかな。あんまりよくないです。

なので、ぼくの頭のなかではReact Routerは決定版にはなっていない。決定版になってないがゆえに、デファクトスタンダードとはさっき言ったけど、みんな野良ルーターみたいの作っちゃって、結果今あんまりよくない状態になっている。 …というところが「圧敗」ですね(笑)。

shumpei 圧敗(笑) では、圧勝側のご意見も聞きたいです。Angularサイドはいかがですか？

laco 今の話をすると、Angular 2もパスとコンポーネントを結びつけるものだという考え方は変わらないです。ただ、コンポーネントがマウントされるときに呼び出されるフックポイントがあって、そこでリクエストを飛ばして、その結果を持ってマウントができるという仕組みがある。あと、「ルーティングしてもよいかどうか」というcanActivateみたいな仕組みもあって、出ていくときの仕組みもあって。そうしたイベントが全部RxJSに乗っていて、ルーティングが起きるときにはまずイベントが発火するので、使いやすくはなっています。

yosuke_furukawa そういう意味でいくと一応onEnterみたいなのはあるんだけど、そこでデータを拾いに行くのは、推奨しないってことになってまして…(笑)。

laco 今のAngular 2のルーターはとてもよくできているので、今のところは言うことない、っていうくらいの完成度になりました。

koba04 ぼくは個人的にルーティングにこだわりはないんですが、基本的にはここもライブラリに依存しなくてもいいんじゃないかな、とはずっと思っています。汎用的ないいルーターが出てこないのかな、とは思ってるんですが、あんまり出てこないですね。

laco 確かに。イベントだけ発火してくれればそれでいいですからね。

koba04 そう。ライブラリと関連しているところではないので。誰か作るチャンスだと思います。

shumpei ReactやAngularに関係ないルーティングのライブラリがあればいいのに、ということですね。

テンプレート

shumpei 前半最後のトピックになりそうですが、次は「テンプレート」です。これ盛り上がるのかな…お互いの記法がキモい、とかってdisりあっていただいてもかまわないんです(笑)。

83 JSXもキモい、Angular 2テンプレートもキモい、気に入ったキモいほう使え、って感じですね(笑)。

laco でもまあ、Angular 2のテンプレートはギリギリHTMLなので、既存のHTMLツールチェインには乗れるわけです。ちなみにJSXってファイル分けられるんですか？「.jsx」みたいなファイルあるんですか？

yosuke_furukawa 一応あります。Angular 2は分けられるんですか？

83 テンプレートの文字列を直接ソースコード中に書くのも、URLで外部ファイルを指定するのも、どちらも可能です。URLを指定した場合はAjaxで取ってきます。

yosuke_furukawa そこの通信（コスト）はいいんだ？

laco それはwebpackのプラグインで、URLをrequire()に変換してくれるやつがある（angular2-template-loader）ので、ありがたく使わせてもらってます。あとひとつ気になるのは、JSXってXSSのサニタイズとかやってくれるんですか？

yosuke_furukawa …えっとですね。…Angularの圧勝です。

会場 (笑)

yosuke_furukawa 普通にpタグやdivタグの中に入れる文字列はサニタイズしてくれるんだけど、例えばaタグのhref属性とかに対しては、別に何もしてくれません。なので、(属性値に)javascript:〜とかやろうと思えばできちゃう。

laco innerHTMLぶち込みとかも？

yosuke_furukawa そうです。だから、innerHTML使うときとか、URLをセットする場合とかは、注意しなくちゃいけない。 (URLから)javascript:を省いてやる必要とか、XSS対策についてはケアが必要です。

shumpei React本体でそこら辺を対応しようという動きはないんですか？

koba04 JSXって結局ただのオブジェクトに展開されるんですけど、Symbolとかを使って、外から知らないタグを差し込まれたりはしないようになってます。なので、渡された文字列をそのままReact Elementsとして展開するということは出来ないようになっていますけどね。

laco あ、あともう一つ。Web Components対応ってどうなってるんですか？

koba04 一応Custom Elementは書けるようになっています。あとは、DOMComponentに不正な属性を渡すと警告が出るようになっていて、それはCustom Elementをサポートするための布石です。なので、この後何らかの対応が入ってくるとは思います。

shumpei そろそろお時間ですので、これで前半を終わりにしたいと思います。後半も、引き続きよろしくお願いします。

後編に続きます

Reactの最新動向とベストプラクティス ── HTML5 Conference 2016セッションレポート

小林徹 — Wed, 19 Oct 2016 00:00:17 +0000

連載： HTML5 Conference 2016 特集 (2)

2016年9月3日に東京電機大学で開催された「HTML5 Conference 2016」のセッションを特集する第二弾は筆者である私、小林徹が登壇した「 Reactの最新動向とベストプラクティス」の内容を解説します。

Reactの現状

Reactは、2013年にFacebookが公開した、Viewを作るためのJavaScriptのライブラリーです。

https://facebook.github.io/react/

現在のバージョンはv15.3.2です。 v1.0.0からv14.0.0までのバージョンはありません。「すでに安定していてプロダクションでも利用できる」ことや「セマンティック・バージョニング（パッチ.マイナー.メジャー）に準拠している」ことを示すために、v0.14.8からのバージョンアップ時にv0.15.0ではなく、マイナーのバージョン番号をメジャーにシフトさせてv15.0.0になりました。

Reactの採用事例を見ていきましょう。

Reactを開発しているFacebookは、ウェブページのコメント欄などで部分的にReactを使用しています。同じくFacebookが運営しているInstagramでは、ウェブページ全体をReactのComponentで構築しています。

Facebook以外の事例を見てみると、NetflixやTwitter、Airbnb、Uberなど多くの企業でReactが使われています。日本でも、Abema.tvなど大規模にReactが導入されている事例が増えています。

これらは、ReactのDeveloper Toolsを使用することで確認できます。

https://github.com/facebook/react-devtools

また、Electron製のターミナルソフトであるHypertermは、ReactとReduxを使って作られています。機能拡張の仕組みを、Reduxのミドルウェアの仕組みで実現するなど興味深い点も多く、ソースコードはGitHubで公開されています。

https://github.com/zeit/hyperterm

他にもJenkinsが、新しいUI ComponentをReactのComponentとして提供しているなど、Reactはまさに「今使われているライブラリー」であることが言えます。

特徴

それではまず最初に、Reactの特徴について見ていきましょう。 Reactのサイトのトップには、「Declarative」、「Component-Based」、「Learn Once, Write Anywhere」の3つのキーワードが紹介されています。

「Learn Once, Write Anywhere（一度学べば、どこでも書ける）」は、ReactにとってDOMはreact-domによるただの1つの環境であることを表しています。 react-nativeなどを使うことで、「同じReactの考え方」でiOSやAndroidのような、DOM以外の環境をターゲットにしたアプリケーションを開発できます。

「Write Once, Run Anywhere（一度書けば、どこでも実行できる）」ではないのは、Viewは各プラットフォームのルールや特徴に応じて構築するべきであり、安易に共通化すべきでないことを意味しています。しかしながらViewに関連しないロジックの多くは共通化できるとしており、実際にFacebookのAds Managerのアプリは、react-nativeを使うことでiOSとAndroidで80%以上のコードが共通化できているそうです。

それでは、DeclarativeとComponent-Basedについて見ていきます。

Declarative

Reactでは、Declarative（宣言的）にComponentを組み合わせてViewを構築します。宣言的という言葉の通り、状態に対しての「あるべき姿」を宣言するように定義します。

例えば、イベントに対する処理を命令的に記述すると、下記のようになります。

// elに対する変化を書いている
button.on(‘click’, () => el.append(child));

これを宣言的に書くと、下記のようになります。

// render関数は、渡されたstateに対するあるべき表示を定義している
render = state => {
  el.innerHTML = state.map(child => `${child}`).join(‘’);
};

// 状態を更新して、render関数に渡す
button.on(‘click’, () => {
  state.push(child);
  render(state);
};

上記の場合、render関数は受け取ったstateをもとにViewを構築するだけです。これは、初期表示の場合もイベントによる更新時も常に同じです。

この結果、render関数はstateのみに依存し、同じstateからは常に同じViewを構築します。これは、テストやデバッグを容易にします。

ReactはComponentを使い、宣言的にViewを構築します。

const View = props => (
    {props.items.map(item => {item}
)}
);

Component-Based

Reactでは、Componentを作り、組み合わせることでViewを構築します。 Componentは、Appのようなアプリケーションを全体を表すものから、TextBoxのような既存の要素を少し拡張するようなものまで規模は様々です。

class App extends React.Component {
  constructor(...args) {
    super(...args);
    this.state = {
      text: '',
    };
  }
  render() {
    return (
       this.setState({text})}
      />
    );
  }
}
const TextBox = (text, onChange) => (
  
     onChange(e.target.value} />
    {text}
  
);

ReactDOM.render(
  ,
  document.getElementById('app')
);

Componentは、View = Component(State)のような、Viewを作る関数として考えることができます。 Componentが返すViewは、ReactElementのツリーとなります。作成したReactElementのツリーは、ReactDOMによってDOMへと反映されます。更新時は、更新前のReactElementのツリーと比較して、差分だけがDOMに反映されます。これがVIRTUAL DOMと呼ばれる部分です。

この差分の反映により、Reactは関数のようにViewの構築を宣言的に書いた場合でも、パフォーマンスの劣化を避けることができます。先ほど紹介したReactを使わないinnerHTMLによる反映では、毎回DOMを再構築するため、規模が大きくなるとパフォーマンス上問題となります。

Componentの作り方

React Componentの作成方法には、下記の4種類あります。

Stateless Functional Components
React.Component
React.PureComponent
React.createClass

Stateless Functinal Componenens

関数によるComponentの定義方法です。

const Item = ({item}) => (
  
    {item.name}×{item.count}
  
);

ただの関数であり、インスタンスも持たないのでStateやライフサイクルメソッドが定義できないなどの制限があります。ですが最もシンプルな定義方法であり、Componentを作成する際は、まず最初にStateless Functional Componentsで定義できないかを考えることをオススメします。

SFCと省略して記述されることもあります。

React.Component

ComponentにStateを持たせたい場合や、ライフサイクルメソッドを使いたい場合にはReact.Componentを使った定義方法を使います。

class App extends React.Component {
  constructor(...args) { 
    super(...args);
    this.state = {
      user: null,
    };
  }
  componentDidMount() {
    fetch('/api/user')
    .then(res => res.json())
    .then(user => this.setState({user}))
    ;
  }
  render() {
    if (this.state.user == null) return ;
    return (
      
        
      
    );
  }
}

React.PureComponent

パフォーマンスが問題となるような場面では、React.Componentの代わりにReact.PureComponentの利用を検討します。 React.PureComponentを使うことで、PropsとStateに対してのshallowEqual(浅い比較)がshouldComponentUpdateに適用されるようになります。

shouldComponentUpdateは、無駄なrenderメソッドの呼び出しを避けるためのライフサイクルメソッドです。

class Counter extends React.PureComponent {
  constructor(...args) {
    super(...args);
    this.state = {count: 0};
  }
  render() {
    return (
      
        {this.props.label}:{this.state.count}
        
    );
  }
}

React.PureComponentは、PropsやStateのデータをイミュータブルに扱っている場合に利用できます。イミュータブルであることが保証出来ない場合は、React.Componentを使い、shouldComponentUpdateを自ら実装する必要があります。

ただし、最適化はreact-addons-perfを使い、問題となっている部分を計測して確認してから行うことをオススメします。

React.creteClass

React.createClassは、最初から存在するComponentの作成方法です。ですが、今後は緩やかに非推奨の方向に進んでいます。

Componentの拡張

Reactでは、Componentの拡張を継承ではなく、Higher Order Components(HOC)を使ったCompositionで行うパターンが推奨されています。

Higher Order Componentsとは、高階関数（Higher Order Function）のComponent版と考えることができます。 Higher Order Functionは関数を引数や戻り値とする関数です。

https://ja.wikipedia.org/wiki/高階関数

Higher Order Functionの例

// 何かする関数を受け取って、結果をログ出して返す
const logger = operation => (...args) => {
    const result = operation(...args);
    console.log(result);
    return result;
};
const add = logger((a, b) => a + b);
add(10, 20);
// 30

Higher Order Componentsでは、Componentを引数として受け取り、それをラップした新しいComponentを返します。

Higher Order Componentsの例

// Componentを受け取って、PureComponentでラップして返す
const pure = Component => (
  class Pure extends React.PureComponent {
    render() {
      return ;
    }
  }
);
const Item = ({name}) => {name};
const PureItem = pure(Item);
//

Higher Order Componentsのパターンは、react-routerやreact-reduxなどのライブラリーでも使われています。

また、Higher Order Componentsのパターンを集めたrecomposeというライブラリーもあります。

https://github.com/acdlite/recompose

// isLoadedによってComponentを出し分ける
const enhance = branch(
  props => props.isLoaded,
  Component => Component,
  () => Loading
);
const LoadUser = enhance(User);
//

State管理

Reactでは、ComponentはView = Component(State)であると紹介しました。したがって、Componentにはなるべく状態を持たせないことが推奨されます。

これにより、親Componentだけに状態管理が集約します。親Componentは、子Componentに「状態」と「状態を変更するための関数」を渡します。子以下のComponentは、それらを受け取り利用するだけです。

ViewTree = ComponentTree(State)

親Componentに状態管理が集約されることで、アプリケーションの状態を把握することが容易になります。それと同時に、子Componentはほとんどロジックを持たず、状態を受け取りViewを構築するStateless Functional Componentsで定義可能なただの関数になります。これによりテストも容易になります。加えて、親のComponentは状態管理、子のComponentは見た目に関してと、役割を明確に分けることができます。

しかしながら、このパターンの場合、親Componentに処理が集中するため、規模が大きくなると管理が難しくなります。その解決方法として、Facebookが発表したFluxというアーキテクチャがあります。

Fluxでは、状態管理の流れを役割ごとに細かく分割し、React Componentから切り離します。

Fluxの影響を受けているライブラリーとして、Reduxがあります。 Reduxは、状態管理のためのライブラリーです。

http://redux.js.org/

Reduxでは、アプリケーションの状態をシリアライズ可能な1つのオブジェクトにまとめます。状態の更新は、Actionを発行して、Reducerと呼ばれるActionを元に新しい状態を作成する関数によって行われます。

Reduxでは、React ComponentをContainer ComponentとPresentational Componentの2つの役割に分けます。それぞれの役割は以下の通りです。

Reduxでは、データはシリアライズ可能なオブジェクトとして単一のStoreに保持されるため、各処理は入力を受け取り入力に応じた結果を出力するただの関数として実装できます。

アクションの発行 – action = ActionCreator([event])
状態の更新 – newState = Reducer(state, action)
状態の取得 – props = Selector(state)

これにより、各部分もPresentational Componentのように簡単にテストができます。

状態と処理を切り離し、ActionとStateをシリアライズ可能なオブジェクトにすることは、デバッグや状態の再現を容易にします。それを利用したRedux DevTools Extensionでは、Actionを記録して任意のActionの流れを再現するだけでなく、指定したActionの流れをJSONとしてインポート・エクスポートできます。これにより、処理の流れを複数人で共有したり、エラーがあった場合にサーバーに送信することで、状況の再現が可能になります。

https://github.com/zalmoxisus/redux-devtools-extension

Reduxを使う場合、副作用や非同期処理の扱いを、Middlewareのレイヤーで吸収します。 Middlewareは発行されたActionを改変したり別のActionを発行するなど、アプリケーションの処理に大きく影響を与える部分です。副作用や非同期処理を扱うためのMiddlewareは、すでにたくさん公開されています。したがって、アプリケーションの要件に適した、副作用や非同期処理の方法を選択できます。

FluxアーキテクチャやReduxは、必要と感じるまで利用する必要はありません。ですが、Reduxを使わない場合でも、React ComponentをContainer ComponentとPresentational Componentに分けて考えることは重要です。

エコシステム

Reactでは、すでに多くのエコシステムが存在します。 React Componentのテストを簡単に書くための仕組みを提供してくれるEnzymeや、Component単位でデザインを確認しながら開発できるReact StorybookなどOSSからたくさんのライブラリーやツールが公開されています。

また、React ComponentやJSXのためのESLintのプラグインも存在します。

https://github.com/yannickcr/eslint-plugin-react

コーディングのスタイルだけでなく、廃止予定のAPIの使用や、ベストプラクティスに沿っているかなど数多くの観点からのチェックが可能です。 ESLintとともに利用をオススメします。

また、a11yに対するチェックを行うeslint-plugin-jsx-a11yというプラグインもあります。

https://github.com/evcohen/eslint-plugin-jsx-a11y

将来

Reactは、Facebookが開発しているライブラリーです。 Facebookの内部ではすでに25,000以上のReact Componentがあるそうで、ReactはFacebookの中でも重要な位置付けのライブラリーとなっています。そのためFacebookが必要としている機能に対する優先度は当然高くなりますが、今後も継続してメンテナンスされることが期待できます。

加えて、OSSとしての役割も重要視されています。例えば、SVGやcustom elementsの対応のようなFacebookでは必要とされていない機能も必要であればReact本体でサポートされます。また、ReactのコアチームのミーティングノートをGitHubで公開したり、コマンド1つでReactを使ったアプリケーションの雛型を作成するcreate-react-appもその1つです。

前述した通り、Facebookだけでなく多くの企業がReactをプロダクションで使用しています。そのため、Reactは非互換な変更に対してはとても慎重です。

何かAPIを廃止する場合は、「次のメジャーバージョンで警告の出力と移行プランの提供」、「その次のメジャーバージョンで廃止」という流れになります。したがって、メジャーバージョンアップで突然動作しなくなることがないように配慮されています。

現在進行中の大きな開発として、「ReactFiber」があります。 ReactFiberは、ComponentとRendererがやりとりする、Reactのコアとなるアルゴリズムを全面的に書き直すものです。

現在は、更新処理からReactElementの差分計算・DOMへの反映までが同期的に行われています。これは、規模の大きなComponentツリーや60FPSが求められるような場面で問題となることがあります。

ReactFiberでは、更新処理をFiberというタスクの単位で非同期に処理できるようになります。例えば、アニメーションの更新処理など遅延が許されないものは、requestAnimationFrameを使い可能な限りすぐに反映し、APIのレスポンスや画面に表示されてない部分は、requestIdleCallbackを使い多少の遅延を許容するといった具合です。

ReactFiberは、現在ベースとなる部分が実装中であり、すぐに現在のアルゴリズムと置き換えられるものではありません。しかしながら、今後注目すべき動向の1つです。

まとめ

ReactはComponentを使いViewを構築するためのライブラリーです。そのためReactが担う範囲は広くありません。しかし、Reactを使うことでクライアントでの状態管理の難しさを排除し、シンプルに考えることができます。

また、Facebookのサイト自体もそうであるように、ReactはSingle Page Applicationではないアプリケーションに対しても、部分的に導入していくことが可能です。その際に必要となる、設計としては綺麗とは言えないようなAPIも提供しています。

Reactを取り巻くエコシステムは大きくなっており、それらの組み合わせを紹介する記事も多く存在します。

しかしながら、Reactをこれから初めてみようと思っている場合は、最低限の構成で小さく始めることをオススメします。その後、必要だと思った段階で、エコシステムが提供するライブラリーの導入を順番に検討してください。

そうすることで、各ライブラリーが、「何を」問題と考えて「どのように」解決しようとしているのかを理解できるようになります。その結果、多くの情報やライブラリーに振り回されることなく、エコシステムと付き合っていけるようになると考えています。

上記の基調講演は動画でも公開中です

当日の資料と動画は下記で公開されていますので、こちらも参照してください。

モバイルUIフレームワークのド本命、Onsen UI 2正式リリース！──React, Angular 2両対応！

又川尚樹 — Wed, 05 Oct 2016 00:19:13 +0000

連載： React/Angular2時代のWeb開発 (1)

先日、本サイトにて公開された React/Angular2時代のUIフレームワーク考──Ionic2、Onsen UI2を語るという記事を受けて、本記事ではOnsen UI 2の具体的な使い方をご紹介していきたいと思います。

Onsen UI 2 の概要

Onsen UIはアシアル株式会社が2013年から公開しているオープンソースのHTML5 UIライブラリです。 HTML5モバイルアプリでの利用に特化した高速な動作性が特徴です。

2016/09/15（日本時間）に次期バージョン「Onsen UI 2」の正式版をリリースしました。 AngularJSのロードが必要だったOnsen UI 1と異なり、Onsen UI 2は単体で動作 します（Web 標準の Custom Elements を利用しています）。

また、Android向けの画面とiOS向けの画面をワンソースで構築できるAutomatic Stylingなどの新機能を備えています。

Hello, World

空ディレクトリを作成し、以下のコマンドでonsenuiパッケージをインストールします。

npm init --yes
npm install onsenui@2.0.0 --save

次に、index.htmlを以下の内容で作成します。




    
    
    
    
    
    


    
        
            Onsen UI
        

        
            Hello World!
            Click Me!

head要素内で読み込まれているonsenui.css, onsen-css-components.css, onsenui.min.jsがOnsen UI 2の実体です。

上記3つのファイルの読み込みが完了すると、ons-page や ons-toolbarといった要素がブラウザに登録され、元々ブラウザに組み込まれているinput要素などと同じ感覚で使えるようになります。

最終的なディレクトリ構成は以下のようになります。

├── index.html
├── node_modules
│   └── onsenui
└── package.json

ブラウザでindex.htmlを開くと以下のような画面が表示されているはずです。ボタンをクリックするとOnsen UI製のダイアログ（ons-alert-dialog 要素）が表示されます。

このようにOnsen UI 2は、特殊な知識を必要とすることなく、少しの準備ですぐに使い始めることができます。

なお、今回使用したons-page, ons-toolbar, ons-button, ons-alert-dialog以外にも、Onsen UI 2はモバイルアプリに不可欠なコンポーネントを数多く揃えています（以下はその例です）。

使用可能なコンポーネントの一覧は Onsen UI 2 Docs にあります。Onsen UI 2を使った開発では、使用可能なコンポーネントとその使い方を公式ドキュメントから探しながら画面を実装していくことになります。

アプリケーションフレームワークと併用する

発展的な内容として、Onsen UI 2をアプリケーションフレームワークと併用する方法について解説します。

Onsen UI 2の特徴は任意のアプリケーションフレームワークと併用できる点です。実際、React, AngularJS, Angular2, Vue.js, Meteorと一緒に動作させても問題なく動作することを確認しています。

しかし Onsen UI 2のコンポーネントは input 要素などと同じく、DOM要素自体にメソッドが紐づけられているため、Onsen UI 2単体ではコンポーネントを操作する際にDOM要素への直接アクセスが必要になってしまいます。DOM要素への直接アクセスは、ReactやAngular2などといったDOM要素への直接アクセスを忌避するアプリケーションフレームワークにおいて問題となります。

その問題の解決策として、Onsen UI 2は一部のアプリケーションフレームワークに対してバインディングを用意しています。

バインディングを利用すると、DOM要素への直接アクセスを回避し、各アプリケーションフレームワークの流儀に則って Onsen UI 2のコンポーネントを操作することができます。

2016/09現在、Onsen UI 2は React, AngularJS, Angular 2, Vue.js の4種類のアプリケーションフレームワークに対してバインディングを提供しています。

React と併用する

Onsen UI 2をReactと併用する場合は react-onsenui パッケージ（React バインディング）を使用します。

空ディレクトリを作成し、以下のコマンドで必要なパッケージをインストールします。

npm init --yes

# Onsen UI本体
npm install onsenui@2.0.0 --save

# アプリケーションフレームワーク （React）
npm install react react-dom --save

# Onsen UIのReactバインディング
npm install react-onsenui@1.0.0 --save

# トランスパイラ （Babel）
npm install babel-core@^5 --save

次に、index.html を以下の内容で作成します。

最終的なディレクトリ構成は以下のようになります。

├── index.html
├── node_modules
│   ├── babel-core
│   ├── onsenui
│   ├── react
│   ├── react-dom
│   └── react-onsenui
└── package.json

ブラウザで index.html を開くと先ほどと同様の画面が表示されているはずです。

Angular 2と併用する

Angular 2をReactと併用する場合はangular2-onsenuiパッケージ（Angular 2 バインディング）を使用します。

空ディレクトリを作成し、以下のコマンドで必要なパッケージ・型定義ファイルをインストールします。

npm init --yes

# Onsen UI本体
npm install onsenui@2.0.0 --save

# Angular 2 アプリのビルドに使用するツール
npm install --global typescript
npm install --global typings
npm install --global webpack

# Angular 2の動作に必要なライブラリ （polyfill）
npm install core-js --save
npm install reflect-metadata --save
npm install zone.js --save
npm install rxjs --save

# Angular 2本体
npm install @angular/core@2.0.0 --save
npm install @angular/common@2.0.0 --save
npm install @angular/compiler@2.0.0 --save
npm install @angular/platform-browser@2.0.0 --save
npm install @angular/platform-browser-dynamic@2.0.0 --save

# Onsen UIのAngular 2バインディング
npm install angular2-onsenui@1.0.0-rc.1 --save

# Angular 2アプリのビルドに必要な型定義ファイル
typings install --global dt~core-js#0.0.0+20160725163759

次にmain.tsを以下の内容で作成します。

import { NgModule, CUSTOM_ELEMENTS_SCHEMA, Component } from '@angular/core';
import { platformBrowserDynamic } from '@angular/platform-browser-dynamic';

import { OnsenModule, onsNotification } from 'angular2-onsenui';

@Component({
    selector: 'app-root',
    template: `
        
            
                Onsen UI
            

            
                Hello World!
                Click Me!
            
        
    `,
})
export class AppComponent {
    alertPopup() {
        onsNotification.alert('Onsen UI alert');
    }
}

@NgModule({
  imports:      [ OnsenModule ],
  declarations: [ AppComponent ],
  bootstrap:    [ AppComponent ],
  schemas:      [ CUSTOM_ELEMENTS_SCHEMA ],
})
export class AppModule {
}

platformBrowserDynamic().bootstrapModule(AppModule);

次に以下のコマンドを実行します。

tsc --init

生成された tsconfig.json を以下の内容に書き換えます。

{
    "compilerOptions": {
        "moduleResolution": "node",
        "module": "commonjs",
        "target": "es5",
        "noImplicitAny": false,
        "sourceMap": false,
        "experimentalDecorators": true,
        "emitDecoratorMetadata": true
    },
    "exclude": [
        "node_modules"
    ]
}

次に以下のコマンドで main.bundle.js を生成します。

# トランスパイル
tsc

# バンドル
webpack main.js main.bundle.js

最後に index.html を以下の内容で作成します。

最終的なディレクトリ構成は以下のようになります。

├── index.html
├── tsconfig.json
├── main.ts
├── main.js
├── main.bundle.js
├── node_modules
│   ├── @angular
│   │   ├── common
│   │   ├── compiler
│   │   ├── core
│   │   ├── platform-browser
│   │   └── platform-browser-dynamic
│   ├── angular2-onsenui
│   ├── core-js
│   ├── onsenui
│   ├── reflect-metadata
│   ├── rxjs
│   └── zone.js
├── package.json
└── typings
    ├── globals
    │   └── core-js
    └── index.d.ts

ブラウザでindex.htmlを開くと先ほどと同様の画面が表示されているはずです。

まとめ

本記事ではOnsen UI 2の具体的な使い方を紹介しました。また、発展的な内容として、Onsen UI 2をReact, Angular 2と併用する方法について解説しました。

アプリケーションフレームワークの進化やUIライブラリの充実により、HTML5によるモバイルアプリの実装の敷居は下がり続けています。

ハイブリッドアプリに続いてProgressive Web Appsが話題となる中、そこで必要となるモバイルアプリライクな UI/UX の実装に対する一つの解として、是非Onsen UI 2を活用していただければと思います。

（追伸: 先日Twitterに@Onsen_UI_jaを開設しました。日本語での技術的な質問はこちらまでどうぞ）

React Native入門 ─ Hello,Worldからネイティブ連携まで

Kameda Shohei — Tue, 06 Sep 2016 00:16:23 +0000

連載： Web技術でアプリ開発2016 (1)

モバイルアプリ開発におけるWeb技術の可能性を探る特集・第一弾でご紹介するのはReact Native。その生い立ち、チュートリアルから、コードベースやUIを記述する言語、パフォーマンスまで解説します。

概要

React Nativeは2013年にFacebook社内のハッカソンで生まれたプロジェクトです。2014年にiOSアプリのFacebook Ads ManagerをReact Nativeを用いて開発し、2015年3月にオープンソースとして公開されました。そして、半年後の2015年9月にAndroidをサポートし、今年のF8では、MicrosoftがReact NativeでWindowsプラットフォーム（PC, Mobile, Xbox）の開発ができます、という発表がありました。また、macOSアプリの開発、Ubuntuアプリの開発など他のプラットフォームの開発もできるようにするプロジェクトも走っているようです。

React Nativeのコンセプトは、”Write Once, Run Anywhere”(一つのコードでどこでも動く）ではなく、”Learn Once, Run Anywhere”(一度学べば、どこでも動かせる）です。一度React Nativeを理解すれば、どのプラットフォーム上でも同様のコーディングを行って、プラットフォームネイティブなアプリケーションを開発することが出来ます。Githubのスター数は35,000を超え、リリースの頻度も多く、グローバルな視点でみると、非常に熱い技術であると言えます。

（編集部注: 「Write Once, Run Anywhere」は、あらゆるプラットフォームで同一のコードが動作するという、Javaが喧伝していたコンセプトです）

Hello, World

以下は、macOS上で開発することを前提としたチュートリアルです。

React Native開発に必要なものは、 Node.js, React Nativeのコマンドラインツール、Watchman（Facebookによって開発されているファイル監視ツール）になります。Homebrewで下記のようにインストールします。

$ brew install node $ brew install watchman $ npm install -g react-native-cli $ npm -v 3.6.0 $ node -v v5.0.0

iOS

iOSの場合はXcodeが必要です。XcodeはMac App Storeからインストールしましょう。　準備が整ったところで、プロジェクトを作って走らせてみます。

$ react-native init AppByWebTech2016 $ cd AppByWebTech2016 $ react-native run-ios

Android

Androidの場合は、Android Studioが必要なのでインストールしておきます。アプリの起動には、実機をUSBで繋げておくか、Emulatorが必要なので適宜用意します。今回は、Genymotion(個人利用は無料）を起動しておいて, 下記のコマンドを走らせます。

$ react-native run-android

NativeBaseを使う

これだけだと味気ないので、NativeBaseを用いてUIを作ってみたいと思います。NativeBaseはWebでいうBootstrapのようなものです。ボタン等のUIを自分でデザインする必要がなく見栄えの良いインターフェイスを簡単に作ることができます。

では、NativeBaseをインストールしてみましょう。(※react-nativeのバージョンは0.32)

$ cd AppByWebTech2016 $ npm install native-base --save $ react-native link react-native-vector-icons

index.ios.jsを下記のように変更すると、

import React, { Component } from 'react';
import { Container, Content, Button, Header, Title, List, ListItem, Badge } from 'native-base';
import { Col, Row, Grid } from 'react-native-easy-grid';
import { AppRegistry, Text, View } from 'react-native';

class AppByWebTech2016 extends Component {
  render() {
    return (
      
        
          Hello World
        
        
          
            
              1
            
            
              2
            
            
              List 3
            
          
          
            
              
                
              
              
                React Native!
              
            
            
              Learn once, Write anywhere
            
          
        
      
    );
  }
}

AppRegistry.registerComponent('AppByWebTech2016', () => AppByWebTech2016);

スタイルのことを気にせずボタンを作ることができ、グリッドなども簡単に使用できます。プロトタイピングなどにはもってこいのモジュールとなっています。

プラットフォーム／ライブラリの特徴

項目	説明
対応プラットフォーム	iOS, Android, Windows(PC, Mobile, Xbox), macOS※, Ubuntu※
コードベースは（ほぼ）完全に統一できるか？	統一できない（実際は7,8割は共有できる）
UIを記述する言語	JavaScript, React, スタイルシート
UIはネイティブか、Webか	WebViewではない。ネイティブもしくはJSとのハイブリットで実現
パフォーマンス	ネイティブ同等
ネイティブな機能を呼び出せるか？	APIを通じて自由に呼び出せる

※コミュニティがサポート

以下に、上の表を補足します。

対応プラットフォーム

私が確認したのはiOSとAndroidですが、前述した通り、下記のプラットフォームでReact Nativeの方法でNativeアプリを動かすことができるようです。

iOS
Android
Windows(PC, Mobile, Xbox)
MacOS
Ubuntu
Browser※1

※１React Native for WebというChrome, Firefox, Safari >= 7, IE 10, Edge.のBrowser上でReact Nativeコードを動かすというプロジェクトさえ存在します。

コードベースは（ほぼ）完全に統一できるか？

残念ながら完全には統一できません。現実には各プラットフォームの作法（例えば、iOSはtabbarは下部、Androidは上部）が存在し、完全に同じにすべきかというのは別の議論が必要な気がします。ただ85%は同じコードを再利用できたといった話もないわけではありません。ビジネスロジック部分は統一させ、UIは個別のコードで実現するというのが、コードの再利用＋ネイティブの作法の両面を考慮に入れたReact Nativeの流儀だと言ってよいでしょう。

UIを記述する言語

コードはJavaScript(ES6), コンポーネントはReact, デザインはスタイルシートを用いて記述していきます。スタイルシートはCamel記法となるのでCSSのbackground-colorがbackgroundColorという属性になり、非常に馴染みの深いものになります。 React Nativeは、レイアウトを行うためにFlexboxを用います。最近のWebブラウザでは広くサポートされているので、ご存じの方も多いことでしょう。

ES6やReactは確かに学習コストがあります。しかし、Web業界で生きているひとは少なくとも触っておくべき技術でしょう。React Nativeでのアプリ開発の経験が逆にWebに生かすというようなことも起きるかもしれません。

パフォーマンス

ネイティブのコンポーネントを利用する限り、ネイティブと同等のパフォーマンスになると言ってよいでしょう。パフォーマンスの最適化を開発者に意識させないようにすることがReact Nativeが実現しようとしていることです。

しかし、公式のドキュメントによると、現実には何点か難しい箇所があると述べられています。

React Nativeは下図のようにスレッドが走っています。

React.js Conf 2016 – Tadeu Zagallo – Optimising React Native: Tools and Tipsより転載

端的に言うと、JavaScriptのビジネスロジックが動くJSスレッド上で時間のかかる処理を行うと、UI出力時に遅延が起きてしまうケースがあります。もしパフォーマンスに影響が出たときは、このJSスレッドを意識してコードを見直してみる必要があります。

今年のReact Confの発表でも言及されていましたが、Facebookは社内にReact Nativeのパフォーマンスチームを作ってパフォーマンスを継続的に改善しています。彼らがリソースを割いて注力している部分でもあるので、これからも改善されていく部分だと思います。

UIはネイティブか、Webか

WebViewを使わないという観点でWebではありません。ネイティブのライブラリを呼び出すAPIが多いですが、JSとのコードのハイブリッドといったイメージでしょうか。UIの動作は非常にネイティブライクです。

ネイティブな機能を呼び出す方法

React Nativeとネイティブ間を受け渡すようなAPIが用意されています。これを使うことで容易にネイティブからの値を受け取ったり、受け渡したりすることができます。この程よい抽象化があることで、現行のiOSアプリにも組み込むことが可能となります。実際、Facebookのアプリでも一部はReact Nativeで書かれてると言っています。

今回は非常に簡単な例ですが、React Native側で２つの数字を渡しネイティブ側で和を求めて返すメソッドを用いて説明します。(今回はiOS）

まずは、Xcodeでios/AppByWebTech2016.xcodeprojをOpenし、新規作成からCocoaClassを選び、適当なSubクラスを選びます。

すると、AppNativeSum.hとAppNativeSum.mができると思います。このファイルを下記のように書き換えます。RCT_*(ReaCTの略らしい）の接頭辞がついたAPIをReact Nativeが提供しています。Callbackを用いて返す方法もありますが、今回はPromiseを使います。

#import "RCTBridgeModule.h"

@interface AppNativeSum : NSObject <RCTBridgeModule

@end

#import "AppNativeSum.h"

@implementation AppNativeSum

RCT_EXPORT_MODULE();

RCT_EXPORT_METHOD(sumNumber:(int)val1 val2:(int)val2 resolver:(RCTPromiseResolveBlock)resolve
                  rejecter:(RCTPromiseRejectBlock)reject)
{
  NSInteger val3 = val1 + val2;
  NSString *val3Str = [NSString stringWithFormat:@"%ld", (long)val3];
  resolve(val3Str);
}

@end

このメソッドの戻り値は、JavaScriptのPromiseです。通常のPromiseと同様に、async/awaitを使って非同期処理の結果を処理することも可能です。

import { NativeModules } from 'react-native';
var AppNativeSum = NativeModules.AppNativeSum;

class AppByWebTech2016 extends Component {

  constructor(props){
    super(props);
    this.state = {
      sum: 0
    }
  }

  async componentDidMount(){
    let sum = await AppNativeSum.sumNumber(1,2);
    this.setState({sum: sum});
  }
...

ネイティブコードに精通していれば、公式ドキュメントにあるAPIに渡すだけで容易にReact Nativeとネイティブのやりとりができます。

まとめ

マレーシアの友人が、彼の国では企業がReact Nativeエンジニアの採用をしていると言っていました(中国でも似たような状況にあるとか)。日本でもちらほらReact Nativeを採用する会社がでてきているようです。一年半以上経過し、リリース速度が多少遅くなっているといってもどんどん新しいバージョンが出てきて、かつよりよいUIモジュールもでてきています。今こそ、React Nativeを始めてみてはいかがでしょうか。

React/Angular2時代のUIフレームワーク考──Ionic2、Onsen UI2を語る

白石俊平 — Fri, 02 Sep 2016 00:00:21 +0000

連載： React/Angular2時代のWeb開発 (2)

読者の皆様こんにちは、編集長の白石です。

先日ふとしたきっかけで、本サイトの認定エキスパートでありアシアル株式会社の社長でもある田中正裕さんと、Web技術について語り合う機会がありました。

ReactやAngular2といった次世代のアプリケーションフレームワークが存在感を増す中で、UIを構築するためのフレームワークはどう進化するのか？

これらのアプリケーションフレームワークをベースとしたIonic2やOnsen UI2と言ったUIフレームワークについて、それぞれの立場から語り合ってみました。（田中さんはOnsen UI2の開発者、白石はIonic2をかなりヘビーに使い倒しています）

Progressive Web Apps (PWApps)というキーワードが認知を広げる中で、ハイブリッドアプリやモバイルサイトを構築する手段として、これらのフレームワークは存在感を増しています。PWApps、React、Angular2、Cordovaといったキーワードに関心のある方は必読です！

では、本編をお楽しみください。

対談参加者のプロフィール

田中正裕(アシアル株式会社代表取締役社長)

ユーザーインタフェース設計からインフラストラクチャー構築まで、最先端の技術を駆使したシステム構築を手がける。特にPHPをはじめとするOSSや、HTML5やJavaScriptといったオープンなアーキテクチャーを用いたシステムの構築に尽力している。モバイルアプリ開発プラットフォーム「Monaca」のプロダクトマネジャーを兼務。

白石俊平(HTML5 Experts.jp編集長)

株式会社オープンウェブ・テクノロジーCEO。2015年12月、「最先端は、ここにある。」を謳うテクノロジー情報キュレーションサービスTechFeedをリリース。Web技術者向け情報メディア「HTML5 Experts.jp」編集長。日本最大（6,500名超）のHTML5開発者コミュニティ「html5j」ファウンダー。Google社公認Developer Expert (HTML5)、Microsoft社公認Most Valuable Professional (IE) などを歴任。著書に「HTML5&API入門」（2010, 日経BP）、「Google Gearsスタートガイド」（2007, 技術評論社）など。監訳に「実践jQuery Mobile」（2013, オライリー）など。

Ionic2とOnsen UI2

白石: 本日はよろしくお願いします。今回はReact/Angular2時代のUIフレームワークということで、最先端のUIフレームワークについて語る場にしたいと思っています。

田中: はい、よろしくお願いします！

白石: まずは、Ionic2やOnsen UI2について馴染みのない読者も多いと思うので、それぞれのフレームワークとぼくらの関わりについて話しましょうか。まずは、両フレームワークの共通点としては、以下の様な点が挙げられるかと思います。

どちらもコンポーネント指向のUIフレームワーク。独自のタグを元に、HTMLっぽいテンプレートを記述することでUIを構築していける。
どちらも最初から数多くのUIコンポーネントを備えており、モバイルネイティブに近い見た目のアプリを作れる。
どちらも、Cordovaをベースとしたモバイルアプリ開発（ハイブリッドアプリ）を前提としている。そのため、以下に示すようなCordovaの特徴を備えることになる。
- ほぼ完全なクロスプラットフォーム性を備える
- プラグインを通じて、ネイティブの機能を呼び出すことができる
- WebView上で動作するので、ネイティブアプリに比べて動作が遅い

白石: で、こうした認識をベースとして、それぞれのフレームワークの違いなどに踏み込んでいければと思います。まずは田中さんとOnsen UIの関係ですが、田中さんはOnsen UIのメイン開発者ということでいいんでしょうか？

田中: 正確に言うと、開発のリードをしている立場ですね。

白石: では、開発の優先順位なども田中さんが決定してらっしゃるということですね。チームは何人くらいいるんですか？

田中: 以前弊社に所属していた久保田光則さんも含めると、4〜5人くらいがフルコミットしている感じですね。

そもそもOnsen UIとは何かというと、バージョン1の時はAngular1をベースとしたUIフレームワークでした。現在開発を続けているOnsen UI2の大きな特徴は「アプリケーションフレームワーク非依存」ということです。



  
  Click Me!

Onsen UI2自体はWeb Componentsに則って作られていて、それをReactやAngular2、Angular1、さらにはjQueryなどと組み合わせて利用できます。最近だとVue.jsとか今はMeteorとかいうバインディングも増えていますね。

白石: そこがIonicとの大きな違いですね。

ぼくは、先日リリースしたTechFeedというアプリで、Ionic2を全面的に採用しました。TechFeedはエンジニア向けのニュースアプリなのですが、Web/メール/モバイルアプリと、様々なクライアントがあります。そのモバイルアプリを開発するにあたって、プラットフォームごとにコードベースを分けたくなかったので、Cordova上で動作するモバイルアプリ用UIフレームワークを探していたんですね。

その際、まだβ版が出たばかりだったAngular2が割とアーキテクチャ的に美しくまとまっていたのと、Ionic2が既にAngular2に対応していたので、採用することにしました。なので、Ionic2はAngular2をベースにしたUIフレームワークです。Angular2以外では動きません。

この、UIフレームワークとアプリケーションフレームワークが密結合（Ionic2）なのか、それとも疎結合（Onsen UI2）なのかというところが、今日の対談のポイントになりそうですね。

ただこのまま、UIフレームワークありきの議論に入っていく前に、ぼくは一つ確認したいことがありまして。そもそもUIフレームワークって必要とされているんでしょうか？

UIフレームワークは必要か？

白石: 「いらないだろう」という前提で話すわけではなくて、Webの世界にとってコンポーネント指向のUIフレームワークというのはまだ新しい存在なので、そもそも「なぜ必要なのか？」を確認したいのです。とりあえず、フレームワークが必要か不要かで言うと、Webデザイナーさんの中には、フレームワークを嫌がる方も多い気がするのですが。

田中: 確かにそういう方もいらっしゃるとは思います。が、（Bootstrapなどのような）CSSフレームワークと、JavaScriptも含めたUIフレームワークは別に考えるべきじゃないかと思います。

白石: 確かにそうですね。CSSフレームワークは、デフォルトでそれなりの見た目になるとか、コーディングスタイルが統一されるなどの利点はあると思いますが、フレームワークのスタイルを変更しようとすると途端に面倒だったりしますしね。フレームワーク独自のルールを覚えなくちゃいけないし、最終的には全部リセットしたくなったり（笑）。

田中: その通りです。それに、ことモバイルアプリやサイトをWeb技術で作る場合に大事なのって、単なるCSSのプリセットがあることではありません。実際に操作してみた時のスムーズさだったり、アプリ全体から受ける印象だったりと、振る舞いも含めたもっと包括的なUXです。

そういう面で、アプリ全体のUXを統一して、なおかつプラットフォームに馴染んだものにするためには、やはり一貫した枠組みが必要です。それは実際に私がMonacaを運営する上で、お客様からご要望をいただいてきたところでもありますし、だからこそOnsen UIを作ることにも繋がりました。ということで、私はUIフレームワークは確実に必要だと思いますね。

白石: なるほど。ただ、UIフレームワークって、寿命が短くないですか？昔はjQuery MobileやKendo UIなんてのもありましたが、今ではあまり使っているという話を聞きません。

UIフレームワークとアプリケーションフレームワーク

田中: それは、それらのフレームワークがUI的に古びてしまったというわけではなく、アーキテクチャ的に古いと見なされたから使われなくなってしまったんだと思うんです。JavaScriptアプリケーションのアーキテクチャは、ここ数年目まぐるしく移り変わってきました。jQueryのあとAngular1、React、Angular2, 他にもRiot.jsとかVue.jsなども出てきている。

ですがそれはアーキテクチャの進化であって、UIが進化したわけではありません。例えばUIの進化って、iOS7からフラットデザインになりましたとか、マテリアルデザインが出てきましたとか、そういうことです。こうした進化がすごく早いかと言われると、正直そうは思いません。UIフレームワークが、アプリケーションアーキテクチャの進化に引きずられちゃってたんじゃないか、というのがぼくの思うところです。

白石: なるほど、だからOnsen UI2はアプリケーション・フレームワークに依存しない形で設計されているわけですね。ぼくはTechFeedをIonic2で作りましたが、それはAngular2の採用を先に決めていたから、というのもあります。というか、その時はまだOnsen UI2が今ほど開発が進んでいなかったので、モバイルアプリを包括的に作れるUIフレームワークと、コンポーネント指向のアプリケーションフレームワークの組み合わせが、Ionic2 + Angular2しかなかったんですよね。

田中: Ionic2はAngular2に強く依存しているわけですが、Ionic2を学ぶには先にAngular2を学ばなくてはならないわけですよね。私はそこを少しもったいないな、と思います。元々私がUIフレームワークで実現したかったことって、「JavaScriptのフレームワークを学ばなくても簡単に使える」ということだったので。

白石: 確かに、Onsen UIはそういうところの配慮が行き届いている気がします。ぼくもOnsen UI1の時に使わせていただいていましたが、Webサイト上のサンプルコードが良くできていて、コピペするだけでUIが作れてしまうのが、とても楽ちんでした。

それぞれのフレームワークが目指すもの

田中: あと、Ionic2はどことなくUIフレームワークというよりは「プラットフォーム」を目指している気がします。

白石: 確かに。Ionicはモバイルアプリを作る際はCordovaを使用するのですが、CordovaもあくまでIonicが規定するプラットフォームの一部というつもりなのか、cordovaコマンドをラップしたionicコマンドを提供していますね。また、CordovaプラグインのAPIをラップした ionic-native というモジュールも提供しています。これは、各種プラグインをTypeScriptから使えるようにしてくれているので、結構ありがたくはあるんですが。

田中: UIフレームワークを入り口として、プラットフォームに入ってきてください、というスタンスな気がしますよね。 Onsen UIはあくまでUIフレームワークであり、アプリケーションスタックの一部という位置付けなので、そこは思想の違いが現れている気がします。

白石: Ionic2はアプリケーションプラットフォームを限定していて、プラットフォームを志向している。Onsen UI2はアプリケーションプラットフォーム非依存で、ライブラリを指向している。こういう対比になりますね。こうして並べると、個人的にはOnsen UI2の方が設計面で魅力を感じます。

田中: ありがとうございます(笑)。

白石: ただ、まだ結論を出すのは早い気もしますね。どちらも正式リリース前ですし(笑)。

TechFeedがAngular2とIonic2を採用しているからというわけではないですが、アプリケーションプラットフォームを限定しているからこその強みもあるかもしれません。ぼくはまだOnsen UI2を実際に触ってみたことがないので比較ができないのですが、Ionic2のほうがAngular2との相性とかはさすがにいいでしょうし。先ほど出てきたionic-nativeパッケージとかもなかなか便利です。

またぼくらがIonicを採用した理由の一つには、コミュニティの大きさがIonicのほうが大きそうだった、という理由もあります。GitHubのStarの数が、Ionicは25,000、Onsen UIは3,000という違いがあったので。コミュニティの大きさは、Web上の情報量の差にもなって表れてくるので、困ったときに情報を得やすいと思ったのです。

このようにいろんな観点での比較ができそうなので、一概にどちらが優れているとここでは結論付けられなそうですが、こうした議論が読者の皆さんにとって判断の助けになるといいですね。

（編集部: 参考までに、ここまでに出てきた論点や、Web上で得られる内容を比較した表を掲載しておきます）

項目	Ionic2	Onsen UI2
依存するアプリケーションプラットフォーム	Angular2	非依存（現時点ではAngular1/2, Reactなど）
フレームワークの実装言語	TypeScript	ES2015とTypeScript
目指す地点	プラットフォーム？	ライブラリ
GitHub上でのStar数 (2016/8/25時点)	25,370	3,216

（UIコンポーネントは現在のところほぼ同数ですが、どちらかにしか実装されていないコンポーネントもいくつかありますし、今後大きく増えていく部分だと思われるため、表からは除外しています）

今後のWeb技術の展望を語る

白石: 最後にお聞きしたいんですが、Onsen UIに限らず、今後のWeb技術って、どういう方向に進んでいくとお考えですか？

田中: Web技術って、今どんどん開発のバリエーションが増えている状態だと思っています。それはフラグメンテーションと呼べるかもしれない。例えば、Angular2がTypeScriptを、ReactがJSXを使用しているように、です。これらが収束して一つの太い流れができていくのか、このまま個別の進化を続けていくのかは、まだ何ともいえません。

白石: テクノロジーのスタックが積み上がっていくにつれ、それぞれの開発手法の間の差異が広がっているというわけですね。こうした状況は、なぜ起きていると考えられますか？

田中: 私はMonacaを通じて「ハイブリッドアプリ」、つまりWeb技術でモバイルアプリを作るというところをずっとやってきました。その経験から言うと、モバイルアプリは大きく2パターンあります。一つは長期間のメンテナンスが必要なアプリ。もう一つはキャンペーンなどのワンタイムなアプリケーションですね。前者には強固な基盤が求められるので、Angular2のようなものが求められます。後者はそうではないですね。逆にさくっと作れるようなものが求められます。

こうしたニーズの二分化も理由の一つじゃないかなあとは思っています。

白石: なるほど、ニーズが分かれていると。そういう意味でいうと、静的な文書中心の「Webサイト」と、Single Page Application化が進む「Webアプリ」の違いも、フロントエンド技術のフラグメンテーションに一役買っていそうです。「Webサイト」の制作においては、まだまだjQueryは現役ですし、無理にそこを変える必要もなさそうですし。

あと、Web技術の適用範囲が増えてきているというのもあるかもしれませんね。WebVRとか、JavaScriptで動かせる組み込み基板とか。ウェアラブルやロボティクスという分野にも、Web技術が広まっていくとは思います。実際にそれがどれくらい使われるかは未知数ですけども。

田中: とはいえWeb技術って、情報技術全体から見るとエッジの技術ではありませんよね。かなりコモディティ化の進んだ、汎用的でメインストリームな技術。

白石: 確かに。これだけ技術が進んでも、結局のところHTML/CSS/JavaScriptという基本的な部分はあまり変わっていません。

田中: こうしたWeb技術の適用範囲をいかに広げていくか…というのは、個人的な興味として強くあります。いちエンジニアとして、Webのスキルセットをいろんなプラットフォームで使えるよう後支えしたいというのは、私の目指すところです。

白石: それは、HTML5 Experts.jpでもぜひ進めていきたいところです。ではそろそろお時間ですね。本日はお付き合いいただき、どうもありがとうございました！

ポエム駆動開発がエッジすぎる！白石俊平がピクシブの開発環境について、聞いてみた！

馬場美由紀 — Wed, 02 Dec 2015 00:00:03 +0000

次々と登場する開発ツールや言語のバージョンアップ。開発スピードがどんどん早くなるWeb業界ですが、実際に企業の開発現場ではどのように開発環境やツール・体制などを構築しているのか──。

HTML5 Experts.jp白石俊平編集長が、根ほり葉ほり聞いちゃうシリーズ・第一弾は、ピクシブを訪問！HTML5 Experts.jpのエキスパートでもある川田寛@_furoshikiさんと片倉@geta6さんにお話を聞いてきました。

クリエイターがやんちゃして遊べる基地ピクシブ

白石：まずはピクシブのサービスや、川田さんが今どんな業務を担当しているのか聞かせてください。

川田：ピクシブでは「創作活動をもっと楽しくする」という理念を持って、いろんなサービスを提供しています。イラスト・漫画・小説が投稿できる「pixiv」以外にも、ネットショップサービス「BOOTH」やグッズ制作サービス「pixivFACTORY」といったECサービス、お絵かきアプリ「pixiv Sketch」とか、いろいろな創作活動向けのサービスを提供しています。

▲ピクシブ株式会社　エンジニア　川田寛さん

私がメインとして担当しているのは　CtoCのECサービスです。同人イベントなどであつかわれる創作物の頒布を、どうやったらネットの力で便利に変えられるのかって、いつも考えてますね。主に「BOOTH」と「pixivFACTORY」を担当しています。

白石：グッズ化したり、販売できたりするサービスですよね。ピクシブならではの強みってあります？

川田：「創作活動をしている人」にフォーカスしているところでしょうね。そういう人たちに愛されるサービスにできていると思っているし、社内の空気としても、クリエーターに対する尊敬があって、彼らをどう幸せにできるのかを考えていたりして。

たとえばBOOTHだと、普通のECサービスじゃ採算があわないという理由で蔑ろにされてもおかしくないような作品を作っている人も、ちゃんと大切にできる。例えば、マニアックすぎて日の目を見ない人たちも気軽に参加できるし、投資できるような仕組みも作っています。普通なら500円くらいでしか売れない作品でも、その価値を認めた人は1000円とか1万円というように、購入者側の評価価格で購入できるような仕組みを作ったりとか。

朝思いついたことをすぐコードで書くスピード感

白石：川田さんは入社したばかりですけど、前職との違いをどう感じてますか？

川田：前は100年以上歴史があったりとか、受託をメインとしている企業だったので、ピクシブとは何もかもが真逆ですね。社員の年代も若いし、サービスもまだできて7年くらい。開発言語一つとっても、今まではJavaがメインだったのが、RubyやPHP、Scala、Goなど、前の会社だったら絶対に手を出さなかったような言語もガンガン使っています。

開発するものについても、大規模な受託案件で、1年以上先にリリースされるようなウォーターフォール型が多かったのですが、ピクシブは自社開発で、それこそ朝に思いついた良いアイデアはその日のうちにコードを書いて形にしてリリースしたりすることもあります。ユーザーに価値を提供していく上で、とにかくスピード感が命なので、そのために多くの権限を現場に委ねているというかんじがしています。

白石：全然違うんですね。コードを書くってことは、川田さんはプログラマ寄りの仕事なんですか？

川田：UIまわりが多く、フロントエンドエンジニアをやってます。サーバーサイドも書くときは書きます。うちの会社はフロントエンジニアが3人いますが、みんな特にフロントエンドだけをやっているという感じではありませんね。iOSとかAndroidを作るアプリエンジニアもいますが、あまり境目がなくて何でもやっているというかんじがします。前職はお客様対応みたいなのが絡むので、SEという言葉がぴったりハマるような仕事だったのですが、今は完全にエンジニアです。コードを書くことで、ユーザーへの価値を発揮しています。

白石：そうなると、仕様策定は誰がやるんでしょうか。

川田：大きな機能追加とかロードマップは、ディレクターがまとめたり経営層を巻き込んだりしていますが、そうでないものは現場で考えてスピーディーにやってしまいます。

　▲ピクシブ株式会社のオフィスには、いたるところに絵師さんのイラストが描かれている。

ポエムはesa、意見交換・情報共有はidobataで

川田：うちの会社にはポエム駆動開発というのがあるんです。コードがかけるだけじゃなくて、創作をする人に対して想いが強い人が入社してくる。エンジニアにも想いが強い人がいっぱいいるので、ポエムを通じて刺激されて作る。

白石：へえ。川田さんはどんなポエムを書いたんですか？

川田：新サービスとかユーザーの声とかいろんな話が絡んでてあまりまだ公表できない話も多いのですが。作品を扱っているサービスとしては、やはり、それを求めているユーザーとうまく繋いであげないことには、出展しているクリエーターやアーティストさんにとっても良くないわけで。そこをどう改善していけばいいのか、というお話をしていました。

社内ではesaというツールを使ってポエムを語るんです。このサービスはこうやったら成功するんじゃないかって書くと、みんなが反応を示していく。そうやってどんどんプロダクトを改善したり、新しく作り出したりしていますね。

白石：現場から上がってくるボトムアップなかんじがいいですね。

川田：何を作るのかとか、どう改善するかは現場から上げていけますね。経営層も「お前らでドラスティックに変えていってくれ」って言ってくれて。

白石：チーム体制は何人くらいでやってるんですか？

川田：うちのチームだと、BOOTHとpixivFactoryであわせて10名弱くらい。両方ともRailsなど同じ道具を使って作っているので、エンジニアはどちらもみている感じですね。

白石：アジャイルで開発しているんでしたっけ。

川田：うちのチームではアジャイルと呼べるほど、そこまできっちりしていません。どちらかといえばDevOpsが自然に機能しているという印象。大きな機能リリースに向けた開発はしているけれど、それだけをメインとしてやってはいられない。いま動いているものに問題があれば、そこで対応もしなくてはいけないので。サポートチームのフィードバックであったり、エゴサーチして問題を探って、idobataで即座に共有されたり。

白石：エゴサーチを開発チームがしているのはすごい。社内のコミュニケーションツールはSlackじゃないんですね。idobataって、Slackと比べてどうなんですか？使いやすいとか。

川田：Slackとidobataを使ってはいますが、うちのチームだとidobataの方がメインになりましたね。自分たちの使っている範囲で、機能面にそこまでの違いは感じてはいません。Slackはチームごとで導入してしまっているからか、会社全体として導入しているidobataのほうがオープンに議論が交わされてて。他のチームのスレをみて気軽に意見を言ったり、挙句にプルリクを作って後方支援することもあったり。プロダクトやチームを超えて議論がされていますね。

タスク管理はカンバン。具体的なタスクはGitHub

白石：タスク管理は何を使ってます？

川田：うちのチームだと、タスク管理はカンバン。ToDoリストとしてざっくりタスクをポストイットで並べてます。トラブルがあったらそっちを優先したり、技術的な問題で遅れることもあります。タスクも今まで見てきた中ではわりと独立性が高いとおもってて、エンジニアやデザイナー、ディレクターやサポート担当者など、全員にビルド/デプロイ権限があって、自分たちが主体になってデプロイにまでもっていく。とはいえ、リーダーが責任をとるとか、デプロイした人が責任をとるとかそういうものもなく、リスクはチーム全体でうまく運用方法を改善しながらカバーしていきます。

細かい機能とかコードレベルの話はGitHubです。プライベートのリポジトリ上に、Issue立てたり、PullRequest作ってMergeして、みたいなかんじです。よくあるGitHubの普通な運用方法になるとおもいます。

想いとか、こうやったほうがいいというポエムはesa、具体的なのはGitHubです。全体像はカンバンで、普段のコミュニケーションはidobataがメインです。

白石：ほかに開発体制で面白いトピックはありますか？

川田：開発体制とは違うかもしれないんですけど、前の会社ではコミュニケーション手段がほぼメールと電話だけだったんです。それがこの会社に来てからは、メールと電話は一切使ったことがない。一度もです。ツールをしっかり固めて、コミュニケーションコストを下げると、得られる情報量が大きくなって、結果としてチームを超えていろんな情報にアクセスできるんです。ツールひとつで、ここまで組織がフラットになれるものなんですね。

ただ一方で、まずいと思うところもあって。メールや電話といったツールは、一般的なビジネスでは必須のコミュニケーションツールですよね。オーバーヘッドはとてつもなく大きいのですが、使わなくなるとそれはそれで、マナーやルールがわからなくなって社会から取り残されていく不安も感じるんです。両方のバランスが重要と感じています。

白石：社員同士のやりとりは何を使ってるんですか？

川田：一部はSkypeですが、基本はidobataでオープンにしてます。idobataのタイムライン上には、社員同士のやりとりだけじゃなく、自動的にデプロイの情報が流れてきたり、サポートの状況とかが流れてきたりで、社員同士のやりとりが発生しやすいというかんじがしています。

インフラはコンシューマ向きの超安いサーバー？

白石：開発環境はどうですか？

川田：開発環境の話だと、うちにはちょっとした特殊なインフラがありまして。初期のpixivは社長が借金をして買ってきた大量のサーバーがあるのですが。コンシューマー向けの安いマザーボードを、ラックにくくりつけて使ってるんですよ。ほんとうにむき出しのままなんです(笑)。

さすがに今は本番環境をデータセンターに預けるようにしていますが、開発環境には未だにそのマザーボードむき出しのサーバーをインフラとして使ってるんです。インフラチームの図画工作スキルは、いまだに高いようですね(笑)。

インフラの話をもう少し突っ込んですると、pixivの場合はサービスの特性上、クラウドよりオンプレのほうが向いていてそっちが中心ですね。とはいえ、ところどころにクラウドは使われていて、新しいプロジェクトだとAWSみたいなクラウドも使われています。

データベースは、基本的にはMySQL使ってます。OSはLinux。新しいプロジェクトはRails使うことが多いんですが、「Rails最強!! Railsじゃないとダメだ！」みたいな人はいなくて、ツールとして使っているという印象です。

サービスはリリースした時の最新技術で

白石：HTML5 Experts.jpはフロントエンド開発者が主な読者なので、フロントエンド開発の話も聞かせてもらえますか？

川田：私が関わるBOOTHだと、マークアップはSlim、CSSはSASSやCoffeeScriptとか。Ruby書いている人にやりやすい環境で整っています。また、開発したのが2013年なので、CoffeeScript、Backbone.js、Marionette.jsなどを使ってます。いまだとReactあたりがもっと上手く問題を解決してくれたりするんでしょうし、SPA（Single page application）ももっといいやり方があるのでしょうが、当時の技術を使っているので…。

とはいえ、2007年に作られたpixivでも、CoffeeScriptが使われていたりはします。部分的に入れ替えも進んでいます。今年の6月にリリースしたお絵かきアプリ「pixiv Sketch」は、React.jsやBabelが使われています。もろ時代の影響を受けていますね。

白石：それだけフロントエンドの流れが早いってことですね。

フロントエンドだと、そこそこエッジな事例がきけそうな、pixiv Sketchのエンジニアを呼んでみますね。

ReactとFluxでサーバーサイドレンダリング

──ということで、geta6さんにご登場いただきました。

geta6：片倉@geta6です。「pixiv Sketch」の担当エンジニアをしています。

白石：ぜひ、フレームワーク周りで面白い話を聞かせてください。

geta6：ブラウザ版のpixiv Sketchは、Node.js上で動かしています。

　　▲ピクシブ株式会社　エンジニア　片倉弘貴さん

白石：Node.jsってことは、サーバーサイドから全然違うかんじなんでしょうか。

geta6：サーバーサイドは、RailsによるAPIサーバーと、Node.jsによるレンダリングサーバーで構成されていて。前者はgrapeを使用していてviewを持たずJSONしか吐かない仕様になっていて、後者はサーバーサイドでAPIを叩いてDOMを構築するReactサーバーになっています。

白石：なるほど。最近、Universal JavaScriptととも言われているIsomorphic Javascriptですね。それでサーバーサイドレンダリングしてるって、まさに最新ですね。

geta6：フレームワークは、Yahooさんが作ったfluxibleというのを使っています。サーバーとクライアントが同じコードで動くので、キツイ面もありますけど。

白石：fluxibleって、結構ヘビーだって聞きますね。

geta6：fluxibleは一人でさくっと開発する場合とか、SPA（シングルページアプリケーション）とかには向いてないかもしれません。ただ、pixiv Sketchみたいに複数人数で開発する場合は、ある程度がっつりしたコードを書けるし、メンテナビリティがあるので魅力的です。

良いところは、二重実装をしなくていいことですね。テンプレートをslim側で書いて、Backbone.jsからもってきて、Javascriptテンプレート内にテキストテンプレートをもう一個書いて…とか面倒なことはしなくていい。同じコードベースでAPIのリクエストとかすべてのことができるので、そこが便利です。

白石：サーバーとクライアントが同じコードで動くのがキツイと言ってましたが、具体的にはどんなところが大変なんですか？

geta6：Reactは、クライアント側の世界とサーバー側の世界で、呼ばれるメソッドが違うところがあるんです。componentDidMountっていうメソッドなんですが、それはクライアント側にしか呼ばれないので、その中ではCanvasの操作やDOMの操作が書けるんです。それがわかっていればそんなにつらくないけど、React始めたばかりだと、その辺がわからないのでつらいのかもしれないです。

白石：getaさんの勉強量は相当すごそうですね。

geta6：いつもはそんなに勉強はしてないんですけど、pixiv Sketch始めるときに、Reactが流行ってるって聞いて、どうしてもやりたいって言ったら採用されたんです。React全然知らなかったのに、採用されたので一から徹底的に勉強しました(笑)。

課題はパフォーマンス改善。野望はES6への乗り換え

白石：お二人が、今課題だと思ってることってありますか。

川田：まだ入社したばかりなので、あまり深く掴めていませんが。自分の関わっているサービスのパフォーマンスが悪いことが気になっていますね。RailsとかJavaScriptとか、いろんなところに悪さするのが潜んでいますね。

もう一つは闇のコードたち。締め切り間際で、アドホックに作りこんじゃったコードとかがたくさんありまして。たとえば、BOOTHは「APOLLO(アポロ)」という同人音楽をネット上で頒布する即売会イベントを開いていて、そういうイベント対応のために作りこまれて、めったに呼ばれないメンテされにくい闇のコードが眠っているんです。ある日とつぜん爆発しそうなので、なんとか阻止したいです。すでに若干、爆発しかけていますが…

こういう、サービス固有の問題みたいなのは山程ありますが、それ以外はとくに不安を感じてはいません。テストコードも書かれているし、最新のバージョンに上げていきましょうというモチベーションもある。機能追加や改善ばかりな企画屋さんがいるチームは世の中にいっぱいいるけど、うちはコードヘルスがサービスのライフサイクルやセキュリティにどんな影響を与えるのか理解されているし、バージョンアップしておかないと大変という感覚とか、エンジニアならわかる勘所を大事にしてくれています。上手くやれている感じがしています。

白石：今後チャレンジしたいことはどうでしょう。

川田：やっぱり、早くES6にしたいです。CoffeeScriptやめたい(笑)。

白石：でも、CoffeeScriptのほうが言語的な機能は上じゃないですか？

geta6：CoffeeScriptって1週間前に書いた自分のコードが読めなくなるんですよ。言語機能が強すぎて。特殊な記法が必要だし。ES6では普通に読めるから、メンテナンス性は高いですよね。

川田：CoffeeScriptって、少し大きくなってくると、ビルドした結果を想像しながら書かなきゃいけなくなることがある。Devツールで、ちょっとこの値どうなってるんだろうとかコンソールを叩き始めると、今までCoffeeScriptのコードを読んでたはずなのに、完全にJavaScriptに戻ってたり。

geta6：CoffeeScript書いてるより、JavaScript書いてるかんじが強いんですよね。インデントが効かないのも厳しい(笑)。

川田：そうなんです。以前、私はTypeScriptを使っていたんですが、あれはビルドした結果がストレートに想像できるのがいい。あと、将来を見据えるとやっぱりES6を推しちゃいますね。

Nodeのデプロイツールに定番がほしい

白石：getaさんはどうですか？

geta6：開発環境の課題は、Node.jsのデプロイツールとプロセスマネージャーに定番がないことですね。デプロイは、信頼性をとってcapistranoを使ってるんですよ。Nodeのデプロイツールはどれも機能が貧弱で手数も多いので、定番でいいのが出てこないかなって思ってます。

白石：プロセスマネージャーは何を使ってるんですか？

geta6：プロセスマネージャーはPM2を使ってます。capistranoからシンボリックリンク設置して、currentで新しいファイルをディレクトリに送るんですが、Nodeのファイルシステムが変わってから、シンボリックリンクを追跡して、デプロイ前のファイルのところで監視しちゃうようになったんです。そこでプロセスマネージャーが生きちゃってるので、デプロイしてもファイルが新しくならないんです。そこで一回殺すというのをやってるので、ダウンタイムが若干できてしまうっていう問題点があります。

白石：そういった課題の改善に取り組んでいるんですね。次にチャレンジしたいことはありますか？

geta6：API側はバックエンドのプロセスマネージャーがUnicornなんですけど、ラインがN個しかなくて、同時に来ちゃったらつまっちゃうんです。Node側でいいかんじでリクエストをバッファリングしてうまく送れないかと。受付サーバーをNodeにしてゆっくり流すというようなことをしたいです。

白石：なかなかエッジなプロジェクトになりそうですね。

geta6：requestIdleCallBackだっけ？あれも何かやってみたい。

川田：ピクシブで「東京 Web Performance」という濃い勉強会をやったんですけど、エッジすぎて人が集まらないかなと思ったら、エッジな人が結構集まってきて(笑)。第一回は「requestIdleCallback」を味見したんですが、広告やアナリティクスに割といいかんじで使えそうだったんで、全力で攻めるんじゃないかって話をしてました。ピクシブに思いのほか、いい影響を及ぼしそうな予感がしてます。

白石：じゃあ、そこも次のチャレンジになりそうですね。今日は面白いお話を聞かせていただき、ありがとうございました。

乗るしかない！Reactのビッグウェーブに！─isomorphic tokyo meetupに参加してきた

白石俊平 — Fri, 01 May 2015 03:01:33 +0000

連載：アプリケーションアーキテクチャ最前線 (1)

おはようございます。編集長の白石です。

昨日（2015年4月30日）、isomorphic tokyo meetupに参加してきました。

というのも実は近々、HTML5 Experts.jpでは「Webアプリケーション・アーキテクチャ」に関する特集を行う予定なのですが、そこでキーワードとして挙げられていたのがisomorphic。 サーバサイドとクライアントサイドでコードの共有を促進するのが主な目的の一つ、というところまでは理解できたのですが、実際のところ、アーキテクチャはどう変わるのか？それを探りたいと思っていたところ、ちょうどよくイベントの開催がアナウンスされていたので、急遽取材させていただきました。

取材を快く受け入れてくださった、主催のYosuke FURUKAWAさん、本当にありがとうございました。

この記事では、トップバッターで講演されていたkoichikさんの講演内容を中心にご紹介して、isomorphicに触れるきっかけとなる記事を目指します。

なお、本日の講演者の皆様による資料はこちらになります。

isomorphic tokyo meetupの発表資料

「やみくも isomorphic から抜け出すために足りてないもの」 (by Jxck_)

※資料は後日公開だそうです。

今日のスライドがちょっと片手間すぎるので、公開はいろいろ直してからにします。 #isomorphic_meetup
— Jxck (@Jxck_) 2015, 4月 30

koichikさんによる「Isomorphic Survival Guide」つまみ食いレポート

koichikさんの「Isomorphic Survival Guide」は、まずIsomorphicという言葉の語源からでした。ギリシャ語で「同じ」という意味を表す「isos」という言葉と、「形」という意味を表す「morphe」という言葉を合わせたものだそうです。

isomorphicの語源

同じ成り立ちの言葉として、「metamorphic」や「polymorphic」があるとのこと。オブジェクト指向の世界で頻繁に用いられる「ポリモーフィック」という言葉が、isomorphicと同様「-morphic」で終わる単語だと気づいたのはこの時が初めてで、ハッとしました。

“-morphic”で終わる言葉はほかにも

で、isomorphicが語られるときには、「クライアントとサーバの間でのコード共有」や「フロントエンドとバックエンドの間でのコード共有」と紹介されることが多いですが、そもそもクライアントとフロントエンド、サーバとバックエンドが同じ意味の単語なのか、そこには人による解釈の違いもあれば、指している意味合いの違いもある、と指摘。

クライアント・サーバという用語とフロントエンド・バックエンドという用語は同一ではない

この講演においては、クライアントとサーバはネットワークの「こちら側」と「あちら側」、フロントエンドとバックエンドは情報の入出力を「人間相手に行う」のか「ストレージ相手に行う」のか、という意味で取り扱う。

本講演における用語の定義

例えば90年ごろの「C/Sシステム」（いわゆる「クラサバ」）は、クライアントのWindowsマシン上で「人間向け」（フロントエンド）の処理も「ストレージ向け」（バックエンド）の処理も行われていました。このように、クライアント＝フロントエンド、サーバ＝バックエンドという対応関係は時代によって変遷してきており、J2EEが提唱した三層アーキテクチャやRIAなど、様々なアーキテクチャと製品が模索されてきました。

C/Sシステム

フロントエンドとバックエンドの変遷

isomorphicに挑戦してきた様々なフレームワーク

こうした中、少しでも開発から無駄をなくすために、クライアント／サーバ、フロントエンド／バックエンドの間でコードを共有できないかという可能性が探られてきました。

「isomorphic」という単語は、筆者としては最近になって聞くようになったのですが、実は2011年にリリースされた「Flatiron」というフレームワークが提唱した概念だったそうです。4年近くも前から使われていた用語だったのですね。

Flatiron

しかし、Flatironはそれほど普及することなく現在に至ります。その後もYahoo!の「Mojito」や、一時期大きな話題になった（今でもアクティブに開発されていますが）Meteorなど、様々なプロダクトがisomorphicなアプローチにチャレンジしてきました。しかしこれらがあまり大きく普及しなかった要因は、「（プロダクト利用者にとっての）どんな課題を解くのか」が不明瞭だったり、ニッチ過ぎたり、先進的すぎたりしたことにあると指摘。

どんな課題を解くのかが重要

そんな中、Airbnbが2013年に公開した「Rendr」は、SPA (Single Page Application)の「初期表示が遅い」「SEOが弱い」という課題を解決すべく生み出されたもので、かなり実用的でした。

Rendr(Airbnb)

RendrはBackbone.jsを拡張してisomorphicな環境を実現するものでした。Rendrは、以下のように様々な可能性を切り開きました。

サーバサイドにおけるフロントエンドレイヤをJavaScriptで提供することで、クライアントとサーバのコード共有を実現しやすい
サーバサイドにおけるフロントエンドレイヤがセッション管理を行うことで、バックエンドのAPIをステートレスに保つことができる
サーバサイドにおけるフロントエンドレイヤがAPIゲートウェイとしてデータ変換を行ったり、様々なバックエンドAPIを組み合わせてフロントエンドに提供する（オーケストレーション）ことを可能にする
上記のことから、（サーバサイドにおける）フロントエンドとバックエンドの疎結合な関係や、バックエンドの実装をJavaScript に縛られず自由に開発できるようになり、ステートレスなマイクロサービスが協調して一つのサービスを作り上げるという構成を構築しやすい

Rendr的なIsomorphicの可能性

Reactの波に乗れ！

ですが、Rendrがリリースされた時期はAngularJSが人気を獲得した時期と重なっており、残念ながら大きな話題にはなりませんでした…。しかし今、「仮想DOM」というキャッチーなキーワードを引っさげ、Reactが登場するや、非常な人気を博して今に至ります。

Reactの仮想DOM

しかしReactはあくまでビューだけに特化したライブラリ。アプリケーションアーキテクチャとしては、Facebookが「Flux」を提唱していますが、公式な実装が提供されたのはFluxの一部分のみであったため、独自実装が乱立する事態となっています。

Flux

Fluxを用いたアプリの基本的な構成は以下のようになります。フロントエンド部分に限ってみると、処理の流れが綺麗に一方向（unidirectional）になっているのがわかります。

Flux的アプリの基本要素

そして何よりReactが期待されているのは、仮想DOMの仕組みを応用したisomorphicなアーキテクチャ。クライアントでは仮想DOMを実際のDOMツリーに変換しますが、サーバサイドでは仮想DOMからHTML文字列を出力するようにできるので、クライアントとサーバのどちらでも同様のコードが実行できるわけです。

Reactに関係するisomorphicなライブラリには、以下の様なものがあります。

Reactに関係した、Isomorphicなライブラリ

Flummoxも期待のライブラリ。

Flummox

Yahoo!が開発中のFluxibleは、比較的重量級なアプローチの、isomorphicなFluxアプリケーションコンテナ。

Fluxible

Fluxibleが使用する「Fetchr」は、バックエンド（の窓口となるWeb API）へのアクセスを、クライアントサイドとサーバサイドで同様のコードを用いることを実現します。正しくセットアップしていれば、Fluxアプリケーションのisomorphic化を促進できると期待されています。

Fetchr

まとめ

isomorphicなアーキテクチャは長い間模索されていましたが、これまでいまいち波に乗り切れていませんでした。しかし今はReactが非常に人気を博し、isomorphicなアーキテクチャの実現に対して、多くの人々が注力しています。

マイクロサービスとの相性も非常に良いと考えられ、今後大きな潮流になっていくのは間違いないでしょう。

まとめ

Reactの波に乗り遅れるな！