A collection of websites focused on browsers usage and features.
L'API Sanitizer arrive tout doucement dans Firefox, pour aider à se prémunir efficacement contre les attaques XSS.
Une ode au web des années 2000 où la créativité primait sur le reste.
L'API Invoker devrait s'étoffer dans les années à venir pour proposer plus de commandes déclaratives qui ne nécessitent pas de code JavaScript.
Je n'aime pas Vercel mais cette page regroupe de bons conseils en matière de construction d'interface graphique pour le web.
Un outil pour exposer publiquement une application qui tourne sur votre machine via un tunnel TCP.
Un article passionnant qui expose de manière argumentée le problème de la gestion des dépendances dans le JavaScript côté client, la courbe d'apprentissage ardue qu'elle représente pour les néophytes et de l'omniprésence des bundlers.
Il n'y a pas de solution immédiate et évidente mais quelques pistes.
Un serveur de fichier complet et léger.
Alternative : https://copyparty.eu/
Un important rappel que, quand bien même les interfaces disponibles dans nos navigateurs sont standardisées, leur implémentation ne l'est pas et dépend souvent de services privés dont l'éthique peut ne pas être ce que l'on imagine (la géolocalisation dans Chrome, par exemple).
Si l'article est trop long pour vous, lisez au moins la section Why This Matters.
Un article un peu ancien(2021) mais qui explique le principe du CORS qui rend fou de nombreux développeurs.
C'est un concept que je conseille à tous les dev web de maîtriser sur le bout des doigts histoire d'éviter de futures prises de tête.
Retour d'expérience sur une tentative de migration mitigée de Electron vers Tauri (2 technologies permettant de développer des applications de bureau avec les technos web).
La "nouvelle" Navigation API vise à remplacer l'actuelle History API qui n'a jamais été très ergonomique.
Cette nouvelle API est assez massive, elle propose – notamment pour les SPA (Single Page Application) – de centraliser la gestion de la navigation à un seul endroit.
Bien évidemment, ça ouvre la porte aux sites qui vont vouloir en faire trop, qui vont vouloir outrepasser le comportement natif du navigateur, et ça peut finir en grand n'importe quoi comme à l'époque des popups.
Heureusement il semble y avoir quelques garde-fous pour, par exemple, empêcher un site de rendre le bouton de retour natif du navigateur inopérant et ainsi vous piéger dessus.
Par contre j'imagine que rien n'empêche un site de créer des navigations programmatiques artificielles lorsque vous arrivez dessus pour qu'il faille appuyer un grand nombre de fois sur "retour" pour s'en échapper. Mais c'est techniquement déjà possible avec l'History API de toute façon.
C'est pour l'instant uniquement supporté par les navigateurs basés sur Chromium.
La documentation MDN est également disponible.
Je ne pourrais pas être plus d'accord.
C'est encore une fonctionnalité native simple mais très puissante des navigateurs que certains frameworks ont encouragé à ignorer et à remplacer maladroitement.
Ça ne veut pas dire qu'il faut bannir le state en mémoire, mais simplement comprendre les avantages et inconvénients de chacun et les utiliser à bon escient. L'article illustre ça avec beaucoup de justesse.
Un navigateur web alternatif, basé sur Chromium, mais qui met l'accent sur la légèreté, le respect de la vie privée et l'absence de requêtes intempestives en arrière-plan sans votre consentement.
Il en est à ses débuts mais semble prometteur.
Contrairement à Chrome, il supporte encore les extensions au format MV2 comme uBlock Origin (qui est d'ailleurs installé par défaut).
Une explication assez simple et explicite de l'objectif du protocole atproto qu'utilise Bluesky.
Même si l'implantation qu'en fait Bluesky actuellement est centralisée, j'aime assez l'idée de rendre les interactions sociales décentralisées et "possédées" par les gens grâce à leur nom de domaine.
Un (long !) tour d'horizon chronologique des pratiques qui furent standard en matière de développement front-end, avant de devenir désuètes.
J'aime particulièrement la conclusion, que j'applique de plus en plus, contre vents et marées de développeurs qui veulent foutre du React partout :
Technologies come and go, but the contract with the browser remains. Choose the simplest path that produces high quality HTML, CSS, and JavaScript. The closer you stay to the platform, the easier your product will be to maintain, to make accessible, and to run fast at scale.
Traduction à la mano :
Les technologies vont et viennent, mais le contrat que l'on passe avec le navigateur, lui, reste. Choisissez le chemin le plus direct qui produise du HTML, CSS et JavaScript de qualité. Plus vous restez proche de la Web Platform plus il sera facile de maintenir votre site ou app, de le rendre accessible et performant.
Je ne connaissais pas Gopher, un concurrent au web que nous connaissons bien, à l'époque de sa naissance. Il est même arrivé un peu avant.
Un exercice intéressant ! L'auteur étudie les performances des sites web des écuries des coureurs du tour de France et les classe du plus au moins performant, et il s'intéresse ensuite aux détails d'implémentation et à ce qui aurait encore pu encore être amélioré.
Une mine d'infos si vous vous intéressez à l'optimisation des pages web.
Une gigantesque collection de liens vers des articles orientés performances web, mais aussi une liste de blogueurs à suivre si vous vous intéressez au web de manière générale.
Une liste de newsletters à destination des gens qui développent et créent pour le web.