JS
TS
- typescriptlang.org を読むのと、uhyoさんの記事をいくつか読んだ
- TSがあるからギリJSが書ける、ありがとうMicrosoft
- ただどちらかというとあらゆるJSになるだけ型がつくように頑張る言語、という設計みたいなので、JSの異常性を隠蔽はしてくれない
- 型レベル計算の表現力が高くてすごい（それ故に型パズルとか批判されたりもするみたいだけど）
- フロー解析でのユニオン型の絞り込みとかが小気味良く動いて感動したが、逆に「これはわかってくれないんかい」もちょこちょこあって困った
- 正直自分が本当に欲しいのはJSのお行儀の良いsubsetを定義する強い型付き言語だけど、TSがなぜ成功したか（そしてなぜこのアプローチじゃないといけなかったか）もよくわかるのでしょうがない
React
- 普通に react.dev をひたすら読んだ
- これはすごい良かった。UIプログラミングに対する抽象化の思想やアプローチがはっきりしている（し自分好み）
- React Server Componentsも仮想DOMベースだからこそできる面白い最適化だと思った。BFF作るぐらいならJSONじゃなくてそのまま（ある程度）仮想DOMにまでしてからブラウザに送れば良いじゃん、というのは一理ある
- ブラウザに送るデータはコンポーネント定義+JSONからRSC payload単体に変わる訳だけど、それこそmarkdownをHTMLに変換するみたいな非自明な処理でもない限り、プログラムと入力の組（JS + API response）よりそのプログラムの計算結果（= RSC payload）の方がUIプログラミングではしばしば大きいので、そこは意識した方が良いんじゃないかなとは思った（もちろんクライアント側で実行しなくて良いメリットは依然ある）
- 例えば対戦情報のリストをDBから引っ張ってきて、それを対戦カードのリストとして表示したい時、「対戦カードコンポーネントの定義+対戦データJSON」の方が「（展開された）対戦カードリストの仮想DOM」よりさすがに小さい（前者はコンポーネントのサイズ + チーム数のオーダーだけど後者はコンポーネントのサイズ x チーム数ぐらいある）
- RSCを学ぶ過程でその元になった？とされるGraphQL + Relayについても学んだけど、正直自分はこっちの方が欲しいなと思った。コンポーネントが欲しいデータを宣言して、ナビゲーション単位でそれを全て巻き上げてひとつのqueryにする、というのはそのクエリを実際に受けて処理するresolverにとって最適化の余地が大きい。もちろんこれはGraphQLのデータモデルの抽象化のおかげで、だからこそ実装側はその抽象化に合わせるコストは払わないといけないけど
- GraphQLみたいな特定の抽象化を押し付けず、かつReactがちょうど仮想DOMベースであることを利用すると似たような問題を解ける、という意味ではRSCの価値は大きいとは思うけど、同じ問題をMetaとかのスケールで解くなら極論ではRelayの方が依然優れてるのでは、という気はする
Reactフレームワーク
- 前提: RSCを使いたい & Cloudflare Workersで動かしたい
- Next.js: Cloudflareで動かすのがちょっと大変でやめた。いや動きはしたし途中まではNext.jsでやってたけど、ちょうどいいタイミングで後述の @vitejs/plugin-rsc が出たので乗り換え