Ah je crois que je comprends la source de la confusion.
L'attribut mu-patch-target ne sert pas à dire "ceci est un élément qui peut être patché".
C'est un attribut qu'il faut mettre sur le flux renvoyé par le serveur, pour dire "voici la définition de l'élément qu'il faut mettre à jour".
Là, ça va mettre deux fragments à jour : le tag <header>, et l'élément qui a l'ID zone-2.
Dans les exemples précédents, la page initiale (celle du premier chargement) contenait des attributs mu-patch-target, mais ils ne sont pas utilisés. C'était pour montrer qu'on peut envoyer le même code HTML lors du premier chargement et lors des patchs.
J'ai appliqué un correctif : j'ai remplacé le window.location.href = document.location par location.reload(). J'évite aussi de sauver l'état du scroll pendant le popstate.
Là ça dépend de ton application. Le contexte vient de tes données, et de la session utilisateur.
Regarde l'exemple que j'ai mis plus haut. Il y a deux zones à mettre à jour : la liste des items, et le nombre total d'items. Donc le serveur peut n'envoyer que ces deux fragments-là.
Mais on pourrait imaginer que, dans certains cas, le serveur envoie un troisième fragment. Par exemple un message pour dire qu'il y a une erreur sur un item. Ce fragment apparaîtrait dans une zone de la page qui est prévue pour ça, mais qui serait vide en temps normal.
Ou imaginons un tableau de bord qui affiche des données (des tableaux, des graphiques, etc.). Il y a un polling qui fait une requête toutes les minutes. À chaque fois, l'application envoie un fragment pour chaque bloc de données, uniquement si la donnée a été modifiée depuis moins d'une minute. Parfois ça ne renverra rien ; d'autres fois ça renverra un ou deux blocs ; et d'autres fois ça renverra tous les blocs de la page.
J'ai fais des tests et vérifié le code : le titre est bien mis à jour.
Il y a des subtilités :
Le titre n'est mis à jour que si l'historique de navigation est mis à jour. Donc un lien avec l'attribut mu-history="false" ne verra pas la mise à jour du titre.
Dans le mode patch, la mise à jour ne se fait que sur les fragments qui portent l'attribut mu-patch-target. Donc si on veut mettre le titre à jour, il faut explicitement l'indiquer :
"Obligé de fournir tous les tags patchables" : Non, pas du tout. En mode patch, le serveur retourne uniquement les fragments qu'il veut mettre à jour. Il n'y a pas d'obligation de retourner tous les éléments patchables de la page. Le serveur décide ce qu'il envoie, µJS applique ce qu'il reçoit.
Dans l'exemple que j'ai donné, le serveur envoie deux fragments qui vont modifier deux zones dans la page. Mais on pourrait tout aussi bien envoyer un seul fragment. Ou trois.
En fait, il n'y a pas de notion de "tag patchable". En mode patch, le flux envoyé par le serveur détermine les éléments à mettre à jour grâce aux attributs mu-patch-target qui servent à indiquer la cible à mettre à jour. Mais ça peut être n'importe quel élément "ciblable" de la page.
Éléments interactifs dans les zones patchables : C'est ça, idiomorph est là pour ça. Il fait du diff/patch du DOM plutôt que de remplacer brutalement, ce qui préserve l'état des inputs, vidéos, checkboxes, etc.
Service worker et headers : Bonne remarque. Si le service worker crée une nouvelle requête (new Request(…)), il faut bien recopier les headers µJS manuellement, sinon le backend ne les voit plus. À toi de voir si ton backend en a vraiment besoin ou pas.
Je n'ai pas grand-chose à répondre à tout ça. Surtout que je suis d'accord avec une partie de ce que tu as écrit.
Mais il n'empêche qu'il y a déjà plus de projets open-source qui utilisent l'IA qu'on ne peut le croire (cf. l'exemple de LLVM que j'ai cité, mais j'en connais d'autres). Et dans des mesures que peu de gens soupçonnent.
Merci beaucoup pour ce retour d'expérience, ça m'est très utile !
J'ai juste ajouté à la main les deux balises script sur la page index. Comme ensuite les page article ne sont pas rechargé mais chargées par µJS, pas besoin de le déclarer sur toutes les pages.
Si on peut accéder directement aux pages d'articles, il faut mettre le Javascript sur toutes les pages. Ce n'est pas un souci, µJS ne le réinterprétera pas. Mais comme ça, lorsqu'on va directement sur un article, si ensuite on navigue sur une autre page on bénéficiera du chargement par µJS.
En conséquence, cela fonctionne bien tant qu'on a pas de changement de styles. C'est la première page à charger µJS qui impose ces styles au reste du contenu.
La plupart du temps, les mêmes CSS sont utilisés sur toutes les pages d'un site.
Mais si une page contient du CSS ou du JS (dans la page ou via le chargement d'un fichier externe) qui n'est pas connu, µJS va le charger.
Je confirme que l'URL est bien mise à jour dans la barre d'URL et bien inscrite dans l'historique. Que les boutons "back" and "forth" sont fonctionnels. Cependant, le titre n'est pas mis à jour et que sauter loin dans l'historique (click droit sur les boutons et choix d'une entrée) ne fonctionne pas.
Pour le titre, ça devrait le prendre en compte. Je vais me pencher dessus.
Pour l'historique, j'avoue ne pas avoir testé. Je vais regarder aussi.
D'autant que µJS vient avec un coût en RAM. Dans mon cas, sans µJS : 10MB, avec : 100MB ; YMMV.
Intéressant. C'est après avoir navigué sur plusieurs pages, ou dès le chargement de la page initiale ?
Headers complets : il y en a 4 en tout. X-Requested-With: XMLHttpRequest, X-Mu-Mode (mode d'injection courant), X-Mu-Method (pour les requêtes non-GET), et X-Mu-Prefetch: 1 (sur les prefetch uniquement).
LeX-Requested-With: muJS était sur une ancienne version de µJS (et notamment visible sur le site mujs.org, qui vient d'être mis à jour)
Quel fragment servir : deux approches. Soit le serveur retourne la page complète et µJS extrait lui-même le bon fragment via mu-source. Soit le serveur détecte X-Requested-With et retourne uniquement le fragment. C'est le développeur qui choisit.
Pour illustrer les choses, imaginons que tu aies un page qui affiche 10 items (sur une liste qui peut en contenir plus), ainsi que le nombre total d'items. Tu auras une page qui ressemble à ça :
<!-- URL : /mapage -->
<html>
<head>...</head>
<body>
<nav>...</nav>
<ul>
<li>Item 1</li>
...
<li>Item 10</li>
</ul>
...
<div>
Total : 125 items
</div>
...
reste de la page
...
<a href="/mapage">Mettre à jour</a>
</body>
</html>
Tu peux garder les choses comme ça. À chaque clic sur le lient "Mettre à jour", µJS va chercher la page, récupère le <body>, et le met à la place du <body> de la page courante. Ça met à jour toute la page.
Autre solution : tu ne veux mettre à jour que deux portions (la liste et le nombre total d'items), pas la page entière. Dans ce cas, tu vas mettre des instructions qui n'ont pas d'effet sur le navigateur au chargement initial, mais qui seront utilisées par µJS lors du chargement dynamique.
<!-- URL : /mapage -->
<html>
<head>...</head>
<body>
<nav>...</nav>
<ul id="liste" mu-patch-target="#liste">
<li>Item 1</li>
...
<li>Item 10</li>
</ul>
...
<div id="nombre" mu-patch-target="#nombre">
Total : 125 items
</div>
...
reste de la page
...
<a href="/mapage" mu-mode="patch">Mettre à jour</a>
</body>
</html>
Ici, le lien porte un attribut mu-mode="patch", donc µJS va chercher à "patcher" la page. Il va récupérer le HTML en AJAX, puis il regarde ce qu'il y a dedans.
Le tag avec l'attribut mu-patch-target="#liste" va donc remplacer le tag avec id="liste" dans page actuelle .
Et le tag avec l'attribut mu-patch-target="#nombre" va remplacer le tag avec id="nombre" dans la page actuelle.
Et si tu cherches à vraiment aller plus loin (mais c'est souvent inutile), tu détectes l'en-tête HTTP X-Requested-With pour que lors d'une requête effectuée par µJS, tu ne renvoies que ce flux :
<ul id="liste" mu-patch-target="#liste">
<li>Item 1</li>
...
<li>Item 10</li>
</ul>
<div id="nombre" mu-patch-target="#nombre">
Total : 125 items
</div>
Cache HTTP : La remarque est juste, uniquement dans le tout dernier cas décris (si tu détectes X-Requested-With pour ne pas renvoyer la page entière). Dans ce cas, la solution standard est d'ajouter Vary: X-Requested-With dans les réponses serveur. Ça crée deux entrées de cache distinctes pour la même URL (réponse complète vs fragment).
Service workers :fetch() passe par le service worker, qui voit tous les headers. Aucun problème particulier. Le service worker peut même les utiliser pour différencier les stratégies de cache.
C'est la même raison qui pousse µJS à proposer les attributs mu-* et data-mu-*, que celle qui a poussé htmx à proposer hx-* et data-htmx-*.
Si tu as vraiment besoin que ton code HTML passe dans un validateur HTML sans erreur, tu utilises les attributs data-*.
Par contre, pour la plupart des gens ce n'est pas une nécessité absolue, et dans ce cas on est content d'avoir un code moins verbeux. Les navigateurs gèrent cela sans le moindre problème.
On peut remarquer que µJS et htmx ne sont pas les seuls à proposer des attributs personnalisés (dont les noms ne commencent pas par data-). C'est aussi le cas d'AlpineJS (x-data, x-show…), de VueJS (v-if, v-for…), d'Angular (ng-if, ng-click…), Svelte (on:click, bind:value…), Unpoly (up-target, up-follow…), Livewire (wire:click, wire:model…).
Ce que tu décris est effectivement le cas de base, et il peut être traité de 2 manières différentes.
Solution basique
Tes deux pages "A" et "B" sont des pages normales, qui contiennent un HTML complet. Par défaut, en activant µJS, quand on clique sur un lien (par exemple, sur la page A, un lien qui pointe vers B), la lib va chercher le contenu de la page B en AJAX. La balise <body> de la page B est extraite du contenu récupéré, et elle est utilisée pour remplacer la balise <body> de la page courante.
Dans ce cas il n'y a rien à faire côté back-end. Tu génères tes pages comme d'habitude. µJS va juste rendre la navigation plus rapide et plus fluide, et évitant de refaire tout le traitement CSS et JS. L'écran ne "clignote" pas au chargement de la page.
Solution avancée
Si tu veux faire quelque chose de plus pointu, tu peux ne vouloir renvoyer qu'une portion de la page au lieu de la page complète. Dans ce cas, ton code backend doit regarder s'il y a un en-tête HTTP X-Requested-With (contenant la valeur XMLHttpRequest), pour faire un traitement conditionnel.
Mais honnêtement, la plupart du temps on peut s'en passer et rester sur le fonctionnement de base.
Ah merci, je vais regarder ça. Je suis sous Linux, donc je n'ai pas pu tester sur Safari. J'avais aussi cru voir une lenteur, mais je n'ai pas pu la reproduire. Au moins là j'ai une piste ! :)
J'utilise Claude pour générer la documentation et faire de la revue de code.
Il va falloir s'habituer à voir l'IA être utilisée dans les projets libres (cf. la RFC de LLVM intitulée "LLVM AI tool policy: human in the loop"). Tant que c'est fait intelligemment, je n'y vois personnellement pas de problème. On peut avoir un point de vue différent, mais en l'occurrence je ne vois pas quel serait le gain pour qui que ce soit que la documentation soit de moins bonne qualité (sur le fond comme sur la forme) par manque de temps de ma part.
Il y a de ça, oui. La philosophie de µJS se rapproche plus de Turbo : offrir un fonctionnement le plus transparent possible pour rendre la navigation fluide et rapide.
Ensuite, tu peux faire des choses plus spécifiques sur chaque liens, en se rapprochant de ce que propose htmx. Par exemple, le mode patch qui permet de mettre à jour plusieurs portions d'une page en une seule requête, qui s'utilise de la même manière en AJAX classique et en SSE, et qui est un modèle plus simple que le hx-swap-oob de htmx.
Non, ça dépend. Par défaut, l'historique de navigation est mis à jour au fur et à mesure des chargements de pages.
Il est possible de désactiver le changement d'historique (soit individuellement sur le lien, soit par configuration globale). Sur la page de Playground, je l'ai justement désactivé pour éviter qu'un rafraîchissement intempestif fasse sortir de la démo ; on n'est pas dans le cadre d'une navigation classique.
Mais si tu regardes le reste du site (qui utilise évidemment µJS), en naviguant de la page d'accueil vers la documentation, puis vers la page "About", tu verras que l'URL change. Tu peux recharger la page, tu peux copier-coller l'URL, etc.
Le principe de base est vraiment que ce soit transparent, que le comportement soit exactement le même que la navigation habituelle, mais juste plus fluide et plus rapide.
De manière générale, les outils "HTML to PDF" sous licence libre sont assez limités (librairies comme TCPDF, etc.), ou pénibles à installer et gourmands en mémoire (basés sur Chrome headless). Pour cette raison, mon entreprise utilise PrinceXML (via DocRaptor, qui fournit Prince en SaaS), qui est un logiciel propriétaire offrant beaucoup de fonctionnalités.
Après, oui PHP s'est complexifié, dans le sens où il offre maintenant des fonctionnalités supplémentaires et des facilités d'écriture. Mais beaucoup d'évolutions sont à destination des développeurs de frameworks et ne sont pas forcément destinées aux développeurs applicatifs. De manière générale, tu utilises ce que tu veux utiliser… la limite étant l'utilisation de code externe.
La courbe d'apprentissage de PHP reste assez douce quand on vient de langages comme le C ou la Java. Comme c'est un langage qui n'a pas grand-chose à envier aux autres sur le plan des fonctionnalités et des performances, si tu as déjà les bases ça peut valoir la peine de te tenir à jour des évolutions du langage de temps en temps. Ce sera beaucoup moins violent que de se former à un autre langage moderne.
Là où je suis d'accord, c'est que par rapport au C, on est sur un rythme très différent. Mais es-tu au courant des nouveautés des normes C11 et C18 ? J'avoue que même si je continue à coder en C (rarement mais ça m'arrive, la sensation de toute puissance quand on sait ce qu'on fait avec la mémoire est assez géniale), je suis resté au C99… si j'ai besoin de “plus” (plus de fonctionnalités ou plus de simplicité), je vais vite passer au PHP.
Question de point de vue. Il y a tellement de logiciels écrits en C qui te prouvent le contraire…
Encore une fois, si tu sais ce que tu fais et que tu utilises les bons outils, le C est à la fois simple et puissant.
Mais bon, on s'éloigne du sujet (et c'est de la bonne matière à troll, tout ça).
Ce retour d'expérience est vraiment très intéressant, aussi bien pour les aspects techniques qu'organisationnels.
J'ai juste relevé une petite erreur, induite je pense par l'excès d'enthousiasme : le C++ a quarante ans et se compile toujours dans le même esprit que le C qui a lui soixante ans
Autant on peut arrondir à 40 ans pour le C++ (37 ans en fait), autant c'est vieillir le C d'une quinzaine d'années (créé en 1972 mais stabilisé vers 1978).
Et je pense qu'on ne compilait pas dans les années 70 de la même manière que maintenant (make est apparu en 1977, et j'imagine que ça a pris du temps avant qu'il ne se répande).
Encore merci pour l'article. Personnellement, je préfère le C quand je veux m'éloigner des langages interprétés (et je ne suis pas le seul, comme je l'écrivais sur mon blog il y a quelques années). La simplicité extrême du langage, la sensation de puissance… Comme le dit Ben Klemens (auteur du livre 21st Century C), le C c'est le langage punk :)
Non, je n'en vois pas trop l'utilité pour l'instant, le temps de compilation par tcc étant négligeable. Ou alors plus tard : on pourrait l'utiliser par défaut si aucun compilateur n'a été trouvé (par exemple).
Oui, utiliser tcc à la place de gcc permettrait déjà de voir si le code C produit est bien compatible (je ne sais pas si vous utilisez des spécificités de la norme C11 ; il me semble que tcc n'est compatible qu'avec la norme C99, qui est quand même 12 ans plus vieille). Il faudrait aussi regarder si tcc supporte toutes les plateformes que Gambas supporte.
Et je serais aussi curieux de voir le résultat en terme de performance (sachant que tcc sera plus rapide à compiler, mais produira du code moins rapide ; c'est vraiment ce qui se rapproche le plus d'une compilation JIT).
Est-ce que le fait de pouvoir choisir le compilateur est vraiment primordial ? (c'est une vraie question)
Je trouve que c'est plus "propre" d'avoir un compilateur qui contienne tout ce dont il a besoin, plutôt que de passer par des programmes externe. On pourrait dire qu'utiliser une librairie externe versus un programme externe ne change pas grand-chose ; mais très concrètement je pense qu'une installation de Gambas peut embarquer des librairies (c'est assez commun), mais plus difficilement embarquer gcc ou clang.
Ce compilateur traduit le « bytecode » Gambas en langage C pendant l’exécution, et utilise ensuite le compilateur du système (gcc ou clang) pour obtenir le code machine final.
Plutôt que d'appeler un compilateur externe, est-ce que vous avez envisagé d'utiliser la bibliothèque du compilateur TinyCC (libtcc) ? Il produit du code moins optimisé que GCC/LLVM, mais il compile beaucoup plus vite, ce qui est parfait pour une compilation JIT. Et ça évite une dépendance avec un programme externe.
Peut-être que Gambas a besoin de produire du code C++ et non pas du code C (notamment pour Qt) ? Si c'est le cas, je comprendrais que TinyCC ne soit pas utilisable.
[^] # Re: contenus et habillage
Posté par Amaury Bouchard (site web personnel) . En réponse à la dépêche Sortie de µJS, une bibliothèque JavaScript légère pour dynamiser un site sans framework. Évalué à 0 (+0/-1).
Ah je crois que je comprends la source de la confusion.
L'attribut
mu-patch-targetne sert pas à dire "ceci est un élément qui peut être patché".C'est un attribut qu'il faut mettre sur le flux renvoyé par le serveur, pour dire "voici la définition de l'élément qu'il faut mettre à jour".
Par exemple, imagine si ta page contient ça :
En cliquant sur le lien, µJS va chercher le flux HTML disponible sur
/update.Imaginons que le serveur renvoie ça :
Ça mettra à jour l'élément de la page
#zone-1(donc l'élément qui a l'attributid="zone-1").Imaginons qu'au clic suivant sur le lien, le serveur réponde ça :
Là, ça va mettre deux fragments à jour : le tag
<header>, et l'élément qui a l'IDzone-2.Dans les exemples précédents, la page initiale (celle du premier chargement) contenait des attributs
mu-patch-target, mais ils ne sont pas utilisés. C'était pour montrer qu'on peut envoyer le même code HTML lors du premier chargement et lors des patchs.[^] # Re: Problème avec Safari
Posté par Amaury Bouchard (site web personnel) . En réponse à la dépêche Sortie de µJS, une bibliothèque JavaScript légère pour dynamiser un site sans framework. Évalué à 1 (+0/-0). Dernière modification le 13 mars 2026 à 14:56.
J'ai appliqué un correctif : j'ai remplacé le
window.location.href = document.locationparlocation.reload(). J'évite aussi de sauver l'état du scroll pendant le popstate.C'est tagué dans la version 1.4.5.
[^] # Re: contenus et habillage
Posté par Amaury Bouchard (site web personnel) . En réponse à la dépêche Sortie de µJS, une bibliothèque JavaScript légère pour dynamiser un site sans framework. Évalué à 1 (+0/-0).
Là ça dépend de ton application. Le contexte vient de tes données, et de la session utilisateur.
Regarde l'exemple que j'ai mis plus haut. Il y a deux zones à mettre à jour : la liste des items, et le nombre total d'items. Donc le serveur peut n'envoyer que ces deux fragments-là.
Mais on pourrait imaginer que, dans certains cas, le serveur envoie un troisième fragment. Par exemple un message pour dire qu'il y a une erreur sur un item. Ce fragment apparaîtrait dans une zone de la page qui est prévue pour ça, mais qui serait vide en temps normal.
Ou imaginons un tableau de bord qui affiche des données (des tableaux, des graphiques, etc.). Il y a un polling qui fait une requête toutes les minutes. À chaque fois, l'application envoie un fragment pour chaque bloc de données, uniquement si la donnée a été modifiée depuis moins d'une minute. Parfois ça ne renverra rien ; d'autres fois ça renverra un ou deux blocs ; et d'autres fois ça renverra tous les blocs de la page.
[^] # Re: test sur site static
Posté par Amaury Bouchard (site web personnel) . En réponse à la dépêche Sortie de µJS, une bibliothèque JavaScript légère pour dynamiser un site sans framework. Évalué à 2 (+1/-0).
J'ai fais des tests et vérifié le code : le titre est bien mis à jour.
Il y a des subtilités :
Le titre n'est mis à jour que si l'historique de navigation est mis à jour. Donc un lien avec l'attribut
mu-history="false"ne verra pas la mise à jour du titre.Dans le mode patch, la mise à jour ne se fait que sur les fragments qui portent l'attribut
mu-patch-target. Donc si on veut mettre le titre à jour, il faut explicitement l'indiquer :[^] # Re: contenus et habillage
Posté par Amaury Bouchard (site web personnel) . En réponse à la dépêche Sortie de µJS, une bibliothèque JavaScript légère pour dynamiser un site sans framework. Évalué à 2 (+1/-0).
"Obligé de fournir tous les tags patchables" : Non, pas du tout. En mode patch, le serveur retourne uniquement les fragments qu'il veut mettre à jour. Il n'y a pas d'obligation de retourner tous les éléments patchables de la page. Le serveur décide ce qu'il envoie, µJS applique ce qu'il reçoit.
Dans l'exemple que j'ai donné, le serveur envoie deux fragments qui vont modifier deux zones dans la page. Mais on pourrait tout aussi bien envoyer un seul fragment. Ou trois.
En fait, il n'y a pas de notion de "tag patchable". En mode patch, le flux envoyé par le serveur détermine les éléments à mettre à jour grâce aux attributs
mu-patch-targetqui servent à indiquer la cible à mettre à jour. Mais ça peut être n'importe quel élément "ciblable" de la page.Éléments interactifs dans les zones patchables : C'est ça, idiomorph est là pour ça. Il fait du diff/patch du DOM plutôt que de remplacer brutalement, ce qui préserve l'état des inputs, vidéos, checkboxes, etc.
Service worker et headers : Bonne remarque. Si le service worker crée une nouvelle requête (new Request(…)), il faut bien recopier les headers µJS manuellement, sinon le backend ne les voit plus. À toi de voir si ton backend en a vraiment besoin ou pas.
[^] # Re: Utilisation d'IA - Claude
Posté par Amaury Bouchard (site web personnel) . En réponse à la dépêche Sortie de µJS, une bibliothèque JavaScript légère pour dynamiser un site sans framework. Évalué à 2 (+1/-0).
Je n'ai pas grand-chose à répondre à tout ça. Surtout que je suis d'accord avec une partie de ce que tu as écrit.
Mais il n'empêche qu'il y a déjà plus de projets open-source qui utilisent l'IA qu'on ne peut le croire (cf. l'exemple de LLVM que j'ai cité, mais j'en connais d'autres). Et dans des mesures que peu de gens soupçonnent.
[^] # Re: test sur site static
Posté par Amaury Bouchard (site web personnel) . En réponse à la dépêche Sortie de µJS, une bibliothèque JavaScript légère pour dynamiser un site sans framework. Évalué à 1 (+0/-0).
Merci beaucoup pour ce retour d'expérience, ça m'est très utile !
Si on peut accéder directement aux pages d'articles, il faut mettre le Javascript sur toutes les pages. Ce n'est pas un souci, µJS ne le réinterprétera pas. Mais comme ça, lorsqu'on va directement sur un article, si ensuite on navigue sur une autre page on bénéficiera du chargement par µJS.
La plupart du temps, les mêmes CSS sont utilisés sur toutes les pages d'un site.
Mais si une page contient du CSS ou du JS (dans la page ou via le chargement d'un fichier externe) qui n'est pas connu, µJS va le charger.
Pour le titre, ça devrait le prendre en compte. Je vais me pencher dessus.
Pour l'historique, j'avoue ne pas avoir testé. Je vais regarder aussi.
Intéressant. C'est après avoir navigué sur plusieurs pages, ou dès le chargement de la page initiale ?
[^] # Re: Merci, ça me plait beaucoup
Posté par Amaury Bouchard (site web personnel) . En réponse à la dépêche Sortie de µJS, une bibliothèque JavaScript légère pour dynamiser un site sans framework. Évalué à 1 (+0/-0).
Merci ! :)
[^] # Re: contenus et habillage
Posté par Amaury Bouchard (site web personnel) . En réponse à la dépêche Sortie de µJS, une bibliothèque JavaScript légère pour dynamiser un site sans framework. Évalué à 2 (+1/-0).
Headers complets : il y en a 4 en tout.
X-Requested-With: XMLHttpRequest,X-Mu-Mode(mode d'injection courant),X-Mu-Method(pour les requêtes non-GET), etX-Mu-Prefetch: 1(sur les prefetch uniquement).Le
X-Requested-With: muJSétait sur une ancienne version de µJS (et notamment visible sur le site mujs.org, qui vient d'être mis à jour)Quel fragment servir : deux approches. Soit le serveur retourne la page complète et µJS extrait lui-même le bon fragment via
mu-source. Soit le serveur détecteX-Requested-Withet retourne uniquement le fragment. C'est le développeur qui choisit.Pour illustrer les choses, imaginons que tu aies un page qui affiche 10 items (sur une liste qui peut en contenir plus), ainsi que le nombre total d'items. Tu auras une page qui ressemble à ça :
<!-- URL : /mapage -->
<html>
<head>...</head>
<body>
<nav>...</nav>
<ul>
<li>Item 1</li>
...
<li>Item 10</li>
</ul>
...
<div>
Total : 125 items
</div>
...
reste de la page
...
<a href="/mapage">Mettre à jour</a>
</body>
</html>
Tu peux garder les choses comme ça. À chaque clic sur le lient "Mettre à jour", µJS va chercher la page, récupère le
<body>, et le met à la place du<body>de la page courante. Ça met à jour toute la page.Autre solution : tu ne veux mettre à jour que deux portions (la liste et le nombre total d'items), pas la page entière. Dans ce cas, tu vas mettre des instructions qui n'ont pas d'effet sur le navigateur au chargement initial, mais qui seront utilisées par µJS lors du chargement dynamique.
<!-- URL : /mapage -->
<html>
<head>...</head>
<body>
<nav>...</nav>
<ul id="liste" mu-patch-target="#liste">
<li>Item 1</li>
...
<li>Item 10</li>
</ul>
...
<div id="nombre" mu-patch-target="#nombre">
Total : 125 items
</div>
...
reste de la page
...
<a href="/mapage" mu-mode="patch">Mettre à jour</a>
</body>
</html>
Ici, le lien porte un attribut
mu-mode="patch", donc µJS va chercher à "patcher" la page. Il va récupérer le HTML en AJAX, puis il regarde ce qu'il y a dedans.Le tag avec l'attribut
mu-patch-target="#liste"va donc remplacer le tag avecid="liste"dans page actuelle .Et le tag avec l'attribut
mu-patch-target="#nombre"va remplacer le tag avecid="nombre"dans la page actuelle.Et si tu cherches à vraiment aller plus loin (mais c'est souvent inutile), tu détectes l'en-tête HTTP
X-Requested-Withpour que lors d'une requête effectuée par µJS, tu ne renvoies que ce flux :<ul id="liste" mu-patch-target="#liste">
<li>Item 1</li>
...
<li>Item 10</li>
</ul>
<div id="nombre" mu-patch-target="#nombre">
Total : 125 items
</div>
Cache HTTP : La remarque est juste, uniquement dans le tout dernier cas décris (si tu détectes
X-Requested-Withpour ne pas renvoyer la page entière). Dans ce cas, la solution standard est d'ajouterVary: X-Requested-Withdans les réponses serveur. Ça crée deux entrées de cache distinctes pour la même URL (réponse complète vs fragment).Service workers :
fetch()passe par le service worker, qui voit tous les headers. Aucun problème particulier. Le service worker peut même les utiliser pour différencier les stratégies de cache.[^] # Re: Utiliser les "data-" attributes
Posté par Amaury Bouchard (site web personnel) . En réponse à la dépêche Sortie de µJS, une bibliothèque JavaScript légère pour dynamiser un site sans framework. Évalué à 2 (+1/-0).
C'est la même raison qui pousse µJS à proposer les attributs
mu-*etdata-mu-*, que celle qui a poussé htmx à proposerhx-*etdata-htmx-*.Si tu as vraiment besoin que ton code HTML passe dans un validateur HTML sans erreur, tu utilises les attributs
data-*.Par contre, pour la plupart des gens ce n'est pas une nécessité absolue, et dans ce cas on est content d'avoir un code moins verbeux. Les navigateurs gèrent cela sans le moindre problème.
On peut remarquer que µJS et htmx ne sont pas les seuls à proposer des attributs personnalisés (dont les noms ne commencent pas par
data-). C'est aussi le cas d'AlpineJS (x-data,x-show…), de VueJS (v-if,v-for…), d'Angular (ng-if,ng-click…), Svelte (on:click,bind:value…), Unpoly (up-target,up-follow…), Livewire (wire:click,wire:model…).[^] # Re: contenus et habillage
Posté par Amaury Bouchard (site web personnel) . En réponse à la dépêche Sortie de µJS, une bibliothèque JavaScript légère pour dynamiser un site sans framework. Évalué à 3 (+2/-0).
Ce que tu décris est effectivement le cas de base, et il peut être traité de 2 manières différentes.
Solution basique
Tes deux pages "A" et "B" sont des pages normales, qui contiennent un HTML complet. Par défaut, en activant µJS, quand on clique sur un lien (par exemple, sur la page A, un lien qui pointe vers B), la lib va chercher le contenu de la page B en AJAX. La balise
<body>de la page B est extraite du contenu récupéré, et elle est utilisée pour remplacer la balise<body>de la page courante.Dans ce cas il n'y a rien à faire côté back-end. Tu génères tes pages comme d'habitude. µJS va juste rendre la navigation plus rapide et plus fluide, et évitant de refaire tout le traitement CSS et JS. L'écran ne "clignote" pas au chargement de la page.
Solution avancée
Si tu veux faire quelque chose de plus pointu, tu peux ne vouloir renvoyer qu'une portion de la page au lieu de la page complète. Dans ce cas, ton code backend doit regarder s'il y a un en-tête HTTP
X-Requested-With(contenant la valeurXMLHttpRequest), pour faire un traitement conditionnel.Mais honnêtement, la plupart du temps on peut s'en passer et rester sur le fonctionnement de base.
[^] # Re: Problème avec Safari
Posté par Amaury Bouchard (site web personnel) . En réponse à la dépêche Sortie de µJS, une bibliothèque JavaScript légère pour dynamiser un site sans framework. Évalué à 1 (+0/-0).
Encore merci :)
Je vais regarder dans cette direction !
[^] # Re: Problème avec Safari
Posté par Amaury Bouchard (site web personnel) . En réponse à la dépêche Sortie de µJS, une bibliothèque JavaScript légère pour dynamiser un site sans framework. Évalué à 1 (+0/-0).
Merci ! Je viens de l'installer. Et… malheureusement je ne reproduis toujours pas le ralentissement :/
C'est compliqué, mais il semblerait que certaines versions de Safari gèrent mal le déclenchement de popstate. Je vais continuer à creuser.
[^] # Re: Problème avec Safari
Posté par Amaury Bouchard (site web personnel) . En réponse à la dépêche Sortie de µJS, une bibliothèque JavaScript légère pour dynamiser un site sans framework. Évalué à 1 (+0/-0).
Ah merci, je vais regarder ça. Je suis sous Linux, donc je n'ai pas pu tester sur Safari. J'avais aussi cru voir une lenteur, mais je n'ai pas pu la reproduire. Au moins là j'ai une piste ! :)
[^] # Re: Utilisation d'IA - Claude
Posté par Amaury Bouchard (site web personnel) . En réponse à la dépêche Sortie de µJS, une bibliothèque JavaScript légère pour dynamiser un site sans framework. Évalué à 2 (+5/-4).
J'utilise Claude pour générer la documentation et faire de la revue de code.
Il va falloir s'habituer à voir l'IA être utilisée dans les projets libres (cf. la RFC de LLVM intitulée "LLVM AI tool policy: human in the loop"). Tant que c'est fait intelligemment, je n'y vois personnellement pas de problème. On peut avoir un point de vue différent, mais en l'occurrence je ne vois pas quel serait le gain pour qui que ce soit que la documentation soit de moins bonne qualité (sur le fond comme sur la forme) par manque de temps de ma part.
[^] # Re: htmx
Posté par Amaury Bouchard (site web personnel) . En réponse à la dépêche Sortie de µJS, une bibliothèque JavaScript légère pour dynamiser un site sans framework. Évalué à 1 (+0/-0).
Il y a de ça, oui. La philosophie de µJS se rapproche plus de Turbo : offrir un fonctionnement le plus transparent possible pour rendre la navigation fluide et rapide.
Ensuite, tu peux faire des choses plus spécifiques sur chaque liens, en se rapprochant de ce que propose htmx. Par exemple, le mode patch qui permet de mettre à jour plusieurs portions d'une page en une seule requête, qui s'utilise de la même manière en AJAX classique et en SSE, et qui est un modèle plus simple que le
hx-swap-oobde htmx.[^] # Re: Ça va casser le partage de lien...
Posté par Amaury Bouchard (site web personnel) . En réponse à la dépêche Sortie de µJS, une bibliothèque JavaScript légère pour dynamiser un site sans framework. Évalué à 4 (+3/-0).
Non, ça dépend. Par défaut, l'historique de navigation est mis à jour au fur et à mesure des chargements de pages.
Il est possible de désactiver le changement d'historique (soit individuellement sur le lien, soit par configuration globale). Sur la page de Playground, je l'ai justement désactivé pour éviter qu'un rafraîchissement intempestif fasse sortir de la démo ; on n'est pas dans le cadre d'une navigation classique.
Mais si tu regardes le reste du site (qui utilise évidemment µJS), en naviguant de la page d'accueil vers la documentation, puis vers la page "About", tu verras que l'URL change. Tu peux recharger la page, tu peux copier-coller l'URL, etc.
Le principe de base est vraiment que ce soit transparent, que le comportement soit exactement le même que la navigation habituelle, mais juste plus fluide et plus rapide.
# Par rapport à PrinceXML ?
Posté par Amaury Bouchard (site web personnel) . En réponse à la dépêche Des nouvelles de WeasyPrint, ou comment développer du libre à (presque) plein temps. Évalué à 2.
Merci pour ce témoignage intéressant.
De manière générale, les outils "HTML to PDF" sous licence libre sont assez limités (librairies comme TCPDF, etc.), ou pénibles à installer et gourmands en mémoire (basés sur Chrome headless). Pour cette raison, mon entreprise utilise PrinceXML (via DocRaptor, qui fournit Prince en SaaS), qui est un logiciel propriétaire offrant beaucoup de fonctionnalités.
Comment vous situez-vous par rapport à Prince ?
[^] # Re: re: La version 8.1 de PHP et création de la fondation PHP
Posté par Amaury Bouchard (site web personnel) . En réponse à la dépêche La version 8.1 de PHP et création de la fondation PHP. Évalué à 4.
Pour avoir un rappel des évolutions de PHP depuis PHP 7, je t'invite à lire l'article de blog que j'avais écrit sur le sujet : https://www.geek-directeur-technique.com/2021/10/17/de-php-7-a-php-8-retour-sur-cinq-ans-dinnovation
Après, oui PHP s'est complexifié, dans le sens où il offre maintenant des fonctionnalités supplémentaires et des facilités d'écriture. Mais beaucoup d'évolutions sont à destination des développeurs de frameworks et ne sont pas forcément destinées aux développeurs applicatifs. De manière générale, tu utilises ce que tu veux utiliser… la limite étant l'utilisation de code externe.
La courbe d'apprentissage de PHP reste assez douce quand on vient de langages comme le C ou la Java. Comme c'est un langage qui n'a pas grand-chose à envier aux autres sur le plan des fonctionnalités et des performances, si tu as déjà les bases ça peut valoir la peine de te tenir à jour des évolutions du langage de temps en temps. Ce sera beaucoup moins violent que de se former à un autre langage moderne.
Là où je suis d'accord, c'est que par rapport au C, on est sur un rythme très différent. Mais es-tu au courant des nouveautés des normes C11 et C18 ? J'avoue que même si je continue à coder en C (rarement mais ça m'arrive, la sensation de toute puissance quand on sait ce qu'on fait avec la mémoire est assez géniale), je suis resté au C99… si j'ai besoin de “plus” (plus de fonctionnalités ou plus de simplicité), je vais vite passer au PHP.
[^] # Re: Petite erreur
Posté par Amaury Bouchard (site web personnel) . En réponse à la dépêche Moi, expert C++, j’abandonne le C++. Évalué à 5.
Question de point de vue. Il y a tellement de logiciels écrits en C qui te prouvent le contraire…
Encore une fois, si tu sais ce que tu fais et que tu utilises les bons outils, le C est à la fois simple et puissant.
Mais bon, on s'éloigne du sujet (et c'est de la bonne matière à troll, tout ça).
# Petite erreur
Posté par Amaury Bouchard (site web personnel) . En réponse à la dépêche Moi, expert C++, j’abandonne le C++. Évalué à 4.
Ce retour d'expérience est vraiment très intéressant, aussi bien pour les aspects techniques qu'organisationnels.
J'ai juste relevé une petite erreur, induite je pense par l'excès d'enthousiasme :
le C++ a quarante ans et se compile toujours dans le même esprit que le C qui a lui soixante ans
Autant on peut arrondir à 40 ans pour le C++ (37 ans en fait), autant c'est vieillir le C d'une quinzaine d'années (créé en 1972 mais stabilisé vers 1978).
Et je pense qu'on ne compilait pas dans les années 70 de la même manière que maintenant (make est apparu en 1977, et j'imagine que ça a pris du temps avant qu'il ne se répande).
Encore merci pour l'article. Personnellement, je préfère le C quand je veux m'éloigner des langages interprétés (et je ne suis pas le seul, comme je l'écrivais sur mon blog il y a quelques années). La simplicité extrême du langage, la sensation de puissance… Comme le dit Ben Klemens (auteur du livre 21st Century C), le C c'est le langage punk :)
[^] # Re: Concernant le compilateur JIT
Posté par Amaury Bouchard (site web personnel) . En réponse à la dépêche Sortie de Gambas 3.12. Évalué à 1.
Effectivement, c'est un bon cas d'usage.
[^] # Re: Concernant le compilateur JIT
Posté par Amaury Bouchard (site web personnel) . En réponse à la dépêche Sortie de Gambas 3.12. Évalué à 1.
Donc tu as testé, le code C produit est bien du C99 compatible avec TCC ? Cool.
Pas de plan d'utiliser la librairie alors ?
[^] # Re: Concernant le compilateur JIT
Posté par Amaury Bouchard (site web personnel) . En réponse à la dépêche Sortie de Gambas 3.12. Évalué à 2.
Oui, utiliser tcc à la place de gcc permettrait déjà de voir si le code C produit est bien compatible (je ne sais pas si vous utilisez des spécificités de la norme C11 ; il me semble que tcc n'est compatible qu'avec la norme C99, qui est quand même 12 ans plus vieille). Il faudrait aussi regarder si tcc supporte toutes les plateformes que Gambas supporte.
Et je serais aussi curieux de voir le résultat en terme de performance (sachant que tcc sera plus rapide à compiler, mais produira du code moins rapide ; c'est vraiment ce qui se rapproche le plus d'une compilation JIT).
Est-ce que le fait de pouvoir choisir le compilateur est vraiment primordial ? (c'est une vraie question)
Je trouve que c'est plus "propre" d'avoir un compilateur qui contienne tout ce dont il a besoin, plutôt que de passer par des programmes externe. On pourrait dire qu'utiliser une librairie externe versus un programme externe ne change pas grand-chose ; mais très concrètement je pense qu'une installation de Gambas peut embarquer des librairies (c'est assez commun), mais plus difficilement embarquer gcc ou clang.
# Concernant le compilateur JIT
Posté par Amaury Bouchard (site web personnel) . En réponse à la dépêche Sortie de Gambas 3.12. Évalué à 4.
Dans la dépêche il est écrit :
Plutôt que d'appeler un compilateur externe, est-ce que vous avez envisagé d'utiliser la bibliothèque du compilateur TinyCC (libtcc) ? Il produit du code moins optimisé que GCC/LLVM, mais il compile beaucoup plus vite, ce qui est parfait pour une compilation JIT. Et ça évite une dépendance avec un programme externe.
Peut-être que Gambas a besoin de produire du code C++ et non pas du code C (notamment pour Qt) ? Si c'est le cas, je comprendrais que TinyCC ne soit pas utilisable.