啥是 XXR ？認(rèn)識(shí)前端項(xiàng)目渲染模式們
這是我們團(tuán)隊(duì) @許濱楠 同學(xué)做的內(nèi)部分享，科普當(dāng)下流行的 CSR、SSR、SSG 等渲染模式的原理與優(yōu)劣勢(shì)，相當(dāng)有料。
PS：我們是字節(jié)游戲中臺(tái)前端團(tuán)隊(duì)，日常學(xué)習(xí)氛圍濃厚，最近聽說要 10-7-5 了，還有大量 HC，歡迎自薦。
一、啥是「啥是 XXR ?」?
前端研發(fā)中有許多常見場(chǎng)景，根據(jù)不同的構(gòu)建、渲染過程有不同的優(yōu)劣勢(shì)和適用情況。如現(xiàn)代 UI 庫(kù)加持下常用的 CSR、具有更好 SEO 效果的 SSR (SPR)、轉(zhuǎn)換思路主打構(gòu)建時(shí)生成的 SSG、大架構(gòu)視野之上的 ISR、DPR，還有更少聽到的 NSR、ESR 等等。
諸多方案的提出和完善帶來了更多的技術(shù)選型可能，迅速涌現(xiàn)的生態(tài)支持也讓不同方案的開發(fā)體驗(yàn)、心智負(fù)擔(dān)漸漸趨于便捷、開發(fā)者無感。
但：
- 各種方案的運(yùn)作模式是怎樣的?
- 不同場(chǎng)景下應(yīng)該如何選擇方案?
- 各種方案能帶來的優(yōu)勢(shì)是什么?造成的劣勢(shì)或者當(dāng)下的不足有什么?
- 有怎樣的開發(fā)工具、類庫(kù)、框架可以支持?
希望這篇文章能幫助解決上述這樣的疑惑，這就是「啥是 XXR ?」。
若尚不完整或有失偏頗，歡迎討論 & 指教。
二、渲染模式——概念與對(duì)比
這里所說的 ✌🏻 渲染模式 ✌🏻，包括：
頁(yè)面 / 應(yīng)用在開發(fā)完成之后的產(chǎn)物編譯方式;
部署上線之后的服務(wù)形態(tài);
資源存儲(chǔ)與分發(fā)的方式;
用戶訪問時(shí)的啟動(dòng)與渲染過程;
這幾方面不同的實(shí)現(xiàn)和規(guī)范。
本節(jié)將介紹各種渲染模式的基本特點(diǎn)、運(yùn)作方式，還有對(duì)應(yīng)的優(yōu)缺點(diǎn)比較。
2.1 CSR for Client Side Rendering
顧名思義的“客戶端渲染”，是當(dāng)下用于渲染各類 UI 庫(kù)構(gòu)建的前端項(xiàng)目的最常見方案。
2.1.1 啥是 CSR?
在這種模式下，頁(yè)面托管服務(wù)器只需要對(duì)頁(yè)面的訪問請(qǐng)求響應(yīng)一個(gè)類似這樣的空頁(yè)面：
- <!DOCTYPE html>
- <html>
- <head>
- <meta charset="utf-8" />
- <!-- metas -->
- <title></title>
- <link rel="shortcut icon" href="xxx.png" />
- <link rel="stylesheet" href="xxx.css" />
- </head>
- <body>
- <div id="root"><!-- page content --></div>
- <script src="xxx/filterXss.min.js"></script>
- <script src="xxx/x.chunk.js"></script>
- <script src="xxx/main.chunk.js"></script>
- </body>
- </html>
可以看到頁(yè)面中留出一個(gè)用于填充渲染內(nèi)容的視圖節(jié)點(diǎn) (div#root)，并插入指向項(xiàng)目編譯壓縮后的 JS Bundle 文件的 script 節(jié)點(diǎn)和指向 CSS 文件的 link.stylesheet 節(jié)點(diǎn)等。
瀏覽器接收到這樣的文檔響應(yīng)之后，會(huì)根據(jù)文檔內(nèi)的鏈接加載腳本與樣式資源，并完成以下幾方面主要工作：執(zhí)行腳本、進(jìn)行網(wǎng)絡(luò)訪問以獲取在線數(shù)據(jù)、使用 DOM API 更新頁(yè)面結(jié)構(gòu)、綁定交互事件、注入樣式，以此完成整個(gè)渲染過程。
2.1.2 優(yōu)劣相依
CSR 模式有以下幾方面優(yōu)點(diǎn)：
- 「UI 庫(kù)支持」：常用 UI 方案如 React、Vue，默認(rèn)的應(yīng)用形態(tài)都是 SPA (for Single Page Application)，是交互程度高、動(dòng)態(tài)化強(qiáng)的 Web 應(yīng)用，CSR 很好地滿足了這種應(yīng)用形態(tài)的需要，并在主流技術(shù)棧中擁有廣泛支持;
- 「前后端分離」：視圖交互和具體數(shù)據(jù)解耦，有賴于這種應(yīng)用形態(tài)的出現(xiàn)和普及，做到前后端職能清晰明確，更容易維護(hù)與協(xié)作;
- 「服務(wù)器負(fù)擔(dān)輕」：從示例可見，CSR 場(chǎng)景下的頁(yè)面托管服務(wù)只需要對(duì)訪問請(qǐng)求返回一個(gè)每次部署后固定的空白頁(yè)，其他的資源加載和渲染交給瀏覽器完成，項(xiàng)目靜態(tài)資源(bundle、css、assets)則都是部署在 CDN 上的，服務(wù)器負(fù)擔(dān)輕、響應(yīng)快，且更利于資源的終端和 CDN 緩存;
優(yōu)劣相依，這樣的模式也具有以下缺陷：
- 「呈現(xiàn)速度受限」：基于上面特點(diǎn)，盡管更輕的服務(wù)負(fù)荷帶來了更快的訪問響應(yīng)速度，但 CSR 頁(yè)面的呈現(xiàn)速度和效果容易受到限制——用戶瀏覽器拿到模板 HTML 之后對(duì)文檔和 JS 代碼的解析耗時(shí)、邏輯執(zhí)行耗時(shí)、接口請(qǐng)求耗時(shí)、加載靜態(tài)資源工作對(duì) CDN 情況、網(wǎng)絡(luò)環(huán)境、終端瀏覽器性能的依賴，都能很大程度上影響甚至阻塞頁(yè)面渲染，破壞用戶體驗(yàn);
- 「不利于 SEO (for Search Engine Optimization)」：爬蟲請(qǐng)求 CSR 的頁(yè)面時(shí)會(huì)受限從服務(wù)器得到不含內(nèi)容的空頁(yè)面，不利于站點(diǎn)在搜索引擎上的信息采集和曝光(但現(xiàn)在頭牌搜索引擎如谷歌、百度、必應(yīng)等，其爬蟲能力已經(jīng)可以部分支持 CSR SPA 的頁(yè)面內(nèi)容爬取)。在非常動(dòng)態(tài)的、交互性很強(qiáng)而輕實(shí)際內(nèi)容的情景下，SEO 友好程度或許并不重要——即使重要，也有部分解決方法，如結(jié)合 meta / template 插入一些重要信息，還有后面將會(huì)提到的 SSG;
- 「*較低的安全性」：了解到的一個(gè)論調(diào)是 CSR 場(chǎng)景下，頁(yè)面更容易受到 XSS (for Cross-Site Scripting) 攻擊，通過發(fā)掘頁(yè)面內(nèi)可以干預(yù)邏輯代碼的入口，劫持用戶的會(huì)話并進(jìn)行惡意操作。CSR 在此方面相對(duì)安全性較低的一個(gè)考慮點(diǎn)，或許是有更多的邏輯代碼需要在瀏覽器上直接運(yùn)行并可見，讓不懷好意者更有可乘之機(jī)——但在如今越來越多的安全工具、瀏覽器安全部署、代碼混淆方案背景下，魔與道孰高孰低其實(shí)一直在較量之中。
2.2 SSR for Server Side Rendering
“事物的發(fā)展是螺旋上升的。”
2.2.1 啥是 SSR?
SSR 的概念，即與 CSR 相對(duì)地，在服務(wù)端完成大部分渲染工作，其實(shí)這就是一開始還沒有如今的前端的時(shí)候，頁(yè)面的呈現(xiàn)方式——服務(wù)器在響應(yīng)站點(diǎn)訪問請(qǐng)求的時(shí)候，就已經(jīng)渲染好可供呈現(xiàn)的頁(yè)面。但不同于刀耕火種時(shí)代通過后端模板之類方案生成頁(yè)面，如今的 SSR 能力已經(jīng)越來越強(qiáng)大，部分情況下甚至能做到“開發(fā)者低感知”的狀態(tài)——開發(fā) SSR 與 CSR 項(xiàng)目并沒有太多不同(如廠內(nèi)框架 Jupiter 的 SSR 支持)。這有賴于社區(qū)生態(tài)的發(fā)展，上面提到 CSR 的框架/類庫(kù)(當(dāng)然還有沒提到，筆者本身也很少實(shí)踐的 Angular、Svelte 等)，都有非常優(yōu)秀的 SSR 方案。
2.2.2 簡(jiǎn)述原理
— “在服務(wù)端完成頁(yè)面渲染，豈不是要在服務(wù)端模擬一個(gè)瀏覽器?”
— “是，但不完全是。”
像 React、Vue 這樣的 UI 生態(tài)巨頭，其實(shí)都有一個(gè)關(guān)鍵的 Virtual DOM (or VDOM) 概念——瀏覽器 DOM API 太慢，先自己建模處理視圖表現(xiàn)與更新、再批量調(diào) DOM API 完成視圖渲染更新。這就帶來了一種 SSR 方案：
VDOM 是自建模型，是一種抽象的嵌套數(shù)據(jù)結(jié)構(gòu)，也就可以在 Node 環(huán)境(或者說一切服務(wù)端環(huán)境)下跑起來，把原來的視圖代碼拿來在服務(wù)端跑，通過 VDOM 維護(hù)，再在最后拼接好字符串作為頁(yè)面響應(yīng)，生成文檔作為響應(yīng)頁(yè)面，此時(shí)的頁(yè)面內(nèi)容已經(jīng)基本生成完畢，把邏輯代碼、樣式代碼附上，則可以實(shí)現(xiàn)完整的、可呈現(xiàn)頁(yè)面的響應(yīng)。
在此基礎(chǔ)上，另外對(duì)于一些需要在客戶端激活的內(nèi)容，如 Vue 實(shí)例接管組件行為、React Effect 在客戶端的觸發(fā)執(zhí)行，則由編譯時(shí)生成 Bundle，并在響應(yīng)頁(yè)面內(nèi)的超鏈接腳本額外附著。
2.2.3 先揚(yáng)后抑
SSR 方案發(fā)展在 CSR 之后再次得到推進(jìn)，很大程度上就是為了解決 CSR 的一些問題，這也是 SSR 相較之下突出的優(yōu)勢(shì)：
- 「呈現(xiàn)速度和用戶體驗(yàn)佳」：SSR 對(duì)比 CSR，少了很多頁(yè)面到達(dá)瀏覽器之后的解析、資源加載、邏輯代碼執(zhí)行的過程，用戶拿到響應(yīng)內(nèi)容后，這份內(nèi)容基本已經(jīng)是可以呈現(xiàn)的頁(yè)面，首屏?xí)r間大大縮短;
- 「SEO 友好」：SSR 服務(wù)對(duì)于站點(diǎn)訪問請(qǐng)求響應(yīng)的是填充過的頁(yè)面，其中已經(jīng)有許多站點(diǎn)信息和數(shù)據(jù)可供爬蟲直接識(shí)別，搜索引擎優(yōu)化自不必說;
- 老規(guī)矩，先揚(yáng)后抑。優(yōu)勢(shì)之上，SSR 也帶來了一些局限：
- 「引入成本高」：SSR 方案重新將視圖渲染的工作交給了服務(wù)器做，這就引入了新的概念和技術(shù)棧(如 Node)，并且?guī)砹烁叩姆?wù)器硬件成本和運(yùn)維成本;
- 「響應(yīng)時(shí)間長(zhǎng)」：對(duì)比 CSR 只需要響應(yīng)早已準(zhǔn)備好的空頁(yè)面，SSR 在完成訪問響應(yīng)的時(shí)候需要做更多的計(jì)算和生成工作，因此其請(qǐng)求響應(yīng)時(shí)間更長(zhǎng)，同時(shí)還受限于前置數(shù)據(jù)接口的響應(yīng)速度，一項(xiàng)關(guān)鍵指標(biāo) TTFB (Time To First Byte) 將變得更大;
- 「首屏交互不佳」：又是那句話，“SSR 的用戶啟動(dòng)體驗(yàn)好，但不完全好”。雖然 SSR 可以讓頁(yè)面請(qǐng)求響應(yīng)后更快在瀏覽器上渲染出來，但在首幀出現(xiàn)，需要客戶端加載激活的邏輯代碼(如事件綁定)還沒有初始化完畢的時(shí)候，其實(shí)是不可交互的狀態(tài)，同樣影響用戶體驗(yàn);
- 「?jìng)鹘y(tǒng)開發(fā)思路受限」：斟酌之下還是將其列出作為 SSR 的局限性，既然主要頁(yè)面內(nèi)容是在服務(wù)端完成渲染的，那么對(duì)于瀏覽器(或者 Hybrid、Webview 之下的宿主)環(huán)境的獲知和相關(guān)操作就會(huì)受到局限，一些操作不得不延遲到客戶端激活之后才得以進(jìn)行，這也是導(dǎo)致上一個(gè)局限點(diǎn)的原因。
2.2.4 SPR for Serverless Pre-Rendering
無服務(wù)預(yù)渲染，這是 Serverless 話題之下的一項(xiàng)渲染技術(shù)。SPR 是指在 SSR 架構(gòu)下通過預(yù)渲染與緩存能力，將部分頁(yè)面轉(zhuǎn)化為靜態(tài)頁(yè)面，以避免其在服務(wù)器接收到請(qǐng)求的時(shí)候頻繁被渲染的能力，同時(shí)一些框架還支持設(shè)置靜態(tài)資源過期時(shí)間，以確保這部分“靜態(tài)頁(yè)面”也能有一定的即時(shí)性。
這是對(duì) SSR 服務(wù)運(yùn)行計(jì)算成本高、服務(wù)負(fù)載大的一種針對(duì)性優(yōu)化，如今也已經(jīng)有不少前沿框架支持，開發(fā)者可以非常方便地引入。
2.3 SSG for Static Site Generation
某種形式上的縫合怪 —— but in a good way.
2.3.1 啥是 SSG?
說它是縫合怪，是因?yàn)樗c CSR 一樣，只需要頁(yè)面托管，不需要真正編寫并部署服務(wù)端，頁(yè)面資源在編譯完成部署之前就已經(jīng)確定;但它又與 SSR 一樣，屬于一種 Prerender 預(yù)渲染操作，即在用戶瀏覽器得到頁(yè)面響應(yīng)之前，頁(yè)面內(nèi)容和結(jié)構(gòu)就已經(jīng)渲染好了。當(dāng)然形式和特征來看，它更接近 SSR。
如果說 CSR 與 Prerender 差異在于渲染工作重心的抉擇，同是 Prerender 的 SSR 和 SSG 則是渲染——或者是這其中非常重要的“注水”——填充內(nèi)容操作在時(shí)機(jī)上的抉擇。
又或者從另一個(gè)角度來說，不同于把大部分渲染工作留到請(qǐng)求時(shí)做的 CSR 和 SSR，SSG 在站點(diǎn)項(xiàng)目構(gòu)建部署的時(shí)候，就把頁(yè)面內(nèi)容大致填充好了。
最終 SSG 模式的有點(diǎn)真正“返璞歸真”的意思，原本日益動(dòng)態(tài)化、交互性增強(qiáng)的頁(yè)面，變成了大部分已經(jīng)填充好，托管在頁(yè)面服務(wù) / CDN 上的靜態(tài)頁(yè)面。
2.3.2 平衡得夠好嗎?
SSG 兼收了傳統(tǒng) CSR 和 SSR 的優(yōu)點(diǎn)的同時(shí)，對(duì)這兩者的短板也做到較好的互補(bǔ)。服務(wù)負(fù)擔(dān)低、加載性能與體驗(yàn)佳、SEO 友好，這些 SSG 的取各家之長(zhǎng)的優(yōu)勢(shì)此處不必單獨(dú)分析，但還有一些好處源自這個(gè)模式本身：
頁(yè)面內(nèi)容都是靜態(tài)生成過的，頁(yè)面部署只需要簡(jiǎn)單的頁(yè)面托管服務(wù)器，甚至只需要放在 CDN 之上，大量減少了動(dòng)態(tài)性，還有服務(wù)器對(duì)頁(yè)面加載、渲染工作的干預(yù)，也就讓惡意攻擊少了很多可乘之機(jī);
SSG 的不足之處也值得提出來討論：
隨著應(yīng)用的拓展和復(fù)雜化，預(yù)渲染頁(yè)面的數(shù)量增長(zhǎng)速度很快。SSG 項(xiàng)目有較高的構(gòu)建和部署開銷，應(yīng)用越復(fù)雜，需要構(gòu)建出來的靜態(tài)頁(yè)面就會(huì)越多，對(duì)于功能豐富的大型站點(diǎn)，每次構(gòu)建需要渲染成千上萬個(gè)頁(yè)面都是有可能的，這必然帶來較高的部署、更新成本;
高度靜態(tài)化帶來非即時(shí)性，用戶訪問到的頁(yè)面內(nèi) SSG 生成的部分，確保有效性的時(shí)間節(jié)點(diǎn)是上一次構(gòu)建，使該模式下的應(yīng)用失去了部分時(shí)效性，這部分缺陷需要通過定時(shí)構(gòu)建、或者部分非 SSG 來彌補(bǔ)，這也是 SSG 的主要問題。
2.4 BTW
既然說到了，那就說一說。
還有一些 XXR，并不是 CSR / SSR 那樣的大陣營(yíng)或整體方案，而是一些性能策略、優(yōu)化手段，同時(shí)還依賴更大架構(gòu)下的技術(shù)能力支持，這里羅列并簡(jiǎn)單介紹。
2.4.1 NSR for Native Side Rendering *
Native 就是客戶端，萬物皆可分布式，可以理解為這就是一種分布式的 SSR，不過這里的渲染工作交給了客戶端去做而不是遠(yuǎn)端服務(wù)器。在用戶即將訪問頁(yè)面的上級(jí)頁(yè)面預(yù)取頁(yè)面數(shù)據(jù)，由客戶端緩存 HTML 結(jié)構(gòu)，以達(dá)到用戶真正訪問時(shí)快速響應(yīng)的效果。
NSR 見于各種移動(dòng)端 + Webview 的 Hybrid 場(chǎng)景，是需要頁(yè)面與客戶端研發(fā)協(xié)作的一種優(yōu)化手段。
2.4.2 ESR for Edge Side Rendering *
Edge 就是邊緣，類比前面的各種 XSR，ESR 就是將渲染工作交給邊緣服務(wù)器節(jié)點(diǎn)，常見的就是 CDN 的邊緣節(jié)點(diǎn)。這個(gè)方案主打的是邊緣節(jié)點(diǎn)相比核心服務(wù)器與用戶的距離優(yōu)勢(shì)，利用了 CDN 分級(jí)緩存的概念，渲染和內(nèi)容填充也可以是分級(jí)進(jìn)行并緩存下來的。
ESR 之下靜態(tài)內(nèi)容與動(dòng)態(tài)內(nèi)容是分流的，邊緣 CDN 節(jié)點(diǎn)可以將靜態(tài)頁(yè)面內(nèi)容先響應(yīng)給用戶，然后再自己發(fā)起動(dòng)態(tài)內(nèi)容請(qǐng)求，得到核心服務(wù)器響應(yīng)之后再返回給用戶，是在大型網(wǎng)絡(luò)架構(gòu)下非常極致的一種優(yōu)化，但這也就依賴更龐大的技術(shù)基建體系了。
2.4.3 ISR for Incremental Site Rendering
直譯，增量式網(wǎng)站渲染。也很好理解，就是對(duì)待頁(yè)面內(nèi)容小刀切，有更細(xì)的差異化渲染粒度，能漸進(jìn)、分層地進(jìn)行渲染。常見的選擇是：對(duì)于重要頁(yè)面如首屏、訪問量較大的直接落地頁(yè)，進(jìn)行預(yù)渲染并添加緩存，保證最佳的訪問性能;對(duì)于次要頁(yè)面，則確保有兜底內(nèi)容可以即時(shí) fallback，再將其實(shí)時(shí)數(shù)據(jù)的渲染留到 CSR 層次完成，同時(shí)觸發(fā)異步緩存更新。
對(duì)于“異步緩存更新”，則需要提到一個(gè)常見的內(nèi)容緩存策略：Stale While Revalidate，CDN 對(duì)于數(shù)據(jù)請(qǐng)求始終首先響應(yīng)緩存內(nèi)容，如果這份內(nèi)容已經(jīng)過期，則在響應(yīng)之后再觸發(fā)異步更新——這也是對(duì)于次要元素或頁(yè)面的緩存處理方式。
基于此，CDN 做的事情是直接響應(yīng)用戶的每個(gè)請(qǐng)求，并在用戶觸發(fā) fallback、當(dāng)前預(yù)渲染過的頁(yè)面過期失效且再次被用戶訪問的時(shí)候更新緩存的預(yù)渲染資源;客戶端在感知上則有以下不好的體驗(yàn)：
- 訪問到?jīng)]被預(yù)渲染過的次要內(nèi)容觸發(fā) fallback，需要進(jìn)行 CSR，加載較慢;
- 訪問到之前被預(yù)渲染過，但已經(jīng)過期且未更新的頁(yè)面，會(huì)先得到過期的緩存響應(yīng)，在觸發(fā) CDN 異步緩存更新之后再次訪問才能得到新資源，造成體驗(yàn)上的前后不一致。
2.4.4 DPR for Distributed Persistent Rendering
DPR 是一家云計(jì)算公司 Netlify 在幾個(gè)月前 (2021/04) 才發(fā)出的一個(gè) 「新提案」(https://github.com/jamstack/jamstack.org/discussions/549)，它是基于 ISR 基本模型的一種升級(jí)，也是針對(duì) ISR 在即時(shí)性上的不足的優(yōu)化。
看過定義和提案之后我對(duì) DPR 的譯名斟酌不定，大概是“分布式持續(xù)/持久化渲染”，因?yàn)槠淅昧?CDN 分布節(jié)點(diǎn)進(jìn)行渲染請(qǐng)求——分布(而且渲染時(shí)機(jī)也是分布在構(gòu)建 / 請(qǐng)求時(shí)的);又是一個(gè)按需漸進(jìn)的過程——持續(xù);同時(shí)在 CDN 基礎(chǔ)上架設(shè)了緩存能力——持久化。
這聽起來在分布式方面跟上面剛剛說到的 NSR 有點(diǎn)像，又跟 ESR 很接近，實(shí)際上這里的分布式跟前者完全不同，但與 ESR 確實(shí)有很多相似之處，甚至可以說是其升級(jí)版本。這里借用提案中的圖簡(jiǎn)單介紹：
左邊虛線框是構(gòu)建過程，中間 DPR functions 可以是一些 Serverless 的或是在核心頁(yè)面服務(wù)器上的按需構(gòu)建函數(shù)，然后是 CDN 緩存節(jié)點(diǎn)，最后到用戶瀏覽器。
Build 階段就會(huì)完成 generate site 的操作，這一步并不會(huì)完成所有構(gòu)建，而只生成關(guān)鍵部分的資源，部署到頁(yè)面托管服務(wù)或者 CDN 之上;而對(duì)于其他內(nèi)容，有一個(gè)按需處理的過程—— CDN 會(huì)在收到首個(gè)訪問請(qǐng)求的時(shí)候?qū)崟r(shí)要求構(gòu)建，并將最新構(gòu)建結(jié)果返回給用戶，同時(shí)將這部分內(nèi)容加入原有緩存資源中;緩存的資源也會(huì)在下一次構(gòu)建更新的時(shí)候被失效。
三、如何選擇
— 現(xiàn)在我選眼花了 😵💫
這些方案并非完全并列，較難完全“分支化決策”，這里列出幾個(gè)考慮中的關(guān)注點(diǎn)：
特性關(guān)注點(diǎn)：
是否關(guān)注 SEO
- 是：需要 Pre-Render，純 CSR 不可取
- 否：無限制
是否具有豐富可交互性、需要用戶能力、差異化渲染
- 是：CSR 較方便、SSR 加載快
- 否：Pre-Render 系列保證加載體驗(yàn)
頁(yè)面結(jié)構(gòu) & 路由是否復(fù)雜、數(shù)據(jù)更新是否頻繁、是否依賴實(shí)時(shí)數(shù)據(jù)接口
- 是：首先排除 SSG、如果內(nèi)容不能拆解，ISR、DPR 也不便接入
- 否：無限制
依賴關(guān)注點(diǎn)：
是否接受引入服務(wù)器運(yùn)維成本
- 是：無限制，SSR 可沖
- 否：失去 SSR 選項(xiàng)
舊有實(shí)現(xiàn)中是否有瀏覽器依賴如 UI 框架內(nèi)對(duì) DOM、BOM，或 Hybrid 場(chǎng)景下的 JSBridge 的使用
- 是：SSR、SSG 受限
- 否：無限制
以上考慮點(diǎn)都不產(chǎn)生限制，那就選用優(yōu)缺點(diǎn)最能滿足項(xiàng)目特征的、有比較完備的技術(shù)基建支持的模式吧～
本文轉(zhuǎn)載自微信公眾號(hào)「Tecvan」
