SPA 的替代方案
Carson Gross最近 Tom MacWright 寫了一些關於單頁應用程式及其不滿的文章
網路開發的新興規範是建立一個具有伺服器端渲染的 React 單頁應用程式。這種架構的兩個關鍵要素如下：
- 主要 UI 是使用 React 或類似的技術在 JavaScript 中建構和更新。
- 後端是一個應用程式請求的 API。
這個想法確實席捲了網際網路。它從一些主要的熱門網站開始，並蔓延到行銷網站和部落格等角落。
在這兩篇文章中，Tom 列出了與 React/SPA 無處不在的心態相關的問題。如果我可以用一句話總結它們：SPA 框架往往很複雜，而且在許多情況下，你並不會因為所有這些複雜性而獲得太多好處。
#替代方案
Tom 在第二篇文章中概述了 SPA 方法的一些替代方案，我很高興地說，他提到了 htmx。然而，他將 htmx（以及 Stimulus 和 Alpine.js）歸類為「漸進式增強」函式庫。這是一個很好的描述，但是，至少在 htmx 的情況下，我認為有一個更好的術語可以幫助描述這種風格的函式庫：以 HTML 為中心（或者，也許是 以超文本為中心）
#以 HTML 為中心的開發
在以 HTML 為中心的開發中，HTML 不是事後才考慮的，而是被視為應用程式開發的主要媒介。這與大多數 SPA 框架形成對比，後者以客戶端模型和操縱它的 JavaScript 為中心。
以 HTML 為中心的開發建立在網路的原始模型之上，如 Roy Fielding 的博士論文中所述，該論文描述了網路架構。特別是，通過將 HTML 作為超文本來採用，您將獲得 REST 和 HATEOAS 的好處，而無需成為這兩個主題的專家。
（回想一下，Roy 是在描述網路架構，因此原始網路在很大程度上是 REST 風格的，而原始參與者沒有做出任何特別的努力）
通過選擇以 HTML 為中心的開發，您將獲得許多好處
- 一個更簡單的前端允許您節省您的 複雜性預算，用於區分您的應用程式與其他應用程式的後端功能。
- 您不會因為「前端是用 JavaScript 寫的」而面臨在後端採用 JavaScript 的壓力。這允許您為您的特定應用程式使用最佳的後端框架。
- 使用更簡單的前端，「全端」開發人員可以更容易地管理和優化應用程式中的前端到後端優化，從而實現更好的系統調整。
- 您的 Web 應用程式無論如何都會包含 HTML，因此通過最大化其效用，您正在提升現有組件的功能，而不是在最終使用者和您的應用程式程式碼之間添加另一層複雜性。
- 網路的無狀態網路模型已被證明非常具有彈性，並且易於開發。許多成熟且經過實戰考驗的技術和方法（例如 快取）用於建構基於 HTML 的應用程式。
#HTML：不好的部分
有了以 HTML 為中心的模型的所有這些好處，人們可能會想知道為什麼它被許多網路開發人員放棄（並且經常被嘲笑）。在較高的層面上，答案是
與基於 JavaScript 的應用程式相比，以 HTML 為中心的應用程式在歷史上提供的互動性有限.
這很大程度上是因為 HTML 是一種有限的超文本。特別是
- 只有
<a>和<form>可以發出 HTTP 請求 - 只有
click和submit事件可以觸發它們 - 只有 GET 和 POST HTTP 方法被廣泛使用
- 請求必須替換整個螢幕，導致笨拙且有時令人不快的用戶體驗
當然，這些約束都不是超文本概念固有的，htmx 的目標是消除它們中的每一個。
通過消除這些約束並將 HTML 作為功能齊全且功能強大的超文本來完成，以 HTML 為中心的應用程式可以在許多應用程式領域中與 SPA 競爭，同時獲得上述技術和複雜性的好處。
#在技術上要勇敢
Tom 用這句話結束了他的第一篇文章
如果大家都錯了怎麼辦？我們以前也錯過。
網路開發已經走了不少死胡同：GWT、Java Server Faces、Angular 1、FlatUI 等。
在每項技術炒作週期的高峰期，很難逆流而上。在科技界尤其如此，在科技界，被技術拋在後面不僅是對我們自我的威脅，也是對我們工作的威脅。
「沒有人會因為使用 React 而被解僱」
是今天的
「沒有人會因為購買 IBM 而被解僱」
這是我們必須接受的現實，即使我們認為 React 等技術不適合今天正在建構的許多（甚至大多數）Web 應用程式。
然而，我們開始看到對 SPA 方法的重新思考。憑藉一點技術上的勇氣，願意與眾不同，您也許可以讓您的應用程式變得不那麼複雜，並將您的開發精力集中在您的應用程式的作用上，而不是如何作用上。
