htmx 4.0.0 ya está disponible y el cambio importante para equipos que usan htmx 2 no es aprender otra librería, sino revisar herencia de atributos, eventos, errores HTTP, extensiones y el paso interno de XMLHttpRequest a fetch().
La versión se publicó el 28 de agosto de 2026. En GitHub aparece como v4.0.0, con el release publicado “this 28 Aug 13:00”, y el anuncio oficial explica que htmx 4 llega después de ocho meses de trabajo.
También llegó con tracción inmediata entre desarrolladores. La discusión de Hacker News sobre “Htmx 4.0” estuvo en portada el 28 de agosto y, al revisar la historia durante esta nota el 29 de agosto de 2026, mostraba cientos de puntos y más de cien comentarios. Esa señal no convierte una release en buena por sí sola, pero sí confirma que el tema importa a la comunidad que usa herramientas web de bajo nivel.
El punto técnico es más concreto: htmx 4 mantiene la idea central de htmx, pero cambia varias decisiones que afectan a aplicaciones existentes.
Si ya usas htmx en producción, esta no es una noticia para leer como “salió una versión nueva”. Es una lista de migración.
¿Qué es htmx 4?
htmx 4 es la nueva versión mayor de htmx, una librería JavaScript sin dependencias que permite usar atributos HTML para hacer requests, swaps, transiciones, WebSockets y Server-Sent Events sin convertir toda la aplicación en una SPA.
La promesa sigue siendo la misma: dejar que el servidor siga produciendo HTML y que el navegador actualice partes de la página con atributos como hx-get, hx-post, hx-target o hx-swap.
Lo que cambia en htmx 4 es la base interna y varias reglas alrededor de ese modelo.
El equipo movió las requests internas desde XMLHttpRequest a la API nativa fetch(). Según la documentación de “What’s New in htmx 4”, todas las requests usan fetch() y ese cambio no se puede revertir. El anuncio dice que para la mayoría de usuarios debería ser transparente, pero también explica que esa migración abrió espacio para replantear extensiones, streaming HTML y comportamiento asíncrono.
Esa es la tensión de la release.
Para una aplicación sencilla, htmx 4 puede sentirse casi igual a htmx 2. Para una aplicación con atributos heredados, listeners JavaScript, manejo especial de errores, extensiones propias o dependencias de headers, sí hay trabajo.
¿Cómo instalar htmx 4?
Puedes instalar htmx 4 fijando la versión 4.0.0 en el gestor de paquetes o cargándolo desde un CDN con una URL versionada.
El anuncio oficial muestra este ejemplo de CDN:
<script src="https://unpkg.com/htmx.org@4.0.0/dist/htmx.min.js"></script>
También dice que htmx 4.0 puede instalarse mediante un package manager apuntando a la versión 4.0.0.
Hay una advertencia importante: htmx 4.0.0 no está marcado como latest en npm al momento de publicar esta nota. El equipo explica que no quiere forzar actualizaciones accidentales a usuarios que dependen de URLs de CDN sin versión fija. Por eso, la línea 2.x seguirá como latest y 4.0 quedará como next hasta algún punto de 2027.
Eso cambia la recomendación práctica.
No uses un snippet genérico ni una URL sin versión si estás probando la migración. Fija 4.0.0, revisa la guía de four.htmx.org y no confíes ciegamente en páginas indexadas antiguas: durante esta revisión, htmx.org/docs/ todavía mostraba ejemplos de instalación de 2.x en algunas secciones, mientras la documentación nueva de htmx 4 vive en four.htmx.org.
Para producción, además, conviene mantener el criterio habitual: descargar y servir el archivo tú mismo si tu política no permite depender de CDNs públicos.
¿Cómo migrar de htmx 2 a htmx 4?
Para migrar de htmx 2 a htmx 4, empieza por correr el upgrade-check, revisar herencia de atributos y decidir si necesitas una capa temporal de compatibilidad.
El anuncio oficial muestra este comando:
npx htmx.org@4.0.0 upgrade-check -- ./templates
La guía de migración también documenta el patrón con el canal next:
npx htmx.org@next upgrade-check -- ./path/to/project/root
Y permite agregar extensiones de archivo:
npx htmx.org@next upgrade-check --ext .vue ./path/to/project/root
La herramienta escanea plantillas y archivos JavaScript buscando señales típicas de código htmx 2: atributos removidos, nombres antiguos de eventos, patrones de herencia, cambios en extensiones y APIs eliminadas. Por defecto, la guía lista soporte para .html, .php, .js, .ts, .jinja, .jinja2, .j2, .erb y .hbs. También indica que el checker requiere Python 3.
Si necesitas reducir el riesgo mientras migras, la guía de htmx 4 documenta dos líneas de configuración para recuperar dos comportamientos de htmx 2:
<script>
htmx.config.implicitInheritance = true;
htmx.config.noSwap = [204, 304, '4xx', '5xx'];
</script>
implicitInheritance vuelve a activar la herencia implícita de atributos. noSwap evita que las respuestas 4xx y 5xx se intercambien en el DOM como contenido normal.
También existe una extensión htmx-2-compat para compatibilidad, pero trataría esa opción como puente, no como destino. Si vas a adoptar una versión mayor, lo razonable es dejar que el checker te diga qué hay que cambiar y mover el código hacia las reglas nuevas.
¿Qué cambia con la herencia de atributos en htmx 4?
El mayor cambio de migración es que htmx 4 deja de heredar atributos de forma implícita y exige marcar la herencia con el sufijo :inherited.
En htmx 2 era común poner un atributo en un contenedor y esperar que afectara a elementos internos. Por ejemplo, un hx-confirm en un padre podía cubrir botones hijos. En htmx 4, esa intención debe quedar explícita:
<!-- htmx 2 -->
<div hx-confirm="Are you sure?">
<button hx-delete="/item/1">Delete</button>
</div>
<!-- htmx 4 -->
<div hx-confirm:inherited="Are you sure?">
<button hx-delete="/item/1">Delete</button>
</div>
Esto aplica a atributos como hx-boost, hx-target, hx-confirm y otros atributos que antes podían heredarse.
El cambio parece pequeño, pero puede romper flujos importantes. Si tu aplicación depende de hx-headers para CSRF, de hx-target en wrappers, de confirmaciones colocadas a nivel de sección o de patrones heredados en layouts, la migración no debería hacerse a ojo.
La buena noticia es que el nuevo comportamiento es más legible. La mala es que te obliga a encontrar lugares donde la intención estaba implícita.
Por eso el upgrade-check no es un accesorio. Es el primer paso serio de la migración.
¿Qué pasa con los errores HTTP en htmx 4?
htmx 4 intercambia en el DOM todas las respuestas HTTP salvo 204 y 304, así que las respuestas 4xx y 5xx ahora pueden reemplazar contenido si el servidor devuelve HTML.
En htmx 2, las respuestas 400 y 500 no se intercambiaban por defecto. En htmx 4, si tu servidor devuelve una respuesta 422 con HTML de validación, ese HTML puede entrar al target. Lo mismo puede pasar con una respuesta 500 si el backend devuelve una página o fragmento que coincide con el flujo.
Esto puede ser una mejora si tu aplicación ya piensa los errores como HTML intercambiable.
También puede ser una sorpresa si tu backend devuelve páginas completas de error, trazas internas en entornos mal configurados o fragmentos que no fueron diseñados para entrar en un componente.
La guía de htmx 4 apunta a hx-status y noSwap para controlar este comportamiento por código de estado. La decisión práctica es simple: revisa cómo responden tus formularios, validaciones, expiraciones de sesión, errores de permisos y errores de servidor antes de activar 4.0 en producción.
La migración no se trata solo de que el cliente funcione. Se trata de que el contrato HTML entre servidor y navegador siga siendo deliberado.
¿Qué cambia con eventos y JavaScript en htmx 4?
htmx 4 estandariza los nombres de eventos y elimina varios eventos ligados a XMLHttpRequest, así que los listeners JavaScript son una zona de riesgo en la migración.
El anuncio muestra cambios como estos:
htmx:beforeRequest -> htmx:before:request
htmx:afterRequest -> htmx:after:request
htmx:beforeSwap -> htmx:before:swap
htmx:afterSwap -> htmx:after:swap
htmx:configRequest -> htmx:config:request
La documentación explica que los eventos ahora siguen el patrón htmx:phase:action[:sub-action]. También indica que la mayoría de eventos de error se consolidan en htmx:error, que los errores HTTP disparan htmx:response:error, que los eventos htmx:xhr:* desaparecen porque htmx 4 usa fetch(), y que los eventos de validación de htmx se eliminan a favor de la validación nativa del navegador.
Además, algunas APIs JavaScript se eliminan o se reemplazan por APIs nativas del navegador. Por ejemplo, la guía recomienda usar element.classList.add() en lugar de htmx.addClass(), element.remove() en lugar de htmx.remove(), y removeEventListener() en lugar de htmx.off().
Este es el tipo de cambio que no aparece en una demo feliz.
Si tu htmx vive principalmente en HTML, el impacto puede ser bajo. Si tu equipo integró htmx con Alpine.js, Stimulus, código propio, analytics, observabilidad, validaciones o eventos de ciclo de vida, revisa listeners y helpers con cuidado.
¿Qué pasa con WebSockets, SSE y extensiones en htmx 4?
htmx 4 vuelve más importante el sistema de extensiones: WebSockets, SSE, streaming multipart, preload, downloads, compatibilidad con Alpine y caché de historial aparecen como parte central de la nueva línea.
El anuncio destaca extensiones como:
hx-preloadpara precargar contenido.hx-downloadpara descargas nativas basadas enfetch().hx-alpine-compatpara suavizar compatibilidad entre htmx y Alpine.js.hx-history-cachepara cachear historial ensessionStorage.hx-ssepara streaming sobretext/event-stream.hx-wspara enviar y recibir por WebSockets.hx-multipartpara streaming sobremultipart/mixed.hx-livecomo una pequeña solución de scripting/reactividad integrada con htmx.
También aparece htmax.js, un bundle que empaqueta htmx junto con extensiones populares para no tener que elegir cada pieza por separado.
Pero aquí hay un cambio de modelo: la documentación de “What’s New” dice que las extensiones se incluyen directamente con scripts y ya no necesitan hx-ext para cargarse. Si quieres restringir qué extensiones pueden registrarse, la guía muestra una meta configuración:
<meta name="htmx-config" content='{"extensions": "sse, ws"}'>
Para equipos con extensiones propias, el cambio es más profundo. La guía de migración de extensiones dice que htmx 4 reemplaza el API basado en callbacks por hooks basados en eventos. La migración mínima empieza renombrando htmx.defineExtension() a htmx.registerExtension(), pero una extensión real probablemente necesite mapear callbacks antiguos a nuevos hooks.
Si tu proyecto solo consume extensiones oficiales, revisa instalación y atributos. Si mantiene extensiones internas, reserva tiempo de migración real.
¿Qué cambia con el historial en htmx 4?
htmx 4 deja de usar localStorage como caché de historial por defecto y vuelve a pedir la página al navegar hacia atrás.
El anuncio explica el motivo: el snapshot guardado en localStorage podía incluir mutaciones hechas por librerías JavaScript de terceros. Al restaurar la página, esas mutaciones quedaban en el DOM, pero la lógica JavaScript detrás no necesariamente volvía en el mismo estado.
En htmx 4, al volver en el historial, htmx vuelve a pedir la página y la intercambia en <body> o en el elemento [hx-history-elt] si existe.
Esto debería reducir una clase de bugs incómodos en aplicaciones que mezclan HTML de servidor con scripting de cliente. El costo es que el historial depende más claramente del comportamiento del servidor, de cachés HTTP y de la capacidad de recomponer la página.
Si quieres caché local, el equipo ahora apunta a la extensión hx-history-cache, que usa sessionStorage y está diseñada para convivir mejor con soluciones como Alpine.js.
Para equipos, la pregunta de migración es simple: ¿tu aplicación esperaba restauración instantánea desde localStorage, o puede volver a pedir la página sin romper estado, permisos, scroll y componentes?
¿htmx 4 reemplaza inmediatamente a htmx 2?
htmx 4 no reemplaza inmediatamente a htmx 2 para todos los proyectos, y el propio equipo está evitando un salto accidental al no marcar 4.0 como latest en npm.
El anuncio dice que htmx 2 seguirá soportado indefinidamente y que no hay presión para actualizar. Esa frase importa.
Una versión mayor recién salida no debería entrar en producción solo porque existe. Para proyectos nuevos, htmx 4 es el camino natural si quieres empezar sobre la línea actual. Para proyectos existentes en htmx 2, la pregunta no es “¿debo migrar hoy?”, sino “¿qué tan explícitos son mis contratos?”.
Revisa especialmente:
- Atributos heredados en layouts y componentes.
- Manejo de respuestas
4xxy5xx. - Listeners de eventos htmx en JavaScript.
- Uso de APIs JavaScript eliminadas.
- Dependencias de
localStoragepara historial. - Extensiones oficiales o personalizadas.
- Headers que usa tu backend o librerías de servidor.
Esa lista es el valor de la release para yoDEV: no una celebración abstracta de “menos JavaScript”, sino una guía para saber dónde mirar antes de romper una app que ya funciona.
¿Por qué htmx 4 importa para desarrolladores en Iberoamerica?
htmx 4 importa porque muestra que el stack web del servidor no está congelado: sigue ganando herramientas modernas sin rendirse por completo al modelo SPA.
Durante años, muchos equipos sintieron que la única forma seria de construir interfaces web modernas era mover más estado, más routing, más validación y más rendering al cliente. htmx empujó una alternativa: usar HTML como medio de aplicación, mantener el servidor cerca del producto y agregar interactividad donde hace falta.
htmx 4 no abandona esa tesis. La actualiza.
El paso a fetch() acomoda la base interna al navegador moderno. La herencia explícita vuelve más legibles los contratos. Los eventos estandarizados hacen más razonable integrar observabilidad y scripting. Las extensiones de streaming empujan casos donde HTML puede viajar de forma incremental. hx-partial, morph swaps y htmax.js amplían el repertorio sin convertir htmx en un framework monolítico.
La señal para equipos no es que deban reemplazar React, Vue, Svelte o cualquier otra pila. Esa discusión suele volverse religiosa demasiado rápido.
La señal útil es otra: si tu producto ya se expresa bien como HTML de servidor, htmx 4 te da una ruta moderna para seguir ahí con menos ceremonia. Y si tu equipo mantiene una aplicación htmx 2, esta release te obliga a hacer inventario técnico de las partes implícitas del sistema.
Eso es sano.
Las mejores migraciones no son las que cambian todo. Son las que descubren qué supuestos estaban escondidos.
htmx 4 trae justamente ese tipo de trabajo: pequeño en apariencia, muy concreto en impacto.