节目信息

PodRocket | 整理时间：2026年2月9日

本期嘉宾：Rich Harris (Vercel 软件工程师，Svelte 创始人)
主持人：Noel

---

节目简介

本期节目深入探讨了前端性能优化的核心问题，特别是 React Server Components (RSC) 的性能开销，以及 Svelte 如何通过细粒度响应式机制和异步优先架构来优化前端性能。Rich Harris 分享了他在性能前沿大会上的演讲内容，讨论了服务器与客户端通信的真实成本，以及为什么精细粒度的响应式是未来框架的发展方向。

---

核心话题讨论

话题 1：React Server Components 的性能开销

Rich: 归根结底是因为服务器并不了解客户端所掌握的信息。客户端是一个长期存在且具有状态的实体，而当需要从服务器获取新数据时，这是一次性完成的操作。

Rich: RSC 的工作方式与 React 虚拟 DOM 更新过程相似，至少在概念上是重新渲染全部内容，然后应用发生变化的那些部分。

Noel: 你将其描述为还不够，始终存在一定的开销。能否进一步展开说明一下，对于比计数器应用更复杂一些的场景，实际痛点在哪里？

Rich: 当你点击按钮并希望了解该按钮的更新状态时，现在需要在服务器上重新渲染应用，因为这些是服务器组件而非客户端组件，服务器并不知道页面的当前状态，因此它所能做的只能是返回全部内容。在小型应用中，该数据量不会巨大，但其中包含了许多不仅未发生变化、而且根本不可能变化的内容，因为服务器无法知晓这些状态。

💡 要点: RSC 的核心问题是服务器不知道客户端状态，导致必须传输大量不必要的数据。这就是”细粒度一切”理念的核心——只获取真正需要的数据。

---

话题 2：细粒度响应式与远程函数

Rich: 如果采用一种不尝试在服务器上重新渲染全部内容的方法，而是仅获取客户端实际完成任务所需的数据，那么在服务器和客户端之间来回传输的数据量将显著减少。

Rich: 我们创建了名为远程函数的功能，这是 SvelteKit 应用框架的一个特性。远程函数是我们对远程过程调用（RPC）这一理念的实现。

Rich: 无需手动声明 HTTP 请求、获取 JSON、传递和解析，作为开发者你本质上只需进行函数调用，而 TypeScript 也认为你只是在进行函数调用，因此你能获得类型安全等所有优势。

Noel: 从开发者体验的角度来看，这种差异会如何体现？

Rich: 在 React 中，当使用 React 服务器组件时，它们可以使用 await，但不能使用 hooks，例如 useState 或 useEffect。客户端组件可以使用钩子，但无法使用 await 关键字。因此在不同组件中可以执行的操作存在一系列不同的规则。而在 Svelte 中，由于这种区分并不存在，你根本不会用这样的思维去考虑问题。

💡 要点: Svelte 的远程函数（RPC）让开发者像调用普通函数一样调用服务器端代码，自动获得类型安全。同时，Svelte 不区分服务器组件和客户端组件，开发者体验更自然。

---

话题 3：同地部署（Co-location）与类型安全

Rich: 顺理成章地，我们把样式集中在一起，把标记集中在一起，把行为集中在一起，把导入也集中在一起。让我们也将数据放在相同的位置。这正是过去十年网页开发演进的方向。

Rich: 在前端框架中处理数据的方式是先获取数据，在渲染过程之外，因为渲染本质上是同步的，所以你会将数据作为属性推送给组件。但这种方式存在重大缺陷：你无法获得良好的类型安全性，而且数据需要经过所有组件层级才能到达它应有的位置。

Rich: 如果我需要获取某些数据，而这些数据是在我进行路由逻辑导航时获取的，随后又在页面角落某个组件中使用，那么组件与数据的共处问题就非常严重。你基本上不得不在获取数据的逻辑中复制组件树的结构，这使得整个系统完全无法维护。

Noel: 在客户端服务器框架的世界中，你认为理想的类型安全是什么样的？

Rich: 作为应用程序作者，我希望能尽可能不用考虑类型问题。我希望所有内容都能被自动推断。你真正需要考虑这类问题的唯一场景，是将数据从客户端发送到服务器时，为此我们采用先验证后保障类型的策略。

💡 要点: 同地部署（co-location）将数据依赖与组件放在同一位置，避免了数据层层传递的问题。Svelte 通过模式验证（如 Zod）确保类型安全，自动推断类型。

---

话题 4：异步优先框架

Rich: 我们秉持这种理念，尝试将其应用于解决组件数据需求与组件其他部分紧密耦合的问题。显而易见，你只需要能够在组件内部使用 await 关键字。

Rich: 当你在组件中遇到 await 时，首先这些 await 会被并行化。因为如果你有多个 await 而它们按顺序执行，就会自然发生在异步组件内部，这样可能会导致出现巨大的瀑布效应，从而影响应用性能。

Rich: 我们不希望开发者花费时间思考写下这段代码后会发生什么。我们希望框架能自动为你完成合理的操作。如果你有多个异步操作，它们会自动并行执行，避免瀑布效应。

Noel: 你们是否会关注某个功能的易用性，比如在执行某种变更操作时，需要手动选择是否更新数据？

Rich: 性能爱好者显然是我们的核心用户群体。这很好，它让我们能够持续关注性能问题。在框架中，很容易让性能问题被忽视。但一旦我们发布性能下降的版本，立刻就会有人反应应用彻底崩溃了。

💡 思考: 异步优先框架自动并行化异步操作，避免瀑布效应。虽然这需要开发者手动触发更新，但性能提升显著。Svelte 选择服务性能敏感用户群体，这让框架始终保持高性能。

---

话题 5：默认设置与 AI 代理

Rich: Rails 开发者或 Laravel 开发者会认为，这正是他们所期待的，因为在这些生态体系中，所有这些功能都理所当然地被视为框架的一部分。所有功能都已内置。

Rich: 我们推出了 Svelte 官方的 packages 页面，开发者可以访问 svelte.dev/packages，该页面列出了经过筛选的高质量库。但最终真正理想的情况是，你可以启动一个新应用，所有这些内容都已准备就绪。

Noel: 你认为这能帮助解决这个问题吗？无所谓，只要代理能采取行动就行？

Rich: 很多人并不在意技术选型，他们只关心最终结果。但认为仍有很多人非常在意，特别是当代码是我要在智能体完成处理后持续维护的时候。这些工具喜欢可以遵循的示例和模式，因此我们越能为它们提供顺畅的使用路径，人们在使用代理构建 Svelte 应用时就越是能够取得成功。

Rich: 我们绝不会转向以代理优先的框架。Svelte 明确站在人类一方，面对即将到来的”机器人圣战”。但目前人们正在大量使用这些技术，我们希望始终陪伴在他们身边。

💡 思考: 随着 AI 代理的普及，框架的默认设置和可发现性变得更重要。Svelte 选择”以人类为先”的设计理念，但同时确保为 AI 代理提供清晰的模式和示例，帮助代理更好地理解和使用框架。

---

📚 技术术语

• React Server Components (RSC): React 的服务器组件特性，允许组件在服务器上渲染，只将必要的 UI 描述发送到客户端。
• 细粒度响应式 (Fine-grained Reactivity): 一种响应式系统，只更新真正发生变化的部分，而不是重新渲染整个组件树。Svelte 的核心特性。
• 远程过程调用 (RPC): 一种编程范式，允许开发者像调用本地函数一样调用远程服务器上的函数。
• 同地部署 (Co-location): 将相关的代码（样式、标记、行为、数据）放在一起的组织方式。
• 瀑布效应 (Waterfall): 多个异步操作依次执行，每次等待前一个完成才开始下一个，导致总体延迟增加。
• 模式验证 (Schema Validation): 使用模式（如 Zod）验证数据结构，确保类型安全。

---

💬 金句摘录

“服务器不知道页面的当前状态，因此它所能做的只能是返回全部内容。” —— Rich Harris

“如果你知道某个事物发生了变化，那就直接请求该事物即可。” —— Rich Harris

“我们选择以语言本身的方式解决问题。” —— Rich Harris

“性能爱好者显然是我们的核心用户群体。这很好，它让我们能够持续关注性能问题。” —— Rich Harris

“Svelte 明确站在人类一方，面对即将到来的’机器人圣战’。” —— Rich Harris

---

🤔 思考与启发

本期节目展现了前端框架演进方向的深刻思考：

1. 性能优化的本质: 从 RSC 的讨论中我们看到，性能优化不仅仅是渲染速度的问题，更是关于数据传输效率的根本问题。精细粒度的数据获取比大规模数据传输更有效。
2. 开发者体验 vs 性能: Svelte 选择了一种需要更多手动控制的方式（手动触发更新），但换来的是更好的性能和更清晰的代码模型。这种权衡值得每个开发者思考。
3. 同地部署的价值: 将数据依赖与组件放在一起，不仅提高了代码的可维护性，还带来了更好的类型安全。这是现代前端架构的重要趋势。
4. 异步优先的未来: 随着网络应用的复杂性增加，异步操作的管理变得至关重要。框架层面的自动并行化是提升性能的关键。
5. AI 时代的框架设计: 随着开发者越来越多地使用 AI 辅助编程，框架的默认设置和可发现性变得前所未有的重要。但同时，框架仍应以人类开发者为中心。

延伸思考: 在你的项目中，是否遇到过 RSC 类似的数据传输问题？Svelte 的细粒度响应式和远程函数方案是否提供了更好的解决思路？在选择框架时，你更看重开发者体验还是运行时性能？