Fernando a écrit 93 commentaires

j'ai aéré mon composte, bêché, planté des patates (jeudi à la saint Joseph, je peux pas), semé des petits pois, préparé mes semis de tomates et nettoyé mes haies.
Et tout cela à la main (donc sans cramer la planète pour rien) !
Et en plus je suis allé voter.
Pas mal pour un weekend, non ?

Ce fragment apparaîtrait dans une zone de la page qui est prévue pour ça, mais qui serait vide en temps normal.

Zone qui aurait un mu-patch-target et si le serveur répondait cette zone avec quelque chose de non vide elle apparaîtrait.

Ce que tu veux dire c'est que le serveur peut ne pas répondre avec toutes les targets, seulement celles données par le serveur seront patchées.

Je présume aussi que le serveur peut répondre avec un nouvel élément ayant un mu-patch-target à condition qu'il place ce nouvel élément dans un autre élément ayant lui aussi un mu-patch-target et déjà présent dans la page, sinon il ne sera pas pris en compte.

le serveur retourne uniquement les fragments qu'il veut mettre à jour

Je ne comprends pas bien comment le serveur peut décider quels fragments mettre à jour puisqu'il n'a aucun contexte, il peut juste savoir s'il est appelé par µJS ou directement par le navigateur (ou bot).

Ok donc le backend peut savoir que c'est µJS qui l'appelle mais est obligé à minima de fournir tous les tags patchables de la page et pas éventuellement un en particulier.

Je vois un gros intérêt à ne pas mettre à jour la totalité du body est s'il contient des éléments avec lesquels l'utilisateur peut interagir : vidéo, champ input, tag detail, case à cocher, bouton radio, etc. Du coup il faut éviter de mettre ce type d'élément dans des tags patchables sinon l'effet ne sera pas top pour l'utilisateur.

EDIT: Je viens de voir que tu conseilles d'utiliser le module Idiomorph de chez HTMX pour cela.

Pour le cache effectivement puisque du coup il n'y a que 2 variantes possibles pour une même URL.

Pour le service worker ok mais il faut faire attention à reconduire tes headers si on y bricole une nouvelle requête.

Je vois 2 headers spécifiques (la doc dit qu'il y en a d'autres) :

X-Mu-Prefetch: 1
X-Requested-With: mujs (donc pas XMLHttpRequest)

Du coup le backend peut savoir que c'est µJS qui a fait l'appel mais comment peut-il savoir quel fragment servir ? C'est d'office le tag body ?

Et quid du cache HTTP, c'est la même URL en GET du coup s'il y a du cache cela risque de cafouiller non ?

Par ailleurs que se passe t'il si on utilise un service worker (PWA) ? Ces headers vont-ils passer ?

Et sinon c'est la ligne :

window.location.href = document.location

de la fonction _onPopState() quand le state de l'event est à null qui provoque la boucle infinie. Peut être que tu devrais comparer window.location.href à document.location.href et ne faire l'affection que s'il y a une différence. L'affectation doit probablement produire une event popstate d'office avec Safari et du coup cela tourne en rond.

Oui de mémoire il y a des histoires de sécurité ajoutées par Apple, mais je ne sais plus quoi, désolé.

Pas mal, mais avec Safari (version 26.3.1 sur macOS, pas testé sur iPhone) et sur la partie documentation, la navigation est d'une lenteur abominable. Il doit y avoir un problème avec la fonction _onPopState() qui tombe en erreur :

RangeError: Maximum call stack size exceeded.

D'où la lenteur dés qu'on clique dans la barre de navigation.

On n'apprend rien, c'est bien un des risques.
Un article intéressant de The Conversation sur ce sujet :
Le plus grand danger de l’IA à l’université n’est pas la triche, c’est l’érosion de l’apprentissage lui‑même

Je suis d'accord, site web de l'asso façon blog mais par contre avec un flux RSS plutôt qu'une newsletter et côté utilisateur un lecteur RSS simple.

Tu ouvres sans doute le fichier index.html directement dans Firefox, donc tu es en protocole file://.

Tu devrais peut être mettre "assets/…" et non "./assets/…" pour le chemin de tes fichiers Javascript qui ne sont probablement pas chargés, et du coup, la fonction v2 manque alors qu'elle est appelée dans du code Javascript dans le corps du HTML.

Idem avec le fichier CSS (style.css).

J'ai testé la version de démo, c'est pas mal, mais ce que je trouve dommage c'est que la partie description des flux RSS n'est pas affichée, l'image et le titre c'est bien, mais la description (quand elle existe) est un plus je trouve pour éventuellement aller voir l'article.

Grindinsoft dit :

Note: Les systèmes automatisés ne sont pas parfaits — bien que les preuves suggèrent un risque, il y a encore une chance que le site soit légitime. Nous recommandons de vérifier le site web en utilisant une analyse détaillée ou en contactant l'entreprise directement par des canaux vérifiés.

(cf. https://fr.gridinsoft.com/online-virus-scanner/url/xikipedia-org)

Comme le domaine est jeune (9 jours) cela semble peser pour sa mauvaise note.

Perso, je suis allé plusieurs fois dessus et pas de problème, pas de cookie, uniquement des connexions vers le domaine d'origine xikipedia.org et vers wikimedia.org pour les images des articles.

Il faut mettre un cœur je crois pour que cela fonctionne.

Identique dans le doomscrolling éthique, mais certes il n'y a pas la capacité de suggestion qui d'ailleurs montre bien "l'enfermement" rapide dans certaines catégories d'articles. Par exemple si j'aime quelques articles parlant de voitures, rapidement je vois de plus en plus d'articles de ce genre.

Sympa mais je préfère celui là : https://wikiroom.fr, il n'y a pas les catégories mais tu peux choisir la langue du Wikipédia qui répond et également rechercher dans Wikipédia.

Bienvenue au club 🤣

Il faut quelqu'un de compétent pour la guider, la corriger. C'est un stagiaire, dés fois un peu ivre, qu'il faut guider et rediriger, dont il faut vérifier le travail tout le temps.

Du coup je ne vois pas l'intérêt !

De plus, avec un stagiaire humain, c'est intéressant pour le faire progresser, avec une machine qui n'apprend rien, c'est une perte de temps.

+1000

J'ai des doutes sur le fait que Freenews soit un site GenAI, je l'avais d'ailleurs signalé à Next mais il est toujours dans la liste.
Certes, il n'y a qu'une personne derrière, mais je crois qu'elle existe réellement et le nombre d'articles publiés par jour reste raisonnable (humainement faisable).
L'IA est peut être utilisée pour aider à la rédaction des articles, mais je ne pense pas que l'on soit sur un site où les articles sont produits automatiquement à la chaîne par de l'IA (fermes à contenus).

Si tu le dis.

Ce qui m'étonne dans cette histoire c'est plutôt l'ampleur et la rapidité de la baisse des revenus.

Oui, ça m'étonne aussi, l'IA a peut être bon dos dans cette histoire. C'est peut être plutôt la hype autour de Tailwind CSS qui est retombée.

Et perso, je ne vais pas pleurer, j'ai toujours trouvé Tailwind CSS assez immonde et une fausse bonne idée.

C'est le problème du parasite, s'il provoque la mort de son hôte, il meurt avec.

Il faut un équilibrage de la distribution des revenus, une part pour les vendeurs d'IA (les parasites), une autre pour les créateurs de contenus (l'hôte).

Il y a des négociations dans la presse :
- https://www.lemonde.fr/le-monde-et-vous/article/2024/03/13/intelligence-artificielle-un-accord-de-partenariat-entre-le-monde-et-openai_6221836_6065879.html
- https://www.lemonde.fr/le-monde-et-vous/article/2025/05/14/intelligence-artificielle-un-nouvel-accord-de-partenariat-entre-le-monde-et-perplexity_6605885_6065879.html
- https://www.lefigaro.fr/medias/l-empire-des-medias-de-rupert-murdoch-signe-un-accord-avec-openai-sur-les-contenus-20240523

Clairement la presse des milliardaires a peut être les moyens de contraindre les parasites, la presse indépendante va par contre encore souffrir et les petits qui veulent vivre de leurs productions (comme Korben) risquent de vraiment trinquer.

Le problème de fond est la perte de visibilité et d'accès aux sites. Si les moteurs de recherche n'amènent plus de trafic aux sites en devenant des frontaux d'IA et donc en laissant tomber leur fonction première, c'est tout le modèle du Web actuel qui s'écroule.

pour les trains : Carto Tchoo.