React Forget:問題の所在はどこか

2日ほど時間があきましたが私は元気です。

ちょっと頑張れない期間と難しい部分のコードリーディングが重なってました。

頑張れないときに50%でアウトプットを出すことを許せない自分の在り方がぶきっちょだなあと感じますが、(自分にとって)自明なコードを並べるだけでコードリーディングと称したくはないので、今後も自分のキャパシティを拡大する方向性で作業していきたいと思います。

頑張れないときは頑張れないなりに、未来からみて意義のある作業ができるはずなので、そのあたりを考えていきたいです。

React Conf

昨日はReact Confを見ました。大変良く纏まっていて、React 18について教えてと言われたら最初に見てもらう資料に良さそうです。自分は未知だったReact forgetが出てきた部分を面白く見ました。

React forgetはReactをAOTコンパイルしてビルド時にレンダリングを最適化する技術のようです。Reactは今までレンダリング最適化がある種のプロフェッショナルスキルとして見られてきましたが、その部分を代替していく形になります。

Reactはレンダリング時にpropsが変わったら、Subtreeすべてをレンダリングしなおします。このため無関係の部分まで再計算が走りえます。今まではこの対策としてReact自身としてはcontext, useMemo, memoなどが、外部ではRedux, Recoilのような選択肢がありました。今後はReact forgetがメモ化処理を自動化して、人がuseMemo, memoを触ることを減らす方向性のようです。

Compiler:メモ化の問題はどこに由来するのか?

発表を受けた感想ですが、ReactがImmutabilityモデルを固持してコンパイラまで開発するのかという部分が気になっています。Reactはpropsの比較をShallow Equal(Object.is)で行うため、同値のオブジェクトでも再生成すると再レンダリングが走ります。そのため、現在メモ化の意義は「本当は再レンダリングされる必要がないけどReactのに合わせる」ことにフォーカスしています。

オブジェクトの同一性への関心は、本来はなかった余計な複雑さです。関数プログラミングパラダイムが実践的に有用であるとは思いますが、ImmutabilityモデルはやめてDeep Equalで比較するOptionをつけるほうが開発コストとして結局安いことはないでしょうか?あるいはmapのレンダリングだけ最適化を行う、なるべくオブジェクトをpropsに渡さないようドキュメント/Eslintを改善するなどでも構いません。これらを選択せずImmutabilityによる「癖」をそのまま維持し、コンパイラまで作成するメリットがどこにあるのかがわかりません。

メリットに関しては、今後RFCでどういう展望があるかとあわせて説明があると思います。ですがより不安なのはリリース速度です。

Share, Schedule, Speed.

Reactは目先の改善よりも数年後を見据えた改善をしているのは確かな一方、Reactの開発は遅れがちな面があります。SuspenseはCacheのリリースを待つと足掛け三年半以上かかることになるでしょう。コンパイラの計画もServer Componentsの計画が公表される前から存在しているため、同じくらい掛かっていることになります。

これまでのReactはそれでもよかったのですが、現在Reactがフレームワーク志向で様々な面をサポートしているため、開発の遅さが顕著になっています。Reactはブラウザ以外との互換性を考える点で他フレームワークと異なり、くわえて後方互換性を重視しているため、さらにリリースが遅れがちです。開発が遅いとメジャーフレームワークの座を奪われるまでの時間が短くなることを意味します。Reactの新機能は大概「新しいパラダイム」を作ろうとしているため、毎回リリースが乾坤一擲となりがちです。もしServer Componentsが受け入れられなかったら、もっと「大衆に受けやすい」機能を追加したほうが良かったと考えるかもしれません。リリース速度が遅い現状で毎回伸るか反るかの勝負をするReactの戦略を結構ハラハラしながら見ています。

フレームワークとの競争力を保ちながらReactの現在の姿勢を維持するためには、もっとリリーススピードを上げる必要があるでしょう。ただし今のReactのアーキテクチャは複雑すぎて、正直外部から気軽にコミットできるものではないと考えます。そうなるとReact Core Teamが内部で後進を育ていけるかに掛かっているのですが、コミット数で見るとそこまでうまく行っていない印象です。

https://github.com/facebook/react/pulse

リーダーシップを発揮して働けている新規メンバーはRick Hanlonぐらいでしょうか。実装能力のあるメンバーがIssueハンドリングまでやっている印象で、その部分だけでも分担できればよいのですが(正直Andrew ClarkとBrian Vaughnの実装能力がすごすぎる)。

現在のコアチームの人数は、正確に把握していませんが10人に満たないはずで、大規模に使われているアプリケーションとしてはかなり小さなチームではないでしょうか。もう少し大きくなってほしいと思います。

自分はReactの問題解決手法自体にはかなり好感をもっているのですが、組織規模に対してかなり大きなことをやろうとしているために開発スピードが出ていない現状を憂慮していて、{これが続くと,時間をかけた機能の評判が悪いと,もっとコア開発の主力メンバーが増えないと}厳しいのではと感じています。

おわりに

React Conf の感想を長々と書きました。Reactへの期待感はこれまで通り強い一方、Reactが覇権を取り続けるためにリリーススピードが欠けているのではないかという懸念があったので、これを文章にしました。過剰に反応されると困っちゃいますが。

内省してみると、自分がコントリビュートすることを考えていない典型的な日本のOSSへの反応という感じもあるので、自分もReactが長続きするように頑張っていきたいです。