術語伺服器端渲染（SSR）經常被誤解，許多人用它來描述早於其創建或技術上不合格的實踐。從 PHP 模板到 React 的同構應用程序，SSR 的定義不斷發展，圍繞它的混亂也隨之而來。
本文深入探討了 SSR 的起源、它的真正意義，以及為什麼理解其差異在現代 Web 開發中很重要。
在 PHP 時代我們還沒有 SSR。這個詞不存在。它創建於 2010 年代。在此之前沒有人稱這個東西為SSR。
他們叫它什麼？如果您相信維基百科，它被稱為伺服器端腳本（與客戶端腳本相對）。
有趣的事實：如果你查看維基百科，他們甚至沒有在 2021 年之前將“SSR”添加到 伺服器端腳本 文章中。以下是差異。老實說？我認為這是錯誤的。
在 React 引入「渲染」這個術語之前，我們沒有使用過這個詞。我們擁有的最接近的東西是伺服器端模板。這是一張舊快照。
這個想法很簡單：您可以使用靜態網站產生器或伺服器腳本來建立動態網頁。
有些人爭論道：「好吧，如果我使用伺服器模板，我就會在伺服器上渲染它們。」
React 中的渲染並不總是意味著會產生 HTML 或 DOM。它產生 VDOM （虛擬 DOM）。當您呼叫 renderToString 時，線條會變得模糊，因為元件實際上會呈現為 HTML。
這就是為什麼人們開始聲稱他們的 PHP 應用程式正在執行 SSR。但問題是：這失去了實際 SSR 和常規動態腳本之間的差異。
您只能對也可以在客戶端渲染的部分進行 SSR。
例如：
您可以執行此應用程式兩次：一次在伺服器上，一次在客戶端上。
但是：
這不能在客戶端運作。這裡沒有渲染——沒有「客戶端」或「伺服器端」的區別。這只是老式的動態腳本。
由於沒有人再使用這些舊術語（也許在ASP 中除外），我想我要放棄並稱之為伺服器渲染(SR) 與伺服器端渲染( SSR）。
一個巨大的差別是保濕。
在 PHP 世界裡，沒有水合，但他們仍然確信自己有 SSR。這沒有道理。只有補充水分才能獲得SSR。
React 有兩個關鍵方法：
Angular Universal 直到 2023 年才擁有 SSR。他們擁有的是 SR：在伺服器上產生 HTML，然後在腳本載入後將其丟棄，並將應用程式作為 SPA 渲染到空的
中。標籤。這和 PHP 不一樣，但也跟真正的 SSR 不一樣。
早期，React 應用程式使用無頭 Chrome 進行“預先渲染”，將其儲存為 HTML 字串。該快照進入 CDN。從技術上講，甚至不需要伺服器來完成這項工作。 ？
這是一項毫無意義的努力，但Google曾經推薦它用於搜尋引擎優化。我曾經找到那篇文章，但我不確定是否可以再次找到它。
React 伺服器元件 (RSC) 迫使我們重新檢視這個主題。
從技術上來說，RSC 不做 SSR。這讓很多人感到驚訝。
React 團隊嘗試解釋它但放棄了。重點是伺服器元件只是模板－它們產生靜態 HTML。客戶端元件透過 SSR 產生 HTML 和 DOM。
Inertia.js 也做了類似的區分。 PHP 在伺服器上運行，但您的 JavaScript 應用程式透過在伺服器上運行以產生 HTML，然後在客戶端上進行水化來獲得 SSR。
不。與 RSC 一樣，PHP 正在使用執行 SSR 的步驟來執行動態腳本 (SR)。
如果你使用 Hono 這樣的中間件運行 React 應用程序，將一些動態程式碼注入 HTML，然後呼叫 renderToString，感覺很相似。在這兩種情況下，都是帶有 SSR 步驟的 SR。
這就是為什麼當人們聲稱「我們在 90 年代用 PHP 進行了 SSR」時，會感到很瘋狂。
每次我提起這個問題，都會有人問起SSG。我不在乎。
術語靜態站點產生（SSG）實際上早於React。 SSG 意味著產生 HTML — 無需渲染或水合作用。你製作了 HTML 嗎？恭喜，您正在執行 SSG。
React 框架引入了同構應用程式，使用水合作用在客戶端採用 HTML，而無需重新建立它。
HTML 必須由 SSR 產生。
Qwik 可以補水嗎？這是個大問題。
Qwik 開發人員說“不”，但我傾向於“是”。如果您喜歡 Qwik，則需要砍掉另一塊 SSR 並將其命名為 Resumability。
如果你喜歡聽討論而不是閱讀，你可以從這個關於 Go 中的 React 伺服器元件的播客節目中以音頻形式聽到更多這些論點
以上是大多數人對 SSR 一詞的誤解是什麼的詳細內容。更多資訊請關注PHP中文網其他相關文章！
