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

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

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

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

庫和框架的區(qū)別

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

“框架”是一個口語術(shù)語——對于某些第三方代碼從“庫”演變?yōu)椤翱蚣堋钡某潭葲]有硬性規(guī)定——但我們?nèi)匀粦搰L試定義它。在這種情況下：

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

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

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

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

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

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

htmx（通常）是一個框架

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

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

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

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

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

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

htmx 用于編寫 HTML

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

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

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

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

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

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

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

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

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

圖片

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