</> Htmx – The Fetch()ening

• htmx 4.0 es una gran reconstrucción que reemplaza por completo la arquitectura existente basada en XMLHttpRequest por una estructura asíncrona centrada en fetch()
• El método de herencia de atributos cambia de implícito a una declaración explícita con :inherited, mejorando la claridad del código y su mantenibilidad
• La caché de historial se simplifica: en lugar de guardar snapshots locales, ahora usa una restauración basada en solicitudes de red, lo que refuerza la estabilidad
• Varias funciones nuevas como respuestas en streaming, SSE, DOM morphing, la etiqueta <partial> y la cola de View Transition se integran al core
• A largo plazo, apunta a una simplificación del código base y una mejor extensibilidad, y también se seguirá dando soporte a los usuarios de 2.0

---

Resumen de htmx 4.0

• htmx 4.0 reescribe por completo la estructura existente e incorpora la experiencia de desarrollo de fixi.js y cinco años de lecciones de mantenimiento
• Los cambios principales se resumen en tres puntos clave: migración a fetch(), explicitación de la herencia de atributos y simplificación de la caché de historial

The fetch()ening

• Se reemplaza XMLHttpRequest por fetch() para modernizar la infraestructura Ajax
  • En la mayoría de los casos de uso no habrá un gran impacto, pero el modelo de eventos cambia según la naturaleza asíncrona de fetch()
• Esta transición sienta la base para simplificar el código y ampliar funciones a futuro

Herencia explícita de atributos

• En lugar de la herencia implícita anterior, ahora se declara explícitamente con el modificador :inherited
  • Ejemplo:

    <div hx-target:inherited="#output">
        <button hx-post="/up">Like</button>
        <button hx-post="/down">Dislike</button>
    </div>
    

  • Si hx-target no se declara explícitamente, los elementos hijos no lo heredarán
• Para la mayoría de los usuarios, este será el cambio de actualización más importante

Simplificación de la caché de historial

• La caché local de snapshots del DOM de htmx 2.0 era inestable por modificaciones de terceros, estados ocultos y otros factores
• En 4.0 cambia a un método de restauración mediante solicitudes de red
  • La ampliación de caché se ofrecerá como opción de activación voluntaria (opt-in)
• Esto simplifica el código base y mejora la confiabilidad del comportamiento predeterminado

Elementos que se mantienen

• La API principal sigue igual: hx-get, hx-post, hx-target, hx-boost, hx-swap, hx-trigger, etc.
• Salvo por la adición de :inherited, la mayoría de los proyectos podrán seguir funcionando con su código actual
• Se refuerzan la mantenibilidad a largo plazo y la estabilidad

Política de actualización

• Los usuarios de 2.0 necesitarán un proyecto de actualización, pero 2.0 tendrá soporte permanente
• 4.0 se distribuirá en paralelo con 2.x, y se espera el cambio a latest a inicios de 2027
• Está prevista una extensión para restaurar el comportamiento de 2.0

Resumen de funciones nuevas

Integración de respuestas en streaming y SSE

• Aprovecha el soporte de Readable Streams de fetch() para permitir reemplazos parciales del DOM
• SSE (Server Sent Events) se reintegra como función central, permitiendo actualizaciones progresivas de contenido

Morphing Swap

• Basado en el algoritmo Idiomorph, mejora la decisión de conservar o eliminar nodos al fusionar el DOM
• Los swaps morphInner y morphOuter se incluyen en el core

Soporte para la etiqueta <partial>

• Simplifica la sintaxis compleja del Out-of-band swap existente
• <partial> es un elemento de plantilla que puede usar atributos estándar como hx-target, hx-swap, etc.
• El Out-of-band swap vuelve a un reemplazo simple basado en id

Mejoras en View Transition

• Se introduce una cola de transiciones (queue) para evitar conflictos visuales
• Las transiciones CSS mantienen el enfoque actual, pero se simplifican con un runtime asíncrono
• Aún no está definido si se activará por defecto

Estabilización del orden de eventos

• La estructura asíncrona basada en fetch() facilita garantizar el orden de los eventos
• Se introduce una nueva convención de nombres para eventos:
  htmx:<phase>:<system>[:<optional-sub-action>]
  • Ejemplo: htmx:before:request

Mayor extensibilidad

• Gracias a async, se ofrecen extensiones para solicitudes anticipadas (preload) y actualizaciones optimistas (optimistic update)
• El ciclo de solicitud/respuesta/swap queda abierto a los desarrolladores de extensiones, incluso permitiendo reemplazar la implementación de fetch()
• Será posible implementar el comportamiento deseado sin hacks

Mejoras en hx-on

• Se adopta la sintaxis estandarizada hx-on:<event name>
• El soporte de API asíncrona permite hacer scripting simple del DOM

  <button hx-post="/like"
          hx-on:htmx:after:swap="await timeout('3s'); ctx.newContent[0].remove()">
      Get A Response Then Remove It 3 Seconds Later
  </button>
  

• Funciona incluso en entornos donde eval() está desactivado, aunque con algunas limitaciones

Dirección general

• htmx 4.0 busca mantener una experiencia de uso similar a la de 2.0 mientras apunta a menos bugs y mejores funciones
• Con simplificación del código, estructura explícita y extensibilidad basada en asincronía, ofrece un htmx más estable y moderno

Calendario de desarrollo

• La versión alfa (htmx@4.0.0-alpha1) ya está disponible
• El lanzamiento oficial de 4.0.0 está previsto para inicios o mediados de 2026
• El cambio a latest está previsto a inicios de 2027
• El progreso del desarrollo puede revisarse en la rama four de GitHub y en four.htmx.org

---

[GN⁺]

Opiniones en Hacker News

• Al final cambió de opinión y va a lanzar una nueva versión mayor de htmx
  Pero, para cumplir la promesa de que “no habrá 3.0”, la próxima versión se llamará htmx 4.0
  Bromea con que, técnicamente, esa forma de decirlo es correcta

  • Es una solución divertida, pero podría confundir a los usuarios, como pasó con la desaparecida PHP 6
    Quizás habría sido mejor simplemente llamarla 3.0
  • Alguien bromea con que mejor salten directo a htmx 4.1 y creen “xhtmx 1.0”
  • Dicen que da vibra de Leisure Suit Larry 4: The Missing Floppies
  • Señalan que, por suerte, nunca dijo “no habrá una tercera versión”, así que todavía había margen en la redacción

• htmx 2.0 tendrá soporte permanente, así que no habrá ninguna presión por actualizar
  En una época como la actual, donde los cambios de API son frecuentes, este enfoque merece reconocimiento

• Sienten que quienes priorizan la estabilidad a veces sacan la lección equivocada
  En lugar de meter cambios grandes de golpe, como con Python 3.0, sostienen que es mejor una estrategia de lanzamientos graduales
  Por ejemplo, introducir cambios repartidos entre 2.1, 4.0, 5.0, etc., hace todo mucho más manejable
  Recomiendan un enfoque como el de Django, manteniendo etapas de compatibilidad a lo largo de varias versiones

• Les parece confusa la descripción del atributo hx-target
  “inherited” suena menos natural que “inheritable” o “inherit”

  • Uno comenta que lo entendió como “lo hereda el hijo”, y propone que algo como “pass-down” podría ser más claro
  • Otro dice que “inherited” es la palabra equivocada y que “inherit” es corta y funciona bien
    En broma, agrega que también podría ser “bequeath”
  • Responden que están considerando varias expresiones y que están abiertos a sugerencias
  • También aparecen alternativas como “heritable” o “cascade”

• Les gustan la idea de HTMX y la filosofía de Hypermedia
  Pero, al salir del mundo SPA, eligieron Datastar porque sienten que ofrece más escalabilidad por la inversión de aprendizaje
  Empujaron señales directamente del servidor al navegador y eliminaron el código de polling, reduciendo mucho la complejidad
  También quitaron la dependencia de Alpine.js, lo que simplificó el código, y las actualizaciones completas de vista basadas en streaming funcionan eficientemente gracias a la compresión
  Si vienes de un entorno SPA, recomiendan probar tanto Datastar como HTMX

• Les parece interesante el cambio a fetch() para aprovechar Readable Stream
  Han usado mucho HTMX, pero últimamente prefieren Datastar por su streaming basado en SSE

• Aunque celebran la evolución de HTMX, sienten que Datastar ofrece una API más alineada con los estándares y más flexible
  Dicen que en un paquete pequeño incluye Fetch, SSE, señales declarativas, DOM morphing y varias funciones más
  Por eso plantean la pregunta: “¿por qué usar HTMX?”

  • Señalan que Datastar Pro no es open source, lo que introduce un riesgo de confianza
  • Mencionan la ironía de que el creador de Datastar antes intentó incorporar este tipo de funciones en HTMX
  • Explican que la fortaleza de HTMX está en su interfaz simple, optimizada para el paradigma de solicitud/respuesta
    Datastar está más centrado en flujos de eventos, así que encaja bien para dashboards en tiempo real o juegos, pero para la mayoría de las web apps la simplicidad de HTMX resulta más ventajosa
    Referencias relacionadas: ensayo de Datastar, Less HTMX is More
  • Dicen que HTMX facilita el manejo del historial de URL en el navegador, mientras que Datastar dejó esa función como algo de pago (Pro)

• Cuestionan que, después de decir que era “tan perfecto que ya no habría más versiones mayores”, ahora hayan reconocido la necesidad de evolucionar
  Citan la parte de “ahora vamos a cambiar el estándar de nombres de eventos”, con tono de sátira hacia el intento de evitar JavaScript

  • Se burlan diciendo que, al final, por evitar usar JavaScript terminaron interpretando una sintaxis personalizada con JS
    Aun así, reconocen que poder expresar la intención en HTML tiene valor
  • Alguien lanza la broma de que “esta vez sí será la última versión”
  • Otro lo toma de forma positiva: “igual sigue siendo mejor que escribir JavaScript directamente”
  • También señalan que no tiene nada de malo que el autor haya cambiado de opinión, y cuestionan el tono crítico

• Dicen que el texto es muy claro y que permitió aprender bastante sobre la filosofía de diseño de APIs

• Crearon xhr-fetch-proxy para usar fetch junto con HTMX,
  y creen que este cambio abrirá todavía más posibilidades
  Enlace del proyecto

  • En 4.0, el ciclo de solicitud queda completamente abierto, así que se podrá reemplazar la implementación de fetch en cada request
    Agregan que aprendieron esa idea de fixi.js