---
title: Qwik
tags: udn
type: slide

---


# [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/