LINEのニュースタブをReact.jsで開発しているフロントエンド、JavaとPerlで開発しているサーバーサイドのエンジニアの方々に、どんな開発技術や体制で開発しているのか、HTML5 Experts.jp白石俊平編集長が直撃インタビューしてきました！

今回お話を聞いた「LINE NEWS」開発チームの皆さん

LINE株式会社 前澤 春樹さん
Javaのサーバーサイド担当。200以上の媒体社様向け管理画面のコンテンツ入稿システム開発や、公式アカウントから発信されるメッセージ配信システムが主な担当。

LINE株式会社 森藤 賢司さん
Perlで作られている一般ユーザーから見えるニュースタブ、記事ページのバックエンドや社内向けの管理画面を担当。

LINE株式会社 大槻 友諒さん
フロントエンドエンジニア。WebViewでつくられているニュースタブの実装を担当している。React.jsなどの最新技術に触れることも多い。

LINE株式会社 富田 梓さん
マークアップエンジニア。デザイナーの作成したPSDをもとにしたCSSの設計と実装を行う。ニュースタブの他、PC/SPのWeb、キャンペーンページなどニュース関連全般を担当。

なぜ、ニュースタブはWebViewなの？

白石：今日は主にニュースタブにフォーカスしてお話を聞いていきますね。LINEのニュースタブは、なぜWebViewを使ったのでしょうか。

大槻：もともと記事ページはWebViewで作っていました。ニュースタブを作ろうという話になったときに、記事ページと同じ技術で作るほうが開発スピードも早いし、やりやすい。バージョンアップなども、そろえたほうがリリースしやすいということでWebViewで作ることになりました。

白石：じゃあ、ニュースタブ以外はネイティブでできているんですね。

大槻：そうです。トークやタイムラインなど、メインの機能はネイティブで実装されています。並んでるタブの中だと、ニュースタブだけがWebViewです。

白石：WebViewとネイティブといった複数の技術を混ぜるのって、大変だったんじゃないでしょうか。

大槻：ネイティブとWebView間でデータやイベントをやり取りする必要があって、そのための仕組みをアプリエンジニアと協力して実現しました。ユーザーにはLINEアプリの一部として見えるので、挙動やパフォーマンスに違和感が出ないようにするのが大変でした。

白石：WebViewだと、読み込みや表示が遅かったりしません？

大槻：いえ、結果的にそこまで遅いということはなかったです。Webだからの限界はありましたけど、WebViewだから特別つらいことはありませんでした。

LINEバイトやLINEギフトといったファミリーアプリにはすでにWebViewの技術が使われていて、知見があったことも役立ったんだと思います。

白石：React.jsを使っているとのことですが、SPA的な開発だとマークアップはそんなに必要じゃないと思うんですが、両方必要なのはどうしてなんでしょう。

富田：うちは分業体制をとっていて、僕と大槻さんが所属しているチームはフロントエンドを担当しています。案件によってJSとマークアップの両方を一人が担当することもありますが、newsでは規模の大きさもあって担当が分かれています。

デザインからHTMLを起こして、それを渡しているので、一般的に言われているReactを使うイメージとはちょっと違うかもしれません。

大槻：セマンティックなHTMLを書くとか、CSSを設計するといったところは完全にお任せしてします。一回組んだものを、パーツとして分解してJSXに落とし込んでいます。

白石：PCでも記事ページそのものは見られるんでしたっけ？

富田：記事ページは見られます。

白石：あ、レスポンシブ対応しているんですね。

富田：いえ、レスポンシブとかではなくて、PC専用に作っています。SNSなどでシェアされたURLはPCからでもアクセスできるため、PC用の記事ページを用意しています。

JavaとPerlでサーバー管理

白石：サーバーサイドでJavaとPerlという複数言語を使っているのはなぜですか？

森藤：もともとPerlで全体が作られていたのですが、社内の方針で最近はJavaで作ろうという流れになってきています。なので、最近のレポジトリとかはJavaで作ってます。まあ、歴史的背景です(笑)。

Perlはニュースタブと記事ページ、あと社内向けのCMSもPerlで作られています。

白石：へえ！CMSは自作なんですね。ちなみに、ReactはAPIを出すのに使ってるんですか？

森藤：はい、ニュースタブの部分は、全てAPIで実装されています。

白石：Reactでサーバーサイドレンダリングしているのでしょうか。

大槻：いえ、クライアント側でレンダリングしています。

APIでとってきたデータをローカルストレージにのせておいて、ネットワークがないところでも画面が真っ白にならないように工夫しています。

白石：JavaとPerlで分かれていますけど、システム間連携しているんですか？

森藤：データベースで連携しています。データベースはMySQLを使っています。

白石：MySQLをクラウド上で？

森藤：いえ、オンプレです。本番環境は、現在ほとんどオンプレのサーバーで動いていますが、最近構築したサーバーや開発環境はプライベートクラウドの「Verda」というサービスを使っています。

白石：えっ、どこかの製品を買うのではなく、自分たちで作ってるんですか。かっこいいですね。

森藤：DB周りはDBA（データベース管理者）のチームが運用しています。DBサーバーの構成は、マスター1台に参照やバックアップに使うスレーブが数台ある感じです。テキストで入稿するデータなので、データ容量が一気に増えて困ったとか、容量が足りなくなったという話も聞いたことがないですね。

白石：Javaで入稿システムを作っていらっしゃるんですよね。ScalaやKotlinなんかも使っているんでしょうか？

前澤：Javaだけです。最近のモダンな言語に比べると、やっぱりJavaは冗長というかすごいコード量を書かないといけないのは大変なんですが…。

白石：ぼくは昔Javaエンジニアだったのですごく気になるんですが、Javaのバージョンは何ですか？

前澤：Java 8です。

大槻：僕も前職では、エンタープライズ系のサービスをJavaで書いていました。その時はバージョンが古くて4でした。あと8をちょっと触ったくらい。当時はジェネリクスもアノテーションもなくて(笑)。

白石：僕はXML地獄でしたね(笑)。EclipseみたいなIDEとかは使ってますか？

前澤：Eclipseは使ってなくて、IntelliJ IDEAを使ってます。

React.jsを選択した背景は？

白石：フロントエンドのReact.jsはいつから使ってるんですか？

大槻：ニュースタブができてからなので、2017年2月からですね。

白石：苦労したこととかありますか？

大槻：React.jsだから苦労したことは特になかったんですが、どのライブラリにするかは結構検証しました。Vue.jsやRiot.jsなんかもいろいろ試してみたのですが、結局React.jsにしました。

Create React Appでベースを立ち上げた経緯もあって、最初の環境を整えるのはすごくスムーズでした。React.jsは結構書きやすくて、世の中で使われているアプリも多く、バージョンアップも早いし、安定していて信頼できました。

白石：なるほど。stateの管理とか、Reduxは使ってますか？

大槻：Reduxは最初は使おうと思ったのですが、意外と過剰なスペックがあってやめました。代わりにFlux Utilsを使っています。

足りない開発ツールはどんどん作る

白石：ほかにLINEさん独自の開発手法があれば教えてください。

大槻：フロントのアクセス解析はGoogle アナリティクスを使っているんですが、そのほかに社内で開発した「LINE Analytics」という解析ツールを使っています。JavaScriptのエラー部分もリアルタイムに収集できるので、リリース直後に増減を確認したりしています。

白石：LINEさんは結構社内で作る文化があるんですね。自分たちでも作るというのは、意思決定が必要だと思うんですが、どんなかんじで決めているんですか？

富田：その辺は結構自由にやらせてもらえる風土ですね。プロジェクトで使うツールだけでなく、たとえばメーラーやスケジュール管理といった社内システムについて内製する部署があります。既製品でもの足りなかったら、自分たちで作っちゃおうみたいな。

大槻：分業しているのでサーバーに触れること自体は少ないんですが、JSやCSSの配信ツールをフロントエンドチーム内で開発したりと、役割内で足りないものは作って配布させたりする人が多いですね。

サーバー側はCIも自前で作ってると聞きました。社内の承認フローがそれほどかたくないので、わりと気軽に自前で作ってます。

白石：CIもですか！Jenkinsとかを使わずに？

前澤：Perlでは内製のCIを使っていますが、JavaではJenkinsを使ってビルドしていて、ビルドした成果物をサーバーに配布するシステムは内製です。CDNのオリジンサーバーも自作してますね。

秒間2万のアクセスを捌くパフォーマンス

白石：パフォーマンスなんかもかなり気をつかっているんじゃないでしょうか。

森藤：はい。APIアクセスが秒間2万くらいのアクセスがあるので試行錯誤しています。APPサーバーの台数は約30台くらいなんですが。

森藤：去年の6月に高速化プロジェクトがあって、CDNを追加しました。CDNはAkamaiを使っています。クエリーをちゃんと書いてなかったりするとサービスが止まるので、SQLには気をつけてキャッシュに貯めるようにしていますね。

白石：フロントエンドのパフォーマンスで工夫した点はどうですか？

大槻：ニュースタブは縦に長いんですけど、DOMが増え過ぎるとメモリを食ってアプリがクラッシュしてしまう問題がありました。

iPhoneでは横スワイプでタブ移動できるので、左右のタブを予め描画している分よりDOMが多く、見えないDOMをいかに削除していくかなどの工夫をしています。

タスク管理・チーム間の共有ツールは？

白石：皆さんは所属する組織は違うとのことですが、「LINE NEWS」プロジェクトのタスク管理やチーム間の共有ツールはどうしていますか。

富田：ニュースチームのプロジェクトとして定例ミーティングをして、進捗管理しています。管理に使っているツールはJIRAですね。

白石：進め方はアジャイルですか？

富田：そんなにアジャイルぽくはないです。企画チームが20人くらいいて、案件ベースを作ってくれるので、早い段階で開発からもフィードバックしたり、企画と一緒に練ったりします。1週間のスプリント制でやっています。

白石：ニュースチームは全体で何人くらいいらっしゃるんですか？

前澤：企画や開発、制作、編集、アライアンス、モニタリング、PR・マーケティングなどを含めると、プロジェクトに関わっている人は100人を超えています。エンジニアは現在、バックエンドが8人、フロントエンドが4人です。

白石：大型プロジェクトですね。CIは自作されてるとのことでしたけど、DevOpsみたいな工夫ポイントはありますか？

前澤：これまでは五月雨で流動的だったけど、人が増えてきたので週1回のサイクルを整えたり、模索しているところです。

白石：ソースコードの管理やリリースのルールとかはどうでしょう。

森藤：ソースコードの管理はGitHubです。Perl側は最低2人レビュアーがいないとリリースやマージしちゃいけないことになっています。

急成長するサービスと開発体制に合った環境を構築

白石：最後に今後こうしたいという抱負や、チャレンジしたい目標を教えてください。

前澤：LINEのサービスが急速に成長して、エンジニアも増えているので、開発時期によってリポジトリやフレームワークの使い方も違ってきています。それを統一したいと思っているんですけど、結構大変そうです(笑)。

森藤：これまでのサーバーサイドはほとんどPerlだったんですけど、ここ数年みんなJavaを書くようになって、Perlを書くエンジニアが減ってきているんです。サーバー側をもっとJavaに置き換えていけたらと思ってます。

大槻：TypeScriptを導入も検討していきたいです。依存するライブラリの都合もあって、簡単ではないかもしれませんが。

富田：ニュースのプロジェクトが始まったのが2013年で、最近では更新が滞っているruby-sassやgrunt、compassといった古い環境に依存しており、日々の更新に忙しくてそういった根幹部分はなかなか手を入れることが難しかったんですが、最近のリリースで、タスクランナーに依存したコンパイルをやめたり、node-sassへの移行したりしました。

それに伴ってチームで使っている社内用のツールやsassのライブラリを更新しているので、今後も新しい技術についてそれらに生かせるか検証しつつ対応できればと思っています。

白石：LINEさんは独自の開発ツールをどんどんつくっていく行動力と技術力が素晴らしいですね。今日はいろいろ面白い話をありがとうございました！

LINEさんでは、9月28日(木) にエンジニア向け技術カンファレンス「LINE DEVELOPER DAY 2017」を開催するそうです。LINEの様々なサービスにおける技術領域でのチャレンジや開発体制などについて語られるとのことなので、興味のある方はぜひ参加してみてください。

React現状確認

＠koba04氏は「React現状確認」というタイトルで、現在、Reactの取り巻く状況を様々まとめて語りました。

皆さんご存知の通り、React.jsはFacebookが開発しているJavaScriptライブラリです。まず、Reactはどのようなアプリで利用されているかということからお話します。具体的な例として、まず挙げられるのがFacebookです。ここではバリバリに利用されていますし、Instagramでは、アプリケーション全体がすべてReact.jsで作られていますので、Reactのdevtoolを使って中身を見てみるとなかなか面白いかもしれません。

Netflixではヘビーに利用されていて、テレビのレンダリング部分でも使われています。Twitter(mobile)も、React+Redux+React Routerの構成で利用されています。uberでは最近サイトをリニューアルし、そこでは先の構成にサーバサイドレンダリングなども利用しています。

どのような人がReact.jsを利用しているかというと、パフォーマンスが速いから使っているという人はあまりいない。それよりも宣言的なコンポーネント、ピュアなコンポーネントを定義するためといったことや、メンテナブルなUIを作るために使っている人が多いです。

その他、新しく実装された機能、現状議論されている多くの機能についてコメント。盛りだくさんなので具体的な内容については省略します。詳細な話については、当日の資料をご参照ください。

• Stateless Function Component
• ES2015 Classes & ES2015 Classes Components
• React.createClass
• React.PureComponent
• A pitfall of shouldComponentUpdate
• react-addons-perf
• why-did-you-update
• unstable_batchedUpdates
• ReactElement

最後に、ミーティングが毎週行われていて、ミーティングノートが１週間ごとに出しています。今後のReact.jsはライブラリとしてもっと小さくしていくことや、レンダラー部分についてどう改善していくかなど議論しています。

the-state-of-react-dot-js-2016

なぜReduxを使うのか

＠kuy氏から、最近人気上昇中のReduxについて、Reduxとはどういったものかを語りました。

Reduxが最近注目されている理由は、事例が多くなってきているのと、コミュニティが活発になってきているということが挙げられます。特に開発するための周辺ライブラリが充実し、機運が高まり、Reduxが注目され始めています。

反面、Twitter等でよく見かける投稿は、Reduxがつらい、Redux難しい、Reduxの良さがわからないという意見もあり、結果としてRedux大丈夫なのかと思わせてしまうようなことも起きています。

そこで、なぜReduxを使うのかということを整理してみます。特に、作者のDan Abramovさんいわく、「ライブラリの使い方に時間を費やすよりも背景にあるアイデアを学んで、他所に活用していこう」ということを訴えています。

Fluxは何を解決したのか

Fluxの考え方はご存知の方も多いとは思いますが、順番としてはまず、ViewからActionが投げられます。Dispatherはこの投げられたActionをStoreに投げるルーティングの役割をしています。StoreはActionを受け取ってStateを変更します。このStateの変更をViewが受け取って、Viewはその情報に従ってレンダリングを行うという流れです。

Fluxで解決したかったことは、基本的にはReact単体で構築したときに困ることを解決したかった、具体的には、バケツリレーという問題がありました。バケツリレーというのはコンポーネント階層が深くなったとき、例えば深い階層のコンポーネントへイベントを伝搬するときに、途中のコンポーネントには無関係にも関わらず、通過していくという問題がありました。

Stateをコンポーネントで持っている場合、他のコンポーネントへそのStateを渡したい場合、このコンポーネントの上位の親コンポーネントを作ねばならないという問題があった。何かするときに必ず親コンポーネントを作らないといけない。

Reduxの何がいいのか

FluxにはDispatcherが存在していましたが、ReduxではDispatcherがStoreの中に組み込まれていました。FluxでもStoreがあるが、ReduxではそのStoreを役割ごとに名前を変え、利便性を向上させたところがポイントです。

では、より具体的にReduxのどこがいいのかというと、1つの大きなStateツリーを複数のReducerで構築しています。そして、状態管理だけに特化したところです。反面、それ以外は開発者に丸投げということになりますが、よく言えば開発者の状況に応じて開発できるということを意味します。

そして、状態管理に特化したということがあるので、Reduxを素の状態で利用するのはお勧めできないし、無理してReact, Action, Creator, Reducerで実装すると後で大変な思いをするということです。専用のMiddlewareを入れるといいとのことです。

※当日の資料は以下にアップされていますので、こちらも参照してください。

nazereduxwoshi-ufalseka

Relay

＠hokaccha氏によるRelayのお話です。

RelayはクライアントにReactを利用し、サーバにGraphQLを使ったものです。仕様としてまとめたものがGraphQL Relayで実装としては、react-relayとgraphgl-relayがあります。Relayをひと言で言えば、フルスタックなフレームワークです。Angularがよくフルスタックといわれますが、Angularはクライアントだけなので、Relayはサーバまでやっていますので、本当のフルスタックということになると思います。

GraphQLとは、Facebookが開発したクエリ言語で、クライアント/サーバ間でデータのやり取りに利用されます。レイヤーとしてはREST/RPCと同じ位置付けになります。

RESTと違って、リクエストに対するレスポンスのフィールドが1:1対応しているところです。そうすると、必要なフィールドだけを選択可能となり、ネスとしたデータを一発で抽出できることや、型定義が存在するなどメリットがあります。

Relayの特徴は、そのサイトにも書いてある通り3つあります。

• DECLARATIVE
• COLOCATION
• MUTATIONS

しかし、Relayは敷居が高いと思います。例えば、GraphQLを覚えて、ちょっとしたアプリを作るにもGraphQLのサーバが必要になりいろいろと大変になる。そしてやっている人もあまりいないので、資料を探すとちょっと大変な思いをします。Relayの期待として、真のフルスタックなフレームワークになり、次世代のRailsになれる可能性があるかもしれないかもしれないです。

※当日の資料は以下にアップされていますので、こちらも参照してください。

relay-1

How to style React components

＠Quramy氏からは、コンポーネント内にあるCSSの話がありました。同氏はメインサービスとしてはAngularを使っているが、社内系ツールではReactを使っています。

UI Componentと呼ばれるものの特徴は、見た目と振る舞いがまとめて提供されていて、適度にカプセル化されているものです。そうなると再利用性が高くなり、保守しやすくなるところに期待があります。このコンポーネントは多くのJSフレームワークでサポートされています。

Style定義は、とても壊れやすいです。コンポーネントの外部から、CSSを破壊することが簡単にできるからです。つまり、React.Componentを使っただけでは、CSSが適切にカプセル化されているわけではないのです。この問題は、CSSセレクタがGlobalであることが最大の問題だと言えます。この問題解決のために、

• CSS命名規約
• Web Component(Shadow DOM)
• CSS in JS
• CSS Modules

ということが挙げられます。

CSS in JS

CSS in JSは、Christopher Chedeauが2014年に発表しました。ReactはJSXでテンプレートをJavaScriptに取り込むことに成功したので、CSSもJavaScriptに取り込めばいいのではということから始まりました。CSS class名を利用しないでinline-styleを利用することで、Styleをコンポーネントに閉じ込めることが可能になり、問題の発生がなくなります。

こうした考えは、他にもいくつかメリットがあります。デメリットとしては、擬似要素セレクタや擬似クラスセレクタなど、インラインスタイルで定義できないようなものは利用できません。

CSS Modules

Glen Maddernが2015年に定評しました。CSS in JSはJavaScriptでStyleを生成したのに対し、CSS ModulesはCSSをJavaScriptから利用するというアプローチを取っています。CSSでできることは、CSSでやろうと言ったところです。

CSSで定義された名前を論理名として扱い、JavaScriptでimportし、その定義を読み込みます。JavaScriptが実行されるときに内部的に付与した名前に書き換え、容易に破壊できないようにしています。

※当日の資料は以下にアップされていますので、こちらも参照してください。

react-css-note

Atomic Design powered by React @AbemaTV

五藤佑典氏による＠AbemaTVの事例紹介です。

＠AbemaTVはサイバーエージントとテレビ朝日が共同で展開していて、多様なコンテンツがあります。AbemaTVでは、開発の初めスマホアプリで開発は進んでいましたが、Web版はなく仕様が決まっていませんでした。しかし、リリース日は決まっているという状態でした。

このような状況では、作っていくうちに画面変更が多々入るのがわかっていたので、わかるところから作るという方針でせめて行きました。

画面仕様の変更に強いコンポーネントの粒度を、チームで明確化したいという欲求が出てきました。ATOMIC DESIGNを参考にしました。ATOMIC DESIGNとは、UIコンポーネントの要素を化学の原子論的な要素に見立て、小さいシンプルなコンポーネントを組み合わせより大きなコンポーネントを構成するデザインシステムのことです。

ATOMIC DESIGNの考え方を適用しグローバルナビ、リモコン、スライダー、アイコンなどを作っていきました。こうして作ったAbemaTVの細かな画面変更に関し粒度がある程度細かったため、変更は割とスムーズにできたというところがこのシステムを採用した良い結果だったと考えています。チーム開発において個人の感覚に依存しない形で行えたことは、プロジェクトがうまくいった要素であります。

@AbemaTVはReact+Flux+Atomic Designですが、ViewでReactとAtomic Designを利用し、StoreでImmutable.js、DespatcherでRxJSを使っています。

当日の資料は以下にアップされていますので、こちらも参照してください。

atomic-desigin-powered-by-react-abematv

最後に

このレポートではイベントが盛りだくさんだったため、内容の細かなところまでは記載できませんでした。各登壇者の資料もアップされていますので、合わせて見ていただけると幸いです。また、html5j配信班による動画もありますので、参照してください。

本イベントとは関係ありませんが、2016年のHTML5カンファレンスが9月3日（土）東京電気大学に決まりました！乞うご期待！！

特集企画「アプリケーションアーキテクチャ最前線」では、さまざまな視点からアプリケーションアーキテクチャをエキスパートたちに語っていただきます。今回は、今話題のAngularJSなどのJavaScript MVCフレームワークの台頭と進化、そして新しいアーキテクチャであるFluxとそのフレームワークであるReactなどについて、既に先行して学んでいるエキスパートたちにその知見を聞いてみました。

今回はフレームワーク対決ということで、エキスパートたちがAngularとReactという陣営に分かれ、それぞれのフレームワークについて疑問点をぶつけたり、議論したりする仮想パネルディスカッションという形式でお伝えします。単なるパネルディスカッションとは違って、キーワードは「プロレス」です。まさかりの投げ合い、disり合いOKという形で、NGワードは「適材適所」「ケースバイケース」などです。白熱した議論をお楽しみください！

　　▲議論が白熱する選手たち。左から、久保田光則さん、金井健一さん、増井雄一郎さん、小林徹さん

選手入場（自己紹介）

白石：さて、それではプロレスを始めていきましょうか（笑）。まずは、皆さんの簡単なプロフィールと一押しのフレームワークなどを教えてください。

（React陣営）
小林：小林徹（@koba04）と申します。前職でソーシャルゲームを作っていました。そのときはBackboneとかAngularとかを使っていて、今はReact.jsに興味があって、業務でも使っていこうかと思っています。　　　　　　　　

　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　
増井：増井雄一郎（@masuidrive）です。一押しのフレームワークは、ReactとFluxなんですが、ReactはViewのライブラリなので、Fluxになるのかなと。複雑なことをやるのは嫌いなので、なるべくシンプルに書けるということでReactとFluxの組み合わせは気に入っています。あとは自由度が高いという点も気に入っています。

（Angular陣営）
金井：金井健一と申します。フリーランスで、AngularJS Japanユーザーグループの管理人をしています。一押しはAngularですね。Angularは何がいいかというと、フルスタックなところで、悪い面もありますが良い面のほうが多いんじゃないかと思います。学習コストが高いというのもよく言われますが、それだけ機能が多岐に渡っているということなので、いったん使いこなせればすごくいいフレームワークだと思います。

久保田：久保田光則と申します。アシアルという会社でエンジニアをやっています。会社ではOnsenUIというフレームワークを作っています。3年か4年くらい前からずっとJSとかフロントエンドばっかりやってきていて、ちょっと前はKnockoutJSがいいなと思っていたんですけど、気がついたらずっとAngularJSばっかり書いていました（笑）。Angular2は野心的な方針で、いろんなものを取り込んで最高のものにしていこうという気概が感じられるので注目していかないとなと思っています。

お互いのフレームワークへの疑問点など

白石：このパネルディスカッションの今後の流れとしては、僕のほうからは何かコントロールするということはないので、レフェリーみたいなものだと思ってください（笑）。自由にやっていただければと思います。それでは、今回の本題ということで、お互いのフレームワークについて疑問点だったり、disったりということをお願いします。

小林：Angularは、1.04ぐらいのときに使っていて、実際にプロダクトに使ったんですが、結構情報がなくて辛かった思い出があります。DirectiveってよくわからないのでシンプルにControllerとかScopeとかで頑張ってやったという印象がありますね。

金井：当時は、結構そうかも。ただ今は、ドキュメントも充実してきているので今はさほど辛くはないかなと思いますね。Reactはルーティングとかバインディングとかその辺はどこまでできるんですか？

増井：React自体はほんとにViewだけなので、まったくそこはケアしないですね。Fluxは考え方なので、実はすごい小さいんですよ。Dispatcherだけなので数百行ぐらいしかない。あとそこにどうやってルーティングをやるかというのは、React Routerとか外部のコンポーネントを組み合わせて使うので、標準では持っていないです。そこは大きく違いところだと思います。

僕はAngular使っていないんですが、会社（トレタ）のほうでは、PC向けの機能は全部Angularで作ってるんです。でもそこの中の人に聞くと、CRUDみたいなよくあるアプリケーションは結構楽にできて、Angularがなかったら短期間では作れなかったと思うと言われました。ただ、そういうパターンからはずれてしまうとすごい書きにくいかもしれなくて、拡張していくとき、パターンが複雑化してきたときに本当に耐えうるのかが不安と聞きました。そういう傾向ってどうなんですかね？

久保田：何もかもScopeとかで管理しようとすると結構はまりどころ多いなというイメージがありますね。細かいインタラクションとか、例えばドラッグ＆ドロップを直接使いたいときって、結局DOMを触るしかなくて、DOM触るにはDirectiveっていうものが用意されています。Directiveは、ある程度DOMに対してのいろんな機能を追加するとか、細かいDOMの操作を担当するものなんですよ。全部Controllerで管理しようとするとすごいぐちゃぐちゃになったりするんですけど、ちゃんと自分でDirectiveを作って管理すると扱いやすいと思います。

増井：なるほど。あと、Angular1系と2系ってはたから見てると、2系が年末だか来年だかに出て、結構互換性がないっていう話で、1系は捨てちゃうっていうことを聞いてそこはちょっと怖いかなっていう印象はありますね。

金井：2系が主流になって、1系が減ってこない限りはサポートするという話ですね。なので、そこは早いうちにアップデートしないといけないかもしれません。

増井：でもアップデートってまるまる書き直しなんですよね？

久保田：ng-japanでもアナウンスされてましたが、Angular2とAngular1を共存する方法はあって、1系のコードと2系のコードを混在させることができるようですね。

今からフレームワークを採用するとしたらどちらを使う？

増井：今から新しくプロジェクト始めるときにどのフレームワークで作ろうかみたいなときに、実際に作る人は悩むんですかね。

白石：実際、今作ろうと思っているものがあるんですが、悩みますね。

金井：なんでそこはAngularじゃないんですか（笑）。

白石：Angularはでかくて複雑すぎて怖いんですよね。しかもAngular2が迫っているという。この今のタイミングで採用するのはちょっと怖い。

増井：そういう意味では、僕はReact.jsがなくなっても、React.jsと同じものを書ける自信があるんですよ。FluxとReact.jsをまるっとFacebookがやめました、明日からReactはありませんと言われたときに、僕はReact全体をメンテナンスできる。まるっと同じものを作れっていわれたら、まあ頑張って作れる。Angularは作れる気がしない。

金井：作れる気はしないですね（笑）。

増井：僕は結構そこが怖くて。なので、大きいフレームワークは採用しにくいっていう面があります。あと、MVCの上にMVCを乗っけるというのは、その考え方はすごくToo Muchかなと。サーバーサイドは、サーバーサイドでMVCを作っていて、さらにクライアントサイドでMVCを作るわけじゃないですか。MVCの2階建てはアーキテクチャとして本当にいいのかっていうのはすごく思っていますね。

そもそもモデルをデータベースから作って、ちゃんとAPIにしているはずなのに、それをさらにもう一回モデルとして扱う、あんまり効率的じゃないんじゃないかっていう。Reactだけに限ると、MVCのVしかないので、そもそも書いて読んだJSONをそのままViewで表示するってことをやったりするんです。だけど、実はAPIが揃ってると結構なWebアプリケーションで、そもそもモデルまでおこさなくてもいいんじゃないかっていう気がするんですよ。

金井：JSONをとってきて出すっていうのはAngularでもできるので、それはアプリの設計によるのかなという気がしています。Angularの場合は、さらにそこから変更もできるという利点があります。

増井：それにしてはToo Muchすぎるんじゃないかと。

金井：それだけしたい場合には確かにそうですね。

増井：結構なケースがそれで済むんじゃないかっていう気はしていて。実はクライアント側でMVCが必要なほど複雑な処理するケースってそんなに多いのかなと。

久保田：まあでも実際には、もちろんアプリの要件によると思います。ハイブリッドアプリって結局JSでなんでもやるので、API叩けばそれで終わりというわけじゃなくて、むしろJSのほうでいろんなことを書かなきゃいけないって感じになるので、API叩けばそれで終わりっていう感じにはならないですよね。

APIってネットワーク越しにやるんでそれってすごく重たいし、あんまりやりたくないっていうのはモバイルアプリだと多いです。そもそもモバイルアプリだとネットワーク繋がらないってこともあるので、それを解決するにはローカルのほうでデータを保持して、繋がったら同期をとるっていう感じになるので、モデルがないとちょっと辛いという感じになりますね。

JSXは気持ち悪い？

白石：JSXがキモいんですけど…。

増井：あれは気持ち悪いんですよ実際（笑）。キモいっていうのはまったく異論ないんですけど、あれはあれで理にかなっていると思っています。DOM操作がなんで難しいかっていうとそもそもこのDOMをみたときに、これがいつどこで書き換わるかわからないし、さらにこのボタンを押したときにどこで何が起こるかわからない、イベントは1個じゃなくて100個でも張れるので。っていうのに対してJSXの場合はそういうのを一応ビューとロジックを同じところに書くことで、さらにイベントリスナーを1対1にすることによって、そういう複雑性を省きましょうという考え方なので、気持ち悪いことは認めつつ、理にはかなっているかなと。

1番の問題は、HTMLしか書けない人がこれを触れないっていう。コーダーと分離ができないっていう点ですよね。ただこれはもっと根本的な問題で、Reactは画面の一部をコンポーネントとしてスコープを作りましょうっていう考え方で、HTMLを切ってるんじゃなくて、プログラミングスコープを切ってるんですよ。それって見た目のデザインとはちょっと違って、アーキテクチャのデザインの話なので、見た目とロジックを切り離すっていうところに、そもそも無理があるじゃないかっていうことですね。

金井：そこらへん（画面の一部をコンポーネントとしてスコープを作る）は、Angularも目指すところは同じかもしれないですね。

増井：そのやり方が違うってだけなんでしょうね。

久保田：ちょっといいですか。別にJSXって気持ち悪くなくないですか。

小林：私も全然違和感ない（笑）。

白石：人によるんだ。

増井：僕も去年からReactを知ってたのに触ってなかったのは、JSXです（笑）。あれで毛嫌いして触らなくて、でもあんまり話題になってるので去年の年末年始から本格的に触ってみたというのがあります。あれは僕個人も気持ち悪いです（笑）。

小林：ぱっと見たときに、あれ（JSX）がやりたいフレームワークなのかなと思っちゃうんですよね。

増井：日本でのReactの評価は、Virtual DOMっていう技術キーワードとJSXという見た目にすごく左右されている印象がありますね。

Virtual DOMって本当に早いんですか？

白石：Virtual DOMって本当にそんなに早かったりするんですか。ぱっと考えると差分をComputeとする計算処理も必要だし、フロントのDOMと仮想DOMって2つ持っているメモリも喰いそうだなと思うんですけど、実際はどうなんですか？

小林：実際は何が一番早いかっていうのはやっぱりDOMを直接触るのが一番早いっていうのは間違いなくて、でもそれってコードとしても複雑になるじゃないですか。モデルのデータの変更された部分だけをどういう風に反映するのかっていうところが煩雑になる。Virtual DOMだと、ひとつの状態をもっておいて、パっと更新すると差分だけを綺麗に反映してくれるので、DOMを直接触るよりは遅いですが、該当部分のDOMを全部入れ替えるよりは早いという感じです。最速ではない。

白石：最速ではないと。わりとプログラマーがいい加減な処理をしてもいいってことですね。

増井：Reactはとりあえずざっくり書けば、そこそこ速いっていうような考えですね。

久保田：最近、Atomで内部でReact使ってたけどパフォーマンスのために削除したっていう話がありましたね。

白石：え、そうなんですか。もう使わなくなっちゃったんだ。

小林：最初のやつがちゃんと構造化されていなくて遅かったのをReactにして、ちょっと速くなって。そこをベースにDOM職人が頑張ってやったらさらに早くなったっていう感じですね。

Angularは謎のルールが多い

白石：Angularを触ったり調べたりしたときに僕的には謎のルールがすごい多くてとっつきにくかった。例えば、$変数が多すぎ。何々のときは$なんとかが多くて、なんだこれはっていう（笑）。

金井：あれ何なんでしょうね。$$とかあるしね（笑）。

白石：Dependency Injectionを実装したのはいいんだけど、まず引数の名前で当てるからminifyしないでねとか、minifyしてもいいように別の書き方も発明したよとか配列で指定できるようになったりとか。なんかもう歴史上の問題かもしれないんですけど、謎ルールが多すぎる感があるんですけど。そこらへんはどうなんでしょう？

久保田：やっぱりそこは気持ち悪いなと思います。でも昔からずっと実務上の必要からそういうのが増えてきたのかなと思いますね。あとから来た方がどうしたもの洗練されたものになっていくので…。

増井：Angularっていつできたんでしたっけ？

金井：結構前で、2009年ですね。

増井：そんなに前なんだ！

金井：Angular1が2012年ぐらいなので、そこで注目された感じですね。2009年にできたフレームワークが5年くらい経って実用になりつつも、辛くなってきたということでAngular2を開発しているということだと思います。Angularのいいところっていうのは、その時々で結構先のことを見据えてやろうとしていて、1系だとWeb Componentsを実装したくてDirective作ったりしてるし、Object.observe()欲しいよねっていって2way bindingを実装してみたりとか。どんどん攻めてるんですよね。

増井：そういうイメージはありますね。

実はReactは大きい

白石：ちなみにフレームワークの大きさでいうとどうなんでしょう。

増井：ReactってViewのライブラリだけのくせにすごいでかいんですよ。へたしたらjQueryよりでかい。

金井：フレームワークのサイズが大きいと、モバイルのユースケースで叩かれませんか、重いとか。Angularは相当叩かれた覚えがあります（笑）。

増井：とはいっても画像ひとつ分ぐらいですからね。Reactも実際よくあるReactのダメなところに「でかい」っていうのはいろいろ言われていて、でも現実ユーザーからそういう話があがってるわけではなく、数字で見てっていう部分があります。あと、Reactはサーバーサイドレンダリングを持っているので、ファーストビューはサーバーサイドで出しちゃって、その後にJS読み込むっていうことができるので、そういう意味では十分早いですね。面倒くさいですけど、やろうと思えばできます。

白石：今、ダウンロードしてみたんですけど、Angularがminify時で126KBで、Reactが121KBという結果に。

増井：しかも、AngularはMVCで、ReactはVだけで、ですからね（笑）。

金井：やれること全然違う。（Angularは）ルーティングからバインディングからすべてできるのに（笑）。

検索可能にするサーバーサイドレンダリング

増井：Reactのひとついいところは、サーバーサイド生成ができるのでぐぐったときに引っかかるんですよね。クローラーは基本的にはJSを実行しないので、みんなテンプレートにはじめから引っかかりそうなキーワードを入れたりとかして頑張るんですけど。でもReactはサーバーサイド（Node.js）でReactエンジンを実行してHTMLを生成することができるんですよ。そうすると例えば、基本的な部分をファーストビューで表示すると、JSが実行されなくてもHTMLで画面が見えて、JSが実行されると残りの部分が表示されるという段階的にできるですよ。

そうすれば、検索エンジンに引っかかるし、JSがもし（ブラウザで）動作しなくても本文はちゃんと読めるというメリットがあります。といってもそれをやるには、それなりに考えて書かなきゃならなきゃいけなかったり、その実行エンジンをいろいろセットアップしなきゃいけないので、手放しでできるっていうわけでもないんですが。

小林：海外はやっぱりReact導入してるところは、サーバーサイドレンダリングもやっているところが多いですね。海外のほうがサーバーにNode.jsを使うのは結構一般的で、日本だとあんまりないから意外なんですけど。サーバーサイドレンダリングできるからReact採用してるっていうとこも結構ありますね。BBCとか。

増井：ぐぐれるっていうのはでかいですからね。

白石：なるほど。じゃあAngularのほうは、どうですか？

久保田：まあAngular2に期待ですね。Angular2のレンダリングのアーキテクチャについて設計文書が公開されていて、その中でVirtual DOMを使いますと言っています。

小林：Ember.jsも次のバージョンでHTMLbarsとsimple-domを組み合わせてサーバーサイドレンダリングできるようになる予定で、これからのフレームワークはサーバーサイドレンダリングはついてきそうな気がしますね。

久保田：あと、ちょっと面白いと思ったのがサーバーサイドレンダリングだけでなく、Viewの処理をWeb Workerでやりたいっていう点ですね。

増井：Web WorkerはReactでもやるっていってますね。そんなに進んでないですが。

白石：確かに仮想DOMは、本物のDOMじゃないからWorkerでいじれるし、間のメッセージングにコストがかからなければ割と早そうですね。

増井：そこ（Reactの仮想DOM）の差分の計算までWorkerでやってしまうので、それなりの速度がでるはずですね。ChromeもServiceWorkerとか機能を強化してるのでたぶんそういうのに合わせてるんだろうなと思います。

開発速度・生産性の比較

小林：たぶんReact使っても開発速度って上がらない。書く量も結構増えますね。

増井：むしろ下がります（笑）。プログラムでひとつ大事なところは、1年後に触れるかどうかだと思っていて、よくプログラムは書くより読む時間、回数のほうが多いので読むことを考えて書くべきだって言う考えがありますよね。時間がかかっても読みやすく書いて、それによってコード量が増えるのはプログラムとしてしょうがないんじゃないかっていう考えがあって、Reactはそういう考えに近いですね。なので記述量は減らないし、同じの書いたら5〜10倍ぐらいになっちゃっていう話もあって、あきらかにめんどくさいです。

金井：AngularJSは、預ける部分が大きいので、勝手にやってくれる。コード量は圧倒的に減りますね。なのでCRUD系作るときはすごく早いです。

おわりに

このように議論はすごく白熱して、興味深いトピックスが目白押しでした。楽しんでいただけましたでしょうか。今回は「議論は平行線だった」ということで終わりたいと思います。

本記事は、2015/2/21に行われたFrontrend Conferenceの「Introduction To React」の内容を紹介します。

当日の資料は以下にアップされていますので、こちらも参照してください。

Introduction To React // Speaker Deck

React.jsとは何か

React.jsはFacebook製のJavaScriptライブラリです。

http://facebook.github.io/react/

公式サイトに、「A JavaScript library for building user interfaces」とあるように、React.jsはUIを構築するためのライブラリです。フレームワークでなくあくまでUIを構築するだけのライブラリで、MVCでいうところのVのみの機能を提供します。

開発を行っているFacebookやInstagramはもちろん、YahooやAirbnbなど多くの採用事例があり、現在注目を集めているライブラリの一つです。

React.jsの特徴

React.jsの特徴を知るために、まずは他のライブラリやフレームワークの問題点について見ていきましょう。例えばTodo MVCのような、フォームを送信したらリストに項目が追加されるようなUIの実装を考えてみましょう。

jQuery

単純にjQueryだけで実装すると次のようになるでしょう。

// Submitされたら
$('form').on('submit', functino() {
  // 要素作って
  var $li = $('<li>');
  // ...

  // リストに追加
  $('ul').append($li);
});

しかし、これだとデータがDOMにしかないので、何か機能を追加しようとしたときに非常にやりづらいですし、テストも書きにくいコードになります。

Backbone.js

Backbone.jsを使うとこの問題をある程度解決することができます。Backbone.jsはデータは管理するModelと、表示を管理するViewに分け、さらにViewをコンポーネントごとに分けるという設計を提案します。例えば次のようになります。

var FormView = Backbone.View.extend({
  onSubmit: function() {
    // dataを作ってモデルに追加するだけ
    this.collection.add(data)
  }
});

var ListView = Backbone.View.extend({
  initialize: function() {
    // モデルが更新されたらリストを更新
    this.collection.on('add', this.render);
  }
});

FormViewやListViewといった、UIの部品ごとに機能を分けていますが、このようなものをここではコンポーネントと呼ぶことにします。

Backbone.jsでデータやコンポーネントを分けて管理できるようになるとある程度の規模ではうまくいきますが、Viewの更新処理を手動で書かないといけない面倒さがあったり、ModelとView間のイベント管理が煩雑になるなど、規模が大きくなった時にスケールしづらいという問題があります。（Backbone.jsのラッパーライブラリであるMarionetteやChaplinといったものもありますが、本質的な問題は同じです）

Angular.js、Vue.js

Angular.js、Vue.jsなどに代表される、いわゆるMVVM系のライブラリの特徴はデータが変更されたら自動的に表示が変わる、という考え方です。

<form ng-submit="onSubmit()">
  <input type="text" ng-model="text">
</form>

<ul>
  <li ng-repeat="item in list">
    {{item.text}}
  </li>
</ul>

// Controller
$scope.onSubmit = function() {
  // データを更新したら勝手にViewが変わる
  $scope.list.push(newItem);
};

このように、HTMLに描画されるデータを記述し、JavaScript側ではデータを更新するだけで自動的に表示が更新されます。しかし、これらのライブラリも、規模が大きくなってきた時に状態を管理するのが難しくなってきます。

React.js

jQueryやBackbone.js、Angular.jsは規模が大きくなったときに管理するのが難しくなる、と述べましたが、きちんと設計すれば管理しやすいアプリケーションにすることは可能でしょう。しかし、それらは元々そのような目的のためのライブラリではないので、規模が大きくなっても管理可能に設計するというのは簡単なことではありません。

React.jsは、規模が大きくなっても管理できるような仕組みを提供してくれるライブラリです。逆に言えば、小さいアプリケーションを高速に開発するためのライブラリではないので、そういった場合はBackbone.jsやVue.jsを使ったほうがいいケースが多いと思います。

React.jsの特徴として、コンポーネントを極力ステートレスにすることで、コンポーネントを管理しやすくするというものがあります。

var Form = React.createClass({
  onSubmit: function() {
    // 親にデータの更新を通知
  },
  render: function() {
    return <form onSubmit={this.onSubmit}>...</form>;
  }
});

var List = React.createClass({
  render: function() {
    // 親からもらったデータを元に構築するだけ
    return <ul>{this.props.list.map(...)</ul>;
  }
});

各コンポーネントは親からデータをもらい、それを元にViewを構築します。ここで重要なのは、コンポーネント自身は状態を持たないということです。常に外部（多くの場合は親コンポーネント）からの入力によって一意な表示を出力することでテストしやすく、管理可能で再利用性の高いコンポーネントにすることができます。

もちろん、全てのコンポーネントが状態を持たないと単なる静的なHTMLと同じですので、状態を持つコンポーネントも必要になりますが、そのようなコンポーネントを最小限にし、基本的にはステートレスなコンポーネントを作って組み合わせていくのがReact.jsにおけるプログラミングの考え方です。

普通はツリーのルートのコンポーネントだけに状態を持たせ、その状態を子のコンポーネントに伝え、ツリーを構築します。

また、コンポーネントの状態が変更すると自動的にツリーは再構築されるので、表示の更新を手動でやる必要がありません。これはAngular.jsなどのような、データが変わったら自動的に表示が変わるという考え方と同じです。

基本的にはルートのコンポーネント以外は状態を持たないようにするのがよいですが、input要素などはユーザーアクションによって自身のデータを変更する必要があるので状態を持ちます。

Virtual DOM

ルートのコンポーネントだけで状態を持ち、その状態が変更したらツリーを再構築するというのは、非常に設計を単純にしますが、一部分の変更だけで毎回全てのDOMツリーを再構築するのは速度的な面で問題になります。そこでReact.jsはVirtual DOMという仕組みを導入しました。

Virtual DOMはざっくり言うと、JavaScriptのオブジェクトとしてDOMツリーのようなものを持っておき、データに変更があった場合にそのオブジェクトの差分を計算し、実際のDOMへの再レンダリングを最小限にするという仕組みです。

React.jsではReact.createClassでコンポーネントを作成し、renderメソッドの返り値にVirtual DOMの定義を返します。Virtual DOMはReact.createElementによって作成します。

var MyComponent = React.createClass({
  render: function() {
    return React.createElement("div", {className: "foo"}, 
      React.createElement("div", {className: "bar"},
        "Hello ", this.props.name
      )
    );
});

また、JSXという独自シンタックスを使うことで、XMLのようなシンタックスでVirtual DOMを表現することができます。

var MyComponent = React.createClass({
  render: function() {
    return (
      <div className="foo">
        <div className="bar">
          Hello {this.props.name}
        </div>
      </div>
    );
  }
});

これはreact-toolsやbabelのようなツールで実行可能なJavaScriptのコードに変換することができます。

React.jsの速度について

React.jsは速い、と聞いたことがある人もいるかもしれませんが、はたして本当でしょうか。Virtual DOMという仕組みを導入し、ルートのデータを変更してもDOMへの変更が最小限になるので、高速になりますが、それはあくまでも全てのDOMを再構築する場合と比べた場合の話です。ここでは以下の3つのケースについて速度を計測しました。

1. Backbone.jsで変更があった部分だけDOMを再構築
2. Backbone.jsで何か変更があった場合全てのDOMを再構築
3. React.jsで何か変更があった場合Virtual DOMの仕組みを通して差分のみDOMを再構築

結果は次のようになります。

※ TodoMVC Benchmark

このように、React.jsは、Backbone.jsで部分的に再構築するよりは遅いが、全てのDOMを再構築するよりははるかに速いことがわかります。

前述したように、状態をルートのコンポーネントだけに持つというのは非常に設計を単純にできます。そのような設計と速度を両立できるのがReact.jsの一番の特徴といえるでしょう。

Flux

Fluxはアプリケーションの設計手法の一つとしてFacebookが提唱しているものです。よくMVCと比較され、MVCと比べてデータの流れが一方通行であるという特徴があります。

引用元：http://facebook.github.io/flux/docs/overview.html

ここまでで、React.jsの基本的な設計として、状態をルートコンポーネントに持ち、何か変更があったらその状態を変更すると述べてきましたが、どのようにその変更を通知するかについては触れませんでした。

例えば、ツリーの末端のコンポーネントで何かユーザーのアクションを検知し、状態の変更が必要になったとします。このとき、React.jsではこの末端のコンポーネントはステートレスなので、変更を外に通知する必要があります。このとき、変更があった場合のイベントを公開しておき、直接の親のコンポーネントにイベントハンドラを通して通知する方法があります。

var Parent = React.createClass({
  handleChange: function(changedData) {
    // 子で何か変更があった時の処理
  },
  render: function() {
    // 子のコンポーネントのイベントにハンドラを設定
    return <Child onChange={this.handleChange}>a</Child>;
  }
});

var Child = React.createClass({
  handleSubmit: function() {
    // 親から受け取ったイベントハンドラを実行
    this.props.onChange(changedData);
  },
  render: function() {
    // formのDOMイベントにハンドラを設定
    return <form onSubmit={this.handleSubmit}>...</form>;
  }
});

しかし、この方法だと、ネストが深いところのコンポーネントの変更を状態を持っているルートコンポーネントに伝えるのは非常に面倒です。そこで、FluxではViewで起こった変更を一括でActionに通知し、Dispatcherを通じてStoreに変更を通知します。

Storeというのはデータを管理する層で、MVCでいうMにあたる部分です。ViewのルートコンポーネントはこのStoreの変更を購読しており、Storeが変更されると自動的に状態が変更されます。

Flux自体は、設計の考え方なので、色々な実装があります。Fluxの考案元であるFacebookにもfacebook/fluxという実装がありますが、これはDispacherのみを提供するかなりミニマムな実装です。他には、例えば次のようなものがあります。

• spoike/refluxjs
• jmreidy/fluxy
• yoshuawuyts/barracks
• BinaryMuse/fluxxor
• deloreanjs/delorean

まとめ

React.jsやFluxの思想・特徴について説明しました。文中でも述べたように、React.jsが提供するのは規模が大きくなってもスケールできるような仕組みで、小さいアプリケーションを高速に開発するためのライブラリではありません。そのようなアプリケーションはAngular.jsやVue.jsのほうが向いている場合も多いですし、静的なページにちょっとしたUIをつけるだけならjQueryだけで十分なケースもあります。

実際にReact.jsとFluxでアプリケーションを書いてみるとわかりますが、ステートレスなコンポネートを組み合わせていくというのは面倒だと感じることも多いです。しかし、その面倒な制限と引き換えに得られるのが堅牢でメンテナンス可能なアプリケーションです。

もしそのような仕組みがほしいと思っている方がいればReact.jsも採用の候補に考えてみてはいかがでしょうか。

イベント動画

イベントの模様はYoutubeで公開されています。よろしければ、ご覧ください。