Vue 3 peut laisser des watchers orphelins lorsqu’ils sont créés après un await dans un composable ou un setup() asynchrone, car ils ne sont alors plus rattachés automatiquement au scope du composant. L’article explique comment éviter ces fuites mémoire : créer les watchers synchroniquement, utiliser le top-level await de <script setup>, conserver puis arrêter explicitement les watchers différés, et s’appuyer sur onScopeDispose ou effectScope hors contexte composant. Il recommande aussi de tester les cycles montage/démontage pour détecter les effets réactifs persistants.
ECMAScript 2026 introduit plusieurs améliorations pratiques à JavaScript, visant à simplifier des schémas courants et à combler des lacunes dans la bibliothèque standard. Plutôt que des changements syntaxiques majeurs, cette édition se concentre sur l'ajout de petites API qui réduisent le code répétitif, comme la gestion de collections de données.
Parmi les nouveautés, Map.prototype.getOrInsert() et Map.prototype.getOrInsertComputed() facilitent l'ajout ou la récupération de valeurs dans une Map, éliminant le besoin de vérifier manuellement l'existence d'une clé et de créer une valeur par défaut. De même, Array.fromAsync() permet de convertir des itérateurs asynchrones directement en tableaux, simplifiant la gestion des données récupérées de manière asynchrone.
D'autres fonctionnalités notables incluent Iterator.concat() pour combiner des itérables, une meilleure gestion des grands entiers lors du parsing JSON, des méthodes directes pour convertir Uint8Array en Base64 ou Hex, une fonction Error.isError() pour détecter les erreurs authentiques, et une approche plus fiable pour la somme de nombres à virgule flottante. Ces additions, bien que discrètes, améliorent l'efficacité et la lisibilité du code JavaScript.
TinyJS permet de créer des applications de bureau pour macOS, Windows et Linux avec une taille de fichier minimale d'environ 6 Mo. Il utilise un backend JavaScript exécuté sur txiki.js pour un accès complet au système et une fenêtre native (WebView) déjà présente sur le système d'exploitation, évitant ainsi l'embarquement de navigateurs lourds comme Electron.
La plateforme offre un accès système complet via RPC sur un socket Unix, des mises à jour à chaud sans étape de compilation pour le développement, et l'intégration d'éléments d'interface natifs comme les menus ou les boîtes de dialogue. TinyJS se distingue par sa légèreté et son approche minimaliste par rapport à des solutions comme Electron ou Tauri, tout en offrant la possibilité d'intégrer facilement du HTML, CSS et JavaScript existant.
L'utilisation de AbortController en JavaScript permet de gérer les requêtes API afin d'éviter la réception de données obsolètes. Dans les interfaces utilisateur dynamiques, comme les champs de recherche ou les filtres, plusieurs requêtes peuvent être lancées rapidement, et leur ordre d'arrivée peut ne pas correspondre à leur ordre d'envoi. Cela peut entraîner une "condition de concurrence" où une réponse plus ancienne écrase des résultats plus récents et pertinents.
Pour pallier ce problème, un AbortController peut être instancié pour chaque nouvelle requête. En passant son signal à la fonction fetch, il devient possible d'annuler explicitement la requête précédente avant d'en lancer une nouvelle. L'appel à la méthode abort() du contrôleur signale aux API compatibles d'interrompre leur opération.
Il est essentiel de distinguer l'annulation d'une requête des erreurs réseau. L'annulation déclenche un rejet de promesse spécifique qui ne doit pas être traité comme une erreur standard. En gérant ces annulations correctement, les applications peuvent garantir que seules les données les plus récentes sont affichées, améliorant ainsi l'expérience utilisateur.
Résumé pour Shaarli:
L'article explique comment prévenir les réponses obsolètes des API en utilisant AbortController. Cela est particulièrement utile pour les interfaces dynamiques où plusieurs requêtes peuvent être envoyées rapidement, créant un risque que des réponses plus anciennes arrivent après des plus récentes. AbortController permet d'annuler les requêtes en cours avant d'en lancer de nouvelles, garantissant ainsi que seules les données les plus à jour sont utilisées.
Les Web Workers offrent une solution pour exécuter des tâches JavaScript gourmandes en ressources sans bloquer le fil d'exécution principal du navigateur, ce qui permet de maintenir l'interactivité de l'interface utilisateur. Contrairement aux fonctions asynchrones qui planifient simplement du travail pour plus tard sur le même fil, les Web Workers créent un nouveau fil d'exécution séparé. Cela signifie que des opérations longues, comme le redimensionnement ou la compression d'images volumineuses, peuvent être effectuées en arrière-plan, libérant ainsi le fil principal pour gérer les interactions utilisateur, les mises à jour de l'interface et le rendu.
Les Web Workers fonctionnent selon deux règles fondamentales : ils ne peuvent pas accéder directement au DOM (Document Object Model) du navigateur et ils ne partagent pas d'état avec le fil principal. La communication entre le fil principal et le Web Worker s'effectue exclusivement par le biais de messages. Le fil principal envoie des données au worker, qui effectue le traitement et renvoie les résultats au fil principal. Cette architecture garantit que les opérations intensives ne perturbent pas l'expérience utilisateur.
En pratique, cela permet d'optimiser des fonctionnalités telles que le pré-traitement d'images avant leur envoi au serveur. Le code du Web Worker est écrit dans un fichier distinct et est instancié à partir du fil principal. La communication est gérée via postMessage pour envoyer des données et onmessage pour recevoir des réponses, permettant ainsi d'intégrer des calculs complexes de manière transparente dans les applications web.
MicroLighter est une bibliothèque de coloration syntaxique légère et sans dépendances, conçue pour être rapide et facile à intégrer. Elle ne génère pas de <span> superflus dans le code, ce qui contribue à sa performance. Les grammaires, au format TextMate utilisé par VS Code, peuvent être chargées de manière asynchrone pour optimiser le temps de chargement.
L'installation de MicroLighter se fait simplement via npm. Il suffit d'importer la fonction highlightAll et un thème CSS, puis d'ajouter la classe language-* aux blocs de code. Une option existe pour un chargement automatique immédiat, ainsi qu'un bundle pour utiliser des éléments personnalisés offrant des fonctionnalités comme la copie ou la numérotation des lignes.
MicroLighter prend en charge plusieurs langages de programmation, tels que JavaScript, CSS, HTML, Ruby, Python, SQL et C++. La librairie est pensée pour une utilisation efficace et moderne du code dans les projets web.
L'auteur présente sa structure HTML de base actuelle, expliquant les choix derrière chaque élément. L'idée principale est de fournir une base solide et bien pensée pour tout projet web, allant au-delà d'un simple copier-coller de modèles existants. Parmi les détails importants, il met en avant l'importance de la déclaration <!DOCTYPE html>, de l'attribut lang pour l'accessibilité et le SEO, ainsi que la gestion de l'encodage des caractères avec <meta charset="UTF-8">. L'utilisation d'une classe no-js sur la balise <html> est également soulignée pour permettre une gestion conditionnelle du JavaScript.
La balise <meta name="viewport"> est essentielle pour assurer un affichage correct et responsive sur les différents appareils mobiles. L'article détaille également la configuration des métadonnées pour l'optimisation des moteurs de recherche (SEO) et le partage sur les réseaux sociaux, incluant des éléments comme la description, le titre, les images et les URL canoniques. Des optimisations pour les icônes de favoris (favicon) et la gestion de la couleur de thème pour les applications web progressives (PWA) sont aussi mentionnées.
Enfin, l'auteur explique l'intégration de feuilles de style, y compris une version spécifique pour l'impression (media="print"), et l'inclusion de scripts JavaScript. L'utilisation de nomodule pour les polyfills JavaScript destinés aux anciens navigateurs et de type="module" pour les scripts modernes est expliquée, démontrant une approche soignée de la compatibilité et des performances.
L’article de Dmitry Zakharov critique l’usage de JSON.stringify en JavaScript, qu’il considère comme une mauvaise pratique à proscrire au profit d’outils d’encodage dédiés. Il souligne que cette fonction native, souvent utilisée par défaut, présente des risques majeurs : elle retourne undefined pour certains types (fonctions, undefined), génère des erreurs non explicites (comme pour les BigInt ou les structures circulaires), et surtout, elle corrompt silencieusement les données en les transformant en null ou en les omettant (par exemple, Infinity devient null, ou les clés avec undefined disparaissent).
L’auteur propose une alternative radicale : remplacer JSON.stringify par des encodeurs spécialisés, comme sa propre bibliothèque Sury, conçue pour éviter ces écueils. Il compare cette approche à la philosophie "Parse, don’t validate" de 2019, suggérant qu’elle pourrait devenir une norme dans l’écosystème JavaScript. Bien que JSON.stringify reste utile en interne pour certains encodeurs, Zakharov insiste sur le fait qu’elle ne devrait jamais apparaître directement dans le code applicatif.
Le site Web Without JS démontre qu'il est possible de créer des interfaces interactives et dynamiques en utilisant uniquement HTML et CSS, sans JavaScript. L'idée principale repose sur l'exploitation des fonctionnalités natives des navigateurs, comme les popovers, les modales ou les changements de thème, pour reproduire des comportements autrefois réservés aux frameworks JavaScript. La page met en avant des exemples concrets, tels que des menus déroulants, des notes modales ou des carrousels, tous implémentés avec des éléments HTML standards et des styles CSS.
Cependant, certaines fonctionnalités avancées, comme la persistance des données, la recherche en temps réel ou un bouton de copier-coller, nécessitent encore du JavaScript. Le site propose également une section Lab qui teste les limites des technologies utilisées, en indiquant pour chaque exemple s'il est compatible avec tous les moteurs de rendu ou s'il reste limité à Chromium. Les performances sont soulignées, avec une page de seulement 12 Ko et une feuille de style de 39 Ko, sans aucun script.
Enfin, le projet explore des solutions créatives pour des cas d'usage spécifiques, comme un système de notes exclusives, un carrousel utilisant le défilement natif ou un mode impression optimisé. L'objectif est de montrer que, malgré certaines contraintes, HTML et CSS peuvent offrir une expérience utilisateur riche et moderne, tout en réduisant la dépendance aux technologies lourdes.
L’article de Smashing Magazine explore l’utilisation de SMIL (Synchronized Multimedia Integration Language) pour animer des SVG, une alternative méconnue aux animations CSS ou JavaScript. SMIL permet d’animer intégralement un SVG, y compris via la balise <img>, sans recourir à JavaScript, bien que certaines propriétés comme viewBox ne disposent pas encore d’équivalents CSS. L’auteur souligne que SMIL, malgré sa syntaxe verbeuse, offre une solution native pour des animations complexes, notamment lorsque JavaScript est bloqué.
Pour simplifier la gestion des animations SMIL, souvent alourdies par des balises répétitives (une par propriété et élément), l’auteur propose de planifier les animations à l’avance en utilisant des timing charts (diagrammes de timing). Ces diagrammes, inspirés de segments de ligne, aident à visualiser les séquences, chevauchements et synchronisations entre animations, facilitant ainsi leur conception et leur maintenance. Une approche visuelle qui rappelle les principes de parallélisme et de séquencement en animation.
L’article explore l’évolution des pseudo-classes CSS qui, bien que conçues pour gérer des états, peuvent parfois imiter le comportement des écouteurs d’événements JavaScript. L’auteur souligne que des pseudo-classes comme :hover, :active, :focus ou :checked réagissent à des interactions utilisateur (clic, survol, focus), offrant une alternative à JavaScript pour des cas simples. Par exemple, :focus-visible utilise des heuristiques pour déterminer si un élément doit afficher un indicateur de focus, une logique difficile à reproduire efficacement en JavaScript.
L’auteur aborde aussi des pseudo-classes plus avancées comme :focus-within et :has(), qui permettent de cibler des éléments parents en fonction de l’état de leurs enfants, réduisant ainsi le besoin de scripts. Ces fonctionnalités illustrent comment CSS gagne en expressivité, notamment avec des spécifications émergentes comme les Animation Triggers, qui pourraient un jour permettre de déclencher des animations via des événements. Cependant, ces innovations restent encore en développement.
Enfin, l’article mentionne des pseudo-classes liées aux formulaires (:valid, :invalid, etc.), qui simplifient la gestion des états de validation sans recourir à JavaScript. L’auteur conclut que, malgré ces avancées, CSS et JavaScript restent complémentaires, chacun ayant ses forces pour gérer les interactions et la logique applicative.
Comment réduire votre dépendance en JavaScript grâce à Baseline
L’article explique comment le projet Baseline, porté par le WebDX Community Group, permet d’alléger les applications JavaScript en remplaçant des bibliothèques tierces par des fonctionnalités natives du navigateur. Beaucoup de dépendances courantes (formatage de dates, requêtes HTTP, modales, etc.) sont désormais intégrées aux navigateurs modernes, réduisant ainsi le poids des applications de 60 à 90 Ko (minifié et compressé). L’auteur propose une méthode pour auditer ces dépendances en regroupant les fonctionnalités par niveau de maturité (Limited, Newly available, Widely available), afin d’identifier celles qui peuvent être supprimées sans risque.
Baseline fournit un cadre clair pour évaluer la compatibilité des fonctionnalités via des outils comme webstatus.dev ou MDN, qui indiquent leur statut (nouveau, stable ou en développement). L’article insiste sur l’importance de réévaluer régulièrement ses dépendances, car le web évolue rapidement. Une approche structurée permet de supprimer des bibliothèques obsolètes tout en maintenant la compatibilité avec les anciens navigateurs si nécessaire.
L’article explique comment gérer la concurrence sur le web avec l’API Web Locks, en s’appuyant sur un cas concret chez OLX : le téléchargement de gros fichiers (jusqu’à 20 Go). Pour permettre à l’utilisateur de continuer à naviguer tout en uploadant, OLX a mis en place un système de reprise des téléchargements, mais cela a posé un problème de synchronisation lorsque plusieurs onglets tentent de reprendre le même téléchargement simultanément, entraînant des doublons coûteux.
L’auteur, ingénieur frontend chez OLX, compare les verrous (locks) à la gestion d’une cuisine professionnelle, où plusieurs tâches doivent être coordonnées pour éviter les conflits. Il souligne que, contrairement aux applications multithreads en Java, le développement web moderne (avec React, Web Workers, etc.) doit désormais intégrer des mécanismes de synchronisation pour éviter des situations chaotiques, comme des téléchargements dupliqués ou des coûts inutiles.
La solution proposée repose sur l’API Web Locks, qui permet de réserver une ressource partagée (comme un téléchargement) pour un seul onglet à la fois. L’article introduit d’abord le concept de verrou, essentiel pour éviter les incohérences dans les systèmes concurrents, avant de détailler son implémentation pratique pour résoudre le problème de reprise des uploads chez OLX.
Travels est une bibliothèque JavaScript légère et agnostique des frameworks, conçue pour implémenter des fonctionnalités d'annulation (undo) et de rétablissement (redo) optimisées pour les états volumineux et les mises à jour fréquentes. Contrairement aux solutions classiques qui copient l'intégralité de l'état à chaque modification, Travels stocke uniquement les différences (JSON Patch selon la RFC 6902), réduisant ainsi considérablement l'empreinte mémoire et facilitant la persistance des historiques.
Compatible avec React, Vue, Zustand ou JavaScript vanilla, cette solution cible les applications interactives comme les éditeurs de texte ou les outils de dessin. Elle propose des modes avancés (journal contrôlé, mode mutable ou archivage) pour s'adapter à différents besoins, tout en garantissant une gestion efficace des historiques longs et des mises à jour mineures.
Le projet, maintenu sous licence MIT, inclut des benchmarks, des exemples et une documentation détaillée pour faciliter son intégration. Il s'appuie sur Mutative, un moteur de patch JSON performant, et vise à équilibrer performance, scalabilité et simplicité d'utilisation.
Gridstack.js est une bibliothèque TypeScript moderne et sans dépendances externes, conçue pour créer rapidement des tableaux de bord interactifs et réactifs. Elle permet de concevoir des interfaces avec des éléments déplaçables, redimensionnables et adaptés aux mobiles, tout en offrant des fonctionnalités avancées comme la gestion de grilles imbriquées ou le déplacement d'éléments entre plusieurs grilles.
Compatible avec divers frameworks (Angular, React, Vue, etc.), Gridstack.js simplifie l'intégration grâce à des wrappers dédiés et des exemples prêts à l'emploi. Son utilisation se résume à quelques lignes de code, comme l'installation via npm et l'initialisation d'une grille avec des widgets personnalisables.
Le projet, open source et maintenu activement, bénéficie d'une communauté active et est utilisé par de nombreuses entreprises. Une version de démonstration interactive est disponible sur le site pour en tester les capacités.
L’article de Victor Ayomipo, publié sur Smashing Magazine, remet en question la règle souvent absolue de ne jamais bloquer le fil principal (main thread) du navigateur en JavaScript. Bien que cette pratique soit généralement déconseillée pour éviter de figer l’interface utilisateur, l’auteur explique qu’il a dû y déroger lors du développement d’une extension Chrome de capture d’écran, Fastary. Malgré l’utilisation d’un Offscreen Document (un processus en arrière-plan), les opérations sur le canevas restaient lentes, parfois plus que si elles avaient été exécutées directement sur le fil principal.
L’argument central repose sur les limites des architectures recommandées, qui séparent strictement les tâches lourdes des opérations d’interface. L’auteur souligne que la communication entre les différents contextes (fil principal, Web Workers, Service Workers) peut introduire des latences supplémentaires, notamment lors de la sérialisation et désérialisation des données. Dans certains cas, comme celui de son extension, le transfert de travail vers un fil secondaire s’est avéré plus lent que de le laisser sur le fil principal.
Pour illustrer ce propos, l’article aborde brièvement l’architecture d’isolation des contextes du navigateur, expliquant comment les différents environnements (fil principal, Web Workers, etc.) communiquent entre eux. Cette analyse met en lumière les compromis inhérents aux bonnes pratiques en matière de performance, invitant les développeurs à évaluer au cas par cas l’opportunité de bloquer le fil principal.
L’article de Mat Marquis sur Piccalilli explore l’utilisation des Proxy et Reflect en JavaScript, des outils puissants pour intercepter et modifier les opérations internes sur les objets. L’auteur explique comment ces mécanismes permettent de mieux comprendre le fonctionnement profond du langage, un atout pour les développeurs souhaitant progresser vers un niveau senior. Il illustre leur utilité en montrant comment un Proxy agit comme intermédiaire entre un objet cible et les opérations qui lui sont appliquées, tout en soulignant leur rôle dans l’apprentissage des mécanismes internes de JavaScript.
L’article s’inscrit dans le cadre du cours JavaScript for Everyone de Piccalilli, bien que présenté comme un extrait non listé, laissant planer un mystère sur son intégration future. Marquis aborde ensuite la structure des objets JavaScript, détaillant les étapes internes déclenchées par l’accès à une propriété (comme la recherche dans la chaîne de prototypes ou l’invocation d’un accesseur), avant d’introduire le Proxy comme moyen de personnaliser ces comportements.
Enfin, l’auteur propose un exemple concret de création d’un Proxy, avec un objet cible et un gestionnaire vide, montrant comment l’objet proxy résultant encapsule à la fois la cible et le gestionnaire via des slots internes. L’article se termine sur une note engageante, invitant le lecteur à explorer davantage ces fonctionnalités pour maîtriser JavaScript au-delà de la syntaxe.
Driver.js est une bibliothèque JavaScript légère et sans dépendances, conçue pour créer des visites guidées de produits, des surbrillances et des aides contextuelles. Elle fonctionne avec tous les navigateurs majeurs, y compris sur mobile, et est compatible avec les frameworks comme React, Vue ou Angular. Écrite en TypeScript et distribuée sous licence MIT, elle est facile à intégrer et à personnaliser.
Cette solution permet d’accompagner les utilisateurs lors de leur première utilisation, de mettre en avant de nouvelles fonctionnalités ou de guider pas à pas dans des formulaires. Son API flexible couvre des cas d’usage variés, comme l’onboarding, les tutoriels interactifs ou la réduction des distractions.
Avec plus de 4 millions de téléchargements mensuels et une adoption par des entreprises comme Red Hat ou Intel, Driver.js se distingue par sa simplicité d’utilisation et son poids plume (environ 5 Ko). Son code source est disponible sur GitHub sous licence MIT, sans obligation d’attribution.
Cette page propose une collection de composants web (accordéons, carrousels, modales, etc.) réalisables avec peu ou pas de JavaScript, en exploitant les capacités modernes de HTML et CSS. L’objectif est de réduire la charge JavaScript sur les sites, souvent excessive pour des fonctionnalités simples. Le projet est open source et disponible sur GitHub, avec des exemples concrets et des démonstrations.
L’auteur souligne l’importance de transférer le travail des tâches basiques vers HTML/CSS, tout en critiquant les approches trop dépendantes de JavaScript. La page inclut aussi des ressources externes et des liens vers des experts du domaine, encourageant les contributions via des pull requests pour enrichir la collection.
La version 9 de TanStack Table réduit jusqu’à 90 % l’utilisation mémoire par rapport à la version 8, notamment pour les grands jeux de données. Cette amélioration, issue d’un refactoring subtil, permet de traiter 10 à 16 millions de lignes avant d’atteindre la limite des 4 Go de mémoire, contre 1 à 1,5 million auparavant. Les gains sont particulièrement marqués pour les tables paginées ou virtualisées avec des centaines de milliers de lignes.
Les benchmarks montrent une réduction significative de la consommation mémoire dès 1 000 lignes, avec des économies dépassant 2 Go pour 1 million de cellules (1 million de lignes × 8 colonnes). Les performances restent similaires pour les petits jeux de données, mais l’écart se creuse rapidement à mesure que la taille des données augmente.
Cette optimisation repose sur une refactorisation simple, avec un impact minimal (une seule rupture de compatibilité). L’approche pourrait inspirer d’autres bibliothèques pour améliorer leur gestion mémoire, bien que l’utilisation de 15 millions de lignes côté client reste rare dans la pratique.