JavaScript ne se résume pas à un seul langage isolé : autour de lui gravitent des frameworks, des outils, et des bibliothèques spécialisées, que vous croiserez tôt ou tard en discutant avec un développeur, en lisant une documentation, ou en configurant un plugin. Ce chapitre ne vous apprend pas à coder avec ces outils — il vous donne les repères pour les reconnaître, les situer les uns par rapport aux autres, et comprendre à quoi ils servent.
En conclusion de ce chapitre, vous trouverez les trois axes prioritaires pour un Concepteur Designer.
1. Le langage lui-même, et ses variantes
JavaScript, TypeScript
Un langage de programmation est un ensemble de règles d’écriture que l’ordinateur sait comprendre et exécuter. TypeScript n’est pas vraiment une « variante » au sens strict : c’est une surcouche de JavaScript, qui se transforme en JavaScript classique (via compilation) avant d’être exécutée par le navigateur.
2. Un outil historique, à part
jQuery, et d’autres, aujourd’hui largement abandonnés (Zepto, Prototype.js)
jQuery a longtemps été la référence pour manipuler une page facilement en JavaScript. Sa logique est différente de celle des outils modernes de la catégorie suivante (il agit directement sur des éléments déjà existants, plutôt que de gérer l’affichage à partir d’un état) — ce n’est donc pas un concurrent direct des noms cités plus bas, même s’il reste très présent dans d’anciens sites, notamment sous WordPress.
3. Les outils modernes pour construire des interfaces
React, Vue, Angular, Svelte, et d’autres (Solid, Qwik, Preact)
Ces outils permettent de construire une interface complète à partir de composants réutilisables. Nuance à connaître : parmi eux, React est à proprement parler une bibliothèque et non un framework complet — elle ne gère que l’affichage, contrairement à Angular par exemple, qui intègre nativement bien plus (routage, gestion des données…). Dans l’usage courant, React est cependant très souvent citée aux côtés des frameworks, par simplification.
4. Les méta-frameworks
- Pour React : Next.js, React Router (en mode framework, héritier direct de Remix), et d’autres
- Pour Vue : Nuxt, et d’autres
- Pour Svelte : SvelteKit, et d’autres
- Astro, à part : contrairement aux précédents, il n’est pas lié à un seul framework — il peut accueillir des composants React, Vue ou Svelte, ou aucun framework du tout, et convient particulièrement aux sites à contenu principalement statique (blogs, sites vitrines)
Un méta-framework est un outil construit par-dessus un framework ou une bibliothèque existante (comme React), qui lui ajoute des fonctionnalités supplémentaires (comme le rendu côté serveur, utile pour le référencement). Angular n’apparaît pas dans cette liste : le rendu côté serveur fait partie de son écosystème officiel (via @angular/ssr), sans nécessiter un outil externe distinct comparable à Next.js ou Nuxt (auparavant, cette fonctionnalité passait par un module séparé, Angular Universal).
5. La communication asynchrone avec le serveur
Le principe général s’appelle Ajax.
- Les méthodes natives, intégrées au navigateur sans rien installer : XMLHttpRequest (ancienne), Fetch (moderne)
- Les bibliothèques tierces qui simplifient cet échange : Axios, et d’autres
Asynchrone : pas besoin d’attendre — la page reste utilisable pendant que les données vont et viennent avec le serveur.
6. Le format des données échangées
JSON (autrefois XML, aujourd’hui moins utilisé)
Un format de données est une façon d’écrire une information pour que deux systèmes différents puissent se la transmettre et la comprendre. Le nom JSON n’est d’ailleurs pas un hasard : il signifie littéralement « JavaScript Object Notation » — sa syntaxe est directement héritée de celle des objets en JavaScript.
7. L’environnement et l’outillage
- Faire fonctionner JavaScript en dehors du navigateur : Node.js, Deno, Bun, et d’autres
- Installer des bibliothèques JavaScript : npm, Yarn, pnpm, et d’autres
- Préparer le code avant sa mise en ligne : Webpack, Vite (plus récent, avec un fonctionnement interne différent), et d’autres
- Tester automatiquement que le code fonctionne correctement : Jest, Vitest, Cypress, Playwright, et d’autres
Ce sont les outils qui entourent le développement JavaScript, sans faire partie du résultat final visible par l’utilisateur.
8. Des bibliothèques ciblées, chacune dédiée à un effet précis
- Animer des éléments à l’écran : GSAP, Anime.js, Motion (anciennement Framer Motion), Motion One (version plus légère, du même créateur), et d’autres
- Rendre le défilement de la page plus fluide : Lenis, Locomotive Scroll, et d’autres
- Créer des graphismes en 3D : Three.js, Babylon.js, et d’autres
- Construire un slider ou un carrousel d’images : Splide, Swiper, Glide.js, et d’autres
- Créer des graphiques et visualisations de données : Chart.js, D3.js, Highcharts, et d’autres
- Glisser-déposer des éléments (drag and drop) : Sortable.js, interact.js, et d’autres
- Enrichir une carte au-delà d’un simple embed figé (chapitre 95) : Leaflet, Mapbox GL, et d’autres
- Enrichir un lecteur vidéo au-delà d’un simple embed figé (chapitre 90) : Video.js, Plyr, et d’autres
Contrairement aux outils de la catégorie 3, qui servent à construire toute une interface, celles-ci ciblent un seul effet précis. Cette liste n’est qu’un échantillon : il existe de nombreuses autres familles de ce type.
Un dernier mot : l’API
Vous croiserez très souvent ce mot en lien avec tout ce qu’on vient de voir — notamment les catégories 5 et 6 ci-dessus, puisque Ajax et Fetch servent justement à dialoguer avec une API. Ce n’est volontairement pas une catégorie de ce panorama : une API n’est pas spécifique à JavaScript, ni même au web — c’est un concept plus large, indépendant du langage utilisé.
API : un point d’accès mis à disposition par un service, pour que d’autres programmes puissent lui demander ou lui envoyer des informations.
API REST : une façon précise et très répandue d’organiser cet accès, avec une adresse dédiée pour chaque type de donnée, et des réponses généralement au format JSON.
Conclusion
Dans un premier temps, le concepteur designer doit connaître ces éléments pour pouvoir discuter avec des développeurs ou des chefs de projet — sans avoir à tout mémoriser par cœur, mais en gardant une conscience de cet environnement : savoir qu’un mot existe, à quelle famille il appartient, et vaguement à quoi il sert, suffit pour ne pas être perdu dans une conversation technique.
D’un point de vue plus opérationnel, trois axes de compétences concrètes se dégagent de ce panorama.
1. Générer et placer du JavaScript avec l’aide d’une IA
Il ne s’agit pas d’apprendre à écrire du JavaScript à la main depuis zéro, mais de savoir faire générer un script, le tester — en console, ou via une expérimentation concrète — et surtout savoir où l’insérer dans un site réel, typiquement dans WordPress (header, footer, champ de code dédié, plugin…).
C’est une compétence d’intégration assistée, pas de programmation à proprement parler.
Cette production doit systématiquement se terminer par un réflexe de sécurité, même basique : s’interroger sur ce que ce script pourrait exposer ou permettre de détourner, quitte à demander à l’IA elle-même de faire cette relecture avant la mise en production. Un code qui s’affiche mal se voit et se corrige ; un code qui compromet la sécurité d’un site peut rester invisible longtemps, avec des conséquences autrement plus graves.
Ce même réflexe s’applique à la question du poids : ce n’est pas la génération par IA en tant que telle qui pose problème (quelques lignes ont un impact négligeable), mais le volume cumulé de JavaScript et de bibliothèques ajoutées au fil du temps — un coût à garder en tête avant chaque nouvelle mise en ligne.
2. Comprendre la logique des bibliothèques ciblées, sans les maîtriser
Ce sont celles qu’on a listées dans ce chapitre pour l’animation, le défilement fluide, la 3D, ou les sliders.
Le concepteur designer doit être en mesure soit de les intégrer lui-même (comme cela a été fait avec Splide), soit de choisir un plugin WordPress qui embarque déjà l’une d’entre elles à sa place.
L’essentiel n’est pas de savoir la coder, mais de comprendre ce qu’elle fait, pourquoi on la choisit plutôt qu’une autre — en gardant en tête que chaque bibliothèque ajoutée représente un coût en temps de chargement.
3. Savoir repérer un plugin qui utilise Ajax, sans le coder
Prenons l’exemple d’une boutique en ligne sous WooCommerce : en PHP seul, sans JavaScript, une recherche de produits ne peut pas afficher instantanément ses résultats — photos, noms, prix — sans recharger la page entière.
Avec Ajax, ces informations peuvent être récupérées à la volée, sans rechargement.
Le concepteur designer n’a pas à coder ce mécanisme, mais il doit être capable de reconnaître qu’un plugin de recherche instantanée repose vraisemblablement dessus — pour en discuter intelligemment, choisir la bonne solution, ou l’expliquer à un client.