Je poste la question en toute innocence. J'ai une vague compréhension du JavaScript et de l'outillage actuel des sites web complexes. J'ai des appétences pour le HTML/CSS minimaliste (le smolweb par exemple), qui me font regarder ces technos avec méfiance, mais je sais aussi qu'on peut faire des trucs légers et chouettes avec un site statique, un peu de JS côté client et des données stockées dans un fichier JSON. Du coup : à quoi ça sert, les "generalized hypermedia controls" dont parle le lisezmoi de fixi.js ? Est-ce que l'auteur de ce projet parle de la même chose que moi quand il parle de minimalisme ?
Quand il parle de minimalisme c'est sur l'implémentation du concept par rapport à htmx qui rajoute beaucoup d'autres choses.
Le concept étant de généraliser les possibilités des "hypermedia controls" à tous les éléments.
Par exemple qu'un bouton (ou autre) puisse faire un GET et renvoyer le résultat dans un autre élément, un div par exemple.
HTMX et Fixi (et d'autre) part de deux principes :
n'importe quel élément HTML et pas uniquement les boutons et les liens devraient pouvoir déclencher une interaction utilisateur = "faire un truc".
il doit être possible, lors d'une interaction, de remplacer une partie du document HTML (le DOM) sans recharger toute la page
C'est ce qu'implémentent les deux bibliothèques une fois chargées dans la page (script).
Il suffit d'ajouter des attributs à un élément pour le rendre interactif. Lorsque l’interaction est activée (click, over, time, etc), la bibliothèque fait une requête asynchrone (AJAX ou XHR), s'attend à recevoir du HTML et retour et le place à l'endroit indiqué.
Je voyais un intérêt à HTMX qui était qu'on puisse :
- exposer des routes qui retournent un HTML complet, pratique si le js est désactivé, ou si l'utilisateur recharge la page
- et si js est activé, HTMX peut appeler ces routes « complètes » et ne remplacer que la partie de la page qui est censée changer, sans rien changer au backend
C'était faisable grâce à hx-target (choisir quoi remplacer dans le document actuel) combiné à hx-select (choisir quoi extraire de la page requêtée), mais plus avec fixi, qui ne propose que fx-target. Il faudrait donc implémenter des routes qui ne retournent que la partie de la page qui nous intéresse en plus de la route qui retourne une page HTML complète, ce qui limite l'intérêt.
Il a écrit fixi pour avoir quelque chose de plus minimaliste que htmx. Mais htmx continuera d'exister.
et si js est activé, HTMX peut appeler ces routes « complètes » et ne remplacer que la partie de la page qui est censée changer, sans rien changer au backend. C'[est] faisable grâce à hx-target (choisir quoi remplacer dans le document actuel) combiné à hx-select
Pour moi, cela tient plus du hack que de la bonne pratique. Car cela veut dire transférer la page complète pour en jeter 99%. Et cela couple le frontend et le backend.
Avec un système de templateting, on peut avoir une template qui fait le rendu d'un seul objet et l'inclure dans une template qui boucle sur une liste d'objets. La route GET /list_all revoie le résultat de la template liste, et la route POST /create_one renvoi le résultat de la template unitaire.
Car cela veut dire transférer la page complète pour en jeter 99%.
De toute façon, il faut prévoir le cas pour pouvoir fonctionner sans JS.
Et cela couple le frontend et le backend.
Bah, c'est encore plus le cas si le backend renvoie du HTML partiel, car tu dois prévoir côté backend quels sont les HTML partiels qui peuvent être renvoyés.
Avec un système de templateting, on peut avoir une template qui fait le rendu d'un seul objet et l'inclure dans une template qui boucle sur une liste d'objets. La route GET /list_all revoie le résultat de la template liste, et la route POST /create_one renvoi le résultat de la template unitaire.
Ok mais il faut aussi implémenter /list_all.html qui renvoie le HTML complet avec tous les éléments, ainsi que /create_one.html qui renvoie le HTML complet avec juste un élément. Ça duplique quand même l'effort.
# Interview de l'auteur
Posté par wilk . Évalué à 2 (+0/-0).
Il en parle ici
https://youtu.be/VKu3Dyyzzjg
HTMX est considéré comme stable, il préfère expérimenter sur un nouveau projet.
# À quoi ça sert ?
Posté par Laurent Pointecouteau (site web personnel, Mastodon) . Évalué à 5 (+3/-0). Dernière modification le 11 mars 2025 à 10:58.
Je poste la question en toute innocence. J'ai une vague compréhension du JavaScript et de l'outillage actuel des sites web complexes. J'ai des appétences pour le HTML/CSS minimaliste (le smolweb par exemple), qui me font regarder ces technos avec méfiance, mais je sais aussi qu'on peut faire des trucs légers et chouettes avec un site statique, un peu de JS côté client et des données stockées dans un fichier JSON. Du coup : à quoi ça sert, les "generalized hypermedia controls" dont parle le lisezmoi de fixi.js ? Est-ce que l'auteur de ce projet parle de la même chose que moi quand il parle de minimalisme ?
[^] # Re: À quoi ça sert ?
Posté par wilk . Évalué à 5 (+3/-0).
Quand il parle de minimalisme c'est sur l'implémentation du concept par rapport à htmx qui rajoute beaucoup d'autres choses.
Le concept étant de généraliser les possibilités des "hypermedia controls" à tous les éléments.
Par exemple qu'un bouton (ou autre) puisse faire un GET et renvoyer le résultat dans un autre élément, un div par exemple.
<button fx-action="/autre" fx-target="ici">Clic</button>
<div id="ici">...</div>
Ce qu'on peut relativement déjà faire avec des forms et des iframe est donc généralisé aux autres éléments.
Il y a un projet pour l'inclure dans les specs html
https://github.com/alexpetros/triptych
[^] # Re: À quoi ça sert ?
Posté par steph1978 . Évalué à 5 (+3/-0).
HTMX et Fixi (et d'autre) part de deux principes :
C'est ce qu'implémentent les deux bibliothèques une fois chargées dans la page (script).
Il suffit d'ajouter des attributs à un élément pour le rendre interactif. Lorsque l’interaction est activée (click, over, time, etc), la bibliothèque fait une requête asynchrone (AJAX ou XHR), s'attend à recevoir du HTML et retour et le place à l'endroit indiqué.
# dommage
Posté par Octabrain . Évalué à 4 (+2/-0).
Je voyais un intérêt à HTMX qui était qu'on puisse :
- exposer des routes qui retournent un HTML complet, pratique si le js est désactivé, ou si l'utilisateur recharge la page
- et si js est activé, HTMX peut appeler ces routes « complètes » et ne remplacer que la partie de la page qui est censée changer, sans rien changer au backend
C'était faisable grâce à
hx-target(choisir quoi remplacer dans le document actuel) combiné àhx-select(choisir quoi extraire de la page requêtée), mais plus avec fixi, qui ne propose quefx-target. Il faudrait donc implémenter des routes qui ne retournent que la partie de la page qui nous intéresse en plus de la route qui retourne une page HTML complète, ce qui limite l'intérêt.[^] # Re: dommage
Posté par steph1978 . Évalué à 3 (+1/-0).
Il a écrit fixi pour avoir quelque chose de plus minimaliste que htmx. Mais htmx continuera d'exister.
Pour moi, cela tient plus du hack que de la bonne pratique. Car cela veut dire transférer la page complète pour en jeter 99%. Et cela couple le frontend et le backend.
Avec un système de templateting, on peut avoir une template qui fait le rendu d'un seul objet et l'inclure dans une template qui boucle sur une liste d'objets. La route
GET /list_allrevoie le résultat de la template liste, et la routePOST /create_onerenvoi le résultat de la template unitaire.[^] # Re: dommage
Posté par Octabrain . Évalué à 2 (+0/-0).
De toute façon, il faut prévoir le cas pour pouvoir fonctionner sans JS.
Bah, c'est encore plus le cas si le backend renvoie du HTML partiel, car tu dois prévoir côté backend quels sont les HTML partiels qui peuvent être renvoyés.
Ok mais il faut aussi implémenter
/list_all.htmlqui renvoie le HTML complet avec tous les éléments, ainsi que/create_one.htmlqui renvoie le HTML complet avec juste un élément. Ça duplique quand même l'effort.Envoyer un commentaire
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.