建站
咨詢
售后
建站咨詢
新聞中心
對 htmx 最常見的批評之一通常來自第一次聽說它的人，如下所示：
麥蓋提ssl適用于網站、小程序/APP、API接口等需要進行數據傳輸應用場景，ssl證書未來市場廣闊！成為成都創(chuàng)新互聯的ssl證書銷售渠道，可以享受市場價格4-6折優(yōu)惠！如果有意向歡迎電話聯系或者加微信：028-86922220（備注：SSL證書合作）期待與您的合作！
你抱怨現代前端框架的復雜性，但你的解決方案只是另一個復雜的前端框架。
這是一個很好的反對意見！對于你引入到項目中的任何第三方 (3P) 代碼，你都有權提出疑問。即使你沒有親自編寫 3P 代碼，但只要將其納入項目，你就必須了解它--如果你想升級它，就必須重新了解它。
讓我們將這些批評分解成其組成部分，并確定htmx在其聲稱要解決的傷害中到底有多少沉迷其中。
庫和框架的區(qū)別
一些 htmx 捍衛(wèi)者向我們求助：“htmx 不是一個框架，它是一個庫。”這可能是不正確的。
“框架”是一個口語術語——對于某些第三方代碼從“庫”演變?yōu)椤翱蚣堋钡某潭葲]有硬性規(guī)定——但我們仍然應該嘗試定義它。在這種情況下：
- 庫 - 3P 代碼，其 API 不會顯著影響應用程序的其余部分
- 框架 - 3P 代碼，其 API 決定應用程序的整體結構
如果你更喜歡比喻：庫是你添加到機器上的一個齒輪，框架是一個預先構建的機器，你可以通過自定義其齒輪來控制它。
這種區(qū)別雖然可能很模糊，但很重要，因為它描述了替換某些第三方代碼的容易程度。例如，使用 CSV 解析庫的 JavaScript 服務可能可以輕松地交換不同的 CSV 解析庫；然而，使用 NextJS 框架的 JavaScript 服務可能在其整個使用壽命中都依賴于 NextJS，因為大量代碼是在假設它與 NextJS 結構交互的情況下編寫的。
因此，如果你的服務是在框架之上構建的，則其使用壽命與該框架的使用壽命相關。如果該框架被放棄，或被鄙視，或以其他方式不受歡迎，那么修改項目的難度將穩(wěn)步增加，直到你放棄修改它，并最終將其完全封存。
這就是人們在問“htmx 只是另一個 JavaScript 框架嗎？”時所擔心的問題。他們希望確保自己不會致力于一個很快就會過時的系統(tǒng)，就像過去的許多 Web 開發(fā)框架一樣。
那么：htmx是一個框架嗎？它是否會很快被淘汰，在其迅速消亡后留下一系列無法維護的網站？
htmx（通常）是一個框架
對我們社區(qū)關于這個問題的持續(xù)爭論表示歉意——我認為 htmx 顯然是一個框架，至少在大多數用例中是這樣。但這確實取決于你如何使用它。
無論你在項目中的何處使用 htmx，你都會在 HTML 中包含 htmx 屬性（即 hx-post 、 hx-target ），編寫使用 htmx 格式數據調用的端點（使用某些請求標頭），并從這些端點返回以 htmx 期望的方式格式化的數據（帶有 hx-* 控件的 HTML）。所有這些屬性以及標頭和端點相互交互以創(chuàng)建一個系統(tǒng)，元素通過該系統(tǒng)通過網絡請求進入和退出 DOM。
如果你使用 htmx 來處理網站的大量網絡請求，那么在應用程序中包含 htmx 會對項目的結構產生重大影響，從構建前端標記的方式到端點進行的數據庫查詢。這是類似框架的行為，在這種情況下，htmx 不能輕易被替換。
你絕對可以以類似庫的方式使用 htmx，為網頁的幾個部分添加動態(tài)功能。但你也可以用這種類似于庫的方式編寫 React，沒有人會說 React 不是一個框架。我只想說，許多在應用程序中使用 htmx 的人都是為了滿足 htmx 的需求，將其作為構建超媒體應用程序的框架。
如果能發(fā)揮 htmx 的優(yōu)勢，那么使用 htmx 構建程序的效果會更好。如果你真的堅持，可以發(fā)送 JSON 格式的表單體。但你不應該這樣做！application/x-www-form-urlencoded 格式的表單體并編寫一個可接受它們的端點會更簡單。如果你真的堅持，你可以編寫一個在多個不同客戶端之間重復使用的端點。但你不應該這樣做！將數據和超媒體 API 分離到不同的 URL 中會更簡單。是的，htmx 可以作為一個庫使用，但或許也可以讓它成為你的框架。
然而，這并不意味著 htmx 只是另一個 JavaScript 框架，因為 htmx 具有其他框架沒有的巨大優(yōu)勢：HTML。
htmx 用于編寫 HTML
假設你使用 htmx 作為框架 - 它是 JavaScript 框架嗎？從一種明顯的意義上來說，是的：htmx 是用大約 4k 行 JS 實現的。但從另一個更重要的意義上來說，它不是：React、Svelte、Solid 等等，你寫的 JS(X) 框架會轉換成 HTML；htmx 只是讓你編寫 HTML。這就免去了可能會讓你放棄其他框架的各種維護工作。
當你想要升級或更改某些依賴項，但你使用的框架與該更改不兼容時，代碼庫往往會陷入困境。Java 是這里最臭名昭著的罪犯——生產中有數百萬行 Java 永遠不會離開 Java 8，因為升級 Spring 太難了——但 npm 包生態(tài)系統(tǒng)緊隨其后。當你使用 htmx“框架”時，你永遠不會遇到這個問題，因為 htmx 是一個零依賴、客戶端加載的 JavaScript 文件，因此保證它永遠不會與你的服務器所依賴的任何構建過程或依賴鏈發(fā)生沖突。
瀏覽器渲染 HTML，因此無需編譯器或轉譯器即可使用 htmx。雖然許多 htmx 用戶很樂意使用 JSX 渲染 API 響應，但 htmx 與經典模板引擎配合得很好，使其可移植到你喜歡的任何語言。不管你對 Django 和 Rails 有何看法，但它們在 2008 年和今天都很重要 — htmx 與它們無縫集成。這是 htmx 驅動開發(fā)的一個反復出現的主題：htmx 與新舊開發(fā)工具都能很好地配合，因為所有這些工具的共同點是 HTML，而 htmx 是用于編寫 HTML 的。
推動用戶主要通過 HTML 而不是 JS 來定義其應用程序的行為有太多優(yōu)點，本文無法一一介紹，因此我將重點談談人們最痛恨的 JavaScript 成名之作：“churn”。根據你編寫 React 應用程序的時間，你可能在編寫表單時使用了受控類組件、react Hooks 或這種實驗性的