RSC ( React Server Component )の価値を理解する

目的

RSCによって何がどう良くなるか、逆に開発を悩ませる要素として何があるか、RSCと仲良くなって良いかを整理するために作成。

Next.js上での場合、

RSC - SSR - Browser
のようになるのであってそう。

以下の記事はわかりやすい。

RSCが返すのはJSON化されたJSX。
そのJSON化されたJSXをレンダリングするのが、Next.jsだとSSRになる。
（ちなみにSSRするとstream性も失われるし、RSCの登場でもはやSSRの必要性あるか？ってなってきてそう）

RSCを使うメリット

・初回ロード時に必要最小限のJSを返すだけで済む。
・その後は必要な分だけRSCがJSXを返すので、ブラウザ側はかえってきたJSON JSXをレンダリングするだけ。

個人的所感としては、Railsのjs.erbが帰ってきた感ある。

RSCを使うメリットがbundle sizeだけの場合、
大規模サービスになるとRSC使って初回レンダリング量減らさないと体験悪くなるよねとなるけど、ぶっちゃけスモールサービスなら無用の長物では？と思った。

一方で、スマホのネイティブアプリなんかは最初に全ダウンロードしてから使うけど特に困らないし、PWAしたいとき等で今後もRSC使わないほうが良い場合もありそうとは思ってる。

LCPを意識している場合
１ページのrendering量が多いとページ速度遅くなるのはいただけないので、RSCで遅延読み込みできるのは良さそう。でもそういうのってページ分けたり、CDNで解決できたりしそう？
大規模サービスになってきた場合
すぐに使う必要のないComponent群を最初にまとめてダウンロードする負荷が大きくなってきた時で、その時はRSCの恩恵がありそう。

通信量と通信速度
jsonデータだけをやりとりしてた場合と比べて、JSON化したJSXをやりとりしたほうが通信量が膨れる場合がある。
通信速度も結局DBとつながるサーバーとRSCが同じネットワーク内にあるとかでない限り通信は変わらない、というかむしろNext.jsの場合DB - RSC - Browserと無駄な通信になってしまうのでは？ DB - Browserの方が速くない？
開発体験
むしろ悪くなりそう。これはまだ言語化できてないが、ほとんどのサービスにとっては無用な複雑性が生まれていそうで、考えることが増えていってしまう気配も。

この辺の記事も読むとRSCの理解が深まる。と思ってリンク貼ったら、２つめizuminじゃん。

RSC が成熟したあとの React は次の Rails （の Controller と View を React で最強にしたやつ）になりうるかもと思っています。いま Bet すると超楽しそう。

ありそー。めっちゃありそー。

欠点もしっかりまとめてくれてて流石。

欠点も同様に RFC の Drawbacks に記述があります。Server Component 特有の制約や、Server Component, Client Component, そして “shared” なコンポーネントの区別のための規約などは悩ましいですね。