</> Htmx – The Fetch()ening

• htmx 4.0 est une version de refonte majeure qui remplace entièrement l’architecture historique basée sur XMLHttpRequest par une architecture asynchrone centrée sur fetch()
• Le mode d’héritage des attributs passe d’un comportement implicite à une déclaration explicite avec :inherited, ce qui améliore la clarté du code et sa maintenabilité
• Le cache d’historique est simplifié : au lieu d’enregistrer des instantanés locaux, il repose désormais sur une restauration via requêtes réseau, pour une meilleure fiabilité
• De nombreuses nouvelles fonctionnalités sont intégrées au cœur : réponses en streaming, SSE, DOM morphing, balise <partial>, file d’attente pour View Transition, etc.
• À long terme, l’objectif est une simplification du codebase et une meilleure extensibilité, avec un support continu prévu pour les utilisateurs de la version 2.0

---

Vue d’ensemble de htmx 4.0

• htmx 4.0 réécrit entièrement son architecture et intègre à la fois l’expérience acquise avec fixi.js et cinq années d’enseignements en maintenance
• Les principaux changements se résument à trois évolutions clés : migration vers fetch(), explicitation de l’héritage des attributs et simplification du cache d’historique

The fetch()ening

• XMLHttpRequest est remplacé par fetch() afin de moderniser l’infrastructure Ajax
  • Dans la plupart des cas d’usage, l’impact sera limité, mais le modèle d’événements évolue pour s’adapter à la nature asynchrone de fetch()
• Cette transition pose les bases d’un code plus simple et d’évolutions fonctionnelles futures

Héritage explicite des attributs

• Au lieu de l’héritage implicite précédent, la déclaration devient explicite grâce au modificateur :inherited
  • Exemple :

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

  • Si hx-target n’est pas explicitement déclaré, les éléments enfants ne l’héritent pas
• Pour la plupart des utilisateurs, il s’agit du changement de compatibilité le plus important

Simplification du cache d’historique

• Le cache local d’instantanés DOM de htmx 2.0 était instable à cause des modifications par des tiers, des états cachés, etc.
• En 4.0, il est remplacé par une restauration via requêtes réseau
  • Une extension du cache sera proposée en option (opt-in)
• Cela simplifie le codebase et améliore la fiabilité du comportement par défaut

Éléments conservés

• Les API cœur comme hx-get, hx-post, hx-target, hx-boost, hx-swap, hx-trigger, etc. restent inchangées
• Hormis l’ajout de :inherited, la plupart des projets devraient continuer à fonctionner avec leur code existant
• L’objectif est de renforcer la maintenabilité à long terme et la stabilité

Politique de mise à niveau

• Les utilisateurs de la 2.0 devront mener un projet de migration, mais la 2.0 restera prise en charge de façon permanente
• La 4.0 sera publiée en parallèle de la branche 2.x, et le basculement de latest est prévu pour début 2027
• Une extension est prévue pour rétablir le comportement de la 2.0

Résumé des nouvelles fonctionnalités

Réponses en streaming et intégration de SSE

• Le support des Readable Streams de fetch() permet des remplacements partiels du DOM
• SSE (Server Sent Events) est réintégré comme fonctionnalité cœur, pour permettre une mise à jour progressive du contenu

Morphing Swap

• Basé sur l’algorithme Idiomorph, le fusionnement du DOM améliore la décision de préserver ou supprimer les nœuds
• Les swaps morphInner et morphOuter sont intégrés au cœur

Support de la balise <partial>

• La syntaxe complexe des anciens out-of-band swaps est simplifiée
• <partial> devient un élément de template pouvant utiliser des attributs standards comme hx-target, hx-swap, etc.
• Les out-of-band swaps reviennent à un remplacement simple basé sur l’id

Améliorations de View Transition

• Introduction d’une file d’attente de transitions pour éviter les conflits visuels
• Les transitions CSS conservent leur fonctionnement actuel, avec une runtime asynchrone simplifiée
• L’activation par défaut n’est pas encore décidée

Stabilisation de l’ordre des événements

• L’architecture asynchrone basée sur fetch() facilite la garantie de l’ordre des événements
• Une nouvelle convention de nommage des événements est introduite :
  htmx:<phase>:<system>[:<optional-sub-action>]
  • Exemple : htmx:before:request

Extensibilité renforcée

• Grâce à async, des extensions pour préchargement (preload) et mise à jour optimiste (optimistic update) sont proposées
• Le cycle requête/réponse/swap est ouvert aux développeurs d’extensions, avec la possibilité de remplacer l’implémentation de fetch()
• Il devient possible d’obtenir le comportement souhaité sans hack

Amélioration de hx-on

• Adoption de la syntaxe standardisée hx-on:<event name>
• Le support de l’API asynchrone permet un script DOM simple

  <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>
  

• Cela fonctionne aussi lorsque eval() est désactivé, avec toutefois certaines limitations

Orientation générale

• htmx 4.0 vise à conserver une expérience proche de la 2.0 tout en réduisant les bugs et en améliorant les fonctionnalités
• Avec un code simplifié, une structure explicite et une extensibilité asynchrone, htmx veut proposer une version plus fiable et plus moderne

Calendrier de développement

• La version alpha (htmx@4.0.0-alpha1) est déjà disponible
• La release stable 4.0.0 est prévue pour le début ou le milieu de l’année 2026
• Le passage à latest est prévu pour début 2027
• L’avancement du développement peut être suivi sur la branche GitHub four et sur four.htmx.org

---

[GN⁺]

Avis Hacker News

• Ils ont finalement changé d’avis et vont sortir une nouvelle version majeure de htmx
  Mais, pour tenir leur promesse qu’« il n’y aurait pas de 3.0 », la prochaine version sera nommée htmx 4.0
  Ils réagissent avec humour en disant que, techniquement, c’est correct

  • C’est une solution amusante, mais cela pourrait aussi semer la confusion chez les utilisateurs, comme l’ancien PHP 6 disparu
    Il aurait peut-être mieux valu assumer franchement une 3.0
  • Quelqu’un plaisante en disant qu’ils devraient directement passer à htmx 4.1 et créer « xhtmx 1.0 »
  • Certains disent que cela rappelle Leisure Suit Larry 4: The Missing Floppies
  • D’autres notent heureusement qu’ils n’avaient jamais dit qu’« il n’y aurait pas de troisième version », ce qui laisse une marge d’interprétation

• htmx 2.0 sera pris en charge de façon permanente, donc il n’y a absolument aucune pression pour migrer
  À une époque où les changements d’API sont fréquents, cette approche est jugée louable

• Certains estiment que les personnes en quête de stabilité tirent souvent les mauvaises leçons
  Plutôt que de concentrer de grands changements d’un seul coup, comme avec Python 3.0, ils défendent une stratégie de releases progressives
  Par exemple, introduire les changements via 2.1, 4.0, 5.0, etc. serait bien plus simple à gérer
  Ils recommandent une approche à la Django, en maintenant des étapes de compatibilité sur plusieurs versions

• La description de l’attribut hx-target semble confuse
  « inherited » paraît moins naturel que « inheritable » ou « inherit »

  • L’un des commentaires dit l’avoir compris comme « hérité par les enfants » et propose qu’une expression comme « pass-down » soit plus claire
  • Un autre affirme que « inherited » est le mauvais mot et que « inherit » est plus court et meilleur
    En plaisantant, il ajoute que « bequeath » pourrait aussi marcher
  • Il est dit qu’ils réfléchissent à plusieurs formulations et sont ouverts aux suggestions
  • D’autres alternatives comme « heritable » ou « cascade » sont aussi proposées

• Les idées de HTMX et la philosophie Hypermedia sont jugées excellentes
  Une personne explique avoir quitté l’univers SPA pour choisir Datastar, car le potentiel de montée en charge lui semble meilleur au regard de l’investissement d’apprentissage
  Elle envoie désormais des signaux directement du serveur vers le navigateur, ce qui a permis d’éliminer le code de polling et de fortement réduire la complexité
  La suppression de la dépendance à Alpine.js a aussi simplifié le code, et les mises à jour complètes de vues en streaming fonctionnent efficacement grâce à la compression
  Si vous venez du monde SPA, elle recommande d’essayer à la fois Datastar et HTMX

• Le passage à fetch() pour exploiter les Readable Streams est jugé intéressant
  Même après avoir beaucoup utilisé HTMX, certains préfèrent désormais Datastar pour son streaming basé sur SSE, qu’ils trouvent plus séduisant

• Tout en se réjouissant de l’évolution de HTMX, certains estiment que Datastar propose une API plus conforme aux standards et plus flexible
  Le petit package regroupe Fetch, SSE, declarative signals, DOM morphing et d’autres fonctions
  D’où la question : « pourquoi utiliser HTMX ? »

  • Il est souligné que Datastar Pro n’est pas open source, ce qui constitue un risque en matière de confiance
  • Certains relèvent l’ironie du fait que le créateur de Datastar avait autrefois essayé d’ajouter ce type de fonctionnalités à HTMX
  • Il est expliqué que la force de HTMX réside dans une interface simple, optimisée pour le paradigme requête/réponse
    Datastar, centré sur les flux d’événements, convient bien aux tableaux de bord temps réel ou aux jeux, mais pour la plupart des web apps, la simplicité de HTMX est jugée plus avantageuse
    Références associées : essai sur Datastar, Less HTMX is More
  • HTMX facilite la gestion de l’historique d’URL du navigateur, alors que Datastar aurait réservé cette fonctionnalité à l’offre payante (Pro)

• Certains pointent le fait qu’après avoir dit que c’était « parfait » et qu’il n’y aurait plus de version majeure, ils reconnaissent finalement la nécessité d’évoluer
  En citant le passage sur le fait de « changer maintenant le standard de nommage des événements », ils y voient une satire de la volonté d’éviter JavaScript

  • Un commentaire raille le fait qu’à force de vouloir éviter JavaScript, ils ont fini par faire interpréter une syntaxe personnalisée par du JS
    Cela dit, il reconnaît qu’exprimer l’intention en HTML garde un intérêt
  • Quelqu’un plaisante : « cette fois, ce sera vraiment la dernière version »
  • Un autre accueille cela positivement en disant que « c’est toujours mieux que d’écrire directement du JavaScript »
  • D’autres demandent quel est le problème si l’auteur a changé d’avis, en soulignant le ton inutilement critique

• L’article est jugé très clair et permettrait d’apprendre beaucoup sur la philosophie de conception d’API

• Quelqu’un a créé xhr-fetch-proxy pour utiliser fetch avec HTMX,
  et pense que ce changement va ouvrir encore plus de possibilités
  Lien du projet

  • Dans la 4.0, le cycle de requête est entièrement ouvert, ce qui permettrait de remplacer l’implémentation de fetch à chaque requête
    Il ajoute avoir repris cette idée de fixi.js