|如何看待 svelte 这个前端框架?


|如何看待 svelte 这个前端框架?

文章图片


|如何看待 svelte 这个前端框架?

svelte代表了前端框架的另一个范式 , 其实就是这样 , 前端框架无非就两个层面:runtime和compiler , 以react为主导的 , immutable方向 , 通过在runtime层大力垦荒 , 找到可以使用算法的地方 , 发掘runtime的最大潜力
以svelte为主导的 , 在compiler层动手术 , 找到了可以使用算法的地方 , 发掘compiler的最大潜力至于vue , 它是这两者的结合 , 将vdom拿来 , 是为了在runtime层开拓一环 , 而template的编译 , 又是在compiler层做 , 所以 vue 本身其实是一个两个层面都有 , 但又都不那么执着的框架 。

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

虽然在简单的 demo 里面代码量确实非常小 , 但同样的组件模板 , 这样的 imperative 操作生成的代码量会比 vdom 渲染函数要大 , 多个组件中会有很多重复的代码(虽然 gzip 时候可以缓解 , 但 parse 和 evaluate 是免不了的) 。 项目里的组件越多 , 代码量的差异就会逐渐缩小
Svelte 在大型应用中的性能还有待观察 , 尤其是在大量动态内容和嵌套组件的情况下 。 它的更新策略决定了它也需要类似 React 的 shouldComponentUpdate 的机制来防止过度更新
Svelte 编译策略决定了它跟 Virtual DOM 绝缘(渲染函数由于其动态性 , 无法像模板那样可以被可靠地静态分析) , 也就享受不到 Virtual DOM 带来的诸多好处 , 比如基于 render function 的组件的强大抽象能力 , 基于 vdom 做测试 , 服务端/原生渲染亲和性等等

【|如何看待 svelte 这个前端框架?】不过目前来说 , Svelte能否承担起大型项目工程 , 这点还很难说;毕竟我司手头也没那么大工程去试验 , so , 留待观察吧 。