Maybe HTMX Is Bad...

HTMX’s core promise—server-driven UI updates that behave predictably—gets undermined when its implicit rules collide with real browser state and with other UI frameworks’ ideas about DOM ownership. Critics point to “inheritance” of HTMX properties as a particularly costly abstraction: it behaves like CSS inheritance, but unlike CSS it can reach across modules, creating non-local behavior that’s hard to reason about and easy to misremember (for example, some HTMX directives are inherited while others are explicitly not). The result is a workflow where developers end up overriding more and more, making inheritance feel pointless and pushing teams toward being explicit everywhere.

A second cluster of complaints targets how HTMX handles DOM replacement and request queuing. Browser-local state—such as whether a <details> element is open, whether an input/dropdown is currently expanded, or other UI state not represented in attributes—can be lost when outer HTML is replaced “wholesale.” Even when libraries try to patch around specific cases (like avoiding messing with input and details elements), the underlying model still feels brittle: replacing the wrong boundary (the element vs. its contents) can produce jarring UI behavior. On the networking side, HTMX’s default request queue behavior is described as unintuitive: requests triggered on the same queue element can cancel inflight work or otherwise drop earlier operations, which is likened to autocomplete systems that must avoid showing stale results. The criticism isn’t that cancellation exists, but that the default semantics are surprising enough to risk losing work.

The conversation widens into a broader systems problem: state synchronization. When a page mixes HTMX with React, both frameworks effectively try to manage the DOM and component state, creating “fighting” between React’s virtual DOM and the real DOM mutations caused by HTMX. That mismatch can lead to clobbered updates and confusing ownership boundaries. React’s approach to state—props, internal component state, and patterns like global state via Redux—doesn’t automatically solve the integration problem; instead, it can amplify it by spreading state logic across a tree and then requiring additional mechanisms (context, global stores) to keep everything consistent.

Still, the critique isn’t framed as “HTMX is useless.” The strongest alternative proposed is to align the architecture so the server and client behave like one system. React Server Components are offered as a direction where the server renders state and streams updates that React can reconcile, reducing the need for special bridges and potentially avoiding HTMX’s morphing and input/state edge cases. The practical takeaway is that HTMX’s strengths—server-side rendering, type-safe business logic, and avoiding client/server divergence—work best when the rest of the stack doesn’t demand client-side DOM/state control.

The thread ends with a meta-lesson about adopting new tools: developers should learn the “colloquial behavior” of a technology and adopt its vernacular rather than forcing it to match another framework’s expectations. In that light, the harshest conclusion becomes less “HTMX is bad” and more “HTMX plus React is a difficult pairing when both try to own state and DOM behavior.”