Ocho meses de trabajo, una versión saltada y una confesión tan sincera como divertida. El equipo de htmx ha lanzado la versión 4.0.0, la primera actualización mayor de la biblioteca de hipermedia desde que la 2.0 llegara en 2024. Carson Gross, su creador, había prometido que nunca existiría un htmx 3. Al preguntarle por el salto directamente a la 4.0, respondió a InfoWorld con una sola palabra: “Oops”.
La anécdota resume el espíritu de un proyecto que, lejos de acomodarse, ha decidido reescribir sus cimientos sin traicionar su filosofía. htmx sigue siendo esa biblioteca que permite construir interfaces modernas añadiendo AJAX, transiciones CSS, WebSockets y eventos enviados por el servidor directamente al HTML mediante atributos. La diferencia es que ahora lo hace sobre una base técnica completamente renovada, más rápida, más limpia y más preparada para el futuro.
De XMLHttpRequest a fetch: el cambio que lo habilita todo
El cambio más profundo de htmx 4.0 es invisible para la mayoría de los desarrolladores, pero transforma todo lo que ocurre bajo el capó.
La biblioteca ha abandonado XMLHttpRequest, su transporte durante años, para adoptar la API fetch() moderna. Los atributos familiares como hx-get y hx-post se comportan exactamente igual que antes, pero la nueva base desbloquea capacidades que eran imposibles con el transporte anterior.
La más importante es el streaming nativo, que permite recibir y procesar respuestas del servidor de forma incremental en lugar de esperar a que llegue el cuerpo completo. Y todo ello manteniendo el script en torno a los 14 KB, una cifra que sigue siendo uno de los grandes argumentos de htmx frente a frameworks de JavaScript mucho más pesados.
Morphing swaps y hx-partial: las dos estrellas del lanzamiento
Las dos características que el equipo destaca con más entusiasmo son el morphing swap integrado y la nueva etiqueta hx-partial.
El morphing swap, impulsado por idiomorph, permite actualizar el DOM preservando su estado. Esto significa que si un usuario está escribiendo en un campo de formulario y llega una actualización desde el servidor, el foco y el contenido se mantienen intactos. Es una diferencia sutil pero enorme en la experiencia de usuario, especialmente en aplicaciones interactivas donde las actualizaciones frecuentes son la norma.
La etiqueta hx-partial resuelve un problema clásico: cómo actualizar varios objetivos del DOM con una sola respuesta del servidor. Antes esto requería la técnica de “out of band swaps”, que funcionaba pero resultaba engorrosa. Ahora, un solo fragmento de HTML puede actualizar limpiamente múltiples secciones de la página, con una sintaxis más clara y predecible.
La herencia explícita: la trampa que debes conocer
Uno de los cambios más delicados de htmx 4.0 es la forma en que funciona la herencia de atributos. Antes, un atributo colocado en un elemento padre se propagaba automáticamente a todos sus hijos. Ahora, esa propagación debe declararse explícitamente mediante el sufijo :inherited.
La razón es la claridad: la herencia implícita podía generar comportamientos inesperados y difíciles de rastrear. Pero el cambio tiene una trampa importante que los desarrolladores deben conocer. Un atributo hx-headers que pasa un token CSRF a los elementos hijos dejará de funcionar silenciosamente si no se marca con :inherited. El servidor comenzará a rechazar las peticiones con un error 403, pero nada en el cliente parecerá roto, lo que puede convertir la depuración en una pesadilla.
Es exactamente el tipo de cambio que justifica el uso de la herramienta de verificación que el equipo ha incluido: un comando de línea que analiza las plantillas y señala problemas de herencia, atributos renombrados y eventos obsoletos. Ejecutarlo antes de migrar es prácticamente obligatorio.
Eventos estandarizados y adiós al localStorage
Los nombres de los eventos también se han estandarizado bajo un patrón más coherente: htmx:fase:acción. Esto significa que htmx:afterRequest se convierte en htmx:after:request, y así sucesivamente. Es un cambio que rompe compatibilidad, pero que aporta claridad y consistencia a largo plazo.
Otra modificación significativa afecta al historial. Antes, htmx guardaba una instantánea del DOM en localStorage para restaurar el estado al navegar hacia atrás. Ahora, simplemente vuelve a solicitar la página al servidor. Aunque pueda parecer un paso atrás en términos de rendimiento, es un avance en compatibilidad: los scripts de terceros funcionan correctamente, sin los conflictos que generaba la restauración desde el almacenamiento local.
Detalles que importan: timeout, renombrados y despliegue seguro
Hay más cambios que conviene tener presentes. htmx 4.0 introduce un tiempo de espera predeterminado de 60 segundos para las peticiones, lo que evita que una petición colgada bloquee indefinidamente la interfaz. También hay renombrados de atributos, como hx-disable, que pasa a llamarse hx-ignore, más coherente con su función real.
El equipo ha sido cuidadoso con el despliegue. htmx 4.0 se publica bajo la etiqueta next de npm, no bajo latest, lo que significa que nadie que use un enlace CDN sin versión fija se actualizará automáticamente. La versión 2.x seguirá recibiendo soporte indefinidamente, lo que da a los equipos el tiempo que necesiten para migrar sin prisas.
La comunidad responde: entusiasmo, dudas y un debate que continúa
La recepción de htmx 4.0 ha sido mayoritariamente entusiasta. Un hilo en Hacker News superó los 700 puntos, con desarrolladores elogiando el stack de Go, SQLite y htmx y destacando lo bien que los asistentes de IA manejan la biblioteca. Un comentario señalaba que Claude “lo entiende y lo hace bien”, un detalle revelador en un momento en el que la compatibilidad con herramientas de IA se ha convertido en un criterio de adopción tan importante como el rendimiento o la documentación.
Sin embargo, no todos son aplausos. Un desarrollador de .NET y Angular argumentó que htmx obliga a mezclar la presentación con la lógica de negocio, y otro confirmó que su equipo está volviendo a React. Es un debate antiguo en el mundo del desarrollo web, y refleja dos filosofías opuestas: la que busca minimizar la complejidad del cliente y la que prefiere separar responsabilidades en capas bien definidas.
Un proyecto que sigue siendo referente del movimiento hipermedia
htmx 4.0 no es una revolución que rompa con el pasado, sino una evolución que refuerza los principios del movimiento hipermedia. La idea central sigue siendo la misma: construir interfaces modernas con HTML en el servidor y un mínimo de JavaScript en el cliente.
Es una filosofía que ha encontrado un hogar natural en comunidades como Django, Go y Rails, donde la renderización en servidor y la baja complejidad del cliente son valores apreciados.
Con la versión 4.0, htmx demuestra que se puede innovar sin traicionar la esencia. La migración a fetch, el morphing integrado, la etiqueta hx-partial y la herencia explícita son mejoras reales que amplían las capacidades de la biblioteca sin añadir peso innecesario. Y la decisión de mantener la 2.x con soporte indefinido es un gesto de respeto hacia una comunidad que ha confiado en el proyecto durante años.
Para quienes ya usan htmx, el mensaje es claro: hay trabajo por hacer, especialmente en lo que respecta a la herencia de atributos y los nombres de eventos. Pero las herramientas están ahí, la documentación es completa y el equipo ha demostrado que responde a las necesidades reales de los desarrolladores.
Para quienes aún no lo han probado, htmx 4.0 es una excusa perfecta para descubrir por qué una biblioteca de 14 KB puede competir con frameworks que pesan cien veces más. A veces, menos es más. Y htmx lo demuestra una versión tras otra.
Descubre más desde CIBERED
Suscríbete y recibe las últimas entradas en tu correo electrónico.
