这是一个创建于 1446 天前的主题，其中的信息可能已经有所发展或是发生改变。
又看了一遍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 可以自动把交互有关的逻辑，比如onClickonChange等提取出来，放到客户端 JS 里，而把数据 + UI 有关的 JS 提取到 Server 里。客户端与 Server 的通信，也由 React 自动处理。
现在 React Server Components 通过 stream 的形式下发 UI ，痛点就是函数不能下发，如果也能实现呢？是不是开发者不用关心写的东西在哪运行了，React 去关心就行。
这觉得是革命性的，我愿意称之为 Modern React 。
时代一直发展，时代一直在变，但变的总是外在，总有一些东西永远不变。
如何更好的把 Server 的数据变成 Client 的 UI ，这个故事还会一直讲下去。
我们拾起 20 年前的概念，发明新名词、描绘新大饼、造出新云雾，我们要改变世界！
12 条回复 2022-02-12 00:05:16 +08:00
 | 1 35aZ4P8mT576683q 2021-11-02 15:25:10 +08:00 via Android 所以说学习能力强，接受新东西快是不可信的，只是旧事物裹上了新衣裳，谁都学得快 |
 | 2 2i2Re2PLMaDnghL 2021-11-02 15:58:29 +08:00  1 @liberty1900 所以说真正的接受新东西快，那就看他如何理解『熵』 这个东西是真正的难解 |
 | 3 rioshikelong121 2021-11-02 16:15:27 +08:00 1 我觉得，其实用起来体验完全不一样啊。侧重点也不一样。 其实 上一代的服务端渲染模式用起来是很头疼的，尤其涉及到一些精细的交互 / 异步的场景的时候。而且技术栈往往是割裂的 (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 |
 | 4 nanxiaobei OP @rioshikelong121 #3 当然不是完全一致的，这里讨论的也不是完全一致的问题。 |
 | 5 duan602728596 2021-11-02 18:06:34 +08:00 问题在于以前是不同的语言写的，而现在是同一个语言写的，不用写两套逻辑 |
 | 6 pluvet 2021-11-02 21:34:15 +08:00 我至今觉得 PHP 是很好用的语言，而且回看以前写 php 模板的套路，其实很多就是函数式组件 |
 | 7 ragnaroks 2021-11-02 22:06:40 +08:00 webform 了解一下，已经淘汰的东西比 react “先进” |
 | 8 kassadin 2021-11-03 02:16:14 +08:00 大致看了一下，有点儿意思 想到了 PowerBook 和 MacBook 的对比，外形一样，但内核完全不一样 后端套 react 之类的组件化模板的话确实很香啊 |
 | 9 agagega 2021-11-03 02:31:35 +08:00 via iPhone |
 | 10 pinkSlime 2021-11-03 09:10:10 +08:00 20 年前的 php 是一个纯粹的 interpreter 吧，且输出的是文档，如今输出的是 ui 抖这种机灵没点意思 |
 | 11 aristolochic 2021-11-03 13:47:50 +08:00 1 与其认为是回到了 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 逻辑了，不过还没发布。 |
 | 12 jk0001688 2022-02-12 00:05:16 +08:00 via Android jsx 就是 php 模板玩剩下的 |
Select Language