Htmx y Web Components: una combinación perfecta

Artículo original ↗ Discusión en Hacker News ↗

HTMX y Web Components están atrayendo un interés renovado como alternativa más simple a los frameworks pesados de aplicaciones de una sola página, al devolver más lógica al servidor y dejar que fragmentos de HTML impulsen la interactividad. Quienes lo defienden destacan una gestión de estado más sencilla, menos modelos duplicados entre cliente y servidor, y un buen encaje para apps CRUD o con mucho contenido, mientras que los escépticos cuestionan la escalabilidad, los casos de uso complejos y la ergonomía de un HTML cargado de atributos—especialmente combinado con CSS utility-first como Tailwind. Gran parte del debate gira en torno a las concesiones entre experiencia de desarrollo, mantenibilidad a largo plazo y elegir el nivel adecuado de JavaScript para cada proyecto.

Sinergia entre HTMX + Web Components y problemas de ciclo de vida

  • Muchos ven HTMX y Web Components como complementarios: los componentes se inicializan por sí mismos cuando se adjuntan al DOM, lo que los hace fáciles de “AJAX-izar”.
  • Patrones prácticos: etiquetas personalizadas como <my-modal> que envuelven HTML normal, con JS pequeño para listeners y atributos.
  • Se señalaron problemas de ciclo de vida: los componentes padre pueden necesitar acceso a elementos personalizados hijo antes de que estén conectados. Se discutieron estas soluciones:
    • Que los hijos se registren a sí mismos en los padres.
    • Usar CustomEvent con bubbling, slotchange, MutationObserver o whenDefined.
  • Algunos argumentan que la composición de web components es limitada sin un framework, ya que los atributos se basan en cadenas y compartir un estado más rico resulta incómodo.

HTMX: beneficios, límites y preguntas de arquitectura

  • A quienes lo usan les gusta que HTMX recupera las UIs guiadas por el servidor: menos JS, sin modelos duplicados en cliente y servidor, apps CRUD más simples, y “diversión como en 2007 pero con CI/CD moderno”.
  • Se elogia para apps pequeñas y medianas, con mucho contenido, donde la complejidad de una SPA completa no está justificada. Muchos informan que escriben mucho menos JS, usándolo solo para casos límite.
  • Los escépticos lo ven como unir fragmentos HTML de una forma que recuerda a viejas apps MVC que acabaron siendo inmantenibles. Algunos prefieren incrustar pequeños widgets SPA en su lugar.
  • Preocupa la necesidad de endpoints separados para HTML (HTMX) y APIs JSON; otros sostienen que separar la UI y las APIs de integración es saludable.
  • Siguen abiertas preguntas sobre:
    • Escalar a bases de código muy grandes; se citan pocas implementaciones grandes de HTMX documentadas públicamente.
    • SEO y comportamiento de rastreadores con respuestas HTML parciales (no hay consenso claro en el hilo).

Frameworks SPA vs enfoques hipermedia

  • Varios comparan experiencias: proyectos en React/Angular descritos como lentos para iterar, con gestión de estado dolorosa (stores globales, reducers, prop drilling), aunque otros dicen que eso es un problema de arquitectura, no del framework.
  • Algunos enfatizan que la mayoría de las apps reales son pequeñas; los stacks SPA y el JS pesado se ven como excesivos para formularios y tablas básicas que HTMX puede manejar con renderizado en el servidor.
  • Otros subrayan que las SPAs siguen sobresaliendo en UIs complejas, muy interactivas, tipo “webapp”, y en estado global compartido; HTMX se considera una mala opción ahí.

Tailwind, CSS y “estilos inline reinventados”

  • Fuerte división:
    • A favor de Tailwind: creación de UI más rápida, escalas consistentes para espaciado/colores, fácil de leer/actualizar en un solo lugar, genial para equipos y sistemas de diseño, a menudo menos CSS en total.
    • En contra de Tailwind: el HTML se vuelve ruidoso, una “sopa de clases”, mantenimiento más difícil a largo plazo, pérdida de nombres de clase semánticos y del aprendizaje tradicional de CSS, se siente como estilos inline glorificados.
  • Algunos lo mitigan con bibliotecas de componentes (Bootstrap, daisyUI), bibliotecas de CSS atómico (UnoCSS, open-props), o mezclando utilidades de Tailwind con clases personalizadas.
  • El debate continúa sobre si el enfoque “parecido a estilos inline” de Tailwind es un retroceso o una abstracción pragmática.