bouzuya/bbn-cycle で cyclejs/cyclejs 7.0.0 を試している。まだ途中だけど、現状での印象を書く。

v7 の変化としては次のような点が挙げられる。

• JavaScript -> TypeScript
• RxJS -> xstream
• virtual-dom -> snabbdom

TypeScript への変化は個人的には嬉しいのだけど、Cycle.js が TypeScript 化されてもほとんど影響がない。まず Cycle.js の API を直接的に使う場面はほとんどない。ぼくの認識では message 基盤の提供や event flow の制御をしているだけだからだ。それに Cycle.js の API は TypeScript 向きじゃない。Sources なども { [driverName: string]: any; } 程度にしか、型の補助をつけられない。

RxJS から xstream はまず v4 を捨てた点、他の stream library を選べる点、過剰な operator がなくなった点や Cold / Hot の違いを考慮しない点で良い。stream library の選択肢の提供は良いが、その裏返しで Cycle.js の API の型指定などで問題が出ていると思う。xstream 単体に関して言うと、個人的にそこまで使い込めていない。そこまで困っていないということは、良い変化なのだと思う。

snabbdom 。それ以前に dom-driver の API に hyperscript-heleprs っぽいものが増えている。 h('div') みたいのが div() に変わっている。h でいいやと思っていたけど、使ってみると書き心地が良い。シンゴジラヒエアワ問題がある中であえて書くし何度でも書くが、ぼくは React の推す JSX をとんでもないクソだと思っているし、あれを好んで選択する人間の感覚を疑っている。仕方なくならまだしも、好んで選ぶのは、ない。少なくとも、ぼくと意見が合わないのは間違いない。

Cycle.js の変化というよりは、ぼくの見方の変化がある。前回の Cycle.js から半年以上が経っている。その間に DDD / naa4e から Clean Architecture や message bus の考え方に触れた。RxJS と message bus の考え方を基に b-o-a を書いた。 redux + redux-saga のような実際に広がっているものを見た。そういう経験や見方の変化を踏まえて、改めてみると Cycle.js の位置は中途半端だ。message bus やそれを提供する API としても、View を提供するものとしても。stream を露出させているのに stream library を固定できないのも何がしたいのか分からない。 component の入れ子のくだりも、どこを相手にしたいのか分からない。 ViewModel + View は Cycle.js の主戦場ではないと思うのだけど、dom-driver の listener を切り離す部分に大きな特徴や強いこだわりを感じる。

もし使うとすれば……。下位に Cycle.js や driver を置く。中間に b-o-a のような message bus を置く。上位にうまく stream library を切り離す形 ( DDD のように…… ) で外部に影響を受けにくい Model を置く。そんな感じかなあ。とりあえず bouzuya/bbn-cycle はそういう形を目指しながら書いている。

悪く書いているように見えるけど、そこまで悪い Framework だと思っていないし、現に新しい bbn: blog.bouzuya.net は Cycle.js 7.0.0 を使おうと思っている。