changed 2 years ago  
Published Linked with GitHub

qwik logo

Qwik

下個世代的前端框架？

簡報內容皆擷取自官方課程 (免費)

  • [1] Why Qwik?
  • [2] What is Qwik?
  • [3] DEMO

[1] Why Qwik?

  • 網頁歷史
  • 未來趨勢

主講人認為使用 Qwik 的推力

  • 使用者體驗 (UX)
  • 開發者體驗 (DX)

影響 使用者體驗 (UX) 的因素

  1. 等待讀取時間
  2. 等待回應時間 (加入購物車後等待加入的時間)
  3. 重複執行的事情所花費的時間 (重複填相同的表單，因為它沒有記住之前的記錄)

影響 開發者體驗 (DX) 的因素

  1. 結構
  2. 做越少的事情越好
  3. 工具很容易理解

從網頁歷史推測下階段的發展

每階段初期出現新技術來拯救 UX，該技術隨時間更成熟後 DX 提升，但問題也隨網站規模變大而越趨嚴重，接著就會發展新技術來解決問題

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

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 檔案，只針對需要的檔案下載

hydration 的做法因為 html 是一片空白，所以每次都需要重新執行 hydration 才能知道整個應用程式的狀態

Note: 對比 hydration 的作法

Qwik 則在 server 執行 JS 來渲染 html 並把所有的資訊 (狀態) 寫在 html，而不需要由 client 端渲染

Dynamic tree shaking

把狀態寫在 html 上面能做到讓使用者只會請求他所需要的部分，幾乎可以把請求的數量與大小最小化 (目前主流框架也有 tree shaking 但僅限於 build 階段)

Note: 把狀態寫在 html 上面更能根據 html 提供的資訊來判斷哪些 js 是頁面所需要的，而這些狀態其實就是要執行的 js 的 url

請求 JS，速度??

client 端開啟 worker 來把所有現在頁面上可能會執行的 js 預先放到瀏覽器的 cache 裡面

client 端會有一個 loader (大約 1kb) 來依照需求把 cache 的檔案拿來執行

[3] DEMO

  • Qwik vs hydration
    • 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/

Select a repo