为什么 Qwik 可能是 JS 框架的未来？
大家好，很高兴又见面了，我是"web 前端分享"，由我带着大家一起关注前端前沿、深入前端底层技术，大家一起进步，也欢迎大家关注、点赞、收藏、转发!
女士们先生们，Qwik 作为新的 JS 框架发布了。这个框架能更好的覆盖以下场景：
- 使用带有少量 JS 的纯 html 构建的网站，以便用户可以与之交互。
- JS 在运行时生成 HTML
- JS 在服务器上生成 HTML，然后在运行时对其进行水合
- JS 通过部分水化在服务器上生成所有 HTML
- 再回到原始的 HTML，它是由 JS 生成的，有额外的 JS 用于交互性。
Qwik 通过 RESUMABILITY 带来了一个全新的渲染模式，就可恢复性。Resumability 消除了许多现代框架的范式，如 Angular、NextJS 和 NUXTJS。 这些框架使用了 Hydration，帮助开发者以各种方式建立 SSR（服务器端渲染）网络应用的交互。
水合的问题
现有的 SSR/SSG 应用在客户端启动时，它需要客户端上做以下事情：
- 1 侦听器 ：定位事件侦听器并将它们安装在 DOM 节点上以使应用程序具有交互性；
- 2 组件树： 构造数据并表现在组件树上。
- 3 应用程序状态 ：恢复应用程序状态。
这就是水合作用，当前所有框架都需要此步骤以使应用程序具有交互性。这个补水过程很昂贵，主要因为以下两点：
- 1 框架必须下载与当前页面相关的所有组件代码。
- 2 框架必须执行与页面上的组件关联的模板，以重建侦听器位置和内部组件树。
而 Qwik 则不同，Qwik 提出 Resumable（可恢复）的概念，启动时则不需要这个补水的过程，也就大大缩减了客户端的启动时间。Qwik 则通过将事件侦听序列化到 DOM 中，然后通过 Qwikloader 来解决上述问题。
click me
衡量 Web 应用程序性能的最佳工具之一是灯塔，每个优秀的开发人员都沉迷于完美的 LIGHTHOUSE SCORE 。
但是对于使用水合或部分水合的框架，需要编写大量 JS 来实现所有交互。而更多的 JS 意味着性能上的妥协，但是也意味着这是需要在浏览器获得完美的灯塔分数必须要做的事情 。
Qwik 速度快不是因为它使用了聪明的算法，而是因为它的设计方式使得大多数 JAVAScript 永远不需要下载或执行。它的速度来自于不做其他框架必须做的事情（例如水合作用-hydration）。
更好的性能意味着更高的收入？
问题是为什么开发人员如此痴迷于满分，仅仅是为了分数本身，还是它真的带来了什么？ 好吧，根据研究，您的应用程序越快，您获得的转化率就越高。
用更少的 JavaScript 提供更多的功能？
当您在应用程序中加载页面时，通过水化，会得到如下的加载流程：
- 获取 HTML
- 下载一大堆 JS
- 解析然后执行 JS
- 绑定监听器
每次用户刷新页面时，主线程都会再次加载 JS，用户会再次经历上述的等待流程。
解决方案？
有使用水合的框架，也有部分使用水合的框架。 Qwik 没有水合作用。 它是如何做到的？ 您可以将其视为可即时交互的 HTML。 有了这个，您可以获得完美的灯塔分数！
但它是如何发生的呢？ Qwik 应用程序已完全序列化， 这意味着您的所有 JS 状态、侦听器和闭包都以 HTML 字符串的形式出现在您的应用程序中，这使得可即时重播并带来可恢复性（Resumability）。
使用 Qwik 进行延迟加载
当您运行 Qwik 应用程序时，您在网络检查中看不到 JS，但在单击事件时，您将看到要执行的 JS 代码。那是为什么？它基本上会在您的应用程序需要时触发 JS 代码 。
使用 Qwik 会带来更好体验？
我们看到 Qwik 的性能更好，但它是否为用户提供了更好的体验？ 假设用户启动您的应用程序并立即加载，但没有任何 JS。 然后用户开始向下滚动，你的应用程序开始执行迷你 JS 文件，是不是很丝滑？
结论
现在已经了解了 Qwik 提供的内容、它解决的问题以及它如何解决问题。 很明显，它具有潜力和充满希望的未来。 确实取得了更好的性能，但在用户体验方面出现了一些问题。 Qwik 期待找到新的更好的打包方法，使可恢复性更加出彩。
参考资料
https://upmostly.com/web-development/why-qwik-is-potentially-the-future-of-js-frameworks
https://www.toutiao.com/article/7149468834204779042/?channel=&source=search_tab
