lesenelir
commented
6 months ago 以「代码在哪执行」为问题进行阐述。
我的电脑（部署服务器）和用户的电脑（浏览器 JS 主线程）。
dev 模式下，开发者电脑充当服务端；浏览器 localhost 充当客户端。 prod 模式下，部署的服务器为服务器，同时诸如流行的 serverless 本质背后也是服务器；用户的浏览器充当客户端。
-
服务端：
UI = f(data)最早，诸如 JSP 年代，代码直接跑在服务端，用户的每一次交互都会发起一个新的请求给服务器，服务器发送新的 HTML 给客户端。有时延。 -
客户端：
UI = f(state)在越来越多 JS UI 框架推行后，渲染的任务交给客户端，由服务器给客户端发送 JS，由客户端浏览器 JS 主线程执行 JS 构建 UI。 -
RSC :
UI = f(state, data)靠近数据源一侧，RSC 读取数据，0 JS Bundle Size， 永不 re-render。 交互一侧，RCC 利用 State 来更改 UI 的展示。 相较于 SSR 会提高 TTI 指标，毕竟 RSC 生成 0 JS Bundle Size，水合量就少。
一些想法：
对于 rsc 和 rcc 还有 ssr 都是比较常见的知识点，这篇文章的好处是更明白的阐述了代码运行环境，可以以更宏观、更全局的角度来看待整个架构。
不禁感慨，JS UI Framework 推出后，才衍生出了前端开发者；而现如今，React 把 f 即组件往服务端上引，让组件只运行在服务器上，而不用再发送那一部分 JS 代码给客户端，往后可能越来越多流行的 JS UI Framework 可能都会采用 server first 的策略。
补充：
我看很多人说 rsc 是在走 php 的老路。我没写过 php ， 对于最早的服务端构建 HTML 发送给客户端的方式，只了解过 java 体系下的 jsp。如果当年在 JS UI Framework 推出前，所有的渲染方式都是由后端模版语法渲染生成 HTML，用户的每次交互都会由后端推行 HTML 到客户端导致页面刷新的话，那无疑 RSC 相较于最早的方式是一种进步，同时相比于普通的 JS UI Framework 也是一次进步，总的来说集这两种渲染方式的优点吧。
BTW，尽管我非常不喜欢 NextJS App Router 的写法，但或许 server first 是之后很多 JS UI Framework 都会走的路了，而 React 体系下，也需要一个写法和 NextJS App Router 不同、写法更加友好，但同时又支持 rsc 的框架，或许 waku 就是那个框架。
最后说一句： NextJS Pages Router 真滴永远的神。
https://overreacted.io/the-two-reacts/