当前位置: 首页 > 科技观察

这会不会是制约Svelte发展的最大因素

时间:2023-03-20 22:26:28 科技观察

大家好,我是Kason。多年来,前端框架一直在螺旋式发展。具体来说,很多主流的前端框架采用的技术其实很早就发明了。比如10年,“细粒度更新”在Knockout中首创。新框架的出现一般遵循:新的“idea”+现有技术的组合近两年,最流行的“idea”是Svelte带来的“重新编译”的概念。这也让他成为StackOverflow21年开发者报告中最受欢迎的框架。然而,开源世界和工业世界可能会出现两种情况:开发者说“哦,这个框架不错”,但是在写项目的时候,本体却很老老实实的选择了React。这也不能怪开发商。毕竟,生态是前端框架最重要的部分。本文想谈的是一个很可能制约Svelte生态发展的因素。VUE3在选技术的时候讲到VUE3,有一个考虑点:要不要把“虚拟DOM”去掉,拥抱“重新编译”,“虚拟DOM”的作用是找出交互引起的UI变化部分。而VUE3采用的是“细粒度更新”。理论上只要粒度够细,根本不需要“虚拟DOM”。通常,依赖于“虚拟DOM”的框架,“虚拟DOM”会占据一半以上的运行时工作量(如React、VUE)。如果能够去除“虚拟DOM”,可以带来以下好处:封装后的框架代码体积减小,运行时交互导致UI更新过程更短。不过,VUE3最终还是保留了“虚拟DOM”。其中一个重要的原因是:“虚拟DOM”可以弥补“模板语言”的局限性。比如当你需要在VUE中实现“布局组件”时:

1
2
33
44
预期的效果是:Layout中嵌套的结构有不同的缩进。输出的HTML如下:
1
2
33
44
这需要使用slot特性。但是要注意这部分,需要根据组件传入的levelprop动态变化://...例如:level=1对应类=“布局--1”。单纯使用“模板语法”,是无法描述这个特性的。此时,你需要手写“渲染函数”。因此,为了编写复杂的组件,VUE为开发者开辟了两条路,“模板语法”和“手写渲染函数”。之所以有两条路径,是因为这两条路径最终通向“虚拟DOM”。前端框架生态中很重要的一环就是组件库的丰富性。为有用的组件库更改框架是很常见的。因此,为了降低开发者编写复杂组件的成本,VUE保留了“虚拟DOM”。Svelte永远关上的门作为和VUE一样使用“模板语法”的框架,Svelte选择了“重新编译时间”的道路。这意味着他永远抛弃了“虚拟DOM”,也抛弃了“虚拟DOM”带来的灵活性。在讨论Render函数的PR[1]中,官方明确表示:Svelte永远不会考虑render函数。既然放弃了“renderfunction”(以及背后的“virtualDOM”),那么在写复杂组件的时候,唯一的出路就是:提供越来越复杂的API来应对复杂的场景例如:针对slot特性,Svelte提供了4个API:$$slots反观React,由于其极致的灵活性,根本没有对应的API。我们可以大胆推测编写复杂组件的成本:React