使用傳統伺服器端渲染 (SSR) 建立 Web 應用程式，或者換句話說，建立 超媒體驅動應用程式 (HDA)，相較於使用 React 等單頁應用程式框架建立 Web 應用程式，需要思維模式的轉換。
如果您以開發 SPA 的思維來進行這種開發風格，您可能會感到沮喪，並且錯失此特定架構選擇的許多優勢。
這裡有 10 個訣竅，可幫助您順利地進行思維轉換，利用此方法的優勢並盡量減少其缺點
超媒體驅動方法的一大優勢在於，它使伺服器端環境在建立 Web 應用程式時變得更加重要。您的後端不再只是產生 JSON，而是成為 Web 應用程式使用者體驗中不可或缺的元件。
因此，深入了解伺服器端可用的功能是有意義的。許多較舊的 Web 框架在產生 HTML 方面都有非常深入的功能。諸如 伺服器端快取 之類的功能可以決定 Web 應用程式是否反應迅速，還是使用者體驗遲緩。
花時間學習所有可用的工具。
一個好的經驗法則是，讓應用程式中的回應在 100 毫秒內完成，而成熟的伺服器端框架具有可協助實現此目標的工具。
伺服器端環境通常具有非常成熟的機制來正確地分解（或組織）您的程式碼。 模型/視圖/控制器 模式在大多數環境中都已完善，而模組、套件等工具則提供了組織程式碼的絕佳方式。
SPAs 的使用者介面通常透過元件來組織，而超媒體驅動應用程式通常透過範本包含來組織，其中伺服器端範本會根據應用程式的 HTML 呈現需求進行分解，然後根據需要彼此包含。這往往會產生比基於元件的應用程式更少、更大型的檔案。
另一個要尋找的技術是 範本片段，它允許您僅呈現範本檔案的一部分。這可以進一步減少伺服器端應用程式所需的範本檔案數量。
與 JSON API 不同，您為超媒體驅動應用程式產生的超媒體 API 應該具有專門針對您特定應用程式 UI 需求的端點。
由於超媒體 API 並非設計為供通用客戶端使用，因此您可以拋開讓它們保持通用的壓力，並產生特定應用程式所需的內容。
您的端點應針對您特定應用程式的 UI/UX 需求進行最佳化，而不是針對您的網域模型的一般用途資料存取模型。
一個相關的訣竅是，當您擁有基於超媒體的 API 時，您可以積極重構您的 API，這種方式在編寫基於 JSON API 的 SPA 時是不鼓勵的。由於基於超媒體的應用程式使用 超媒體作為應用程式狀態引擎，因此您可以並且實際上鼓勵您隨著應用程式開發人員和使用案例的變化而改變它們的形狀。
超媒體方法的一大優勢在於，您可以隨著時間的推移完全重新設計 API 以適應新的需求，而無需對 API 進行版本控制，甚至不需要記錄它。
當使用 SPA 方法建立應用程式時，資料儲存區通常位於 JSON API 後面。這種間接層級通常會阻止前端開發人員充分利用資料儲存區中可用的工具。 GraphQL 可以協助解決此問題，但會帶來許多開發人員似乎不太了解的安全性相關問題。
另一方面，當您在伺服器端產生 HTML 時，建立該 HTML 的開發人員可以完全存取資料儲存區，並利用 SQL 儲存區中的 聯結 和 聚合函數 等功能。
這將更具表現力的力量直接放在產生 HTML 的開發人員手中。由於您的超媒體 API 可以根據您的 UI 需求進行結構化，因此您可以調整每個端點以發出盡可能少的資料儲存區請求。
一個好的經驗法則是，每個請求都應盡量讓三次或更少的資料儲存區存取。
對話框在當今的許多 Web 應用程式中已變得流行，幾乎是標準配備。
不幸的是，對話框與 Web 的許多基礎架構不太相容，並且會引入難以（儘管並非不可能）與基於超媒體的方法乾淨地整合的用戶端狀態。
請考慮使用 內嵌編輯等替代方案，而不是使用對話框。
許多 SPA 開發人員在接觸 HDA 方法時面臨的一個問題是，他們會查看目前的 SPA 應用程式，並想像使用超媒體完全實作它。雖然 htmx 和其他面向超媒體的函式庫顯著縮小了基於超媒體的應用程式與 SPA 之間的互動差距，但這個差距仍然存在。
正如 Roy Fielding 在談到 Web 的 RESTful 網路架構時 所說
不過，折衷方案是統一介面會降低效率，因為資訊是以標準化的形式傳輸，而不是以特定於應用程式需求的形式傳輸。
接受對於特定 UX 而言效率稍低且互動性稍差的解決方案，可以在建立 Web 應用程式時為您節省大量的 複雜性。
不要讓完美成為好的敵人。
在您的 Web 應用程式中的某個時候，可能會出現超媒體方法本身無法解決的問題。
一個很好的例子是重新排序一個項目列表。這可以在「純」超媒體中完成，方法是按一下向上和向下箭頭或在項目旁邊顯示排序#下拉式選單。（我很慚愧地承認我建了這兩種！）
但是，這種體驗與人們習慣的拖放相比，真是糟透了。
在這種情況下，完全可以使用前端密集的方法作為「互動島嶼」。
請考慮 SortableJS 範例。在這裡，您有一個複雜的互動區域，允許拖放，並透過事件與 htmx 和更廣泛的超媒體驅動應用程式整合。
這是將更豐富的 UX 封裝在 HDA 中的絕佳方式。
編寫指令碼 明確是 Web 架構的一部分，採用超媒體方法的開發人員不應害怕使用它。當然，有編寫指令碼和編寫指令碼之分。
您應盡可能嘗試使用 超媒體友好的編寫指令碼方法，保留超媒體交換作為與伺服器通訊系統狀態變化的主要機制。
內嵌式指令碼（例如 alpine.js 和 hyperscript 所啟用的）也值得探索，因為它將您的指令碼重新聚焦於超媒體 (HTML) 本身，並對您可以編寫的程式碼數量施加了美學約束。
最後，不要教條地使用超媒體。歸根究底，它只是一種具有自身優勢和劣勢的技術。如果應用程式的某個特定部分或整個應用程式需要比超媒體所能提供的更具互動性的功能，那麼請使用可以提供的技術。
只需熟悉 超媒體可以做的事情，以便您可以作為知情的開發人員做出該決定。
希望這些訣竅可以幫助您更有效、更順利地採用超媒體和伺服器端渲染作為工具。它不是一個完美的用戶端-伺服器架構，它涉及明確的權衡，但它可以對許多 Web 應用程式非常有效（遠遠超過當今大多數 Web 開發人員所懷疑的），並且在這些情況下提供了更簡單的整體開發體驗。