又看了一遍 React Server Components 的介绍视频。

不禁想到，内个 ... 以前的 PHP 开发网页，不就是 Server Components 吗？

而 JavaScript 这玩意最初的意图，就是与 Client Components 一样，处理客户端交互。

而我们又知道，React 的诞生，本身与 PHP 开发网页的写法有关系。

突然感到一阵眩晕，真是历史螺旋式上升。

我们来分析一下故事脉络：

1. PHP Server Components(90%) + JS Client Components(10%, JS)

最开始，网页主要是看，交互并不多，PHP 吐「数据 + UI 」，JS 添加 UI 交互。

2. PHP Server Components(50%) + JS Client Components(50%, jQuery)

接着，网页交互越来越多，JS 需要操作越来越多的 UI ，不过还是 PHP 吐「数据 + UI 」。

3. PHP Server Data + JS Client Components(100%, jQuery)

终于，随着 Ajax 大量使用，JS 获取数据、拼装 UI 、局部更新网页，成了固定开发范式，PHP 觉得既然 JS 这么嘚瑟，这么爱处理 UI ，那就全给你好了，我只负责接口下发数据就行了。

4. PHP Server Data + JS Client Components(100%, React & Vue)

这是现在这个时代的 Modern 开发模式。既然 JS 拼装 UI 是为了渲染「数据」，那就改一下思路，让 JS 专门去关心数据，怎么更新 UI 交给框架就好。

JS 处理了全部 UI 工作，JS 文件越来越大，就带来了新问题。

JS 渲染 UI：下载 JS → 下载数据 → JS 处理数据 → 渲染 UI

在 React Server Components 介绍视频中，最初痛点是为了分段渲染 UI ，那么此时，下载数据会慢（演示里为了有序渲染 UI ，希望接口一个等一个）。

既然下载 JS 、下载数据很慢，而两者是为了得到 UI ，那么不能直接下载 UI 吗？

于是，撒花，React Server Components 就诞生了。

听起来多么吓人，其实 20 年前不就有了嘛，PHP Server Components 就是直接下载 UI 😒，20 年前的技术又被重新发明了，Yeah 。

5. React Server Components(50%) + React Client Components(50%)

展望未来，我们再回到 20 年前。把 JS 放 Server 端替代 PHP 的位置，React 吐「数据 + UI 」，React 添加交互。

这么开发起来当然很分裂，尤其是文件名还得区分个 .server.js 与 .client.js ，还有限制，这多费劲啊，让人情不自禁的想崩溃。

于是，我们还希望展望一下更未来。

6. React Server Components(100%) + React Auto Client

免责声明：我不知道技术上能不能实现，我只是瞎扯淡。

我希望，也别分什么 .server.js 和 .client.js 了，全都是 Server Components ，还跟现在一样的开发习惯，要不然大脑得分裂。

只不过 React 可以自动把交互有关的逻辑，比如 onClick onChange 等提取出来，放到客户端 JS 里，而把数据 + UI 有关的 JS 提取到 Server 里。客户端与 Server 的通信，也由 React 自动处理。

现在 React Server Components 通过 stream 的形式下发 UI ，痛点就是函数不能下发，如果也能实现呢？是不是开发者不用关心写的东西在哪运行了，React 去关心就行。

这觉得是革命性的，我愿意称之为 Modern React 。

时代一直发展，时代一直在变，但变的总是外在，总有一些东西永远不变。

如何更好的把 Server 的数据变成 Client 的 UI ，这个故事还会一直讲下去。

我们拾起 20 年前的概念，发明新名词、描绘新大饼、造出新云雾，我们要改变世界！