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.
Dans 99% des cas, le cloud est une fausse promesse qui vous coûtera cher.
Des "starter packs" de comptes à suivre sur le Fediverse, classés par thème.
Ces packs sont une fonctionnalité qui arrivera dans Mastodon 4.6, la prochaine version. Bluesky avait initié cette idée qui a très bien marché au début.
Un Web Component qui permet de choisir une couleur.
Il y a un color picker natif mais sur certaines plateformes le choix de couleur est limité.
Un outil qui permet de s'assurer qu'un package publié suit les bonnes pratiques.
Une liste de petites applications utilitaires qui ont la particularité de tourner intégralement dans le terminal, mais de proposer néanmoins une interface "graphique".
Un outil qui permet de gérer la synchronisation d'applications de type offline first, c'est à dire qu'elles stockent leurs données localement et les synchronisent par différents moyens supportés par cette lib (en local via le navigateur, via le réseau, etc.).
Gérer ce type de synchro soi-même peut sembler simple mais ça devient vite un cauchemar lorsqu'il y a des conflits entre 2 clients ou plus. D'où l'intérêt de ces outils optimisés.
Accessoirement j'adore le design de leur site !
Un parallèle que j'aime bien entre l'écriture et le fait d'être un bon manageur.
L'inverse n'est cependant pas vrai. Je connais des gens qui écrivent très bien mais sont de très mauvais manageurs.
Gestion de la navigation à travers une page web avec la touche de tabulation.
Un type d'attaque propre à JavaScript, et qu'il est important de comprendre pour écrire du code sécurisé.
Quelques pistes pour se protéger des supply chain attacks.
Une explication de ce qu'est OKLCH (utilisable notamment en CSS) accompagnée d'outils pour générer des palettes de couleurs.
Un retour d'expérience (à nuancer comme toujours) sur une migration de Python vers Node justifiée par la difficulté d'écrire du code asynchrone avec Python.
Une application de gestion et de partage de photos open source et à auto-héberger.
J'ai un peu le même ressenti que celui exprimé dans cet article. Dans l'idée j'adore ce qu'est NextCloud et c'est heureux qu'il existe pour offrir une véritable alternative ouverte aux GAFAMs, mais j'ai toujours eu cette impression de lourdeur qui me bloque un peu.
Les ADRs sont de simples documents, souvent au format texte, qui visent à documenter les prises de décision qui impactent la façon de développer une application.
L'idée est de justifier et d'expliquer les choix effectués.
Un système de commentaire à la Disqus, assez ingénieux, qui utilise le système de discussions de GitHub pour "stocker" et modérer les commentaires.
C'est visiblement facile à intégrer.
Via https://alfy.blog/2025/08/22/from-code-that-works-to-code-that-matters.md.html
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.
Cet article suggère que PostgreSQL peut à peu près tout faire et représente donc une solution idéale pour la majorité des boîtes dont les besoins en scalabilité (évolution de la charge) ne seront jamais suffisants pour justifier une infra plus complexe.
C'est l'idée de MVI : minimum viable infrastructure.
J'aime bien le côté pragmatique, même si ça implique, de fait, une très grande maîtrise de PostgreSQL.
Une application qui semble faire du speech to text (reconnaissance vocale, vous parlez, l'outil écrit ce que vous dites) assez efficacement.