大家好，很高興又見面了，我是"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
