|如何看待 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 组件编译了以后，所有需要的运行时代码都包含在里面了，除了引入这个组件本身，你不需要再额外引入一个所谓的框架运行时！

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

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