快速做個了解，知道大概的東西。
背景#
如果使用 客戶端渲染的 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 遷移過來變化沒有那麼大。