Espace client
Espace client

JavaScript

J

JavaScript est ce qui rend un site vivant. Sans lui, une page se contente d’afficher : chaque action du visiteur oblige à repartir vers le serveur, à attendre, puis à recharger la page entière. Avec lui, la page réagit sur place : un filtre se met à jour, un menu se déplie, une carte se déplace, un formulaire signale une erreur avant même d’être envoyé. C’est ce qui permet un rendu au plus proche de ce qu’on avait imaginé, et surtout dans l’immédiat.

Cette immédiateté n’a rien de magique, elle vient d’une idée maligne : faire travailler le navigateur et la machine du visiteur plutôt que votre serveur. Le calcul se fait là où se trouve la personne, donc sans aller-retour, donc sans attente. C’est aussi ce qui explique la contrepartie : ce travail, quelqu’un le fait quand même. Un site qui multiplie les éléments dynamiques déporte une charge croissante sur des machines dont vous ne savez rien, et le confort de consultation finit par s’en ressentir.

J

Le même métier que PHP, mais pas au même endroit

La façon la plus juste de situer JavaScript est de le comparer à PHP. Les deux sont des langages de programmation, et ils savent faire globalement les mêmes choses : calculer, trier, décider, manipuler des données. La vraie différence n’est pas leur nature, c’est le lieu d’exécution. PHP travaille sur le serveur, fabrique la page puis l’envoie. JavaScript travaille ensuite, dans le navigateur, sur la page déjà reçue. L’un prépare, l’autre anime.

Cette répartition a une conséquence directe sur ce que vous ressentez. Ce qui passe par le serveur coûte un aller-retour sur le réseau, quelques centaines de millisecondes au mieux. Ce qui se joue en JavaScript ne coûte aucun voyage : la réponse est instantanée parce qu’elle ne quitte jamais la machine du visiteur. En contrepartie, elle dépend entièrement de cette machine, de sa mémoire et de son processeur. Précision utile : depuis Node.js, apparu en 2009, JavaScript sait aussi tourner côté serveur, exactement là où PHP officie. La frontière n’est donc pas une propriété du langage, c’est un choix d’architecture.

JavaScript

Ce que le dynamique change dans l'usage quotidien

Filtrer un catalogue sans attendre. Sur une boutique, choisir une taille, une couleur et une fourchette de prix relève typiquement de JavaScript. Chaque critère affine la liste immédiatement, sans recharger la page. Le même parcours sans JavaScript demanderait un rechargement complet à chaque clic, et une bonne partie des visiteurs abandonnerait en route. Ici, l’immédiateté n’est pas du confort, c’est du chiffre d’affaires.

Guider la saisie d’un formulaire. Signaler une adresse e-mail mal écrite au moment où elle est tapée, afficher un champ supplémentaire seulement s’il devient pertinent, indiquer qu’un créneau est complet : autant de corrections faites sur place. Elles évitent au visiteur d’envoyer, d’attendre, puis de recommencer, et elles réduisent nettement les abandons en cours de route.

Rendre un outil métier agréable à utiliser. C’est sur les applications internes que la différence se voit le mieux. Un tableau de bord où l’on trie une colonne, replie une section ou modifie une ligne sans jamais recharger devient un outil qu’on utilise volontiers. Le même écran en rechargement complet à chaque action devient une corvée, et les équipes finissent par le contourner. L’adoption d’un outil se joue souvent là.

Afficher ce qui vient d’ailleurs. Une carte, un agenda de réservation, un lecteur vidéo, un module d’avis clients : ces éléments arrivent en JavaScript, souvent fournis par un service tiers. Ils rendent service, mais chacun ajoute son propre poids à la page, et c’est le cumul qui pose problème, jamais le premier.

Garder la main sur la quantité

J

Se demander à chaque ajout si le dynamique sert le visiteur. Un carrousel qui défile tout seul, une animation à l’apparition, un compteur qui s’incrémente : chacun paraît gratuit au moment où on l’ajoute, aucun ne l’est. La bonne question n’est pas « est-ce que ça fait joli ? » mais « est-ce que cela aide quelqu’un à faire ce qu’il est venu faire ? ». La réponse est souvent non, et c’est le meilleur moment pour renoncer.

Mesurer plutôt que ressentir. Votre site vous paraît rapide parce que votre navigateur a tout gardé en mémoire et que votre connexion est bonne. Vos visiteurs, eux, arrivent en 4G sur un téléphone de milieu de gamme. Les Core Web Vitals mesurent exactement cet écart, et ils sont pris en compte par Google. C’est une mesure, pas une impression, et elle se consulte régulièrement.

Compter les services tiers. Chaque outil externe ajouté, statistiques, chat, bandeau de consentement, pixel publicitaire, module d’avis, embarque son propre JavaScript, que vous ne maîtrisez pas et qui évolue sans vous prévenir. Un inventaire annuel de ces briques réserve souvent des surprises : il en reste toujours qui ne servent plus depuis longtemps et continuent de peser sur chaque page.

Traiter la performance comme un sujet continu. Un site rapide au moment de sa mise en ligne ne le reste pas tout seul. Les fonctionnalités s’ajoutent une par une, chacune raisonnable, et c’est la somme qui dégrade l’ensemble sans qu’aucune décision n’ait été identifiée comme fautive. Un point régulier sur le temps de chargement vaut mieux qu’une refonte trois ans plus tard.

JavaScript

Quand l'accumulation se retourne contre le confort

La charge mémoire ne se voit pas depuis votre bureau. Multiplier les éléments dynamiques sur une même page mobilise la mémoire et le processeur du visiteur. Le symptôme n’est pas une page qui ne s’affiche pas, c’est un défilement qui accroche, un clic qui répond avec un temps de retard, un téléphone qui chauffe. Sur une machine récente, rien ne se remarque. Sur un ordinateur de cinq ans ou un téléphone d’entrée de gamme, la consultation devient désagréable, et personne ne vous le signalera jamais.

Une grande partie du JavaScript chargé ne sert à rien. Le constat est documenté à l’échelle du web : d’après le Web Almanac 2024, le poids médian de JavaScript par page atteint 558 kilooctets sur mobile, en hausse de 14 % en un an, et près de 44 % de ces octets ne sont jamais utilisés. Vos visiteurs téléchargent et attendent du code qui ne leur servira pas. C’est le résultat d’ajouts successifs jamais réexaminés, pas d’une faute unique.

Le vieux procès du référencement mérite d’être rejugé. Pendant des années, un site dont le contenu était produit par JavaScript se référençait mal : le robot de Google ne l’exécutait pas et ne voyait qu’une page vide. La règle « le JavaScript nuit au référencement » s’est installée, et elle circule encore aujourd’hui alors qu’elle a largement cessé d’être vraie. Google exécute désormais le JavaScript et les techniques de rendu côté serveur sont courantes. Le sujet n’a pas disparu, il a changé de nature : il ne s’agit plus de savoir si le contenu sera vu, mais à quel coût et avec quelle fiabilité.

Tout ne doit pas être déporté chez le visiteur. Faire travailler la machine de l’utilisateur est malin tant que le travail reste raisonnable et sans enjeu de confidentialité. Un calcul lourd, une règle métier sensible ou une vérification qui engage votre responsabilité ont leur place sur le serveur, où vous en gardez le contrôle. Une vérification faite uniquement en JavaScript peut être contournée par n’importe qui : elle rend service au visiteur honnête, elle ne protège de rien.

JS est simplement l’abréviation de JavaScript. Les deux désignent exactement la même chose, et l’abréviation domine à l’écrit chez les développeurs. Aucune nuance à chercher.

Java n’a aucun rapport avec JavaScript, et c’est la confusion la plus répandue. Le langage créé par Brendan Eich en 1995 s’appelait LiveScript ; Netscape l’a rebaptisé JavaScript quelques jours avant sa sortie, alors que Java, propriété de son partenaire Sun Microsystems, gagnait en popularité. Le nom relève donc d’une opportunité commerciale, pas d’une parenté technique. Trente ans plus tard, il continue d’induire tout le monde en erreur.

ECMAScript (souvent abrégé ES) est la norme officielle du langage, publiée par Ecma International sous la référence ECMA-262. JavaScript en est la mise en œuvre. C’est pour cette raison qu’on parle d’ES6 ou d’ES2015 pour désigner une génération du langage : on nomme la version de la norme, pas celle d’un produit.

Node.js n’est pas un langage mais un environnement d’exécution, qui permet de faire tourner du JavaScript en dehors du navigateur, notamment sur un serveur. C’est lui qui a fait passer JavaScript du statut de langage de la page à celui de langage utilisable des deux côtés.

TypeScript est un sur-ensemble de JavaScript développé par Microsoft. Tout code JavaScript valide est du TypeScript valide, mais TypeScript ajoute un typage qui permet de détecter certaines erreurs avant l’exécution. Il est ensuite converti en JavaScript ordinaire, seul langage que les navigateurs comprennent.

jQuery est une bibliothèque JavaScript, apparue en 2006, qui a longtemps servi à écrire plus simplement du code compatible avec tous les navigateurs. Ce n’est ni un langage ni un framework complet. Elle reste présente sur une grande partie du web existant, y compris dans l’écosystème WordPress.

React, Vue et Angular sont des bibliothèques ou des frameworks écrits en JavaScript, destinés à construire des interfaces complexes. Ils ne remplacent pas le langage, ils s’appuient dessus.

JavaScript est ce qui rend un site vivant. Sans lui, une page se contente d’afficher : chaque action du visiteur oblige à repartir vers le serveur, à attendre, puis à recharger la page entière. Avec lui, la page réagit sur place : un filtre se met à jour, un menu se déplie, une carte se déplace, un formulaire signale une erreur avant même d’être envoyé. C’est ce qui permet un rendu au plus proche de ce qu’on avait imaginé, et surtout dans l’immédiat.

Cette immédiateté n’a rien de magique, elle vient d’une idée maligne : faire travailler le navigateur et la machine du visiteur plutôt que votre serveur. Le calcul se fait là où se trouve la personne, donc sans aller-retour, donc sans attente. C’est aussi ce qui explique la contrepartie : ce travail, quelqu’un le fait quand même. Un site qui multiplie les éléments dynamiques déporte une charge croissante sur des machines dont vous ne savez rien, et le confort de consultation finit par s’en ressentir.

D'autres inspirations ...