¿Es htmx solo otro framework de JavaScript?
Que htmx deba verse como una biblioteca ligera de JavaScript, un framework completo o incluso un “polyfill de HTML del futuro” plantea preguntas más amplias sobre cómo construimos interfaces web modernas. Los comentaristas contrastan el modelo centrado en hipertexto, sin build y renderizado en servidor de htmx con las SPAs al estilo React y las pesadas cadenas de herramientas con bundlers, debatiendo compensaciones en complejidad, gestión de dependencias, rendimiento y estructura de equipos. Muchos ven htmx como una forma pragmática de mantener la mayor parte de la lógica en el backend y reducir JavaScript, aunque señalan que es más adecuado para ciertas clases de aplicaciones y que no es probable que reemplace pronto a los frameworks SPA dominantes en las grandes organizaciones.
Qué es htmx: biblioteca vs framework
- Debate en curso sobre las definiciones: algunos ven htmx como una biblioteca (así lo llama HTML), otros como un framework (gestiona un event loop y llama a tu código).
- Varios comentaristas rechazan la tradicional “tú llamas a una biblioteca; un framework te llama a ti” por considerarla demasiado difusa, citando confusiones similares con React, Spring, Rails, etc.
- Surge una definición pragmática: las bibliotecas son más fáciles de sustituir; los frameworks impregnan toda la base de código y son difíciles de reemplazar. Bajo ese معیار, algunos sostienen que htmx se comporta como un framework.
Modelo centrado en hipertexto
- htmx generaliza los “controles de hipermedia” ya existentes en HTML (enlaces y formularios) a cualquier elemento, permitiendo solicitudes HTTP declarativas e intercambios parciales del DOM.
- Muchos usuarios valoran mantener la mayor parte de la lógica en el backend, devolver HTML en lugar de JSON y evitar la duplicación de estado entre cliente y servidor.
- Algunos ven htmx como una prueba de concepto para clientes de hipermedia más ricos y flujos de trabajo “sin build”.
Comparación con SPAs y herramientas de JS
- Fuerte crítica al ecosistema moderno de JS/NPM: explosión de dependencias, actualizaciones frágiles, cambios rotos frecuentes, canalizaciones de build complejas.
- htmx resulta atractivo como una forma de:
- Evitar o minimizar bundlers/transpiladores.
- Mantener la UI más simple para herramientas internas y aplicaciones CRUD.
- Obtener interactividad “tipo SPA” con HTML renderizado en el servidor.
- Otros argumentan que, con el bloqueo y las herramientas adecuadas, TypeScript/React pueden ser estables, y que la complejidad suele venir del mal uso, no del stack en sí.
Limitaciones, preocupaciones sobre DSL y vías de escape
- Los críticos señalan el bajo “techo de expresividad” de la configuración basada en atributos y la aparición de mini-DSLs (por ejemplo, la sintaxis compleja de
hx-trigger) y lenguajes complementarios. - Preocupa que, a medida que crecen los requisitos, los equipos añadan más JS, lo que lleva a spaghetti y, finalmente, a migrar a frameworks SPA completos.
- Los partidarios responden que:
- htmx opera deliberadamente en un nivel de potencia limitado; cuando las necesidades superan eso, hay que añadir scripting de forma consciente o cambiar de herramienta.
- Se compone razonablemente bien con AlpineJS o similares para el estado del lado del cliente.
Adopción, organización y casos de uso
- Puntos óptimos reportados: herramientas internas, paneles de administración, aplicaciones de intranet, sitios con interactividad moderada; especialmente donde los desarrolladores backend controlan tanto los datos como la UI.
- Algunos señalan un uso limitado en grandes empresas impulsadas por beneficio, atribuyéndolo a:
- Inversiones existentes en React/SPAs.
- La división entre equipos especializados de frontend y backend.
- Hay debate sobre si htmx (o sus ideas) influirá en los estándares de HTML; varios son pesimistas respecto a una estandarización a corto plazo.