Svelte 5 在各个方面都实现了 “质的飞跃”,其创始人 Rich Harris 在最近的一次播客访谈中信心满满地表示。
“它变得更为强大、可靠,体积缩减,速度提升,灵活性增强,且组合性更加出色,”Harris 强调道。“采用 Svelte 5,你将发现相比 Svelte 4,所需编写的代码量大幅减少,同时开发体验也将更加愉悦。”
在参与 The Modern Web 播客 关于 React 服务器组件 与 Svelte 5 的讨论中,Harris 透露了 Svelte 5 引入的细粒度通用响应性特性,这一创新让开发者不再受限于 Svelte 组件本身。同场参与讨论的还有播客主持人 Tracy Lee、Ben Lesh 和 Adam Rackis。
“你能够在 .cell.json.cell.ts 模块中直接声明响应状态,这简直令人兴奋,”Harris 分享道。“而 Svelte 3 和 Svelte 4 中备受用户喜爱的所有功能,如丰富的动画原语、流畅的过渡效果、作用域 CSS 以及超高速的 服务器端渲染 等,都得以保留并进一步优化。”
Harris 进一步指出,Svelte 5 提供了一个 “与组件框架无缝对接” 的应用框架,且经过精心打磨,体验更佳。他还特别针对以往对编译器的批评做出了回应。
“过去,有人批评 Svelte 的编译器输出杂乱无章,担心如果组件众多,最终生成的包体积可能会超过一些大型框架。但现在,这些问题都已不复存在,因为我们的编译器输出变得更加精简高效,”Harris 解释道。“总而言之,Svelte 5 在各个方面都实现了显著的进步。”
目前,Svelte 5 已作为发布候选版本面世,并设有一个 专为开发者设计的演示平台。
左上至右上依次为:Tracy Lee 和 Rich Harris;左下至右下依次为:Ben Lesh 和 Adam Rackis。
Svelte 选择 Signals 的背后故事Svelte 的诞生恰逢 Signals 技术风靡之时,其创始人 Harris 欣然表示,Svelte 最终选择采用 Signals 技术是一个明智之举。
“这意味着编译器生成的代码异常清晰易懂,且我们无需编写过多代码,因为 Signals 自带了许多便捷功能,” 他解释道,“我们的 Signals 实现极其高效,不仅内存占用低,性能也出类拔萃。作为编译器,我们能够做出其他框架难以企及的设计选择。”
“坦白说,Svelte 在框架界其实算是一个相对保守的选手。”
——Svelte 创始人 Rich Harris
Signals,作为处理应用状态变化的响应式基础构件,赋予了开发者轻松管理并响应应用内变动的强大能力。Harris 追溯其历史渊源,指出其概念可上溯至 2008 年的 Knockout 框架。Lesh 补充说,那时它们被称为可观察对象,但 Harris 强调其易用性并不尽如人意。
Harris 进一步阐述了 Signals 技术的采用历程,从 Vue 3 的兴起,到 Solid 框架创始人 Ryan Carniato 对 Solid 优势的广泛宣传,无不彰显着 Signals 技术的影响力。
谈及 Svelte,Harris 再次强调:“我们 Svelte 确实在框架界中扮演着相对保守的角色。尽管我们享有创新灵活的美誉,但在设计决策上,我们无疑是行动较为迟缓的一派。这并不是因为我们缺乏开发速度,而是因为我们对自己所构建的产品有着极高的标准和要求。因此,我们花费了大量时间才达到今天的成就。”
Harris 盛赞 React Server Components 为 “卓越之作”在播客访谈中,Harris 也被问及了 React Server Components,这一在 React 社区内过去两年间持续引发热议的技术。面对这一既具个人关联又充满挑战的话题,Harris 坦诚而深入地分享了他的看法。
“我确实对 React Server Components 持有积极评价,绝非负面 —— 实际上,我认为它们相当出色。”Harris 说道,“对我而言,React Server Components 的最大魅力在于,它们标志着我们在过去十年左右探索旅程中的一个合乎逻辑且至关重要的下一步,即将我们所有的技术和理念汇聚一堂。”
他进一步阐述道,前端领域曾有一个 “荒谬的概念”,即将 HTML、JavaScript 和 CSS 三者割裂开来处理。然而,随着 React 等技术的兴起,人们逐渐认识到这种分离的做法并不明智。
“大家开始意识到,如果 CSS 与特定标记相关联,而 JavaScript 又与同一标记紧密相连,那么它们理应被整合在一起。因此,我们开始致力于将各种元素融合起来。”Harris 解释道。
“在这方面,Svelte 至少在一段时间内是这一理念的积极倡导者之一。我们不仅仅将行为与标记相结合,更将样式也嵌入到组件文件中,从而构建出自给自足、和谐统一的开发单元。”Harris 自豪地表示。
“而 React Server Components 之所以吸引我,正是因为它们代表了我们在过去十年探索过程中,将一切元素整合起来的自然延伸。”
——Harris
然而,他也指出,尽管这一方向正确,但在数据获取方面仍存在一个缺失的环节。“想象一下,当你将数据传递给组件时,组件可能会在初始化时发送网络请求以获取这些数据,并据此更新内部状态。”Harris 说,“虽然这种方法可行,但它也伴随着诸多弊端。”
他特别指出,通过网络进行数据获取可能会带来加载延迟、瀑布流效应及页面杂乱无章等问题。“但更深层次的问题在于,当你将数据与组件绑定时,你往往需要在组件外部编写数据获取逻辑。”Harris 继续道,“这可能导致一个尴尬的局面:即使你删除了某个组件,相关的数据获取代码可能仍然在运行,而你却浑然不知。”
“这就像是你移除了需要水的植物,但水龙头却依然在滴水。”Harris 形象地比喻道,“更糟糕的是,如果你在组件树的深处添加了一个新组件,你可能需要更新那些 远在天边、甚至由不同团队 维护的数据加载函数。这无疑增加了协调的复杂性和难度。”
但幸运的是,React Server Components 巧妙地解决了这一难题。“在 React Server Components 中,获取组件数据的代码就位于组件本身内部。”Harris 解释道,“因此,当你不再需要某个组件时,只需简单地将其删除即可,无需担心相关的数据获取逻辑仍在运行。这是一个既简洁又高效的解决方案,我认为在这一点上,React Server Components 的表现无可挑剔。”
React Server Components 的 “挑战”Rackis 提问道:“使用 React Server Components 时,会面临哪些挑战呢?”
Harris 解释道,挑战主要在于开发者实际上构建了两个相对独立的世界 —— 服务器端组件与客户端组件。
“当然,这样做有其合理之处,比如服务器是一个无状态的环境,因此不适合使用状态钩子;而客户端组件则不应直接访问数据库,这些都是显而易见的考虑。” 他进一步说明,“服务器组件与客户端组件之间的行为差异有其存在的理由,但现实情况是,这种差异给开发者带来了不少困惑。”
Harris 坦言,即便是作为框架的创建者之一,他也曾对此感到困惑。
“我非常理解这种感受。我希望能在整个应用程序中保持一致的思维模型。” 他继续说道,“如果可以,我真希望不必再去思考这些不同组件如何协同工作,以及哪些数据可以序列化等复杂规则。这不仅让我感到困扰,也让许多开发者感到头疼。这就是主要的挑战所在 —— 它确实不简单。”
作者简介:Loraine Lawson 是一位拥有 25 年经验的资深技术记者,涵盖了从数据集成到安全等技术问题。在加入 The New Stack 之前,她曾担任银行技术网站 Bank Automation News 的编辑。她还曾在 IT Business Edge 担任自由撰稿人,在 Tech Republic 担任 IT Manager 编辑,并作为印刷媒体记者报道了俄克拉荷马城爆炸事件,以及在肯塔基州交通内阁担任公关官员和网站管理员。
原文链接:
https://thenewstack.io/youll-write-less-code-with-svelte-5-0-promises-rich-harris/
声明:本文由 InfoQ 翻译,未经许可禁止转载。
今日好文推荐剥离几百万行代码,复制核心算法去美国?TikTok 最新回应来了
微软蓝屏至今仍未完全恢复,官方给出重启 15 次奇葩解决方案!网友:下一步会建议我检查是否插好电源
AI集体失智!9.11比9.9大?微软回应全球死机蓝屏事件:影响850万设备;OpenAI发布GPT-4o mini | Q资讯