无招胜有招：为何我们没有及早悟到这个办法？

Posted 2021-10-05 前端子鱼

使用原生javascript编写正式的应用，在所难免会陷入复杂的境地，然而编译器可以鼎力相助。

注意：原文发表于 2016-11-26，随着框架不断演进，部分内容可能已不适用。

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

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

—— 但我和前端开发者们一样，对此矢口否认。

毕竟，让页面加载一份 100KB 的 JS 实在轻而易举，不过是少用一张 jpg 罢了。

—— 当应用已经具备交互性时，更为重要的是性能。

然而，我错了。

100 KB 的 JS，并不等同于 100KB 的 jpg。

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

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

Polymer 是类似 Angular、React 或 Ember 的替代方案，但仍未在前端界获得关注，自然也不是因为缺少市场营销。

总而言之，或许我们需要反思一下框架这个事情。

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

一般而言，可以认为框架更为容易管理代码的复杂性。

框架使用 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 帮助我们开启下一个前端开发新时代！