# [Qwik](https://qwik.builder.io/) 下個世代的前端框架？ --- [](https://qwikschool.com/) 簡報內容皆擷取自官方課程 (免費) --- - [1] Why Qwik? - [2] What is Qwik? - [3] DEMO --- ## [1] Why Qwik? - 網頁歷史 - 未來趨勢 --- ### 主講人認為使用 Qwik 的推力 - 使用者體驗 (UX) - 開發者體驗 (DX) --- #### 影響 使用者體驗 (UX) 的因素 1. 等待讀取時間 2. 等待回應時間 (加入購物車後等待加入的時間) 3. 重複執行的事情所花費的時間 (重複填相同的表單，因為它沒有記住之前的記錄) --- #### 影響 開發者體驗 (DX) 的因素 1. 結構 2. 做越少的事情越好 3. 工具很容易理解 --- ### 從網頁歷史推測下階段的發展  <font size="2"> 每階段初期出現新技術來拯救 UX，該技術隨時間更成熟後 DX 提升，但問題也隨網站規模變大而越趨嚴重，接著就會發展新技術來解決問題 </font> Note: static pages (文字＆圖片 HTML only) / dynamic pages (SSR 多頁的應用程式) / MPA + JS (js (jquery)) / RIA (flash) / SPA (AJAX) / hybrid (new SSR + hydration (Next.js & Nuxt.js)) --- #### 前五十的電商網站的表現  --- #### Amazon  世界最大的電商網站 --- ### 下一階段？  Note: 最後三個階段的尾巴都是因為 app size 太大，導致使用者的等待時間過長才發展成下一個階段。 --- #### 未來趨勢 1 : App 越來越大  Note: 因為網站功能越來越強，但是 javascript 是單線程的語言，電腦變強對現況的改善並沒有幫助 --- #### 未來趨勢 2 : edge 技術 讓 app 更接近使用者  Note: 讓使用者可以從更近的節點取得資料，所以未來發展的技術與其相容可以有更好的效果 ---  ---  Note: IWA，qwik 符合了前面提到的幾個特點，重點是每個階段的發生看起來都跟 UX 有很大的關聯 --- ### 網頁效能影響收益  毫秒的讀取時間即可影響收益 Note: 網站效能則是能提升 UX 的重大因子，從很多的研究報告顯示網站的效能大大的影響收益表現 --- ### Core Web Vitals (Google)  [reference](https://web.dev/defining-core-web-vitals-thresholds/) Note: Google 發展出了這個東西來讓網站開發者可以作為網頁效能的判斷基準 --- #### LCP (Largest Contentful Paint) 渲染內容時間 - google: 少於 2.5 秒 - 解決方案 1. 圖片最佳化 2. 下載更少的程式碼 3. 讀取時執行更少的 JavaScript 4. SSR 5. "EDGE" caching & executing --- #### FID (First Input Delay) 網頁回應使用者行為(點按鈕之類的)的時間 - google: 少於 0.1 秒 - 解決方案 1. 下載更少的檔案 2. 執行更少的 JavaScript --- #### CLS (Cumulative Layout Shift) 網頁內容偏移量 - google: 少於 0.1 (偏移量) - 解決方案 1. 下載更少的檔案 2. 執行更少的 JavaScript ---  ---  Note: google 提出的方案都與後面兩點有關，qwik 則針對這兩點來解決 --- ### why Qwik? - Google - Wiz (frontend + backend), but not open source - 現在的框架著重於渲染，但 Qwik 更近一步處理讀取表現 --- ## [2] What is Qwik? 哪些強大的功能？ ---  Note: 從 SPA 講到現在來比較差別 --- ### SPA (Single Page Application) 1. build 2. server 3. client ---  --- index.html 看起來是空白的  --- 讀取完 js 之後才可以跟網頁互動  Note: 可以注意到，所有的內容不論是需不需要互動的內容都是從 JS 產生 --- ### SSR + Hydration  --- 由伺服器用 JSX 來渲染 html 內容  ---  hydration - 讓 html 變成可以互動的狀態 --- ### hydration 的問題  Note: hydration 的過程包含請求渲染完成的 html 後下載 JS 並執行，然而每次 route 切換時，需要整個過程重新跑一次，這個過程在桌機可能花費幾秒鐘，但在手機上的時間可能是好幾倍 (replay) --- ### Lazy loading?  Note: lazy loading 可以用來手動解決這個 JS 檔太大的問題 --- - hydration  --- 問題點： 1. 要手動撰寫 lazy loading 2. 仍然需要執行花費高的 hydration (主流框架目前遇到讀取問題而出現 lazy loading 的解決方案，並無法解決 hydration 帶來的問題) --- ### Resumability (JavaScript Streaming) 目前主流的前端框架都需要做 hydration (replay)， 但 qwik 的做法像是串流平台播放影片的方式，只是傳送的資料是 JS 檔案，只針對需要的檔案下載 ---  ---  <font size="4"> hydration 的做法因為 html 是一片空白，所以每次都需要重新執行 hydration 才能知道整個應用程式的狀態 </font> Note: 對比 hydration 的作法 ---  <font size="4"> Qwik 則在 server 執行 JS 來渲染 html 並把所有的資訊 (狀態) 寫在 html，而不需要由 client 端渲染 </font> --- ### Dynamic tree shaking  <font size="4"> 把狀態寫在 html 上面能做到讓使用者只會請求他所需要的部分，幾乎可以把請求的數量與大小最小化 (目前主流框架也有 tree shaking 但僅限於 build 階段) </font> Note: 把狀態寫在 html 上面更能根據 html 提供的資訊來判斷哪些 js 是頁面所需要的，而這些狀態其實就是要執行的 js 的 url --- ### 請求 JS，速度?? ---  <font size="4"> client 端開啟 worker 來把所有現在頁面上可能會執行的 js 預先放到瀏覽器的 cache 裡面 </font> ---  <font size="4"> client 端會有一個 loader (大約 1kb) 來依照需求把 cache 的檔案拿來執行 </font> ---  --- ## [3] DEMO - [Qwik vs hydration](https://learn.hirez.io/products/a-qwik-introduction/categories/2152654619/posts/2166812749) - 1:11 qwik (讀取時沒有請求 js，需要的時候從 worker 取出 JS 並執行) - 2:54 比較 (用 3g 網路 & 無痕模式，比較 "兩個" 主流框架與 qwik 的速度，讀取頁面時直接在 input 上面打數字，比較要花多久時間才能與應用程式互動) Note: https://qwik-app-edge-kevinshu1995.vercel.app/ https://qwik-app-kevinshu1995.vercel.app/