Htmx and Web Components: A Perfect Match

Original Article ↗ Hacker News Discussion ↗

HTMX and Web Components are drawing renewed interest as a simpler alternative to heavyweight single-page app frameworks, by pushing more logic back to the server and letting HTML fragments drive interactivity. Supporters highlight easier state management, less duplicated client/server models, and good fit for CRUD-style or content-heavy apps, while skeptics question scalability, complex use cases, and the ergonomics of attribute-heavy HTML—especially when combined with utility-first CSS like Tailwind. Much of the debate centers on trade-offs between developer experience, long-term maintainability, and choosing the right level of JavaScript for a given project.

HTMX + Web Components synergy and lifecycle issues

  • Many see HTMX and Web Components as complementary: components self‑initialize when attached to the DOM, making them easy to “AJAX in”.
  • Practical patterns: custom tags like <my-modal> wrapping normal HTML, with small JS for listeners and attributes.
  • Lifecycle problems noted: parent components may need access to child custom elements before they are connected. Workarounds discussed:
    • Children registering themselves on parents.
    • Using CustomEvent bubbling, slotchange, MutationObserver, or whenDefined.
  • Some argue composition of web components is limited without a framework, since attributes are string-based and richer state sharing is awkward.

HTMX: benefits, limits, and architecture questions

  • Fans like that HTMX restores server‑driven UIs: less JS, no duplicate models on client and server, simpler CRUD apps, and “fun like 2007 but with modern CI/CD”.
  • It’s praised for small-to-medium, content‑heavy apps where full SPA complexity isn’t justified. Many report writing far less JS, using it only for edge cases.
  • Skeptics see it as stitching HTML fragments in a way reminiscent of old MVC apps that became unmaintainable. Some prefer embedding small SPA widgets instead.
  • Concern: needing separate endpoints for HTML (HTMX) and JSON APIs; others argue splitting UI and integration APIs is healthy.
  • Open questions remain about:
    • Scaling to very large codebases; few publicly documented big HTMX deployments are cited.
    • SEO and crawler behavior with partial HTML responses (no clear consensus in the thread).

SPA frameworks vs hypermedia approaches

  • Several compare experiences: React/Angular projects described as slow to iterate, with painful state management (global stores, reducers, prop drilling), though others say this is an architecture, not framework, problem.
  • Some emphasize most real‑world apps are small; SPA stacks and heavy JS are seen as overkill for basic forms and tables that HTMX can handle with server rendering.
  • Others stress SPAs still excel for complex, highly interactive “webapp” UIs and shared global state; HTMX is viewed as a poor fit there.

Tailwind, CSS, and “inline styles reimagined”

  • Strong split:
    • Pro‑Tailwind: faster UI building, consistent scales for spacing/colors, easy to read/update in one place, great for teams and design systems, often less CSS overall.
    • Anti‑Tailwind: HTML becomes noisy “class soup”, harder long‑term maintenance, loss of semantic class names and traditional CSS learning, feels like glorified inline styles.
  • Some mitigate with component libraries (Bootstrap, daisyUI), atomic CSS libs (UnoCSS, open‑props), or mixing Tailwind utilities with custom classes.
  • Debate continues whether Tailwind’s “inline‑style‑like” approach is a regression or a pragmatic abstraction.