了解 qwik - 理论概念篇

快速做个了解，知道大概的东西。

背景#

如果使用客户端渲染的 CSR，首屏会慢，我们要怎么办？

这里后面单独摘出去。

服务端执行、客户端执行

可以使用 ssr 渲染，首次渲染首屏，后续还是使用 js 渲染
但还是需要下载 js 经历 hydrate 水合的过程，也就是 html 和对应的 js 要关联起来，水合不意味着重新渲染，是给 html 增加对应的事件监听逻辑。理论上 FCP 就非常快。
水合过程 js 会运行两次，服务端一次、客户端一次，理论上增加了 TTI 可交互时间
有了 ssr 就意味着有了 node.js ，也就有了安全性、稳定性、高性能的要求

服务端执行，分块渲染，可选客户端执行

stale-while-revalidate=<seconds> 实验性表明客户端愿意接受陈旧的响应，同时在后台异步检查新的响应。秒值指示客户愿意接受陈旧响应的时间长度。 —from MDN

客？

qwik 提出 hydration is pure overhead 水合过程是完全多余的， hydration is pure overhead 水合最难的是找到事件并连接对应。也就是 where 和 what，what 是关闭 app_state 和 framework_state 的闭包
app_state 大家理解的状态
框架的关联映射的状态
水合的过程：下载组件代码 - 执行组件代码 - 恢复状态和定位关联 - 事件处理添加到 dom

号称世界上第一个 O(1) 的 JavaScript SSR 框架

Misko Hevery，Qwik 的作者，更为知名的 Title 是 Angular.js&Angular 的作者。

参考解读文章

spa 和 island 的差异，island 点击交互才产生 js 请求

server component

RSC 可以将一些组件的渲染放到服务端，前端做纯展示，而且仅 RSC 的依赖不会被打包到客户端，这样如果某个组件有一个较大的第三方依赖，就可以把第三方依赖放到 RSC 里，在服务端运行组件并将产生的结果传输到浏览器端进行展示。

比如一个图表、画布 canvas、一个 markdown 渲染，这个过程是在服务端完成。这样客户端是接触不到渲染的过程。

如何做到？

简单说，html 中包含了要执行 js 的相关信息，必要时解析和触发下载额外的 js，这个 html 包含额外信息称之为额外信息序列化，比如事件、状态等。

![[Pasted image 20231022184321.png]]

这种能力称之为 resum-ability 可恢复性。

举例，一个计数工具，默认展示静态页面，只有点击触发实践才去下载执行 js。在用户有操作之前，就完全没有 js 下载和执行，这就是彻底的懒加载了。构建的时候，会产生很多个 chunk，每个都很小，颗粒度很小。

这是解决一切问题的银弹嘛？不一定，比如懒加载执行，同样也会产生激活的过程。合理使用动态 prefetch 技术吧

延迟加载的构建产物不会很大，会不会太多了？传统的构建工具颗粒度分割进行处理

不用担心执行完毕后是否有性能泄露。

内置 component$ 方法，表示定义懒加载的边界

页面不会满足基础的单页面，所以有 Qwik City 套件，支持路由、布局、加载器、验证、中间件、缓存等。

支持 SSR 和 SSG。

感觉有点意思，其实从 vue/react 迁移过来变化没有那么大。

qwik city 是自己的套件，前端时间 qwik 和 astro 搞一块去了，也就是一些路由、工程化组织使用 astro 作为底层能力。qwik 提供的是语法能力。