react (next.js)の節々がなぜ歪んでいるように思えるのか考察してみた

西田和史(k.bigwheel) 開発基盤EM @k_bigwheel

React(nextjs)をまた触っているんだけど、これFunctionalなのは計算機工学の進化上正しい道だとして、関心事の分離、具体的にはカプセル化やDependency Injectionがやりづらいのは微妙に感じる。 根本的には、JavaScript上でFunctionalをやろうとしていることに無理があるんだと思う。

西田和史(k.bigwheel) 開発基盤EM @k_bigwheel

その辺の歪みがめちゃくちゃ扱いが特殊なsetXxxxだったり、容易に発生する無限ループだと思う。 react(nextjs)は膨大なリソースで持ってそれを抑え込んでいるけど、WASMなどで関数言語使えばよりシンプルな解決ができるかもね。

西田和史(k.bigwheel) 開発基盤EM @k_bigwheel

やっぱりreact(nextjs)はトリッキーだなあ。 フレームワークの理想は言語機能を従前に活用した上で言語でできること = フレームワークで表現できること、であることだと思っているけど、reactはjavascript言語の表現力に変な制約と固有のルールを持ち込んじゃうんだよな。

西田和史(k.bigwheel) 開発基盤EM @k_bigwheel

例えばsetXxxの変な制約やfunctional componentでイデオム的にclassが使えない(使えなくはないけどspread演算子が使えなくてすごく書きづらい)など。

西田和史(k.bigwheel) 開発基盤EM @k_bigwheel

理想論を言うなら、フレームワーク側で変な迂回策取るんじゃなくてJavaScriptの言語機能を拡張するのが正道なんだろうけど、JSは政治的に面倒すぎて変えるのが辛い。だからこんな魔改造をしている。

西田和史(k.bigwheel) 開発基盤EM @k_bigwheel

考えてみると、reactもnextjsも大したことしてないんだよな。nextjsがやったのはフロントエンドとバックエンドの言語を統一したことと、そのFE/BEの処理を透過的にしたことだけ(エッジコンピューティングなんかも最近やるらしいけど、まあBE処理の派生だよね)。

西田和史(k.bigwheel) 開発基盤EM @k_bigwheel

フロントエンドとバックエンドの言語を適当な関数型言語にできれば、nextjs相当に必要なのはBE/FEの処理の透過化ぐらい。めっちゃ薄いフレームワークになると思う。 なのにnextjsがあれほど巨大なフレームワークになっているのは、それがJavaScriptだと難しいからなわけで。

西田和史(k.bigwheel) 開発基盤EM @k_bigwheel

やっぱり、nextjsの課題はJavaScriptという古くて歪んだ制約の中でモダンで高機能な開発を行おうとしている点なんだと思う。だから、nextjs単体での解決は難しい。

西田和史(k.bigwheel) 開発基盤EM @k_bigwheel

class componentからfunctional componentへ移行できたことで、今後もよりsimpleになる可能性があるのかなと思ったけど、nextjsの複雑性の源泉が前述の理由なので、たぶんこの複雑性は永久に変わらなんだろうなという結論になった。