无招胜有招:为什么咱们没有及早悟到这个办法?

使用原生JavaScript编写正式的应用,在所不免会陷入复杂的境地,然而编译器能够鼎力相助。

注意:原文发表于 2016-11-26,随着框架不断演进,部份内容可能已不适用。前端

慢着!这个新框架也有运行时?呃……就此谢别,江湖再见。
—— 2018年前端开发者

咱们向用户滥发了过多的代码。react

—— 但我和前端开发者们同样,对此矢口否定。git

毕竟,让页面加载一份 100KB 的 JS 实在垂手可得,不过是少用一张 jpg 罢了。github

—— 当应用已经具有交互性时,更为重要的是性能。npm

然而,我错了。浏览器

100 KB 的 JS,并不等同于 100KB 的 jpg。网络

不只网络开销会下降程序的启动性能,还有解析和评估脚本所耗费的时间,在此期间浏览器会彻底失去响应。在移动设备上,这种时间损耗的境况尤甚。mvc

若你对此心存质疑,不妨在 Twitter 上关注 Alex Russell,Alex 虽然在框架圈里朋友寥寥无几,但他确实是言之有理。框架

Polymer 是相似 Angular、React 或 Ember 的替代方案,但仍未在前端界得到关注,天然也不是由于缺乏市场营销。dom

总而言之,或许咱们须要反思一下框架这个事情。

框架真正解决了什么问题?

通常而言,能够认为框架更为容易管理代码的复杂性。

框架使用 Virtual DOM 差别比较等技术,从更高层次对繁琐的实现细节进行抽象。

然而……事实并不是如此。

最优的状况下,框架能将复杂性的代码从之前的必写转化为不写

相反地,React 之类的思想之因此如此流行并得到成功,全因它们创造的新概念使得管理复杂性更为容易。

框架是构筑思想的工具,并不是代码。

有鉴及此,咱们假设浏览器上若是再也不加载和运行框架的状况呢?

与前述的 React 背道而行,假若用一种办法直接把您的代码转为原生的 JavaScript 呢?就如 Babel 将 ES6+ 的代码转为 ES5 同样,会输出什么样的结果呢?

—— 这样您的代码在前期将不需再背负大量的框架运行时,程序会变得飞快!

由于您的程序和浏览器之间,再也不有所谓的抽象层。

Svelte 登场

Svelte 就是为此而生的新框架。

您使用 HTML、CSS 和 JavaScript 编写组件(还有一些您能够在5分钟内学会的额外内容),在构建过程当中,Svelte 将其编译为微小且独立的 JavaScript 模块。

经过静态分析组件模板,咱们能确保浏览器所作的工做尽量少。

Svelte 实现的 TodoMVC 压缩后体积仅 3.6KB。

相较于没有任何业务代码的 React + ReactDOM,其压缩后体积约为 45KB。

在浏览器中,评估 React 使用交互式 TodoMVC 启动和运行所需的时间,React 花费的时间大约是 Svelte 的 10 倍。

根据 js-framework-benchmark 所示,一旦启动并运行你的 Svelte 程序,它的速度超级快

它比 Reack 快,比 Vue 快,比 Angular 快,比 Ember 快,比 Reactive、Preact、Mithril 通通都快,一个能打的都没有。

除了 Inferno,这是一个有力的竞争对手,它多是目前世界上最快的 UI 框架,由于 Dominic Gannaway 是一个向导程序。(Svelte 移除元素的速度较慢,咱们正为此努力

它基本上和原生 JS 同样快,这是有其因由的,由于它就是原生 JS,只不过你不用真的去写原生 JS 而已。

但,这不是最重要的

性能固然很重要。

不过用这种新的方法真正使人兴奋的点就在于,咱们终于有办法解决 Web 开发中最棘手的问题。

试考虑一下这个场景:

假设您要 npm install cool-calendar-widget 安装一个小组件,而后在程序中使用它。

在以往您得先确认这个小组件所基于的框架(以及正确的版本号)是什么,以后才能 npm 安装和使用它。

若是 cool-calendar-widget 是一个 React 内置的组件,而您正在使用 Angular 的话,那么……好吧,这状况就令人以为如鲠在喉,难如下咽了。

可是,若是小组件的做者使用的是 Svelte(生成不依赖框架的代码),则您可使用任何现有的技术来使用这个小组件(在代办列表中,会提供一种方法将 Svelte 组件转为 Web Component 的方法)。

同时代码分割也是一个很好的想法,只需加载用户所需的初始的 UI 视图,而后其余视图后续再取)。

可是存在一个问题。

即便您最初只是提供一个 React 组件而不是100个,您最终程序在运行时仍然须要 React 这个库自己。

使用 Svelte,代码分割会更加有用,由于框架是嵌入到组件中去的,而且组件体积也小。

最后谈一下,我做为一个开源维护做者,一直致力要解决的问题:用户老是但愿优先考虑他们提的 features,而忽略了不须要这些 features 的用户的使用成本。

框架做者须要始终平衡项目长期的健康情况,以及知足用户需求的愿望。

这里头的困难大得使人难以置信。

由于项目是难以预测(更别提)急速增量的后果,它须要一些委婉的软技能来告诉人们(这些人可能一直在热情地帮您宣传),他们提的功能并不足够重要。

但若是用的是 Svelte,许多功能特性就能够方便地被添加了,那么那些不须要这些特性的人,也没必要付出任何代价,由于实现这些特性的代码,非必要的状况下是不会被编译器拿去生成最终产物的。

咱们只是初显身手

Svelte 还很新。

百事待举:建立 build 工具集成、添加服务端渲染 SSR、热加载、transition 等等。

还有文档、示例和入门教程等等。

不过您已经可使用它来编写组件了,这是为何咱们直接就发布 v1.0 的缘由,您能够阅读入门教程,而后在 REPL 中小试身手,也能够前往 Github 帮助咱们开启下一个前端开发新时代!

相关文章
相关标签/搜索