svelte 与虚拟DOM

最近读了一下尤雨溪在知乎的回答《如何看待 svelte 这个前端框架？》，然后去了解了一下 svelte 这个已经超越 Angular 排到第三的新框架。

与使用虚拟（virtual）DOM 差异对比不同。Svelte 编写的代码在应用程序的状态更改时就能像做外科手术一样更新 DOM。
———Svelte 中文网

虚拟DOM

结合尤雨溪的文章，最大的不同在于 svelte 不使用虚拟DOM 的方案。而虚拟DOM 的优势也是很多面试题中所述一样，将原本直接操作 DOM 造成的负担转变为在内存中操作 DOM，优势在于：

• 不直接操作 DOM，节省性能
• 避免复杂逻辑中代码的杂乱冗余和耦合

但针对这两点优势是有它固定的业务场景的，针对一些大型的系统，使用虚拟DOM 确实可以大大减少开发难度节省性能，但针对小型系统本身现有的机能已经足够满足性能开销，直接操作 DOM 也未必会与使用虚拟DOM 有显著的差异，反而是虚拟DOM 需要的 diff/patch 算法会更显的冗余。

按需构建

它在编译时，如果一个功能没用到，对应的代码就根本不会被编译到结果里去。

svelte 另一个特点则是根据需要来构建代码，相比较三大框架而言，不管开发的模块多么小，都需要将最基础的框架代码打包进去，会有种“大炮打蚊子”的感觉。

优缺点

基于这两个特点， svelte 轻量的优势就较为显著。但是问题也随之产生，正如尤雨溪所写：

项目里的组件越多，代码量的差异就会逐渐缩小。

如果系统逐渐迭代更新，功能越来越多的情况下，svelte 的性能优势会逐渐被追平甚至赶超，因为虚拟 DOM 的算法代码只有一份，但是 svelte 的“外科手术”式的 DOM 操作代码则会逐渐累加，最终在项目中的性能优势还余多少就不得而知了。

本质上对于正常的业务系统来说仍旧没有产生“质”的飞跃，那么 svelte 适合什么场景呢？尤雨溪给出了回答，较为适合 Web Components 这种组件类的场景。

再看一些 svelte 在国内真实应用生产的程序员的反馈，现有的 bug 和问题还比较多，但趋势是稳中向好的，也许不久的将来 svelte 真的会成为国内某些特定业务场景的新主流。

之前公司某条业务线就是开发 line 小程序（地位等同与日本的微信），个人感觉由于 line 始终还不算成熟，并且优化和用户体验也较差，对于一些复杂的业务来说 line 能否支持还是个问题，因此大部分基于 line 小程序的使用还是利用原生 js 开发的相对简单的功能。

但另一方面原生 js 的项目恶名远播，成熟的工程师避之不及，初级工程师操作原生 js 可以想象到那堆积的代码，这种场景下也许可以考虑使用 svelte 来进行开发工作。

参考文章：如何看待 svelte 这个前端框架？