• 已解决 73482 个问题
  • 已帮助 5993 位优秀工程师

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

diyatian 2016-12-16 浏览量:1109
 如何看待 svelte 这个前端框架?
看了下。十分精简。思路也很独特。
0 0 收起

我来回答

上传资料:
选择文件 文件大小不超过15M(格式支持:doc、ppt、xls、pdf、zip、rar、txt)
最佳答案

  • 作者是 Rich Harris,也就是 Ractive, Rollup 和 Buble 的作者,堪称前端界的轮子哥,现在又带来新轮子了!
    这个框架的 API 设计是从 Ractive 那边传承过来的(自然跟 Vue 也非常像),但这不是重点。Svelte 的核心思想在于『通过静态编译减少框架运行时的代码量』。举例来说,当前的框架无论是 React Angular 还是 Vue,不管你怎么编译,使用的时候必然需要『引入』框架本身,也就是所谓的运行时 (runtime)。但是用 Svelte 就不一样,一个 Svelte 组件编译了以后,所有需要的运行时代码都包含在里面了,除了引入这个组件本身,你不需要再额外引入一个所谓的框架运行时!
    当然,这不是说 Svelte 没有运行时,但是出于两个原因这个代价可以变得很小:
    1. Svelte 的编译风格是将模板编译为命令式 (imperative) 的原生 DOM 操作。比如这段模板:

    <a>{{ msg }}</a> 

    会被编译成如下代码:

    function renderMainFragment ( root, component, target ) { 

      var a = document.createElement( 'a' );

      var text = document.createTextNode( root.msg ); 

      a.appendChild( text ); 

      target.appendChild( a )

      return { 

        update: function ( changed, root ) { 

          text.data = root.msg; 

        }, 

        teardown: function ( detach ) { 

          if ( detach ) a.parentNode.removeChild( a ); } 

        }; 

    }


    可以看到,跟基于 Virtual DOM 的框架相比,这样的输出不需要 Virtual DOM 的 diff/patch 操作,自然可以省去大量代码,同时,性能上也和 vanilla JS 相差无几(仅就这个简单示例而言),内存占用更是极佳。这个思路其实并不是它首创,之前有一个性能爆表的模板引擎 Monkberry.js 也是这样实现的,ng2 的模板编译其实也跟这个很类似(但是中间加了一层渲染抽象层)。
    2. 对于特定功能,Svelte 依然有对应的运行时代码,比如组件逻辑,if/else 切换逻辑,循环逻辑等等... 但它在编译时,如果一个功能没用到,对应的代码就根本不会被编译到结果里去。这就好像用 Babel 的时候没有用到的功能的 helper 是不会被引入的,又好像用 lodash 或者 RxJS 的时候只选择性地引入对应的函数。
    基于这两个特点,Svelte 应用的最终代码量可以非常小。比如它的 TodoMVC min+gzip 之后只有 3kb。
    但是,Svelte 也不是没有它的潜在问题:
    1. 虽然在简单的 demo 里面代码量确实非常小,但同样的组件模板,这样的 imperative 操作生成的代码量会比 vdom 渲染函数要大,多个组件中会有很多重复的代码(虽然 gzip 时候可以缓解,但 parse 和 evaluate 是免不了的)。项目里的组件越多,代码量的差异就会逐渐缩小。同时,使用的功能越多,Svelte 要包含的运行时代码也越多,最终在实际生产项目中能有多少尺寸优势,其实很难说。
    2. Svelte 在大型应用中的性能还有待观察,尤其是在大量动态内容和嵌套组件的情况下。它的更新策略决定了它也需要类似 React 的 shouldComponentUpdate 的机制来防止过度更新。另一方面,其性能优势比起现在的主流框架并不是质的区别,现在大部分主流框架的性能都可以做到 vanilla js 的 1.2~1.5 倍慢,基于 Virtual DOM 的 Inferno 更是接近原生,证明了 Virtual DOM 这个方向理论上的可能性,所以可以预见以后 web 的性能瓶颈更多是 DOM 本身而不是框架。
    3. Svelte 的编译策略决定了它跟 Virtual DOM 绝缘(渲染函数由于其动态性,无法像模板那样可以被可靠地静态分析),也就享受不到 Virtual DOM 带来的诸多好处,比如基于 render function 的组件的强大抽象能力,基于 vdom 做测试,服务端/原生渲染亲和性等等。这一点在我看来比较关键。让我在一点点性能和 Virtual DOM 之间做抉择的话,我还是会选择 Virtual DOM。
    最后,我个人觉得 Svelte 最具有优势的地方,就是用来编译可独立分发的 Web Components。传统框架和 Web Components 结合最大的问题就在于运行时:单独分发的 WC 里面直接打包框架运行时显然不现实,不打包的话,又做不到开箱即用。但 Svelte 就没有这个问题,可以说是最适合这个用例的框架。

    • 发布于 2016-12-16
    • 举报
    • 评论 0
    • 1
    • 0

其他答案 数量:4

相关问题

问题达人换一批

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