在最近的前端開發技術的探討中，htmx經常成為熱議的話題。一些人批評它，認為盡管htmx批評現代前端框架過于復雜，但它自己卻似乎也是一個復雜的框架。這種看法值得我們深入思考。因為當你將任何第三方代碼引入你的項目時，無論是htmx還是其他，都意味著你需要理解并維護它，尤其是在升級的時候。所以，讓我們仔細分析一下這種批評，并探究htmx在解決它所宣稱的問題時的實際表現。

庫與框架：有何不同？

關于htmx是庫還是框架的討論，常常出現在爭論之中。有人辯稱htmx實際上是一個庫，而不是框架。但這種說法可能不太準確。

“框架”這個詞在技術上并沒有一個嚴格的定義，它和“庫”之間的界限并不是那么明顯。但我們還是可以嘗試去區分它們：

• 庫（Library）：這是一種API對應用程序其他部分影響不大的第三方代碼。
• 框架（Framework）：這種代碼的API則決定了應用程序的整體結構。

這個比喻可能會更加形象：庫就像是你添加到機器中的齒輪，而框架則像是一個你通過定制齒輪來控制的預制機器。

這種區別之所以重要，是因為它關系到代碼的可替換性。比如，一個使用了CSV解析庫的JavaScript服務可以相對容易地更換另一個CSV解析庫；但如果是使用了NextJS這樣的框架，服務可能就會在整個生命周期中依賴于NextJS，因為大量代碼都是基于與NextJS構件的交互編寫的。

因此，如果你的服務是基于某個框架構建的，它的有效壽命就與該框架的有效壽命緊密相連。如果那個框架被廢棄、不受歡迎或難以維護，那么修改你的項目就會變得越來越困難，直到最后你不得不放棄對它的修改，并可能整個項目被擱置。

這正是人們在問“htmx只是另一個JavaScript框架嗎？”時的擔憂所在。他們不希望自己投入到一個很快就會過時的系統中，就像過去很多Web開發框架那樣。

htmx：框架還是更多？

盡管社區對此存在爭議，但從我個人的角度看，htmx在大多數使用場景中顯然更接近于一個框架。當然，這也取決于你如何使用它。

當你在項目中使用htmx時，你會在HTML中包含htmx的屬性（比如hx-post，hx-target），編寫以htmx格式化數據（帶有特定請求頭）來調用的端點，并從這些端點返回htmx期望的格式化數據（帶有hx-*控制的HTML）。所有這些屬性、頭部和端點的相互作用，創建了一個通過網絡請求使元素進入和退出DOM的系統。

如果你在網站的許多網絡請求中使用htmx，那么引入htmx對項目結構的影響是顯著的，從如何構建前端標記到端點進行的數據庫查詢，htmx的加入都會對整個應用程序架構產生深遠影響。這種影響是框架式的，意味著一旦采用了htmx，就不容易被替換掉。

當然，你也可以選擇以更類似于庫的方式使用htmx，僅在網頁的某些部分添加動態功能。這就像你可以用類似庫的方式使用React，但這并不意味著React不是一個框架。實際上，很多開發者在他們的應用中使用htmx，都是在遵循htmx的框架式要求，將其作為構建超媒體應用的一個框架。

使用htmx最有效的方式是順應它的優勢。例如，你當然可以選擇發送JSON格式化的表單體，但更簡單的做法是使用
application/x-www-form-urlencoded格式，并編寫一個能接受這種格式的端點。同樣地，你也可以編寫一個跨多個不同客戶端重用的端點，但更簡單的做法是將你的數據和超媒體API分離到不同的URL。是的，htmx可以作為庫使用，但讓它成為你的框架可能會更好。

htmx的獨特優勢：HTML

盡管htmx在很多情況下被當作一個框架使用，但這并不意味著它就是“另一個JavaScript框架”。htmx最大的優勢在于它的核心是HTML。

如果你將htmx當作框架來使用，那么從一個角度來看，它確實是基于大約4000行JS實現的。但從另一個更重要的角度來看，htmx并不是：不像React、Svelte、Solid等讓你編寫JS(X)并將其轉換為HTML的框架，htmx讓你直接編寫HTML。這種方式避免了很多其他框架隨著時間推移可能帶來的維護問題。

例如，當你想升級或更改某些依賴時，如果你使用的框架與這種更改不兼容，代碼庫往往會遇到困難。Java是一個著名的例子——有無數行Java代碼因為升級Spring太難而永遠停留在Java 8。但當你使用htmx時，你不會遇到這個問題，因為htmx是一個零依賴的、客戶端加載的JavaScript文件，它不會與你的服務器依賴的任何構建過程或依賴鏈發生沖突。

另一個重要優勢是，瀏覽器直接渲染HTML，因此使用htmx時不需要任何編譯器或轉譯器。雖然許多htmx用戶喜歡用JSX來渲染API響應，但htmx與傳統的模板引擎兼容性良好，可以輕松移植到任何語言。Django和Rails在2008年就很流行，到今天仍然如此——htmx也可以與它們無縫集成。htmx的一個反復出現的主題是，它與新舊開發工具都很好地搭配，因為這些工具的共同點是HTML，而htmx正是用來編寫HTML的。

將用戶的主要工作聚焦在HTML上，而不是JS上，帶來了許多優勢。這種方式簡化了學習過程，使得開發者不必為了追隨JavaScript框架的最新趨勢而疲于奔命。無論何時

編寫你的htmx應用程序，htmx表單的行為始終與普通HTML表單的定義方式大致相同：使用<form>標簽。通過htmx添加的網絡功能，例如使用PUT請求并控制響應的去向，都是對傳統HTML表單的增強，但在驗證、輸入、標簽、自動完成等方面，你依然享受到標準<form>元素的默認行為。

更重要的是，因為htmx僅在網絡請求和DOM替換這一狹窄領域擴展了HTML，所以你編寫的大多數“htmx”代碼實際上就是普通的HTML。這意味著當你遇到可以通過原生HTML元素解決的問題時，你的代碼將更加長青。例如，當你需要一個可折疊的div時，如果沒有復雜的狀態管理機制，你可能會選擇使用<details>元素，而不是編寫復雜的JavaScript。這種方式使得學習Web開發變得更加友好，因為你的大部分知識將隨著HTML的持續有效而保持相關性。

從這個角度來看，htmx更像是JQuery而不是React（實際上，htmx的前身intercooler.js是一個JQuery擴展）。但它在JQuery的基礎上做了改進，采用了聲明式、基于HTML的接口：JQuery要求你在<script>標簽中指定AJAX行為，而htmx只需要一個簡單的hx-post屬性。

總的來說，雖然htmx可以作為一個框架使用，但它在很多方面都與傳統的JavaScript框架不同，它的這些特點使得它更加貼近Web的核心語義——HTML。并且，由于Web的向后兼容性保證，htmx將能夠從這些語義的改進中受益，而無需用戶進行額外工作。如果你想構建一個持久的網站，這些特性使得htmx成為比許多同代框架更好的選擇。

結語

通過這篇對htmx的深入探討，我們可以看到，htmx在技術上介于庫和框架之間，它強調使用HTML來驅動應用的行為，而非依賴復雜的JavaScript結構。這種方法降低了學習曲線，增強了代碼的可維護性和可移植性。對于那些尋求簡化Web開發流程、減少對復雜JavaScript框架的依賴的開發者來說，htmx提供了一個有趣且有效的選擇。

無論htmx被視為庫還是框架，其核心價值在于簡潔性和對HTML的重視，這使得它在當前的Web開發生態中占有一席之地。這也提醒我們，在追求前沿技術的同時，不應忽視基礎技術的力量。在復雜性和現代化的交錯中，找到適合自己項目的平衡點，是每個Web開發者的重要任務。