Skip to main content

没有框架的框架:我们为什么没有早点想到这个?

在没有使用框架的原生 JavaScript 中编写严肃的应用程序时,你会遇到复杂性的瓶颈。但编译器可以为你解决这个问题。

等等,这个新框架还有运行时?呃。算了,不用了。 – 2018年的前端开发者

我们向用户传输了太多的代码。像很多前端开发者一样,我一直在否认这个事实,认为在页面加载时提供100kb的JavaScript是可以的 – 只要少用一张.jpg图片!– 而真正重要的是应用程序在交互状态下的性能。

但我错了。100kb的.js文件并不等同于100kb的.jpg文件。不仅仅是网络传输时间会影响你的应用启动性能,还有解析和执行脚本的时间,在此期间浏览器会完全无响应。在移动设备上,这些毫秒会快速累积。

如果你还不相信这是个问题,可以在Twitter上关注Alex Russell。最近Alex在框架社区没有交到很多朋友,但他说得没错。但是作为Angular、React和Ember等框架的替代方案 – Polymer – 在前端世界还没有获得牵引力,这肯定不是因为缺乏营销。

也许我们需要重新思考整个问题。

框架真正解决的是什么问题?

普遍的观点是框架使得管理代码的复杂性变得更容易:框架通过虚拟DOM差异对比等技术抽象出所有繁琐的实现细节。但这并不完全正确。充其量,框架只是_转移了复杂性_,从你必须编写的代码转移到你不需要编写的代码中。

相反,React这样的想法之所以能如此广泛且当之无愧地成功,是因为它们使管理_概念_的复杂性变得更容易。框架主要是一个用于构建思维的工具,而不是构建代码的工具。

考虑到这一点,如果框架_实际上并不在浏览器中运行_会怎样?如果它能像Babel将ES2016+转换为ES5那样,将你的应用程序转换为纯粹的原生JavaScript呢?你就不用承担传输庞大运行时的前期成本,而且你的应用程序会变得非常快,因为应用程序和浏览器之间没有抽象层。

介绍Svelte

Svelte就是一个做到这一点的新框架。你使用HTML、CSS和JavaScript(外加一些可以在5分钟内学会的额外内容)编写组件,在构建过程中Svelte将它们编译成微小的独立JavaScript模块。通过对组件模板进行静态分析,我们可以确保浏览器做尽可能少的工作。

Svelte实现的TodoMVC压缩后只有3.6kb。相比之下,React加上ReactDOM_在没有任何应用代码的情况下_压缩后约45kb。浏览器仅仅评估React的时间就比Svelte启动并运行一个可交互的TodoMVC要长约10倍。

而且一旦你的应用程序_开始运行_,根据js-framework-benchmark的测试,Svelte快得惊人。它比React快。比Vue快。比Angular、Ember、Ractive、Preact、Riot或Mithril都快。它可以与Inferno竞争,Inferno可能是目前世界上最快的UI框架,因为Dominic Gannaway是个奇才。(Svelte在删除元素时较慢。我们正在努力改进。)

它基本上与原生JS一样快,这是有道理的,因为它_就是_原生JS – 只是你不需要自己编写的原生JS。

但这不是最重要的

当然,这很重要 – 性能确实非常重要。不过,这种方法真正令人兴奋的是,我们终于可以解决一些Web开发中最棘手的问题。

考虑互操作性。想要npm install cool-calendar-widget并在你的应用中使用它?以前,只有当你已经在使用(正确版本的)该组件所设计的框架时才能这样做 – 如果cool-calendar-widget是用React构建的,而你在使用Angular,那么,很遗憾。但如果组件作者使用了Svelte,使用该组件的应用可以用任何你喜欢的技术构建。(待办事项列表:一种将Svelte组件转换为Web组件的方法。)

或者代码分割。这是个好主意(只加载用户初始视图需要的代码,然后再获取其余部分),但存在一个问题 – 即使你最初只提供一个React组件而不是100个,你仍然必须提供React本身。使用Svelte,代码分割可以更加有效,因为框架被嵌入到组件中,而且组件非常小。

最后,作为一个开源维护者,我一直在思考的一个问题:你的用户总是希望优先考虑_他们的_功能,并低估这些功能对不需要它们的人的成本。框架作者必须始终在项目的长期健康与满足用户需求的愿望之间保持平衡。这非常困难,因为很难预测 – 更别说阐明 – 增量膨胀的后果,而且需要严格的软技能来告诉人们(他们可能一直在热情地宣传你的工具)他们的功能不够重要。但是通过Svelte这样的方法,许多功能可以完全不会给不使用它们的人带来任何成本,因为如果不需要,实现这些功能的代码就不会被编译器生成。

我们才刚刚开始

Svelte非常新。还有很多工作要做 – 创建构建工具集成、添加服务器端渲染、热重载、过渡效果、更多的文档和示例、启动套件等等。

但你已经可以用它构建丰富的组件了,这就是为什么我们直接发布了稳定的1.0.0版本。阅读指南在REPL中试用,前往GitHub帮助启动前端开发的下一个时代。