HTMX da mucho que hablar, a menudo reducido a «lo que evita React». Es perderse lo esencial. Volvamos a su origen, a la idea, a lo que cambia de verdad — y a lo que prepara la v4.
De dónde viene HTMX
HTMX es el sucesor directo de intercooler.js, una biblioteca nacida a principios de los años 2010 que ya añadía AJAX declarativo al HTML — pero dependía de jQuery. Reescrito desde cero, sin ninguna dependencia, se convirtió en htmx. El proyecto está liderado por Big Sky Software (Carson Gross y su equipo), orgullosamente «made in Montana».
El resultado cabe en una sola línea de script: unos 10 KB minificados y comprimidos, cero dependencias. Lo añades a una página existente sin build, sin bundler, sin ecosistema que aprender.
El porqué: ¿y si el HTML hiciera más?
HTMX parte de cuatro preguntas muy simples sobre los límites del HTML nativo: ¿por qué solo <a> y <form> pueden emitir una petición? ¿Por qué solo con un clic o un envío? ¿Por qué únicamente en GET o POST? ¿Y por qué reemplazar la página entera?
Al levantar estas cuatro restricciones, htmx «completa» el HTML como hipertexto: cualquier elemento puede disparar una petición, en cualquier evento, con cualquier método HTTP, y reemplazar solo un fragmento de la página.
Qué aporta HTMX
En concreto, htmx añade unos pocos atributos: hx-get/hx-post (la petición), hx-trigger (el evento), hx-target (dónde inyectar) y hx-swap (cómo inyectar).
<button hx-post="/clicked" hx-swap="outerHTML">
Haz clic
</button>Al hacer clic, el botón envía un POST a /clicked y se reemplaza por la respuesta. Ni una línea de JavaScript. Sobre todo: el servidor devuelve HTML, no JSON. Sin serialización, sin lógica de visualización que duplicar entre el back y el front.
Su lugar: las aplicaciones hypermedia
HTMX no es solo un truco: es una forma de pensar, la aplicación dirigida por hipermedia (HDA). El servidor sigue siendo la fuente de la verdad y devuelve fragmentos de HTML; el cliente se limita a mostrarlos. Para la microinteractividad puramente local (toggles, dropdowns), espolvoreamos un poco de JS — Alpine.js encaja perfectamente. La obra de referencia, Hypermedia Systems, detalla este enfoque (gratis en línea).
HTMX no reemplaza todo. Para una aplicación muy stateful del lado cliente (editor en tiempo real, canvas, juego), un framework JS sigue teniendo sentido. Pero para un sitio de contenido, un back-office, un dashboard o un CRUD — la inmensa mayoría de la web — la pregunta merece hacerse.
HTMX 2 vs HTMX 4: qué cambia
La v4 está en obras (en four.htmx.org). No es un lavado de cara: moderniza el motor y endurece varios comportamientos por defecto. Visión de conjunto:
| Tema | HTMX 2 | HTMX 4 |
|---|---|---|
| Transporte HTTP | XMLHttpRequest | fetch() nativo |
| Herencia de atributos | implícita por defecto | explícita vía :inherited |
| Respuestas 4xx / 5xx | no swappeadas | swappeadas por defecto |
| Estrategias de swap | estándar | + innerMorph / outerMorph, textContent, delete |
| Multi-destino | <...> hx-swap-oob | + <hx-partial> |
| Por código HTTP | config global | hx-status por código |
| Transiciones de vista | vía extensión | nativo (opt-in) |
| Timeout por defecto | ninguno | 60 s |
| Eventos | htmx:afterSwap… | htmx:after:swap (phase:action) |
| Extensiones | atributo hx-ext | script incluido directamente |
Algunos puntos merecen tu atención. El paso a fetch() es definitivo (imposible de revertir). La herencia de atributos se vuelve explícita: ahora hay que añadir :inherited para que un atributo descienda por el árbol DOM. Y sobre todo, las respuestas 4xx/5xx ahora se swappean: si tu servidor devuelve HTML con un 422 o un 500, ese HTML se inserta en el destino. Te toca diseñar tus páginas de error en consecuencia, o usar el nuevo atributo hx-status.
<form hx-post="/save"
hx-status:422="swap:innerHTML target:#errors"
hx-status:5xx="swap:none">
<!-- campos -->
</form>La v4 también aporta swaps morph (algoritmo idiomorph: innerMorph/outerMorph) que preservan el estado del DOM, el elemento <hx-partial> para apuntar a varias zonas desde una sola respuesta, las transiciones de vista nativas (opt-in), y un timeout de 60 s por defecto. Los eventos se renombran siguiendo un esquema coherente htmx:phase:action (p. ej. htmx:afterSwap pasa a ser htmx:after:swap).
Buena noticia para la migración: dos líneas de configuración — o la extensión htmx-2-compat — restauran el comportamiento de la v2, y una herramienta de línea de comandos (upgrade-check) escanea tus plantillas para listar lo que debe cambiar.
<script>
htmx.config.implicitInheritance = true;
htmx.config.noSwap = [204, 304, '4xx', '5xx'];
</script>¿Qué hacer con HTMX?
Los casos de uso más naturales: la búsqueda en vivo, la paginación / el scroll infinito, los formularios validados en el servidor, los dashboards refrescados sin recarga, la edición inline (CRUD), la carga perezosa de fragmentos y las modales. Aquí un ejemplo de búsqueda instantánea:
<input type="search" name="q"
hx-get="/recherche"
hx-trigger="input changed delay:300ms"
hx-target="#resultats">
<div id="resultats"></div>En nuestro caso, en Punky Tools (CodeIgniter 4), htmx es la columna vertebral del admin y de las interfaces de estadísticas: devolvemos fragmentos Blade, htmx los inserta, Alpine gestiona la microinteractividad. Cero recargas, cero estado de cliente que mantener — y código que releemos sin sudar.
El mejor framework JavaScript es a veces el que no tienes que escribir.