爲什麼你應該選擇 HTMX 作爲你的下一個基於網路的副項目，而不是選擇復雜的 MPA 和麻煩的 SPA

我建立了很多副項目，因此我總是尋找能夠讓我以類似質量更快、更便宜地構建它們的技術和範式。在過去的幾個月裏，我一直在嘗試使用低 JS 工具如 HTM 和 Alpine 來構建 web 應用程序。

在這篇文章中，我將分享爲什麼我認爲HTMX是更快、更便宜地構建網路應用程序的一個不錯選擇，以及它爲什麼現在成爲我的技術堆棧的核心部分 - HAM Stack。

MPA 與 SPA
MPA 與 SPA

多頁面應用 (MPA)
一開始我們有多頁面應用 (MPA)。

每個網址都會跳轉到一個網頁
該網頁在服務器端渲染並發送回用戶
如果您需要更新頁面上的某些內容(因爲用戶更改了某些內容或需要刷新)那麼整個頁面需要重新加載
這很好用，但它給人一種非常緩慢/笨重的感覺，因爲每次頁面上的一件事發生變化時，你都需要重新加載所有內容。舉個例子——想想一個州政府網站，許多這些網站仍然是老派的多頁面應用，與大多數現代應用相比，它們顯得陳舊和笨重。

MPA的優缺點

優點：簡單構建
缺點：由於刷新，感覺緩慢而笨拙
單頁應用(SPA)
爲了解決這個問題，單頁面應用(SPA)被創建。

一個URL加載了一個包含大量應用邏輯的大型JS負載
這個JS接管頁面渲染
它使用內部狀態來確定頁面應該是什麼樣子，並在後臺進行數據傳輸，因此只需要更新需要更改的頁面部分。
這對用戶來說感覺更好，因爲變化感覺更快。頁面只在需要的地方更新，我們不需要完全刷新頁面來更改數據。今天大多數應用程序/網站都是這樣，因爲這通常提供更好的用戶體驗。

優點：豐富的“現代”用戶體驗
缺點：在大規模時復雜 - 處理數據傳輸(graphQL爲此而建立)，抽象和應用邏輯負載大小
所以一般來說：

多頁面應用 (MPA) - 容易構建，但很難獲得豐富的"現代"用戶體驗
單頁面應用 (SPA) - 構建復雜，但可以實現豐富的“現代”用戶體驗
MPA 與 HTMX 與 SPA
MPA 與 HTMX 與 SPA

圖片靈感來自u/Abhilash26在r/htmx上的分享。

HTMX已經存在了好幾年，但在過去的一年左右確實獲得了大量的關注。這種關注並非毫無根據——它通常允許你比SPA更快、更便宜地構建現代網頁應用。

HTMX 本質上擴展了 HTML，使其能夠進行部分頁面重載。

任何元素都可以指定如何檢索最新數據以及何時進行檢索
該元素可以指定如何處理新數據 - 替換自身或頁面上的其他元素
如果我們回顧一下MPA與SPA的比較，我們可以看到，缺乏部分頁面重新加載確實是阻礙MPA發展的主要因素。因此，將此功能添加到MPA中在很大程度上使您能夠獲取SPA的大部分豐富的“現代”用戶體驗，同時保持MPA的復雜性水平。

HTMX用於副項目
側項目的目標往往只是構建這個東西。你可能沒有一支工程師團隊或一大筆風險投資資金來實現這一點——只有你和你的電腦。

因此，降低建設成本 - 無論是時間還是金錢 - 對於使一個副項目成功至關重要。

在我看來，HTMX 提供了一個很好的平衡，讓你可以以非常低的復雜性構建現代應用(，從而節省時間和金錢成本)。因此，它已成爲我技術棧的核心部分——HAM Stack。

下一步
Md Saidur Rahman