Rich Harris :Svelte 5.0 可减少代码编写量

2024年 7月 25日 30.3k 0

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

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

Rich Harris :Svelte 5.0 可减少代码编写量-1

创建者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 除了发布正式版本,还有一个可供开发人员预览该框架的“游乐场”。

Rich Harris :Svelte 5.0 可减少代码编写量-2

播客中的人物。从左上到右分别为: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 也大方承认,作为框架创建者,这些东西也会让他自己感到困惑。

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

相关文章

塑造我成为 CTO 之路的“秘诀”
“人工智能教母”的公司估值达 10 亿美金
教授吐槽:985 高校成高级蓝翔!研究生基本废了,只为房子、票子……
Windows 蓝屏中断提醒开发者:Rust 比 C/C++ 更好
Claude 3.5 Sonnet 在伽利略幻觉指数中名列前茅
上海新增 11 款已完成登记生成式 AI 服务

发布评论