# 海報
## 海報講稿(5分鐘)

您好我們是 G4 組，我們的專題主題是前端框架開發。

Arkhi 是我們開發的前端元框架，它通過島嶼架構，將網頁切分為多個「具備互動性的島嶼」，藉此減少前端 Render 的工作。我們希望透過這項設計，改善網頁的載入速度。

網頁中的內容是由多個節點，共同組成一個樹狀結構，稱為 DOM。我們的渲染流程是遍歷 DOM，在找到島嶼時尋找周圍其他島嶼和非島嶼的元素，重建出一個新的元件，並對其渲染使其獲得互動性。

島嶼架構設計上的一個短處是，將網頁分割為多個小型的區塊後，在具有大量動態內容的環境下，比較無法充分發揮其特性。對此我們使用 SSR 來部份改善動態內容的問題，在伺服器上先渲染上動態的網頁內容，使其無須利用島嶼在客戶端抓取資料和渲染。而針對更細微使用者個人化的資料，我們才利用客戶端呼叫 API 取得資料進行渲染。

我們進行壓力測試的結果，根據 Lighthouse 提供的指標，Arkhi 大部分情況下成績都和一般 React 網站接近。而在以靜態內容為主的網頁中，Arkhi 因為幾乎不需要載入，所以載入速度保持一致。對於幾乎完全靜態的網頁，因為 Arkhi 沒有 Hydrate 網頁內容的需求，所以指令執行的時間和記憶體用量都優於一般的 React 網頁。在具備大量互動元素的網頁中，因為 Arkhi 需要處理大量的島嶼和渲染佇列，在具備大量互動元素的使用場景下，我們在載入速度上會較差。綜上所述，Arkhi 適合靜態內容居多的網站，如部落格、論壇、購物網站等等。而像是社群媒體或是其他大量互動元素的網站，可能就不是 Arkhi 適合的使用場景。

在撰寫 arkhi 以及後續開發 demo 的過程，我們發現一些可以改善開發體驗的機會，並且實做了相關的開發工具整合到框架中。舉例幾項功能來說：

- Prefetch 會預先下載稍後可能造訪的網頁資源，當使用者造訪新頁面時，我們能夠直接從快取資源中取得頁面資料，流暢切換頁面內容
- CMS 將 Markdown 內容轉換為 JSX 後將內容載入為元件，而 MDX 中的互動元素，會被打包成島嶼自動獲得互動性。
- Share API 取代了無法在 Arkhi 中使用的 Context api，方便我們在島嶼之間分享狀態，只要對 Share 內的資料做變動，框架會自動提醒所有聆聽該狀態的島嶼更新

- 介紹 (1.5m)
- 問題
- 目的
- 島嶼架構 (1.5m)
- 概念
- 渲染方式
- SSR
- 測試數據 (<1m)
- 輔助功能 (<1m)

## 問答(5分鐘)

### 開發目的
* **為什麼選擇以島嶼架構為基礎開發網站？**
我們的專題想要探討的一項問題是如何改善網頁的載入速度，那以 React 為基礎所撰寫的網頁經常出現的一項問題就是載入速度偏慢，造成不佳的使用體驗。一方面我們可以透過一些程式上的技巧避免這樣的狀況，但我們也能夠根本上的從渲染方式層面解決。島嶼架構即是為了解決這項問題所提出的，當然島嶼架構並非適合所有的用途，所以我們希望在這個專題中透過實際實做這樣的使用島嶼架構的框架來談討他的實做細節以及適合的使用場景。

* **使用ssr的原因？**
因為島嶼架構的框架在客戶端無法直接掌控網頁中所有內容，如果需要做到像是 Twitter、Facebook 等網頁的效果，雖然不是不可能，但是相較之下無法發揮島嶼的一些優勢。這些使用場景就不適合這樣的框架。
雖然我們無法根本性解決島嶼架構設計上限制，但我們能夠利用 SSR 的方式，在伺服器端先完成大部分動態內容的渲染，在客戶端就只需要叫 API 針對小部分更個人化的資料對渲染。
除此之外 SSR 可以降低對客戶端硬體效能的需求，且伺服器端生成網頁有利於爬蟲解析網頁內容，以增加曝光度。

* **說明為什麼要使用 Vite，並說明 Vite 的功能**
Vite 提供了多項獨特的功能，大幅提升開發者體驗。包括像是開發期間獨特的 ES Module 打包方式和熱更新機制，讓他有極快的啟動速度。過去在啟動 bundler-based 的 server 時，編譯器會主動先編譯和打包所有的程式內容，且過程經常使用 JavaScript 撰寫的編譯器。在比較龐大應用中經常需要用上數分鐘才能重新啟動，看到變更的程式內容。
Vite 在開發環境中會預打包模塊，且使用像是 esbuild 這樣使用原生語言撰寫的編譯器，編譯速度提昇超過十倍之外，會將 bundling 的工作交由瀏覽器負責，在需要用內容時才載入 code split 出的模塊。除此之外，加上即時的重新編譯以及熱更新，使得 Vite 的開發體驗極佳，適合快速迭代。

* **以靜態內容的快速載入為目的，那有處理除了 md 文檔其他檔案類型嗎？**
除了最基本的 markdown 檔案之外，我們支援 mdx 檔案，自動將檔案中的元件轉換為島嶼，以在靜態內容中穿插動態的互動元素。
我們對於其他類型檔案的應用沒有做限制，我們希望利用開發者間常用的 Markdown 和 mdx 作為範例，讓開發者了解能夠如何利用我們框架的特性，撰寫更多的插件。
另外在圖片方面，我們有實現 preload API，可以透過 http hint 讓使用者在頁面載入的同時，一並預先載入圖片，避免圖片載入緩慢。

### 效能比較
* **既然你們提到React本身的限制，那為何還選擇它作為框架的基礎？**
由於 React 本身的泛用性、知名度、以及社群規模等都相當龐大，我們研究的內容可以直接應用在很多既有的程式上。同時對於初次接觸這個框架開發主題的我們，選擇 React 除了更加容易上手，也更好好了解其他新框架的設計上是想要解決哪些 React 不好，或是無法解決的問題。

* **Arkhi 有較低的記憶體使用量和編譯時間，這對網頁有什麼好處？**
Arkhi 較低的記憶體使用量主要體現在客戶端渲染的過程，主要原因就如前面所介紹的、大部分的內容都已經在 伺服端渲染完成，客戶端只針對必要的 script 部分（Island）進行渲染，因此記憶體使用量自然比較少。而這對網頁的好處是可以降低客戶端設備的硬體需求。
較短編譯時間對一般使用者來說並沒有直接的影響，但對於使用Arkhi的開發者來說，卻可以減少每次更新或修改網頁內容時所需要等待的編譯時間，相比其他大型網頁數分鐘甚至長達數十分鐘的編譯時間來說，這將大幅提升開發者的開放體驗。

* **Arkhi 與 Vue （或是其他的既有選項）相比，哪個比較適合寫購物網站？**
若要將 Arkhi 與 Vue相比，Vue絕對是比較合適的，Arkhi 本質上是實驗性質的設計，完整性遠不及已經行之有年的 Vue。同時對於購物網站來說，安全性跟穩定性都是相當重要的，而這在 Arkhi 上是仍需要完善的部分。
另一個原因是 Arkhi 的底層依賴於 React，而由於 React 自身架構的問題，其響應時間並不及 Vue 來得快速，因此綜合考慮下 Vue 會比 Arkhi 還要適合開發購物網站，但我們認為島嶼架構整體的概念除了可以用來改善一些既有網站的效能，也能夠應用在未來開發的其他框架當中。

* **arkhi 使用 ssr 是否會對伺服器造成壓力？**
這個問題要考慮到現有 JavaScript 客戶端框架的渲染設計，近年來為了 SEO 和其他使用者體驗因素，大部分會採用完整 SSR 或是 Partial Pre-rendering 這類的渲染方式，那既然瀏覽器無論如何都會宣渲染一次，我們不妨減少客戶端的工作量，讓伺服器複雜整體網頁內容渲染，讓客戶端管理更細微的網頁內容變化。這樣對伺服器工作量是沒有多少的改變，但是可以簡化伺服器和客戶端的關係，降低兩者之間需要重複管理同樣一份狀態的諸多網路請求和快取。我覺得這不探沒有造成伺服器的壓力，對整個網頁的開發還有正向的影響。

* **你們如何分析效能差異？**
我們使用 Chrome 的燈塔測試取得基礎的測試數據，同時使用極端龐大的網頁壓力測試我們的框架，以獲得渲染效能的數據，以觀察純 React 網頁和我們框架，包含記憶體、CPU 用量、渲染時常上的差異。

* **你們如何確認實驗的有效性？**
以我們目標比較的場景，我們認為 Chrome 燈塔測試很大程度上可以代表使用者主觀在網頁載入上的體驗，且在前端開發是經常被使用來初步檢測網站效能的指標。除了燈塔我們也透過其他系統的數據了解 Arkhi 運作時的其他數據，以及

### 使用範圍
* **(框架應用場景相關問題)**
根據我們的實驗數據，以及開發 Demo 的經驗，我們認為這個框架適合大量靜態內容的網頁，或是內容較固定、可預測，具備小範圍互動性的網頁。可以看到我們 Demo，我們實作了文檔網站、論壇、以及購物網站。這是我們認為最好展現這個框架優勢的幾個使用場景。

### 可以修正的方向
* 你覺得目前Arkhi的功能是否完善？
在 Arkhi 中我們實作出了島嶼架構的渲染流程，也探究了幾個我們認為有助於輔助這個框架使用的功能。但是我們認為還有很多可以改善的空間，包含實作的細節、整體架構的優化、以及一些長期使用才能發現的盲區及使用方式。現在我們能做的(直接接下題)

* Arkhi可以改善的部分是什麼？想要怎麼修改？這樣修改可以改正哪些部分？
- 可以使用 preact 等比 react 更適合島嶼架構的框架代替目前的基底，Preact 具有直接隊員見本體 Hydrate 或渲染的功能，讓我們省去重建島嶼的步驟
- 從編譯器階層去尋找和標記島嶼的位置，或許可以降低開發時的思考負擔，簡化開發
- 尋找其他更低 overhead 的渲染流程，優化現有的許多流程
- 自行撰寫伺服器的 routing 和 bundling 流程，代替現有使用的套件，以有效的發揮島嶼架構的設

## 建議

- context switch
- proxy server
- 彈性使用的問題（參考google app

---

- 在島嶼架構不適用的場景，改用其他渲染方式
- 更加善用靜態渲染和 CDN Cache
- 在客戶端使用彈性的問題
- 完成 CMS 等輔助功能的開發

在先前研究中發現，島嶼架構雖適用在靜態內容為主的網頁，但是在高度動態的網頁中會受到渲染流程的高開銷，反而出現渲染極度緩慢的情況。雖先前我們認為這代表這是我們的框架以及島嶼架構不適用的場景，在實際開發中仍有一個方案支援多功能及場景的需求。

為此，我們認為能夠參考 Nuxt.js 對渲染模式的設定，在不同的頁面根據需求提供 API，設定最適的渲染模式以及優化選項。

---

現在我們的框架是完全 SSR，最初的原因是因為希望藉此補足島嶼架構的缺陷，但是在最高流量的頁面（例如首頁）這個 SSR 步驟也會成為一個流量瓶頸。這個問題的解決方法和上個問題類似，可以透過在關鍵頁面使用預渲染（Prerender）改善。

---

因為在客戶端不無法透過島嶼對網頁排版進行大規模的變動，我們叫一般的框架少了一些使用彈性。我們可以思考如何在渲染完成後，根據使用需求動態插入更多的島嶼。這項功能可以更進一步降低島嶼架構使用彈性的問題，甚至降低最初載入時需要進行的渲染任務量，在必要的時候才執行渲染任務以進一步改善載入速度。