htmz - Framework HTML ultra-léger

• Un microframework HTML minimaliste qui permet de créer des interfaces web modulaires et dynamiques avec une simplicité comparable à celle du HTML brut
• Il ne fait qu’une seule chose : permettre de charger des ressources HTML depuis n’importe quel élément de la page
  • Cela permet de mettre à jour seulement une partie de la page, et donc de remplacer des fragments de page
• D’une taille totale de 166 octets, il utilise uniquement du HTML pur, sans dépendances, et ne nécessite ni bundle JS, ni backend, ni attributs spéciaux, ni DSL, ni éléments personnalisés
• Il interagit avec le DOM réel et n’utilise ni VDOM, ni écouteurs de clic, ni AJAX, ni fetch, etc.
• Il suffit d’ajouter un simple snippet HTML inline sous forme d’iframe

Utilisation de base

• Pour utiliser htmz, il faut un lien hypertexte (ou un formulaire) avec un attribut href pointant vers l’URL de la ressource (ou action pour un formulaire) et un sélecteur d’ID de destination.
• Cela peut donner l’impression de réutiliser le fragment d’URL comme sélecteur d’ID de destination, mais dans ce contexte le fragment d’URL n’est pas utilisé à d’autres fins, donc cette réutilisation est possible.

Que fait-il exactement ?

• htmz fournit une fonctionnalité unique : charger une ressource HTML à l’intérieur de n’importe quel élément de la page.
• L’idée n’est pas nouvelle : découper une page web en parties qui se rechargent indépendamment existe depuis le milieu des années 1990.
• htmz est une généralisation des frames HTML, capable de charger une ressource HTML depuis n’importe quel élément de la page.

Utilisation avancée

• Actuellement, en HTML5, seuls les éléments et peuvent cibler et invoquer htmz.
• Il est possible d’utiliser l’élément `` pour définir htmz comme cible par défaut de tous les liens relatifs.
• Si vous préférez utiliser une vraie valeur de cible, vous pouvez recourir à un hack permettant d’écrire le sélecteur d’ID de destination directement dans l’attribut target.

Scripting / interaction

• Si davantage d’interactivité est nécessaire, il est possible d’utiliser JavaScript, le langage de script compagnon de htmz.
• htmz n’exclut ni l’écriture de JS ni l’utilisation de bibliothèques d’interface, et il reste possible de soumettre des valeurs de formulaire via des formulaires HTTP classiques avec htmz.

Extensibilité

• Si vous avez besoin de sélecteurs avancés, de gestion des erreurs ou de cibles multiples, les développeurs peuvent l’étendre selon leurs besoins.

FAQ

• htmz est un iframe nommé "htmz" ; il est invoqué en chargeant une URL via cet iframe.
• htmz agit comme une cible proxy et transmet la réponse à la cible spécifiée.
• htmz n’analyse pas le DOM en continu, ne recherche pas d’attributs ou de syntaxes spéciales, et n’attache pas de listeners au DOM.
• htmz est un microframework HTML qui n’utilise qu’un minimum de JS.
• htmz est un snippet ; son nom est l’abréviation de 'Html with Targeted Manipulation Zones'.
• Ce projet a démarré comme une réaction à htmx et comme une expérimentation visant à voir s’il était possible d’implémenter la fonctionnalité charger-lier-cibler du web actuel sans utiliser htmx.
• Malgré sa très petite taille, htmz donne une impression de puissance, et sa principale limite est de ne pouvoir avoir qu’une seule destination par réponse.

---

L’avis de GN⁺

• Une approche innovante : htmz propose une approche innovante du développement web en réduisant la complexité des frameworks et en construisant des interfaces web avec du HTML pur. Cela rend le développement web accessible même aux ingénieurs logiciel débutants.
• L’alliance des performances et de la simplicité : avec sa taille extrêmement légère de 166 octets et son absence de dépendances, sa structure peut nettement améliorer les performances des pages web. Elle offre aussi la simplicité de créer des pages efficaces sans devoir apprendre des frameworks JavaScript complexes.
• Le futur du développement web : htmz offre une perspective intéressante sur l’avenir du développement web. Il montre comment l’évolution des standards et des technologies du web peut fournir aux développeurs des outils plus simples et plus efficaces.

[joyfui]

Waouh, c’est vraiment original mdr. Sur le lien, il dit que ce n’est ni une bibliothèque ni un framework, juste un simple snippet… hehe

[savvykang]

Utilisation avancée : dans le HTML5 actuel, seuls les éléments et semblent ne pas être soumis à l’échappement HTML.

[GN⁺]

Avis Hacker News

• Résumé du premier commentaire :

  • Réaction positive à l’idée d’utiliser des iframes nommées et des formulaires ciblés pour des pages rendues côté serveur et des widgets avec portée de style.
  • htmz semble bien implémenter cette idée.
  • Insiste sur le fait qu’il ne faut pas abandonner une bonne idée, qu’il faut se concentrer sur la finition et l’excellence, et bien communiquer l’idée.
  • Considéré comme un excellent hack montrant que le navigateur peut fournir un SPA nativement.
  • Une belle démonstration par quelqu’un qui comprend très bien la plateforme.
  • Avis selon lequel le Web vanilla devrait être simple et puissant.
  • Évaluation positive de l’exploitation maximale des matériaux déjà fournis par le Web.
  • Éloges pour les compétences en communication et en marketing du créateur.

• Résumé du deuxième commentaire :

  • Un hack qui montre que le navigateur peut fournir un SPA nativement.
  • Il suffirait de quelques attributs pour éviter les iframes.
  • Peut être plus utile pour prouver un point que comme véritable outil.
  • Jugé trop complexe par rapport à ce que propose htmx.

• Résumé du troisième commentaire :

  • Partage d’une expérience de développement d’un client email en HTML vers 2001.
  • Utilisation d’un iframe caché pour charger des données depuis le serveur et manipuler le DOM.
  • À l’époque, le support des navigateurs n’était pas suffisant, mais le mécanisme de base est le même.
  • Appréciation positive du fait que cela soit implémenté dans un package concis, sans nécessiter beaucoup de bibliothèques.
  • Cela pourrait convenir à la plupart des cas d’usage, comparé aux frameworks frontend actuels comme React.

• Résumé du quatrième commentaire :

  • Affirmation forte selon laquelle le remplacement du DOM via la réponse devrait faire partie de la plateforme.
  • Proposition d’une première étape avec un élément capable de charger déclarativement du contenu externe dans la page.
  • Mention du fait que HTML devrait prendre en charge des éléments pouvant être la cible de liens.

• Résumé du cinquième commentaire :

  • Éloges pour une belle démonstration par quelqu’un qui comprend réellement la plateforme.
  • Peu probable qu’il l’utilise réellement, mais jugé excellent.

• Résumé du sixième commentaire :

  • Suggestion de supprimer this. dans les écouteurs d’événements inline pour réduire encore la taille du code.
  • Astuce permettant d’économiser 10 octets dans le snippet.

• Résumé du septième commentaire :

  • Fait remarquer qu’en utilisant target, le comportement pourrait ne pas se dégrader aussi élégamment que htmx lorsque JS est désactivé.
  • Exprime une vision idéaliste de la situation où JS est désactivé.

• Résumé du huitième commentaire :

  • Fait remarquer que réutiliser l’élément <slot> de cette manière est une mauvaise idée.
  • Dans le navigateur, <slot> a un comportement très spécifique, et il est remplacé par les enfants de l’élément hôte quoi que fasse la bibliothèque.
  • Mentionne que l’élément <output> existe déjà pour ce type de situation.

• Résumé du neuvième commentaire :

  • Souligne la nécessité d’améliorer la section de démonstration.
  • Lorsqu’on clique sur un « onglet » pour changer le code d’exemple, un événement d’historique est ajouté mais l’URL n’est pas mise à jour.
  • Critique le fait de revendiquer du « simplement HTML » tout en enfreignant des règles de base du Web et de l’UX.

• Résumé du dixième commentaire :

  • Cela rappelle pjax, sauf que pjax utilise XHR au lieu d’un iframe et utilise pushState par défaut afin que le bouton retour fonctionne.