Rx.js, Immutable.js について
自分はImmutable.jsとRxをなぜ採用しなかったか、自分の考えを整理するために書き出してみる。
僕の理解が及んでいない無知のゆえのアレもあると思うので間違っていたら罵倒ブコメお願いします。
Immutalbe(.js)
扱う対象をイミュータブルにするのはたぶん間違いなく正しい。正しいが、現時点のエコシステムにおいてその必要性を示せてない。具体的に言うと、Immutable.jsの110kbのオーバーヘッドの配信負荷、読み込み負荷、開発者の学習コストを支払ったとき、それに見合う価値を提示できているのか？にまだ疑問が残る。
PureなJSでも、ただ単に目的のデータを作るだけなら、ほとんどのケースで組み込みのarray.mapとObject.assign(またはそのポリフィル)で代用できる。(勿論生成したオブジェクトに副作用を加えないことが前提になるが)
あと型がない環境でImmutableにしても片手落ち感がある。これは後述するRxにも言える。
Rx
Rxを使うと連続的なイベントを扱うコードが書きやすくなる反面、それ以外のケースは特に単純化されない。お互いに無関係なイベントが散発的に発生するような、つまりは普通のアプリケーションにおいて、Rxの強みを活かせるシーンがほとんどない。いろいろ試してみてそういう結論に至った。
たとえばタイピングゲームを作る際にキーボードからのイベントをストリームにして扱うのは正しい。が、ボタンがトグルするだけのストリームを1画面につき20個管理するのは馬鹿らしい。自分が扱うのは後者だった。
他、現実的な問題として、僕自身がRxにマスターしたとして、開発チームの同僚にあの大量のオペレーター郡を使ったコードを読解させるのはなかなか辛いことだと思うし、その逆も経験したくない。
巨大なので一度使いはじめると抜け出せなくなり、仕様化されていないデータ構造を抱えることになるのも問題。
実際にFRP的なコードを使っていくかどうかは、現時点ではES Observable が仕様化されてポリフィルが出来てから考えれば良いと思う。
