HTMX Sucks
Based on The PrimeTime's video on YouTube. If you like this content, support the original creators by watching, liking and subscribing to their content.
Critics say HTMX’s implementation is shipped as a single, JavaScript-heavy file with older patterns and global namespace side effects, which they view as poor separation of concerns.
Briefing
HTMX is being attacked less for its core idea—using HTML to trigger browser behavior—and more for how it’s packaged: a single-file, JavaScript-heavy approach with minimal modern tooling, limited ecosystem support, and design choices that critics say blur separation of concerns and invite security mistakes. The central claim is that HTMX’s “hypermedia” pitch is mostly rebranding, while the practical tradeoffs (code organization, build workflow, component availability, and scaling) make it a poor default choice for serious web development.
A major line of criticism targets the library’s implementation style. HTMX is described as “one big ball of JavaScript,” relying heavily on older JavaScript patterns (like `var`), polluting the global `window` namespace, and avoiding modular structure. Critics also point to the lack of a conventional build step—arguing that modern tooling (with examples like Vite) improves consistency, maintainability, and developer experience. Even where HTMX appears to “do without” TypeScript, the complaint is that the project resists TypeScript despite its benefits for large codebases, debugging, and source maps; the response is framed as belated patchwork (adding JSDoc annotations later) rather than an upfront commitment to modern development practices.
Beyond code style, the critique expands into ecosystem and product fit. HTMX is portrayed as lacking the component ecosystem that React developers can draw on immediately—UI libraries and ready-made component systems—forcing teams to assemble UI building blocks themselves and integrate them via events. That gap matters because building common UI (like carousels) becomes more work than it would be in a component-first framework.
Security is another recurring objection. Critics argue that HTMX’s design encourages behavior embedded in markup, which can increase exposure to cross-site scripting (XSS) if developers mishandle sanitization. The counterpoint—“if the backend doesn’t sanitize, you’re already doomed”—doesn’t fully land with the critics, who treat XSS as a common, preventable class of mistakes that frameworks shouldn’t make easier.
Career and adoption incentives also enter the debate. With far more job postings for React than HTMX, critics say HTMX knowledge carries less labor-market upside. They also argue that HTMX’s model may not scale cleanly as applications grow, because component-based approaches keep logic compartmentalized and testable.
Finally, the attack broadens into personality and community signals: the library’s creator is portrayed as unprofessional or overly provocative online, and HTMX’s meme-friendly branding is treated as a mismatch for a serious engineering tool. Still, the transcript ends with a more nuanced concession: HTMX may be a good fit for internal tools and situations where the “HTMX usage” is limited to loading the library and letting it attach behavior to the DOM, rather than building full application architectures around it.
Cornell Notes
The transcript argues that HTMX’s biggest weaknesses aren’t just technical—they’re practical tradeoffs in code organization, tooling, ecosystem support, and risk profile. Critics say the project’s implementation leans on older JavaScript patterns, avoids modular structure, and uses ad hoc build scripts rather than standard tooling. They also claim HTMX lacks a mature component ecosystem compared with React, making larger UI work more manual. Security concerns center on how HTMX can encourage behavior in markup, potentially increasing XSS exposure when sanitization is imperfect. Despite the harsh tone, the transcript suggests HTMX can still succeed for internal tools and limited, targeted use cases.
Why do critics focus so much on HTMX’s code style and build workflow?
What is the argument about TypeScript—does not using it make HTMX worse?
How do critics compare HTMX to React in terms of UI components and developer effort?
What security concern is raised, and how is it justified?
Why does the transcript bring up job market data?
Where does the transcript soften its stance on HTMX?
Review Questions
- Which specific implementation choices (file structure, JavaScript patterns, namespace usage, build approach) does the transcript cite as evidence of HTMX’s maintainability problems?
- How does the transcript connect HTMX’s markup-driven behavior model to the XSS risk argument?
- What practical adoption factors—ecosystem components, scaling concerns, and job market availability—are used to argue against HTMX as a default choice?
Key Points
- 1
Critics say HTMX’s implementation is shipped as a single, JavaScript-heavy file with older patterns and global namespace side effects, which they view as poor separation of concerns.
- 2
The lack of a standard build pipeline is framed as a developer-experience and maintainability drawback, even if ad hoc scripts exist.
- 3
Skepticism about TypeScript centers on the belief that modern tooling (including source maps) should be adopted upfront rather than patched in later via JSDoc.
- 4
HTMX is portrayed as lacking a mature component ecosystem, increasing the effort required to build and integrate UI compared with React’s library landscape.
- 5
Security objections focus on XSS exposure when behavior is embedded in markup and sanitization is imperfect, even though backend validation is still essential.
- 6
Career and hiring incentives are used as a practical argument: React skills have far more job postings than HTMX skills.
- 7
The transcript’s more balanced takeaway is that HTMX may work well for internal tools and limited, targeted use rather than as a full-scale application architecture.