快速做个了解，知道大概的东西。
背景#
如果使用 客户端渲染的 CSR，首屏会慢，我们要怎么办？
这里后面单独摘出去。
水合#
- 可以使用 ssr 渲染，首次渲染首屏，后续还是使用 js 渲染
- 但还是需要下载 js 经历 hydrate 水合的过程，也就是 html 和对应的 js 要关联起来，水合不意味着重新渲染，是给 html 增加对应的事件监听逻辑。理论上 FCP 就非常快。
- 水合过程 js 会运行两次，服务端一次、客户端一次，理论上增加了 TTI 可交互时间
- 有了 ssr 就意味着有了 node.js ，也就有了安全性、稳定性、高性能的要求
部分水合#
- astro 尝试 partial hydration 部分水合，也就是 island
- next/nuxt 都有 server components 的概念
- 但 qwik 完全 0 js，完全提供 html，这样性能足够强，接下来介绍 qwik
- 如何提升 ssr 性能
- 比如缓存
stale-while-revalidate=<seconds>实验性 表明客户端愿意接受陈旧的响应，同时在后台异步检查新的响应。秒值指示客户愿意接受陈旧响应的时间长度。 --from MDN
- 比如 island 架构
- 通过 requestIdleCallback 调度、视口可见、交互可能性、产品价值等随着事件来加载和初始化
- 和上面这种渐进式水合不同，孤岛的部分水合，个别性能不会影响其他单元
不水合#
- qwik 提出
hydration is pure overhead水合过程是完全多余的， hydration is pure overhead
水合最难的是找到事件并连接对应。也就是 where 和 what，what 是关闭app_state和framework_state的闭包 - app_state 大家理解的状态
- 框架的关联映射的状态
- 水合的过程：下载组件代码 - 执行组件代码 - 恢复状态和定位关联 - 事件处理添加到 dom
号称世界上第一个 O (1) 的 JavaScript SSR 框架
参考解读文章
- hydration is pure overhead 所有的解读文章都是从这里来的
- 知乎有一篇文章 新时代的 SSR 框架破局者：qwik
- 高效水合的挑战性 dev.to
- Qwik - 前端性能的终极方案？
spa 和 island 的差异，island 点击交互才产生 js 请求
server component
RSC 可以将一些组件的渲染放到服务端，前端做纯展示，而且仅 RSC 的依赖不会被打包到客户端，这样如果某个组件有一个较大的第三方依赖，就可以把第三方依赖放到 RSC 里，在服务端运行组件并将产生的结果传输到浏览器端进行展示。
比如一个图表、画布 canvas、一个 markdown 渲染，这个过程是在服务端完成。这样客户端是接触不到渲染的过程。
原理介绍#
如何做到？
简单说，html 中包含了要执行 js 的相关信息，必要时解析和触发下载额外的 js，这个 html 包含额外信息称之为额外信息序列化，比如事件、状态等。
- 在 html 属性上记录当前袁术的事件、状态，称之为序列化
- 也会内嵌 js，用来映射对比，从而实现事件恢复
这种能力称之为 resum-ability 可恢复性。
举例，一个计数工具，默认展示静态页面，只有点击触发实践才去下载执行 js。在用户有操作之前，就完全没有 js 下载和执行，这就是彻底的懒加载了。
构建的时候，会产生很多个 chunk，每个都很小，颗粒度很小。
这是解决一切问题的银弹嘛？不一定，比如懒加载执行，同样也会产生激活的过程。合理使用动态 prefetch 技术吧
延迟加载的构建产物不会很大，会不会太多了？传统的构建工具颗粒度分割进行处理
不用担心执行完毕后是否有性能泄露。
内置 component$ 方法，表示定义懒加载的边界
全栈框架#
页面不会满足基础的单页面，所以有 Qwik City 套件，支持路由、布局、加载器、验证、中间件、缓存等。
支持 SSR 和 SSG。
- Qwik 专注组件和状态管理
- Qwik City 是套装功能。
展望#
感觉有点意思，其实从 vue/react 迁移过来变化没有那么大。