如何看待svelte这个前端框架？

svelte代表了前端框架的另一个范式&＃xff0c;其实就是这样&＃xff0c;前端框架无非就两个层面&＃xff1a;runtime和compiler&＃xff0c;以react为主导的&＃xff0c;immutable方向&＃xff0c;通过在runtime层大力垦荒&＃xff0c;找到可以使用算法的地方&＃xff0c;发掘runtime的最大潜力

以svelte为主导的&＃xff0c;在compiler层动手术&＃xff0c;找到了可以使用算法的地方&＃xff0c;发掘compiler的最大潜力至于vue&＃xff0c;它是这两者的结合&＃xff0c;将vdom拿来&＃xff0c;是为了在runtime层开拓一环&＃xff0c;而template的编译&＃xff0c;又是在compiler层做&＃xff0c;所以 vue 本身其实是一个两个层面都有&＃xff0c;但又都不那么执着的框架。

这个框架的 API 设计师从 Ractive 那边传承过来的&＃xff08;自然跟 Vue 也非常像&＃xff09;&＃xff0c;但这不是重点。Svelte 的核心思想在于『通过静态编译减少框架运行时的代码量』。举例来说&＃xff0c;当前的框架无论是 React Angular 还是 Vue&＃xff0c;不管你怎么编译&＃xff0c;使用的时候必然需要『引入』框架本身&＃xff0c;也就是所谓的运行时 (runtime)。但是用 Svelte 就不一样&＃xff0c;一个 Svelte 组件编译了以后&＃xff0c;所有需要的运行时代码都包含在里面了&＃xff0c;除了引入这个组件本身&＃xff0c;你不需要再额外引入一个所谓的框架运行时&＃xff01;

虽然在简单的 demo 里面代码量确实非常小&＃xff0c;但同样的组件模板&＃xff0c;这样的 imperative 操作生成的代码量会比 vdom 渲染函数要大&＃xff0c;多个组件中会有很多重复的代码&＃xff08;虽然 gzip 时候可以缓解&＃xff0c;但 parse 和 evaluate 是免不了的&＃xff09;。项目里的组件越多&＃xff0c;代码量的差异就会逐渐缩小

Svelte 在大型应用中的性能还有待观察&＃xff0c;尤其是在大量动态内容和嵌套组件的情况下。它的更新策略决定了它也需要类似 React 的 shouldComponentUpdate 的机制来防止过度更新

Svelte 编译策略决定了它跟 Virtual DOM 绝缘&＃xff08;渲染函数由于其动态性&＃xff0c;无法像模板那样可以被可靠地静态分析&＃xff09;&＃xff0c;也就享受不到 Virtual DOM 带来的诸多好处&＃xff0c;比如基于 render function 的组件的强大抽象能力&＃xff0c;基于 vdom 做测试&＃xff0c;服务端/原生渲染亲和性等等

总体来说&＃xff0c;这个框架真心不错&＃xff0c; 国外有人称赞它是“The Most Beautiful Framework”&＃xff1b; 作者Rich Harris对这个框架信心十足&＃xff0c;自认为是真正的“React”的框架&＃xff0c; 油管上有他在2019全球前端开发大会上的演讲&＃xff0c;题目叫“Rethinking Reactivity”&＃xff0c;一股子冲着React来的意思&＃xff0c;哈哈。

不过目前来说&＃xff0c;Svelte能否承担起大型项目工程&＃xff0c;这点还很难说&＃xff1b;毕竟我司手头也没那么大工程去试验&＃xff0c;so&＃xff0c;留待观察吧。TG&＃xff1a;li9047