共计 2810 个字符，预计需要花费 8 分钟才能阅读完成。
大家好，我卡颂。
在前不久的 WWC22 中，builder.io的 CTO miško hevery（同时也是 Angular/AngularJS 的发明者）发表了一段充斥想象力的演讲。
在演讲中，他介绍了一款全栈 SSR 框架 —— Qwik，这款框架号称 能帮你移除我的项目中 99% 的 JS 代码。
他是如何办到的，本文咱们来介绍下Qwik。
欢送退出人类高质量前端框架群，带飞
性能差？码农不背锅
先来聊聊 Qwik 诞生的背景。
对于很多 2C web 利用（比方电商），首屏性能指标关乎用户留存，用户留存关乎赚多少钱。
所以，利用关上速度会影响赚钱。
然而，对于前端开发者，首屏性能指标并不容易优化。究其原因，并不是开发者不够致力。
让咱们来看两个性能指标。
如何优化 FCP
FCP（First Contentful Paint，首次内容绘制）测量 页面从开始加载到页面内容的任何局部在屏幕上实现渲染的工夫。
以后 web 利用广泛采纳 前端框架 开发，这意味着会引入大量 JS 代码（框架自身代码、第三方依赖包的代码 ……）
从 HTML 开始解析到最终页面渲染，两头还要经验：
- 下载框架
JS代码 - 执行框架
JS代码 - 由框架实现页面渲染
这就导致 FCP 指标的降落。
为了优化 FCP，框架作者提出了SSR（Server Side Render，服务端渲染），在服务端生成首屏所需HTML，这就为FCP 省去了上述三个步骤所需工夫。
然而，TTI指标依然须要优化。
如何优化 TTI
TTI（Time to Interactive，用户可交互工夫）测量 页面变得齐全可交互所需工夫。
次要掂量的是从下述 1 到 3 所需工夫：
- 首先掂量
FCP工夫 - 为页面中的元素绑定事件
- 对元素产生交互后，事件响应工夫在 50ms 内
应用 SSR 后，尽管 FCP 升高，然而框架 hydrate（注水，即框架使页面可能响应交互）所需工夫对TTI 会有影响。
可见，性能瓶颈的源头在 JS 代码。
React18的 Selective Hydration 通过 让用户交互的局部优先 hydrate来优化 TTI 指标。
然而，Qwik更极其，他的指标是 —— 干掉所有不必要的 JS 耗时，这里的耗时包含两局部：
JS作为动态资源加载的耗时JS运行时的耗时
超超超细粒度 hydrate
如果说传统 SSR 的粒度是 整个页面。
那么 React18 的Selective Hydration的粒度是 产生交互的组件。
那么 Qwik 的粒度是 组件中的某个办法。
举个例子，上面是 HelloWorld 组件（能够发现，Qwik采纳相似 React 的语法）：
对应页面渲染成果：
关上浏览器 Network 面板，这个页面会有多少 JS 申请呢？
因为这是个动态的组件，没有逻辑，所以答案是：没有 JS 申请。
再来看看经典的计数器 Counter 组件，相比 HelloWorld，减少了 点击按钮状态变动的逻辑，代码如下：
对应页面渲染成果：
关上浏览器 Network 面板，这个页面会有多少 JS 申请呢？
答案还是：没有 JS 申请。
留神这两个组件的代码中，定义组件应用的是 component$，有个$ 符号。
在 Counter 中，onClick$回调也有个 $ 符号。
在 Qwik 中，后缀带 $ 的函数都是 懒加载 的。
hydrate的粒度有多细，就取决于 $ 定义的多细。
比方在 Counter 中，onClick$带 $ 后缀，那么点击回调是懒加载的，所以首屏渲染不会蕴含 点击后的逻辑 对应的 JS 代码。
在点击按钮后，会发动 2 个 JS 申请，第一个申请返回的是 点击后的逻辑：
第 2 个 JS 申请返回的是 组件从新 render 的逻辑：
这两段代码执行后，Counter变为 1。
审查元素会发现，点击前，button on:click属性中保留了 逻辑所在的地址：
点击后，会从对应地址下载 JS 代码，执行对应逻辑。
从优良到极致
是不是感觉曾经优化到极致了？还没。
对于一些在页面中长期存在的、须要 JS 驱动的模块（比方轮播图），在模块展示前，模块对应 JS不是必要的。
比方上面这个钟的示例，页面中有个长长的列表，超过一屏高度，在列表底部有个钟。
上面是列表滚到底的样子：
在 Clock 组件的 useClientEffect$ 中定义 时钟指针摆动的逻辑：
Qwik中也存在相似 React 的useEffect，但在 Qwik 中这个 Hook 能够在服务端 / 客户端执行。
为了辨别，useClientEffect是 只在客户端执行的 useEffect。
加了 $ 后缀，代表他是 懒加载的。
具体成果是：当页面滚动到钟露出之前，useClientEffect$对应 JS 代码都不会申请。
当钟露出后，会发动两个 JS 资源申请：
useClientEffect的逻辑Clock组件从新渲染的逻辑
如果审查元素，在钟露出前，指针对应元素都是不动的：
当钟露出，加载并执行 JS 代码后，才开始执行动效：
对数据 hydrate
在传统 SSR 中，数据其实被初始化了两次：
- 页面首次渲染，此时服务端导出的
HTML中曾经携带了首屏渲染的数据 - 框架
hydrate后，数据再转化为框架内的状态供后续渲染
在 Qwik 中，页面初始化时会存在 type 为qwik/json的 script 标签用于存储 以后页面中被激活的状态对应数据：
什么叫 被激活 呢？
比方，上面是一篇文章的评论区，这是首屏渲染后的样子：
这些评论数据会呈现在 qwik/json 保留的数据中么？
不会，因为没有交互激活他们。
咱们发现，有一条评论被折叠了，点击后会开展这条评论：
点击这个行为会申请：
- 点击逻辑对应的
JS代码 - 这条评论对应组件的从新渲染逻辑
此时，评论数据才会呈现在 qwik/json 中，因为点击交互激活了这个数据。
所以在 Qwik 中，如无必要，数据不会被初始化两次。
HTML中存在 未激活的数据 ，qwik/json 的script标签中保留了 激活的数据，这个个性会带来一个很有意思的成果：
复制调试工具中 Elements 面板下的 DOM 构造 后，再在新页面中粘贴，就能复现 页面以后的交互状态（比方，输入框内依然保留之前输出的内容）：
换做其余框架，只能复现 页面初始时的状态。
交互时再申请 JS 不会卡么？
有同学可能会问，如果在网络不好的状况下，交互时再申请 JS 代码不会让交互变得卡顿么？
Qwik容许你指定 哪些组件可能是用户大概率会操作的（比方电商利用中，购物车按钮被点击的概率高）。
这些组件逻辑对应 JS 代码会prefetch，在不影响首屏渲染的前提下被预申请：
并且这些组件 prefetch 的程序是能够调整的。
这意味着能够追踪用户行为，以 用户交互的频率 为指标，作为组件 prefetch 优先级的根据，启发式晋升利用性能。
这才是真正的 以用户为导向 的性能优化，而且是全自动的。
总结
当今是个前端框架百花齐放的时代，不同框架都在寻找本人独特的卖点。
Qwik的卖点是：将 JS 代码的拆分从常见的 编译时 （比方webpack 分块）、运行时 （比方dynamic import），变为 交互时。
对 JS 代码的极致拆分，只为达到一个目标 —— 在首屏渲染时，移除你我的项目中 99% 的 JS 代码。
你感觉这波操作怎么样？