結局HTMLっぽく書きたくなるんですよ。ちなみにさっきの言語の話を少し深掘りしたいんですけど、言語は規模で決まるというのは確かにそのとおりだと思うんですが、一方でエコシステムとかを見ると、BabelをES6じゃない言語で書いてエクスポートしてる例ってあんまりないんですよね。TypeScriptでライブラリ書いてエクスポートしてるなんてあんまりない。エコシステム全体としては、どっちの言語がより慣れているかという度合いはあるのかなと。2はTypeScript、というのはあるんじゃないかと思います。2も)公式サイトのチュートリアルとかも全部TypeScriptで書かれていたりするので、そういう住み分けとかは色がはっきりしているかなと思います。実際、React自身はあんまりFlowでっていう話はないです。propTypesを、Flowで書けるようにしよう、って話は進んでるみたいですが。「propTypesで型チェックをしていく」というのがあんまり綺麗じゃないというか、書き方として洗練されている気がしない。あれをFlow側に寄せていこうという活動はあるみたいです。FacebookがFlowを強制してくるってことは全然ないですね。propTypeを置き換えるときも、FlowかTypeScriptか、好きなのを使えばいいという感じです。そこは、フレームワークが特定の型システムに依存する必要はないので、好きに使っていけばという感じです。Flowは、静的な型チェックをするためのライブラリです。思想としてはもっと踏み込んでいて、JavaScriptでハマりがちなコードとかを静的解析して、静的な型付け以外のチェックをやっていこうと。いう意味では、ESLintとかもカブる部分がありますね。nullチェックをしているかどうかとかも確認できたりとか。静的型付け以上に、JavaScriptでハマりがちなエラーをチェックするためのツールという面が大きいかなと思います。コードそのものは、JavaScriptで書くということですね。次の話題はアーキテクチャについてですが、アーキテクチャというとぼんやりしてますね...。これぼくなんでこのお題を出したんだっけな。えーと...、あ、思い出した。Fluxとかの話をしようと思ったんだった。基本的にReactだけだと、イベントや状態を管理する仕組みがないんです。ReactってViewのライブラリなので。Webアプリって、APIサーバを叩いてデータをもらってきてそれをレンダリングするとか、そういうのが普通ですよね。いうことをしようと思ったら、Reactだけじゃ厳しいんです。いう時に、イベントを管理する仕組み、あと状態を管理する仕組みっていうのが必要になってくる。いう時に必要になってくるのがFluxであったり、Reduxであったりというライブラリです。Fluxはライブラリというよりは「思想」というか、デザインパターンに近いですね。イベントを管理するための、Observerパターンを言い換えたというか。あれねえ、何がすごいかって、名前を付けたのがすごいですよね。考え方が浸透してきたところにReduxっていうのが出てきて、今一番流行っているライブラリです。ひとつ間違えちゃいけないのは、ReactとFlux、ReactとReduxを組み合わせたからといって、Angularほどの「フレームワーク」といえるかというとそこまでいってない。ライブラリを組み合わせただけのものでしかなくて。その上で自分のレールを作っていく必要があるんじゃないかなとは思います。ReactはReactだけで完結しないと。Framework」だそうですね。1)のほうに一旦戻ろうかなと思うんですが。World」だったと。今あるようなES6のモジュールとかがなかった時に、それでもモジュールの仕組みが欲しいとか、そういう要望があったと。angular.module()の中に書いていくというのがあったんですね。それがあったからAngularはエコシステムに乗っていない、一方でReactは乗っているというような分断が起きはじめました。2になっても引きずっている方がまだおられるんじゃないかというのが気になっています。2は「ライブラリ」だと思っているんですよね。2は好きなフレームワークと組み合わせられるようにもなっている。2をどうやって使うかというと、RxJSがよく出てくると思います。RxJSはストリームやイベントを扱うためのライブラリで、FluxのObservableパターンと同じく、何か変化があるまでは動かない。何か変化がemitされたときにsubscribeしてる側で値を書き換える。それでテンプレートの描画が変わると。いう意味では、今時代の変化が、Observableパターンに来てるんじゃないかなと思います。私は実際それをやってみて、別のイベントで発表したこともあるのですが、ぶっちゃけそのときは相当disりまして(笑)。Reduxをdisったわけじゃないんです。2とReduxという組み合わせをdisったんです。Reduxは中立なライブラリとは謳われているのですが、実際にはReactを前提として作られたライブラリなので、まあそうなるわな、という感じでした。2とReduxの組み合わせがなぜいけてないかというと、DIとの相性が悪いんです。ReactにはDIという考え方が全くないし、ReduxもDIを全く無視している設計になっている。2はDIできるのに、Reduxと組み合わせると、ReduxのReducerの中では一切DIできない。2の中でReduxを使うのか。そこだけ別世界に飛ばされるような感じでした。言うとReduxにしてもFluxにしても、シングルトンなステートがあって、ステートの変更を検知してコンポーネントがデータを受け取って、コンポーネントがデータを書き換えて...っていうのをくるくるやるわけじゃないですか。2だとDIで実現するんですよ。Reduxいらないんですよね。仕組み、レールがすでにあって、あとはステートを持つやつを書くだけで、あとはDIでどうとでもなる。2は結局、DIでどうとでもなります。2に足りないものがあって、Reduxがそれを補うのかなとかって勝手に想像していたんですが、別にそんなことないよ、って感じでしょうか。ちなみに例えば、ReactとRxJSを組み合わせる、みたいなバズワードの組み合わせ方とかはないんでしょうか。そこは自由にできて、ReduxとRxJSを組み合わせるためのredux-observableというのをRxJSの作者が作ってたりします。RxJSを使いたい場合はそういう選択肢もある。使う必要もなくてEventEmitterで事足りるかもしれないし、そこは自由に選んでくださいという感じですね。次はビルドツールですね。ここは意見を戦わせるところでもなくて、ただ紹介するだけでいいのかなとも思いますが、暴走や脱線は大歓迎です。webpackやBrowserifyですね。エコシステム全体がBrowserifyやwebpackを前提として作られたりしますので、それを使うのが普通です。コンポーネント志向なんで、コンポーネントを作ってexport/importするのが当たり前の世界になってます。ここは何も変わらないですね。しないとブラウザでは使えないし。installでインストールされる)のが、ESモジュールになったんですよ。exportがそのまま書かれている。できるというのはありますね。SystemJSっていうツールの存在も聞きますが。ごめんなさい、ちょっと失笑です。あれはまだちょっと人類には早いって思ってます(笑)。あれは世界がHTTP/2になるのを待って、出直してきてほしいツールです。importごとにリクエスト飛んだら、(HTTP/1だと)遅すぎて話にならないです。ありますけど、それならwebpackのほうがエコシステムが育っているので、そちらでいいんじゃないかな。プラグインとか、Loaderとか。Loader待ったほうがいい(笑)。Managerでしたっけ。その質問誰に聞いてるんですか(笑)。その程度の扱いということで(笑)。2やってる方もwebpackやBrowserifyがいいんじゃないかなということですね。Plunkerみたいなオンラインエディタ上でやるぶんには、SystemJS割と便利なんですけどね。ブラウザ上ではバンドルできないので。プロダクションでは使う用途ないですよね。次は、細かい話が混じって申し訳ないですが、ルーティングとかに関して言いたいことがあればお聞きしたいのですが。React完敗ですね。そもそもルーティングって、React本体には機能がないんです。Routerっていうのがあるんですが、これみんなdisってる(笑)。使ってみて、「これクソ使えねえな」みたいな話になるんですけど(笑)。何が使えないかって言うと、ルーティングの時に最初にやってほしいことって「アクションを発火してほしい」んです。APIを呼び出してデータを取ってくる、ということをしたいとみんな思うと思うんですが、そういうことをやってくれるような感じになってなくて、まず最初にコンポーネントをマウントしちゃうんです。コンポーネント指向なんで。普通みんながやりたいのって、アクションだと思うんですが、それを書くための記法は今のところない。しょうがないから、真っ白なコンポーネント出してそこでイベント発火させて(データを)取りに行く...みたいなことをみんなやってるんじゃないかな。Routerは決定版にはなっていない。決定版になってないがゆえに、デファクトスタンダードとはさっき言ったけど、みんな野良ルーターみたいの作っちゃって、結果今あんまりよくない状態になっている。...というところが「圧敗」ですね(笑)。圧勝側のご意見も聞きたいです。2もパスとコンポーネントを結びつけるものだという考え方は変わらないです。コンポーネントがマウントされるときに呼び出されるフックポイントがあって、そこでリクエストを飛ばして、その結果を持ってマウントができるという仕組みがある。あと、「ルーティングしてもよいかどうか」というcanActivateみたいな仕組みもあって、出ていくときの仕組みもあって。したイベントが全部RxJSに乗っていて、ルーティングが起きるときにはまずイベントが発火するので、使いやすくはなっています。いう意味でいくと一応onEnterみたいなのはあるんだけど、そこでデータを拾いに行くのは、推奨しないってことになってまして...(笑)。2のルーターはとてもよくできているので、今のところは言うことない、っていうくらいの完成度になりました。ぼくは個人的にルーティングにこだわりはないんですが、基本的にはここもライブラリに依存しなくてもいいんじゃないかな、とはずっと思っています。汎用的ないいルーターが出てこないのかな、とは思ってるんですが、あんまり出てこないですね。イベントだけ発火してくれればそれでいいですからね。ライブラリと関連しているところではないので。誰か作るチャンスだと思います。ReactやAngularに関係ないルーティングのライブラリがあればいいのに、ということですね。前半最後のトピックになりそうですが、次は「テンプレート」です。これ盛り上がるのかな...お互いの記法がキモい、とかってdisりあっていただいてもかまわないんです(笑)。2テンプレートもキモい、気に入ったキモいほう使え、って感じですね(笑)。2のテンプレートはギリギリHTMLなので、既存のHTMLツールチェインには乗れるわけです。テンプレートの文字列を直接ソースコード中に書くのも、URLで外部ファイルを指定するのも、どちらも可能です。URLを指定した場合はAjaxで取ってきます。それはwebpackのプラグインで、URLをrequire()に変換してくれるやつがある(angular2-template-loader)ので、ありがたく使わせてもらってます。...Angularの圧勝です。普通にpタグやdivタグの中に入れる文字列はサニタイズしてくれるんだけど、例えばaタグのhref属性とかに対しては、別に何もしてくれません。(属性値に)javascript:〜とかやろうと思えばできちゃう。innerHTML使うときとか、URLをセットする場合とかは、注意しなくちゃいけない。(URLから)javascript:を省いてやる必要とか、XSS対策についてはケアが必要です。JSXって結局ただのオブジェクトに展開されるんですけど、Symbolとかを使って、外から知らないタグを差し込まれたりはしないようになってます。Elementsとして展開するということは出来ないようになっていますけどね。Elementは書けるようになっています。Elementをサポートするための布石です。この後何らかの対応が入ってくるとは思います。お時間ですので、これで前半を終わりにしたいと思います。後半も、引き続きよろしくお願いします。Communications。