Fluxフレームワーク Arda が気になる10の理由
どうも、@armorik83です。
Fluxフレームワーク"Arda"、皆さんご存知ですか? 概念や思想を含めて大々的に発表されたのは、おそらく2015年2月16日（記事掲載時点でおととい）という新たなOSSです。
開発者は@mizchi氏。Qiitaの中の人 (Kobito)、魂が震えてる人、Reactの人として有名かと思いますが、個人的にはAngularJSが嫌いな人という認識です。
今回、そんなmizchiさんが開発されたフレームワーク"Arda"をあえて取り上げたい衝動に駆られたので、興味のある方はお付き合い下さい。
動機
気になった理由の前に、ここに至った動機を前置きします。ここ長いです。例のアレな感じです。
思い出話
私は2013年秋からAngularJSを使い始めました。これはちょうど1.2.0リリースの頃。
AngularJSに飛びついた理由として画期的なバインディング・テンプレートがありました。<p>{{foo.value}}</p>、これです。この時、残念ながらJavaScriptに対してjQuery程度の理解しか無かった私は、これは新しい!と思い取り組み始めました。
同時にTypeScriptを採用したので、TypeScript + AngularJSの連携を記事として書いたり、AngularJSアンチパターン集が想像以上に受け入れられるなど、AngularJSに関わる活動が増えました。
2014年に1年掛けて良くも悪くも話題になったと感じており、勉強会などでの知名度も高かった印象です。
嫌われ始めた
日本のAngularJS界隈において「mizchi's blog - Angularが嫌い」の記事が与えたインパクトは大きく（少なくとも私はそう思っており）10月を境にAngularJSへの懐疑の流れが出始めました。mizchi氏以外の擁護記事、批判記事はあまり真剣に受け止めていませんでしたが、同じ時期に偶然か必然か、英語の（主にDirectiveを対象とした）批判記事も増え始めたことは覚えています。
mizchi氏の批判内容には個人思想的な事項があるものの、今思い返せばかなり的確に客観的に批判しており、DDO (Directive Definition Object) が本当に開発の負債になってしまったことはAngularチームが一番に認めるところ。
同時期に日本国内でもVirtual DOMに目が向いたことから、処理速度面でも比較される機会が増えてしまいました。（表形式で行がng-repeatされていくとき、もの凄い数のDOM処理が回ります。タイムラインは見ていて面白い。）
要は「バインディングなんて別に珍しくない」時代がやってきたのです。
AngularJSは嫌いになりたくなかった
個人の感想ですが、やっぱり使い始めたときの面白さって大事にしたかったんです。
もう一つは2013年秋から14年秋までの1年間に書いてきた多くの処理群をAngularJSからせーので脱却させるわけにもいかず、なんとか付き合い続けてやろうじゃないか! という気概もありました。
そんなタイミングで発表されたAngular 2.0
2014年10月下旬のng-europeでAngular 2.0は発表されました。正確にはその前から動きは見られましたが、大々的に打ち出されたのはこの頃です。
ちょうどAngularJS関連の登壇の依頼を受けており、資料作成をしていた時期でした。AngularJSが嫌われる方向に傾いている + 2.0が発表されたという勢いで、いかにAngularJS 1.x系をモダンに書くか、というテーマで「モダンAngularJS」という発表をしています。
今このスライドを見返すとうっすらと涙が浮かぶほどです。どうしてこうなった。
Angularの現状
現状――というか現時点の私の認識――なのですが、日本のJavaScript界隈で確実に注目度が上がっているのはReact.jsでしょう。また、Polymerを筆頭とするWeb Components界隈はGoogle好きの中で着々と注目を集めています。
AngularJSもご存知Googleのプロダクトですが、2.0の発表(ng-europe)から現在までの2.0系開発の話題性や、他OSS・アーキテクチャの台頭を見ていると、発表のタイミングはあまり芳しいものではなかったと感じています。
理由は分かりきっていますね。「APIも文法も大幅に変更する」と明言だけしておいて負債の方向に進んだAngularJS 1.x系、いくら「モダンAngularJS」を発表しても、やっぱりちょっと無理がありました。ほんとどうすんの。
Angularとどう向き合うか
私は冒頭に述べた2013年秋からの自主プロジェクトが1件、そしてありがたいことに最近参加した他者の案件が1つと、2つのAngularJSプロジェクトに関わっています。
参加中の案件は大規模な遷移を含むSPAや企業サイト等ではないため、学習コスト面や資産活用の面でAngularJSを採用しました。この設計について深く留意した点があります。（案件が終わったら書くつもりでしたが、ただの勢いです。）
Directiveベース
ng-controllerは使いません。どうせ廃止です。DirectiveベースなのはWeb ComponentsやReact.createClassの流れを意識しています。要はAngularJSからの脱却時において、構造の移植性を意識しています。
細部のロジックは、各流儀に従い直す必要があるでしょう。
Event-driven
共有の$scopeは使いません。どうせ廃止です。内部のprivateなscopeは使っていますが、データのやり取りはすべて$broadcastと$on#です。イベント駆動についてはArdaにも関わってくるので後ほど。
ES6, TypeScript、そしてBrowserify
AngularJSでBrowserifyを使っています。滑稽ですか? そうかもしれません。
AngularJS Serviceにロックインされる範囲が減るという大義名分ですが、使ってみたかったという理由が大きいです。クライアントの了解は得ています。
つまりどういうこと
AngularJS、今でも結構つらいから、あとあともっとつらいぞ…。Angular 2.0で大逆転するか、飲まれるか、それは分かりません。
AngularJSを嫌いになった訳ではありませんが、時代は進むものなんですね。
本題
たぶんこの記事の半分以上は前置きだったことでしょう。本題に入ります。
Fluxフレームワーク"Arda"が気になる10の理由。使ってよかった10の理由じゃないのは、今書きたくなったのと、AngularJSの案件があって浮気している場合ではないからです。（もし今後使って嫌いになったらすいません）
一応これを書き換えて遊ぶ程度には触りました。
1. Reactである
Reactラッパーという表現が正しいのか、Fluxフレームワークと呼ぶほうが好ましいのか、この界隈に触れて日が浅いので誤っているかもしれません。
1.で述べたいのは、これはワラワラ出てくるVirtual DOMライブラリの一種ではなく、Reactを用いるFluxアーキテクチャを汲んだ包括的なフレームワークなのだ、ということです。（Fluxアーキテクチャについては日本語の解説資料が増えているのでそちらで）
2. 読み心地がいい
読みやすいと表現するより読み心地がいいと言いたくなるstarter-projectのソースでした。そらで読んで何をするのか処理順序が想像しやすく、かつ何をどこに書くべきかはある程度示されているフレームワーク具合が気に入りました。
CakePHPを書いていたことがあるので、個人的にはConvention over configurationはうーん?と思ってる。ルールは必要だけど、それはおせっかいじゃないか?という節々があったので。
3. TypeScriptで書ける
これは私の中ではウェイトが大きいです。
Reactは0.13でES6 Classesが使えるようになったそうで、これでReact + TypeScript共存の道も近いなと感じていましたが、更にラップして開発者がTypeScript対応を明言（というか開発者もTSユーザ）している点を評価しました。
4. Componentの概念
これ本当にすげえな、と思った点です。
私のReact経験は一人React ACを読んで、0.12を写経した辺りですが、JSXが個人的にどーにも…なのとpropsやなんやらが色々…うーん!!な感じで、TypeScriptとの相性もほとんど良くなかったので、AngularJSともう一丁付き合うか…と考えたくらいでした。
「色々うーん」はちょっと曖昧ですが、要はマークアップとロジックの分離やりにくくないか?という点を懸念していました。
Componentsは清々しいまでに分離しています。そしてjade。そうきたか。この背景にはjade公式によるreact-jadeという担保があります。
追記、読者諸氏にはcoffeeやjadeだけで「それはちょっと」となって欲しくないので補足します。これはstarter-projectの構成がそうなっていただけで、全て交換可能です。（参考）
5. Contextの概念
Componentと対になっている概念、Context APIが主にReactの多くをラップしているようです。
1 Contextに対して主実装、defs、subscriberとトリオを揃えるのがベストプラクティスらしい。プロジェクト内で膨らんできたらどうなる?とすこし不安になったが、抽象化してモジュール単位でどんどん切っていけばいいのかも。試してみたい。
6. Event-driven
Fluxたる要素、Ardaはイベント駆動です。
4.で述べたロジックの分離の懸念、私自身もこれはEvent Emitterだなぁと薄っすら思っていたものの、なかなか行動に移せなかった部分です。海の向こうの誰かが知らない間にやってくれるだろう…という感じでした。
dispatch, subscribeって用語も取っ付き易いね。
7. 未来感と現実感
「AngularJSとBrowserify」という選択は可能ではあるものの、Angularチームとしては特に想定していないでしょう。これは時代背景が異なっているからです。
ArdaからはES6, BrowserifyといったモダンなJavaScriptの潮流を確実に汲みながらも、独りよがりになっていない必然性を感じます。
一方で、jQueryは何が何でも死ぬべき!と言い切らずに、ArdaはjQueryに対してどう寄り添うべきか?を提示している点が、このフレームワークは地続きであるという現実感となっています。具体例もあります。
8. Ardaというネーミングチョイス
アルダは指輪物語の中つ国を含む世界そのものであり、シルマリルの物語によれば現実の私達の世界そのものでもある。
何言ってるかわからない発音しやすく覚えやすい良いネーミングだと思います。
開発者は名前空間が空いていて短ければ、と発言されていますが、Googleの現時点で2位なのであっと言う間にArdaといえばこのフレームワークという常識になるでしょう。
9. 日本人開発者である
これ、けっこう応援したい要素の一つ。
6.にも書いたように、大体Stack Overflowであったり、何かしらの知見の集積でOSSが生まれて日本にやってくる…もしくは米大企業によるプロジェクト…、なことが多いなか、日本からも広まっていくべきと思っています。
10. 開発者の今回の様子に並ならぬ本気を感じる
あんまり本人のことを言及するのも悪いんですが、OSSを数多くリリースするmizchi氏の中でも今回は資料であったり告知の内容に本気度の高さを感じます。
（mizchi氏の見解を受けて追記）QiitaのKobitoアプリケーションの基盤フレームワークという点も安定してホスティングされるであろうという期待に繋がっています。
AngularJSを嫌った開発者はどんな設計思想を提示してきたのか!という興味（失礼）からすぐにソースを読み始めました。
…参りました、すいませんでした!:bow:
疑問点
小一時間遊んだだけですが、一箇所だけ懸念が。
画面内容の切り替え時にブラウザのアドレスバーが全く変化していないので、URLパラメータを取得するライブラリの導入やHistory APIとの併用はどうしていこうかなーと。今回はどうもatom-shell向けのライブラリが源流のようなので、今後URL方面の扱いをどうしていくのか方向性がすでに思い浮かんでいるならば早めに聞けたらいいな。（追記、見解が頂けました）
こういうところで、すぐにAngularJSだとどう実装するか…という思考回路になってしまう。AngularJSとArdaの組み合わせというのは開発者の本望ではないでしょう! 時間が空いたら解決法を探りつつ小規模のアプリケーションでも試して、使い心地のレポートを再び書きたいと思います。
終わりに
小一時間しか触ってない奴がまたえらい長文を書いたで!
ほんと個人の日記レベルで恐縮ですが、時間が空いてからサンプル組んで…それから記事書いて…とするより発表から間をあけず印象だけでも伝えたほうが初速に繋がる!という衝動で。割と本気で応援したい設計だったので、こういう文量だけ多い内容になってしまいました!
何か伝わるものがあれば幸いです!
Discussion