Qwik简介：一个超快的JavaScript框架-51CTO.COM

译者 | 李睿

审校| 孙淑娟

Qwik对响应式用户界面（UI）的工作方式进行了大胆的反思。其核心前提是框架从头开始构建，以使用最少的JavaScript交付HTML，只要足够的JavaScript就可以根据需要逐步引入交互性。

Qwik使用一种细粒度的模型来隔离应用程序的分段，这些分段根据需要进行水合。通过从基本原则出发，Qwik可以实现其他无法实现的性能，并代表了前端JavaScript的另一种发展路径。

Qwik的状态

Qwik仍处于早期版本中，但它已经推出了一段时间。在StackBlitz中有一个功能完整的示例，一个REPL游乐场和一个命令行工具。Qwik也已经发展到支持对开发人员更友好的、类似响应的语法。其底层仍然是一个高级的、独一无二的响应式引擎，它定义了状态、模板和侦听器的响应边界。

（1）可恢复性

Qwik使用了巧妙的服务器端和客户端渲染的组合，以避免当代框架在两次（一次在服务器上，一次在客户端上）执行水合工作时重复。

正如Qwik的创建者Misko Hevery所写：Qwik的基本思想是它是可恢复的。它可以在服务器停止的地方继续。在客户端上只需要执行最少的代码。

或者换一种方式：让服务器设置一个功能尽可能完整的HTML页面，并允许客户端执行尽可能少的工作，以便继续或恢复用户的进程。

带有服务器端渲染（SSR）的响应式框架中的典型流程是，首先在服务器上生成应用程序的版本，然后将其发送到客户端，客户端渲染架式应用程序。在这一点上，客户端应用程序接管了任务，基本上必须再次引导同一应用程序，以便将一个正常运行的客户端连接在一起。

这个过程被称为水合作用。有几种巧妙的方法可以提高水合作用的效率，但Qwik放弃了这些方法，采用了一种名为“可恢复性”的新方法。

可恢复性意味着客户机可以从服务器中断的地方开始，而不必在客户机上重新构建应用程序。

（2）交互时间

Qwik努力提升的指标是交互时间(TTI)。这是指用户向网页发出请求和网页响应用户交互之间的时间间隔。

加载时间(TTL)跟踪客户端完成接收所有所需数据所需的时间(因此是一个主要由文件大小和网络速度决定的指标)，交互时间(TTI)考虑了现代JS框架的一个突出事实：一旦下载了数据，客户端就必须解压缩，并执行所需的JavaScript代码，以使页面具有交互性。

响应式引擎需要做很多工作。引擎必须分解/解析所有标记(如JSX)，这些标记通过变量和表达式来根据状态的变化修改所显示的内容，以及根据代码的行为。

另一端是一个简单的HTML页面。一旦浏览器掌握了它，页面就可以开始移动了。这就是谷歌的PageSpeed Insights给Reddit.com这样的页面打32分(满分100分)，而原始HTML打100分的原因。

（3）闭包和侦听器

Hevery将快速TTI的技术障碍描述为“死于封闭”。简而言之，每个闭包必须维护封闭的信息世界这一事实意味着运行时应用程序是一个急切加载代码的“千层饼”。

Qwik采用的解决方案是使用与序列化监听器交互的全局事件监听器。换句话说，通用事件侦听器用于编排按需实现的侦听器，而不是下载并封装在闭包中(不管它们是否实际执行)。

Qwik的目标是提供与HTML一致的响应性，使其可序列化。根据标记中封装的信息，只需要一个很小的可执行文件就可以在运行时显示响应性。

（4）代码拆分并进行微调

从另一个角度来看，Qwik正在执行微调的代码拆分。当用户需要时，它会根据需要加载交互代码。如果有必要，捆绑器可以将这些块打包成更大的块。

Qwik从头构建，有三个独立的函数，用于创建状态、模板和侦听器。这允许框架只加载手头任务所需的内容。

状态、模板和侦听器这三个边界一度由开发人员直接编码。多亏了一个新的优化器工具，它可以将类响应式语法转换为这些幕后边界，可以得到一个相当熟悉的DX。优化器的工作是将实际代码转换为一组微小的存根，以便在必要时以小块恢复应用程序。

在优化器中，模板和侦听器用美元符号表示，而状态由useStore钩子处理。稍后将看到这个语法。

Qwik代码的最终输出看起来与其他框架不同，但是将Qwik与优化器一起使用可以使其与其他框架相媲美。Qwik还推出了QwikCity，这是一套更高级的功能（例如路由），可以让构建完整的应用程序更容易。

使用Qwik进行操作

现在已经理解了Qwik背后的概念，以下了解一下如何使用它进行编码。清单1显示了用Qwik编写的一个简单组件。(这个例子来自Qwik FAQ。)

（1）清单1.简单的Qwik组件

import { component$ } from '@builder.io/qwik';
export const App = component$(() => {
  console.log('render');
  return <p onClick$={() => console.log('hello')}>Hello Qwik</p>;
});

清单1显示了Qwik中的一个组件被定义为一个匿名函数，从Qwik库传递到组件$函数中。每当在Qwik中看到美元符号$时，这是在让优化器知道它需要做一些工作。Qwik将在应用程序的美元符号部分设置其细粒度延迟加载边界。

清单1中的onClick$是Qwik特殊语法的另一个例子。Qwik将使用一些技巧，在实际需要时只加载支持该功能所需的JavaScript。

清单1中的代码将被优化器分解为几个片段，如清单2所示。

（2）清单2.编译后的Qwik组件

/ The app.js file itself
import { componentQrl, qrl } from "@builder.io/qwik";
 const App = /*#__PURE__*/ 
 componentQrl(qrl(()=>import('./app_component_akbu84a8zes.js'),   "App_component_AkbU84a8zes"));
 export { App };
 // app_component_akbu84a8zes.js
 import { jsx as _jsx } from "@builder.io/qwik/jsx-runtime";
 import { qrl } from "@builder.io/qwik";
 export const App_component_AkbU84a8zes = ()=>{
     console.log('render');
     return /*#__PURE__*/ _jsx("p", {
         onClick$: qrl(()=>import("./app_component_p_onclick_01pegc10cpw"),  "App_component_p_onClick_01pEgC10cpw"),
         children: "Hello Qwik"
     });
 };

  // app_component_p_onclick_01pegc10cpw.js
 export const App_component_p_onClick_01pEgC10cpw = ()=>console.log('hello');

在清单2中可以看到，Qwik没有包含实际的组件功能，而是使用库中的componentQrl()函数包含了一个引用。这个函数接受一个qrl()函数，该函数使用匿名函数导入生成的组件文件。组件之间的这种关联都是由优化器在后台管理的。开发人员不需要直接考虑这个问题。

QRL代表Qwik URL，这是Qwik引用将被延迟加载的方式。基本上，只要框架需要延迟加载某些内容，它就会插入一个QRL，由特定于QRL的消费者包装(比如组件、状态或模板函数)。

例如，组件QRL可以在子组件中找到的代码的正确时刻加载，而父组件可以快速显示其布局。与onClick处理程序类似：当单击发生时，可以对它进行计算。

（3）Qwik CLI

该命令行工具可从npm获得，具有所期望的基本功能，包括创建、开发模式和生产构建。Qwik CLI使用Vite作为构建工具。可以使用npm create启动新应用程序qwik@latest，这将启动一个交互式提示。

如果创建一个简单的应用程序并运行产品构建，会得到一个dist目录，在那里可以看到前面描述的所有独立的可惰性加载的应用程序块。

Qwik调整

了解Qwik语法的一个有趣的地方是Qwik Cheat Sheet，它提供了Qwik和React代码的并排比较。人们可能会发现，这并不是一个很难的过渡。有些领域非常相似，有些则主要需要思维的转变。更大的收获是，Qwik中的响应式系统与类响应式框架完全不同，尽管优化器实现了相似的语法。

Qwik对代码拆分和延迟加载的创新方法为前端JavaScript提供了一种新的发展方式，而了解事情的发展将会很有趣。

原文标题：Intro to Qwik: A superfast JavaScript framework，作者：Matthew Tyson