HTMX lleva un par de años apareciendo en conferencias, hilos de opinión y charlas de pasillo como la alternativa sensata al exceso de JavaScript en el frontend. Con la versión 2.0 estable desde junio de 2024[1] y un año de rodaje en proyectos pequeños y medianos, toca dejar de mirarlo como curiosidad y evaluarlo como herramienta de empresa. Que funciona ya no está en discusión. Lo que me interesa aquí es dónde tiene sentido usarlo en una organización que ya tiene React o Angular corriendo.

Para el contexto más amplio de stacks frontend modernos, el análisis de fullstack TypeScript en 2025 describe los patrones donde HTMX compite y donde no. La elección de herramientas frontend también influye en los costes de mantenimiento a largo plazo, algo que abordamos en FinOps para infraestructura de IA.

Puntos clave

  • HTMX es una biblioteca de ~14 KB que extiende HTML para hacer peticiones al servidor desde cualquier elemento, devolviendo fragmentos HTML en lugar de JSON.

  • Encaja bien en aplicaciones internas con formularios como protagonista, sitios con SEO relevante y prototipos donde la velocidad de iteración prima.

  • No es adecuado para aplicaciones con interacción de cliente rica, requisito offline relevante o estado global complejo.

  • En empresas con React desplegado, HTMX puede ser complemento para nuevos flujos administrativos sin forzar migración.

  • El coste de mantenimiento a cinco años favorece a HTMX frente a frameworks que cambian de modelo mental cada pocos años.

Qué es y qué propone HTMX

HTMX es una biblioteca de JavaScript pequeña, alrededor de 14 kilobytes una vez comprimida según su propia documentación[2], que extiende HTML con atributos nuevos para hacer peticiones al servidor desde cualquier elemento. La idea es que el servidor devuelva fragmentos de HTML, no JSON, y que esos fragmentos se integren en la página sustituyendo partes concretas del árbol sin recargar todo.

El modelo mental es el clásico de la web antes de las aplicaciones de página única: el servidor es la fuente de verdad y el navegador muestra HTML. La novedad es que esto se puede hacer sin recargas completas, con transiciones visuales cuidadas y con mecanismos para enviar y recibir eventos que permiten patrones dinámicos sorprendentemente ricos.

Los defensores del enfoque hipermedia argumentan que una aplicación de empresa de formularios y tablas no necesita el peso conceptual de React o Vue. Formularios, tablas, flujos de trabajo con validaciones, dashboards de KPIs: estas cuatro pantallas se pueden construir con HTMX y un backend cualquiera. Quedan más simples y más rápidas de mantener que su equivalente en React.

El repositorio del proyecto en GitHub[3] acumula ya más de 40.000 estrellas y cero dependencias externas, una tracción notable para una biblioteca sin empresa detrás. Medios especializados como DevClass[4] describieron el salto a la versión 2.0 como la primera revisión mayor desde el lanzamiento de la 1.0 en noviembre de 2020.

Dónde funciona sin discusión

El caso de uso más claro son las aplicaciones internas de empresa con formularios como protagonista: sistemas de gestión, CRM internos, paneles administrativos, configuradores. En estos contextos HTMX elimina mucha ceremonia. Un botón que abre un modal deja de necesitar estado global en Redux; es simplemente un fragmento de HTML que el servidor devuelve y se inserta.

También funciona bien en aplicaciones donde la renderización en servidor es útil para SEO o rendimiento de la primera carga: páginas de listado de productos, blogs, documentación técnica, paneles públicos con autenticación ligera. HTMX aquí compite con Astro o Next.js con un coste mental mucho menor.

El tercer caso donde HTMX brilla es en prototipos y productos tempranos. Cuando el equipo es de dos o tres personas, todas conocen el backend y la presión por entregar funcionalidades es alta, HTMX permite construir experiencias dinámicas. No hace falta montar toda la infraestructura de un entorno de cliente moderno. Equipos que pasan de idea a producto desplegable en semanas usando Django o Rails junto con HTMX, con calidad visual comparable a la de un producto hecho con React, son un caso habitual.

Dónde la experiencia es mixta

El primer sitio donde empiezan las dudas son las aplicaciones con interacción compleja de cliente. Entran aquí los editores de texto enriquecido, las herramientas de diseño gráfico, los mapas interactivos donde cada elemento es seleccionable y las aplicaciones tipo Figma o Miro. Todas estas pantallas requieren lógica local compleja que tiene poco sentido delegar al servidor.

Otro punto friccional es el estado compartido entre pantallas. En HTMX cada interacción suele pasar por el servidor, y mantener estado optimista en el cliente requiere trucos como almacenar valores en elementos del DOM o usar librerías complementarias como Alpine.js. Funciona, pero el coste de coordinación crece con cada pieza añadida.

Las aplicaciones con requisito offline relevante tampoco son el hábitat natural. HTMX asume que el servidor está disponible. Si la aplicación debe funcionar sin conexión un porcentaje relevante del tiempo, un framework de cliente sigue siendo mejor opción.

Integración con arquitecturas existentes

En una empresa con React ya desplegado, HTMX no es necesariamente un reemplazo sino un complemento. Un patrón útil: mantener las pantallas complejas existentes en React y usar HTMX para los nuevos flujos administrativos o las pantallas secundarias. Esto evita riesgo de migración y permite recoger los beneficios de HTMX donde más encajan sin obligar a reescribir lo que funciona.

La integración con APIs existentes es otro asunto. HTMX espera HTML, no JSON. Si el backend actual solo expone APIs REST o GraphQL, hay que escribir una capa de plantillas que devuelva fragmentos. En arquitecturas que separaron frontend y backend hace años, esta capa hay que montarla desde cero.

El ecosistema de HTMX tampoco tiene un equivalente comparable al de React para ciertos componentes: tablas con paginación compleja, selectores múltiples, editores de texto enriquecido. Para algunos casos hay que implementar a mano o apoyarse en Alpine.js.

Sobre el coste de mantenimiento

Una ventaja que no suele aparecer en las charlas técnicas pero que pesa mucho en empresa es el coste de mantenimiento a cinco años. Los frameworks de JavaScript evolucionan rápido: React ha cambiado dos veces de modelo mental en una década, primero con hooks y luego con server components. Cada cambio obliga a reescrituras parciales. HTMX, al ser una capa fina sobre HTML, apenas cambia, y lo que se ha escrito hace tres años sigue funcionando igual hoy.

Este argumento es más fuerte de lo que parece en aplicaciones internas que rara vez se rehacen. Un sistema de facturación interna vive quince años con suerte, y cambiar de framework de cliente cada cinco es un coste recurrente. HTMX, al apoyarse en HTML, reduce esa presión.

Cuándo compensa

La conclusión tras un año de uso real es que HTMX encaja bien en tres perfiles:

  • Aplicaciones internas de empresa con formularios como protagonista, calidad visual media e interacción de cliente baja.

  • Sitios públicos con servidor como fuente de verdad, SEO relevante y pocos componentes interactivos complejos.

  • Prototipos y productos tempranos donde la velocidad de iteración prima sobre la sofisticación del cliente.

Fuera de estos tres perfiles, para aplicaciones con interacción de cliente rica o requisito offline, React o similares siguen siendo la opción sensata. Mi recomendación a equipos que me consultan es empezar por un proyecto acotado para aprender el modelo y luego decidir si ampliar. HTMX es suficientemente distinto de React para que la curva tenga algo que aprender, pero suficientemente simple para que un equipo experimentado se lo ponga en una semana.

Este artículo también está disponible en inglés: HTMX in the enterprise: where it fits and where it does not.

Fuentes:

  1. Anuncio oficial de htmx 2.0.0 en htmx.org[1]
  2. Documentación oficial de HTMX (tamaño de la biblioteca)[2]
  3. Repositorio bigskysoftware/htmx en GitHub[3]
  4. Cobertura de htmx 2.0 en DevClass, por Tim Anderson[4]

Preguntas frecuentes

¿Puedo usar HTMX si mi backend solo expone APIs REST o GraphQL?

Sí, pero con un coste: HTMX espera fragmentos de HTML, no JSON, así que tendrás que escribir una capa de plantillas que devuelva esos fragmentos. En arquitecturas que separaron frontend y backend hace años, esa capa hay que montarla desde cero. Además, el ecosistema de HTMX no tiene componentes comparables a los de React para tablas con paginación compleja, selectores múltiples o editores de texto enriquecido. Algunos hay que implementarlos a mano o con Alpine.js.

¿Tengo que migrar mi aplicación React para adoptar HTMX?

No. En una empresa con React ya desplegado, HTMX funciona como complemento: mantén las pantallas complejas existentes en React y usa HTMX para los nuevos flujos administrativos o las pantallas secundarias. Así evitas el riesgo de migración y recoges los beneficios donde más encajan. La recomendación práctica es empezar por un proyecto acotado para aprender el modelo, que un equipo experimentado asimila en una semana, y decidir después si ampliar.

¿Para qué tipo de aplicaciones no es adecuado HTMX?

Para aplicaciones con interacción de cliente rica, como editores de texto enriquecido, herramientas de diseño gráfico, mapas interactivos donde cada elemento es seleccionable o productos tipo Figma o Miro. Su lógica local tiene poco sentido delegarla al servidor. Tampoco encaja si hay un requisito offline relevante, porque HTMX asume que el servidor está disponible, ni cuando hay mucho estado compartido entre pantallas que coordinar.

Fuentes

  1. versión 2.0 estable desde junio de 2024
  2. alrededor de 14 kilobytes una vez comprimida según su propia documentación
  3. repositorio del proyecto en GitHub
  4. Medios especializados como DevClass