20 年前的 React Server Components

[nanxiaobei]

又看了一遍 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 年前的概念，发明新名词、描绘新大饼、造出新云雾，我们要改变世界！

[liberty1900]

所以说学习能力强，接受新东西快是不可信的，只是旧事物裹上了新衣裳，谁都学得快

[2i2Re2PLMaDnghL]

@liberty1900 所以说真正的接受新东西快，那就看他如何理解『熵』
这个东西是真正的难解

[rioshikelong121]

我觉得，其实用起来体验完全不一样啊。侧重点也不一样。
其实 上一代的服务端渲染模式用起来是很头疼的，尤其涉及到一些精细的交互 / 异步的场景的时候。而且技术栈往往是割裂的 (ASP / JSP / PHP and JS)，这些偏交互的部分还是放在客户端做起来会更容易一些。

现在的 Server Component 又不是常见的 React 应用的重心。我是把它理解为一种在服务端运行并返回渲染结果的 API, 放在服务端的好处是和 DB/后端逻辑交互更加容易。

另外一个和古老的服务端渲染模式相反的现代模式是微软的 blazor 的 server 模式:

> Alternatively, Blazor can run your client logic on the server. Client UI events are sent back to the server using SignalR - a real-time messaging framework. Once execution completes, the required UI changes are sent to the client and merged into the DOM

[nanxiaobei]

@rioshikelong121 #3 当然不是完全一致的，这里讨论的也不是完全一致的问题。

[duan602728596]

问题在于以前是不同的语言写的，而现在是同一个语言写的，不用写两套逻辑

[pluvet]

我至今觉得 PHP 是很好用的语言，而且回看以前写 php 模板的套路，其实很多就是函数式组件

[ragnaroks]

webform 了解一下，已经淘汰的东西比 react “先进”

[kassadin]

大致看了一下，有点儿意思
想到了 PowerBook 和 MacBook 的对比，外形一样，但内核完全不一样
后端套 react 之类的组件化模板的话确实很香啊

[agagega]

了解一下 https://hotwired.dev/

[pinkSlime]

20 年前的 php 是一个纯粹的 interpreter 吧，且输出的是文档，如今输出的是 ui
抖这种机灵没点意思

[aristolochic]

与其认为是回到了 PHP 或者认为和 Rails 生态的 Hotwire 很像的，不如去看看 Phoenix LiveView ，这个才是完全一致。

不管是 Phoenix LiveView 还是 React Server Component 还是微软在搞的一些，都要求通过 WebSocket 实现双向的状态共享，也即客户端的状态要么需要在服务端保存完整的镜像并通过 hash 校验检测一致性（状态和 UI 部件），要么通过 ID 作为更新的凭据。这既不是传统 HTTP 那样是服务端到客户端被动单向传输，也不是 Hotwire 用 WebSocket 实现主动单向传输，PHP 的 Laravel 和 Rails 的 Hotwire 因为不愿意实现高效大规模 WebSocket 连接，才要么轮询（ Laravel ）要么只推数据不维护状态（ Hotwire ）。尤其是 Hotwire ，意境上就是以前的 Stimulus+Turbolink 改名+现代版 iframe ，这套在以前就没火起来（当然 Turbolink/pjax 用的还是不少的），加上 WebSocket 能推数据了也不比以前的玩法更有革命性。

明确声明了自己受到 Phoenix LiveView 启发的有一些，比如可以把 Hotwire 中的 Stimulus 改造成 StimulusReflux （早在把 Stimulus 并入 Hotwire 之前就有了），甚至连 Haskell 都有类似的。

重点还是只靠后端就能在前端实现（稍微）富客户端的应用，如果 All in Live 的话会有问题，比如在 Phoenix LiveView 0.6 之前想要实现回车提交表单（比如做一个即时通信应用的输入框），那么要想自动清空，就需要把输入框中的值也引入前后端共有的状态中，这样用户每敲一个字都会产生一条 WebSocket 消息（当然也做了开箱即用的节流），然后写提交成功后清空这个状态字段的逻辑，要么就得写 JavaScript 钩子。现在倒是能够用后端写 JavaScript 逻辑了，不过还没发布。

[jk0001688]

jsx 就是 php 模板玩剩下的