#19619

Please stop using CDNs for external Javascript libraries – Terence Eden’s Blog

Y a enfin quelques voies qui se lèvent en présentant les inconvénients dans la pratique de ces choses là.

M’enfin son plus gros argument c’est surtout « évitez tant que possible d’utiliser des lib ». Je pense notamment à jQuery, souvent utilisé pour des broutilles et par habitude alors que ça alourdit considérablement la page à la fois au chargement et à l’exécution.

Quand j’ai fait cet outil par exemple la première chose que j’ai faite c’est retirer jQuery : ce dernier n’était utilisé que pour la gestion DOM de la lib avec la page, même pas dans la lib elle-même. Pourtant la vitesse d’exécution s’en est trouvée nettement améliorée !

https://shkspr.mobi/blog/2020/10/please-stop-using-cdns-for-external-javascript-libraries/

#19434

Adding A Scroll To Top Button Without JavaScript - Kev Quirk

Pas de 80 ko de JS ? Pas de jQuery juste pour un scroll ?

I like this shit !

(Par contre je n’aime pas le fait que l’on soit à faire des tutos pour des trucs aussi triviaux que ça… On en est vraiment là ? Faut croire que oui : voir ici ou )

https://kevq.uk/adding-a-scroll-to-top-button-without-javascript/#top

#19060

Un peu de Javascript… – 24 jours de web

jQuery a peut-être contribué à développer certains concepts, et à rendre le JS plus uniforme à travers les navigateurs à une époque où chaque nav avait ses propres limites, mais on est maintenant presque 15 ans après jQuery et les choses ont changées.

Hormis les applications très spécifiques, une bonne partie du langage JS (et même CSS et HTML) est nativement très bien supporté par les principaux moteurs de rendu (Blink et Gecko). jQuery n’est donc plus nécessaire, à moins de vouloir utiliser à tout prix supporter des systèmes obsolètes et dangereux (au coup d’une lenteur sans nom à l’exécution).

C’est donc un peu comme Flash : Flash a autorisé plein de choses à une époque, mais désormais les mêmes choses sont possibles sans Flash et il convient clairement de s’en passer et même de le bloquer.

Bref, les différents framework sont peut-être pratiques à un moment donnée, mais quand le moment vient où ils deviennent inutiles, il faut s’en débarrasser car ils deviennent des boulets, en terme de poids dans une page, de perfs, de technique…

Le web évolue. C’est peut-être chiant pour les grosses appli, mais aussi une bénédiction car ça permet d’avoir toujours de nouveaux trucs et ça lui permet de rester en vie.

https://www.24joursdeweb.fr/2019/un-peu-de-javascript/

#18987

C'est quoi tous ces divs ? | CommitStrip

Normalement on met le HTML à afficher sur une image, qu’on envoie au nav en base64 dans du JSON. Côté client, on utilise une lib de décodage base64 (pas que tous les nav ont ça désormais, mais c’est mieux avec une lib de 600 ko) puis un scanner OCR de 3 Mo et ses dépendances (2 Mo, dont une implémentation de pong en webGL que personne n’a demandé) avant d’incorporer ça dans le DOM.

http://www.commitstrip.com/fr/2019/09/20/whats-going-on-with-all-these-divs/

#18419

URL - Référence Web API | MDN

Parfois, c’est vraiment des demeurés ceux qui font les spec JS.

"URL" c’est la nouvelle API pour produire/parser une URL. C’est l’équivalent de « pathinfo() » en PHP.

On peut récupérer le chemin, le domaine, le port, l’utilisateur, le mot de passe, le protocole, le hash, les paramètres…
…mais pas le nom du fichier courant.

Yup, ils y ont tout mis… sauf le "basename".

Du coup on est obligé de mettre un

url.pathname.substring(url.pathname.lastIndexOf('/')+1)

Normalement, faut pas ajouter des méthodes aux prototypes, mais je pense que je vais faire une exception ici. Cette lacune est ridicule.

https://developer.mozilla.org/fr/docs/Web/API/URL

#18412

iro.js demo

Un color picker en JS.

Sympa.

Sauf qu’à première vue, les 10 lignes de JS ne sont pas tout : y a une lib qui est incluse (voir les settings). Et la lib seule fait 30 ko…

Ouais, à ce tarif, je préfère mon color picker JS/CSS : https://lehollandaisvolant.net/tout/tools/color/
Ça fait 15 ko (HTML + JS + CSS), et il convertit en RGB/HSL/CMYK/HEX dans n’importe quel sens.
Bon par contre, ça fonctionne pas dans IE.

https://codepen.io/rakujira/pen/WZOeNq

#18411

JavaScript loose comparison (==) step by step

Des exemples du fonctionnement du "==" en JS, sachant que « 2 == "2" » retournera true, il y a tout un tas de procédures qui entrent en jeu pour convertir les deux membres jusqu’à obtenir un résultat.

(PS : connaître le fonctionnement interne d’un ordi, d’un CPU, d’un langage ou d’un environnement d’exécution peut beaucoup aider pour optimiser ses scripts)

https://felix-kling.de/js-loose-comparison/

#18401

[PWA] fetch-serviceworkers.png (image) - 1354x1577px

Les Services Workers JS sont pratiques, mais bordel que c’est chiant à débugguer !

Je suis obligé de mettre des console.log() à toutes les lignes pour savoir ce qui se passe :o

Ici, c’est *juste* la fonction qui intercepte les requêtes réseau de la page (toutes les requêtes : XHR, mais aussi les fichiers scripts, les CSS, les fonts, les background-image()…).

La fonction permet de voir :
– si une requête doit être mise en cache (fichier, image) ou pas (requête de type json/ajax).
– si elle doit être mise en cache, alors on regarde si le fichier s’y trouve. Si oui ? retourne le fichier. Si non ? fait une connexion réseau. La connexion, fonctionne-t-elle ? Si oui : récupère la réponse et la met en cache, puis retourne la réponse. Si non, emet une erreur.

Le truc c’est que pour que le script puisse prétendre être une bonne PWA, aucune requête ne doit finir sur une erreur (404 ou autre). Si l’app est offline, la requête ne marchera pas, mais l’erreur doit être gérée (normale, me diriez-vous, mais c’est assez lourd quand-même).

Autrement, une fois qu’on a notre fonction, comme ça, c’est à peu près tout ce qu’il faut pour transformer n’importe quelle page web en PWA avec capacité de faire du offline (du moment qu’on séparre bien le shell de la page des données, d’où l’intérêt de travailler avec des requêtes Ajax qui envoie des données (json ou xml, html…) qui sont ensuite incorporées dans la page.

Le rendu est spectaculaire et 'achement rapide.

Regardez sur le site de Stéphanie Walter (sous Firefox) : c’est rapide comme l’éclair ! https://stephaniewalter.design/

Et pour cause : la gestion du cache est gérée par la page web (le service-worker) : il suffit de naviguer quelques pages pour que toutes les données soient mises en cache et après c’est super rapide : seulement 14 ko de données sont transférées pour la page d’accueil !

Et normalement ça fonctionne aussi en offline.

Oui, le navigateur a son propre cache… mais il est imprévisible, d’une part, et d’autre part il y a toujours des requêtes réseau de faites, qui vérifient si les cookies sont bons, si les ETAG sont modifiées, si le fichier n’a pas changé, etc.

Ici, les requêtes réseaux sont interceptées par le Service Worker.

Bien-sûr, ce n’est pas une raison pour se lâcher et arrêter d’optimiser ses pages : cette rapidité doit servir à permettre un usage offline du site (c’est pratique pour lecteur RSS en JS par exemple). J’ajoute simplement le raccourcis sur le bureau android (ou iOS, ou Windows 10 comme "webapp") et c’est bon !

Si je suis en ligne, il rapatrie les données mises à jour, autrement il utilise ce qu’il possède en cache.

En plus, les navigateurs utilisent des bases de données locales pour les données en cache : on peut donc très bien utiliser des BDD pour nos données (pas besoin de rester au JSON/XML).

https://lehollandaisvolant.net/img/35/fetch-serviceworkers.png

#18363

Navigator.sendBeacon() - Web APIs | MDN

À utiliser plutôt qu’un « onbeforeunload » dans lequel on met une dernière requête XHR sur lequel on désactive le async (sinon ça marchait pas). Ces derniers retardaient (de façon tout à fait logique) la fermeture de l’onglet et ça gênait le chargement de la page suivante.

Avec sendBeacon(), le navigateur ferme l’onglet et charge la page suivante, mais la « dernière requête » est faite quand le navigateur a le temps et de façon asynchrone.

J’utilise une « dernière requête » dans mon lecteur RSS : la liste des éléments lus est gardée dans un tampon mémoire local. Une requête n’est faite que quand on a 10 éléments : ça m’évite de faire une requête à chaque fois qu’on lit un article, et de surcharger le réseau pour rien.

Si le tampon n’est pas vide au moment de fermer l’onglet, j’utilise donc le .sendBeacon() qui envoie les derniers éléments lus au serveur.

window.addEventListener("beforeunload", function() {
	var formData = new FormData();

	// ajouter les champs du formulaire ici, comme avec une requête Ajax normale

	navigator.sendBeacon('ajax/rss.ajax.php', formData);
});

De même j’ai découvert ça :

document.addEventListener("visibilitychange", function() {
	// do stuff
});

Le « visibilitychange » c’est pour quand on passe à un autre onglet, ou si on met une autre application au premier plan (sur mobile).

Dans mon cas, je mets la même chose que dans le « beforeunload » : comme ça la requête est faite aussi quand l’utilisateur ferme l’onglet.

Faut pas oublier de tester le « document.visibilityState » qui peut prendre différentes valeurs. Dans mon cas, je teste pour « hidden » : inutile de lancer une requête si le visibilityChange concerne une remise au premier plan du navigateur.

Ce truc est utilisé par certains sites pour mettre en pause des vidéos quand on clic l’onglet. C’est d’ailleurs assez chiant quand c’est utilisé à ces fins là. Même chose pour les sites de téléchargement avec des décomptes de 30 secondes : le décompte est pausé quand on change d’onglet.

Je découvre pas mal en ce moment, et c’est vraiment cool tout ce qu’on peut faire en JS natif aujourd’hui :3

https://developer.mozilla.org/en-US/docs/Web/API/Navigator/sendBeacon

#18345

[JS] - Note

Je me note :

En JS, avec element.querySelector(), pour cibler un descendant direct de element, ceci ne marche pas :

element.querySelector('> .class');

Si element possède un id lui-même on peut faire ça :

element.querySelector('#id > .class');

Mais il y a une méthode dédiée :

element.querySelector(':scope > .class');

:scope est censée représenter l’élément sur lequel on utiliser querySelector(). C’est une notation CSS similaire similaire à « :root », et d’ailleurs, à ce jour, il est égal à :root (il n’a pas encore d’autres usages).

C’est censé marcher (même si je n’ai pas réussis sous Firefox).

Sinon, on peut toujours utiliser

element.firstElementChild

(attention, si querySelector() renvoie une nodeList, firstElementChild() renvoie une HTMLCollection.)

https://lehollandaisvolant.net/?mode=links&id=20190221013812