各位看官们，Svelte5 框架已经正式发布了。

官方除了提供有关即将推出的 Svelte 5 的详细信息之外，该框架的作者 Rich Harris 还分享了自己对 React Server Components 的看法，请来详细看本文～

创建者Rich Harris在最近的播客中向开发者们承诺，Svelte 5.0 将在各个方面“变得更加好用” 。

“它更强大、更可靠、更小、更快、更灵活、更易于组合，”Harris 这样承诺道。“它更加简单。使用Svelte 5编写的代码比用Svelte 4少很多，而且感觉更加良好。”

他表示，Svelte 5 增加了细颗粒度的通用反应性，这意味着开发者将不再局限于 Svelte 组件。与他一起参加播客讨论的还有播客Tracy Lee、Ben Lesh和Adam Rackis。

“你可以在 .cell.json.cell.ts 模块内声明反应状态，这可太酷了。人们喜欢的 Svelte 3 和 4 的所有内容都仍然存在，例如所有动态原语、过渡、作用域 CSS、超快的服务器端渲染等。”

Harris 继续说，你会发现一个“与组件框架完美契合”的应用程序框架，它的打包版本会更好。

当然，他也特别回应了开发者们对Svelte 编译器的批评。

“对于那些过去看过 Svelte 编译器输出的人来说，他们会说，‘这看起来真的很混乱与不稳定，而且如果我有很多这样的组件，它最终会成为一个可能我刚一开始就使用的框架的包更大，但这种情况不再是真的了，因为编译器输出要精简得多，’他说。“从每个方面来看，它都在变得更好。”

有意思的是，Svelte 5 除了发布正式版本，还有一个可供开发人员预览该框架的“游乐场”。

播客中的人物。从左上到右分别为：Tracy Lee 和 Rich Harris。从左下到右：Ben Lesh 和 Adam Rackis。

为什么 Svelte 采用 Signals

Svelte 是在 Signals 炒作最热的时期创建的，Harris表示他很高兴 Svelte 选择使用 Signals（信号）。

“这意味着编译器生成的代码非常易于阅读，我们根本不需要生成大量代码，因为 Signals 为您提供了很多免费功能，”他不无“谦虚”地说道：“而且我们对 Signals 的实现非常高效，内存效率很高，性能也相当高。因为作为编译器，我们能够做出其他框架难以做出的设计选择。”

“说实话，我们实际上是比较保守的框架之一。”

——Svelte 创始人 Rich Harris

Signals 是处理应用程序状态的反应原语。它们允许开发人员轻松管理和响应应用程序中的变化。

这个名词实际上可以追溯到 2008 年左右，当时 Knockout 还很流行。当时它们被称为可观察对象，但是Harris 明确指出，它们的人体工程学做得并不咋好。

他解释了 Signals 的采用曲线，将其追溯到 Vue 3，然后他感谢Solid 的创建者 Ryan Carniato宣传了 Solid 的优势。

“说实话，我们实际上是比较保守的框架之一，” Harris谈到 Svelte 时说。“我们以创新而闻名，但在设计方面，我们绝对是行动较慢的框架之一，这并不是因为我们没有开发速度，而是因为我们对构建的内容非常挑剔。所以我们花了很长时间才到达那里。”

Harris 称 React 服务器组件做得“非常出色”

人们向 Harris 询问了React Server Components （RSC）的问题。其实在过去两年多来，React 圈子里一直在热议这个问题。Harris 承认道，这对他来说是一个棘手的谈话，因为他为 Vercel 工作，而 Vercel 已经采用了 React Server Components。

“我确实对 RSC 有看法，但不是坏的看法——实际上我认为它们非常了不起。对我来说，React Server Components 最大的吸引力在于，这是我们在过去十年左右的旅程中合乎逻辑的下一步，将我们所有的东西都放在一块。”

他说基本上前端开发者都有这样的想法，他称之为“荒谬的想法”——就是想将 HTML、JavaScript 和 CSS 分开。他补充说，很大程度上由于 React 的思维，人们现在认为这是一个非常糟糕的想法。

“人们开始认识到这确实是一个非常非常糟糕的想法，实际上，如果你有一些与应用程序中特定标记相关的 CSS，并且你有一些与相同标记相关的 JavaScript，那么它们应都属于一起的，所以我们开始将东西放在一起。至少在一段时间内，Svelte 是这一理念的更积极的追随者之一，因为我们不仅在标记旁边有行为，而且我们实际上在组件文件中就有CSS样式，所以一切都是这个很好的独立小东东。”

“对我来说，React Server Components 最大的吸引力在于，这是我们在过去十年左右的旅程中合乎逻辑的下一步，将我们所有的东西放在一块。”

– Rich Harris

不过，他表示还缺少一个部分，那就是数据获取。他说：

“假设你将数据传递到组件中，也许当组件在浏览器中初始化时，它会发送网络请求并获取一些数据，然后它会更新一些内部状态，”

他说，尽管这种方法有效，但也存在诸多缺点。

“其中一个缺点是，如果可以的话，你真的不想通过网络来做这些事情。比如你会有加载旋转图标，你可能会有各种各样的瀑布和类似的东西。但真正的问题是，如果你要将数据传递到组件中，你需要在组件本身以外的地方有代码来做数据获取。”

而问题是，如果你删除一个组件，你的程序可能仍然在获取数据，而你可能没有意识到这一点。

“你不知道你删除的是需要数据的代码，而不是数据本身。相反地，如果你在树的某个深处添加了一个组件，那么你可能需要更新数据加载函数，而这个函数距离你很远，甚至可能由另一个团队负责。你大概会遇到一个非常棘手的协调问题。”

而 RSC 强有力地解决了这个问题。

“获取属于组件的数据的代码存在于组件本身中。如果你不再需要该组件，你可以删除它，并且你不再需要为该组件获取数据。所以这是一个非常好、优雅的事情，我认为从未见过有人能像 RSC 那样解决这个问题。”

RSC 的《Catch》

目前的问题在于，开发者实际上创建了两个独立的世界，包括服务器上的组件和客户端上的组件。

Harris 说道：

“这显然是有充分理由的，比如服务器是无状态环境，因此没有必要设置有状态的钩子；而对于客户端组件，它们应该能够直接访问数据库，这是没有意义的。诸如此类。服务器组件和客户端组件之间的行为差异显然是有原因的，但我们发现，这种差异确实让人感到一些困惑。”

Harris 也大方承认，作为框架创建者，这些东西也会让他自己感到困惑。

“我对此深表同情。我希望我的整个应用程序都具有相同的思维模式。在可能的范围内，我不想再去思考，规则是什么，如何组合这些不同的组件，哪些数据可以序列化，这些事情只会让我感到困惑。这让很多人都感到困惑。这是主要的症结所在，但改起来确实有困难，需要一些时间。”

作者：场长