辛宝Otto

辛宝Otto 的玄酒清谈

北漂前端程序员儿 / 探索新事物 / Web Worker 主播之一/内向话痨
xiaoyuzhou
email

了解 qwik - 理論概念篇

image

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

背景#

如果使用 客户端渲染的 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_stateframework_state 的闭包
  • app_state 大家理解的状态
  • 框架的关联映射的状态
  • 水合的过程:下载组件代码 - 执行组件代码 - 恢复状态和定位关联 - 事件处理添加到 dom

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

参考解读文章

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

server component

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

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

原理介绍#

如何做到?

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

Pasted image 20231022184321

  • 在 html 属性上记录当前袁术的事件、状态,称之为序列化
  • 也会内嵌 js,用来映射对比,从而实现事件恢复

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

image

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

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

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

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

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

全栈框架#

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

支持 SSR 和 SSG。

  • Qwik 专注组件和状态管理
  • Qwik City 是套装功能。

展望#

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

読み込み中...
文章は、創作者によって署名され、ブロックチェーンに安全に保存されています。