對 htmx 最常見的批評之一通常來自第一次聽說它的人，如下所示：

你抱怨現代前端框架的復雜性，但你的解決方案只是另一個復雜的前端框架。

這是一個很好的反對意見！對于你引入到項目中的任何第三方 (3P) 代碼，你都有權提出疑問。即使你沒有親自編寫 3P 代碼，但只要將其納入項目，你就必須了解它--如果你想升級它，就必須重新了解它。

讓我們將這些批評分解成其組成部分，并確定htmx在其聲稱要解決的傷害中到底有多少沉迷其中。

庫和框架的區別

一些 htmx 捍衛者向我們求助：“htmx 不是一個框架，它是一個庫。”這可能是不正確的。

“框架”是一個口語術語——對于某些第三方代碼從“庫”演變為“框架”的程度沒有硬性規定——但我們仍然應該嘗試定義它。在這種情況下：

• 庫 - 3P 代碼，其 API 不會顯著影響應用程序的其余部分
• 框架 - 3P 代碼，其 API 決定應用程序的整體結構

如果你更喜歡比喻：庫是你添加到機器上的一個齒輪，框架是一個預先構建的機器，你可以通過自定義其齒輪來控制它。

這種區別雖然可能很模糊，但很重要，因為它描述了替換某些第三方代碼的容易程度。例如，使用 CSV 解析庫的 JavaScript 服務可能可以輕松地交換不同的 CSV 解析庫；然而，使用 NextJS 框架的 JavaScript 服務可能在其整個使用壽命中都依賴于 NextJS，因為大量代碼是在假設它與 NextJS 結構交互的情況下編寫的。

因此，如果你的服務是在框架之上構建的，則其使用壽命與該框架的使用壽命相關。如果該框架被放棄，或被鄙視，或以其他方式不受歡迎，那么修改項目的難度將穩步增加，直到你放棄修改它，并最終將其完全封存。

這就是人們在問“htmx 只是另一個 JavaScript 框架嗎？”時所擔心的問題。他們希望確保自己不會致力于一個很快就會過時的系統，就像過去的許多 Web 開發框架一樣。

那么：htmx是一個框架嗎？它是否會很快被淘汰，在其迅速消亡后留下一系列無法維護的網站？

htmx（通常）是一個框架

對我們社區關于這個問題的持續爭論表示歉意——我認為 htmx 顯然是一個框架，至少在大多數用例中是這樣。但這確實取決于你如何使用它。

無論你在項目中的何處使用 htmx，你都會在 HTML 中包含 htmx 屬性（即 hx-post 、 hx-target ），編寫使用 htmx 格式數據調用的端點（使用某些請求標頭），并從這些端點返回以 htmx 期望的方式格式化的數據（帶有 hx-* 控件的 HTML）。所有這些屬性以及標頭和端點相互交互以創建一個系統，元素通過該系統通過網絡請求進入和退出 DOM。

如果你使用 htmx 來處理網站的大量網絡請求，那么在應用程序中包含 htmx 會對項目的結構產生重大影響，從構建前端標記的方式到端點進行的數據庫查詢。這是類似框架的行為，在這種情況下，htmx 不能輕易被替換。

你絕對可以以類似庫的方式使用 htmx，為網頁的幾個部分添加動態功能。但你也可以用這種類似于庫的方式編寫 React，沒有人會說 React 不是一個框架。我只想說，許多在應用程序中使用 htmx 的人都是為了滿足 htmx 的需求，將其作為構建超媒體應用程序的框架。

如果能發揮 htmx 的優勢，那么使用 htmx 構建程序的效果會更好。如果你真的堅持，可以發送 JSON 格式的表單體。但你不應該這樣做！application/x-www-form-urlencoded 格式的表單體并編寫一個可接受它們的端點會更簡單。如果你真的堅持，你可以編寫一個在多個不同客戶端之間重復使用的端點。但你不應該這樣做！將數據和超媒體 API 分離到不同的 URL 中會更簡單。是的，htmx 可以作為一個庫使用，但或許也可以讓它成為你的框架。

然而，這并不意味著 htmx 只是另一個 JavaScript 框架，因為 htmx 具有其他框架沒有的巨大優勢：HTML。

htmx 用于編寫 HTML

假設你使用 htmx 作為框架 - 它是 JavaScript 框架嗎？從一種明顯的意義上來說，是的：htmx 是用大約 4k 行 JS 實現的。但從另一個更重要的意義上來說，它不是：React、Svelte、Solid 等等，你寫的 JS(X) 框架會轉換成 HTML；htmx 只是讓你編寫 HTML。這就免去了可能會讓你放棄其他框架的各種維護工作。

當你想要升級或更改某些依賴項，但你使用的框架與該更改不兼容時，代碼庫往往會陷入困境。Java 是這里最臭名昭著的罪犯——生產中有數百萬行 Java 永遠不會離開 Java 8，因為升級 Spring 太難了——但 npm 包生態系統緊隨其后。當你使用 htmx“框架”時，你永遠不會遇到這個問題，因為 htmx 是一個零依賴、客戶端加載的 JavaScript 文件，因此保證它永遠不會與你的服務器所依賴的任何構建過程或依賴鏈發生沖突。

瀏覽器渲染 HTML，因此無需編譯器或轉譯器即可使用 htmx。雖然許多 htmx 用戶很樂意使用 JSX 渲染 API 響應，但 htmx 與經典模板引擎配合得很好，使其可移植到你喜歡的任何語言。不管你對 Django 和 Rails 有何看法，但它們在 2008 年和今天都很重要 — htmx 與它們無縫集成。這是 htmx 驅動開發的一個反復出現的主題：htmx 與新舊開發工具都能很好地配合，因為所有這些工具的共同點是 HTML，而 htmx 是用于編寫 HTML 的。

推動用戶主要通過 HTML 而不是 JS 來定義其應用程序的行為有太多優點，本文無法一一介紹，因此我將重點談談人們最痛恨的 JavaScript 成名之作：“churn”。根據你編寫 React 應用程序的時間，你可能在編寫表單時使用了受控類組件、react Hooks 或這種實驗性的 <form> 擴展。這確實讓人抓狂，尤其是如果你和我一樣，最初是通過類組件學習如何制作網絡表單的。

然而，無論你是何時編寫的 htmx 應用程序，htmx 表單的行為都是以與普通 HTML 表單大致相同的方式定義的：使用 <form>。隨著 htmx 增加了額外的網絡功能，你終于可以使用 PUT 請求并控制響應的去向，但在所有其他方面--驗證、輸入、標簽、自動完成--你都只能使用默認的 <form> 元素行為。

最后，因為 htmx 只是在一個非常狹窄的域中擴展 HTML（網絡請求和 DOM 替換），所以你編寫的大多數“htmx”只是普通的舊 HTML。當你可以訪問復雜的狀態管理機制時，實現自定義可折疊 div 變得非常容易；如果不這樣做，你可能會停下來足夠長的時間來搜索 <details> 元素。每當問題可以通過本機 HTML 元素解決時，代碼的壽命就會大大提高。這是一種學習 Web 開發的不太陌生的方式，因為只要 HTML 存在，你的大部分知識就將保持相關性。

在這方面，htmx 比 React 更像 jQuery（htmx 的前身 intercooler.js 是 jQuery 擴展），但它通過使用聲明性的、基于 HTML 的界面對 jQuery 進行了改進：jQuery 讓你轉到 <script> 標簽來指定AJAX行為，htmx只需要一個簡單的 hx-post 屬性。

簡而言之，雖然 htmx 可以用作框架，但與 JavaScript 框架相比，它與 Web 語義的偏差要小得多，并且將受益于這些語義的改進，而無需用戶進行額外的工作，這要歸功于 Web 的出色性能向后兼容性保證。如果你想建立一個持續很長時間的網站，這些品質使 htmx 成為比許多同時代網站更好的選擇。

注：盡管卡森(Carson)同意這一分析，認為這篇文章沒有邏輯缺陷，并允許我在他的網站上發表，但他仍然堅持認為 htmx 是一個庫。

圖片

原文：https://htmx.org/essays/is-htmx-another-javascript-framework/