Le navigateur : DOM, événements, rendu

Tu développes tous les jours pour une plateforme que tu connais bien : le téléphone, ses vues natives, son moteur Hermes qui exécute ton JavaScript. Le web a exactement la même architecture — un « OS de l'application » qui s'appelle le navigateur — mais avec ses propres pièces et son propre vocabulaire. Ce module pose les trois fondations de tout le reste du guide : le DOM (l'arbre qui représente ta page), les événements (comment la page réagit à l'utilisateur) et le rendu (comment le navigateur transforme du texte en pixels). Quand ces trois idées sont claires, React, Next.js et les questions d'entrevue deviennent des variations sur un thème que tu connais déjà.

Le navigateur, ta nouvelle plateforme

Un navigateur — Chrome, Firefox, Safari — n'est pas « une app qui affiche des pages » : c'est une plateforme d'exécution complète, au même titre qu'iOS ou Android. Il télécharge du code (HTML, CSS, JavaScript), l'exécute dans un environnement isolé et sécurisé (le sandbox : une page web ne peut pas lire tes fichiers ni espionner les autres onglets), fournit des services (réseau, stockage, audio, caméra…) et dessine le résultat à l'écran. Ton « appareil cible » n'est plus un iPhone ou un Pixel : c'est le navigateur, quel que soit l'appareil en dessous.

Sous le capot, deux gros moteurs collaborent. Le moteur de rendu lit le HTML et le CSS et fabrique les pixels. Le moteur JavaScript exécute ton code — celui de Chrome s'appelle V8, et c'est aussi celui de Node.js, donc tu le recroiseras souvent. Chaque navigateur a sa propre paire, sous d'autres noms ; l'idée seule compte : un moteur qui dessine, un moteur qui exécute ton JS, et une machinerie qui les fait dialoguer.

Ce dialogue, tu le connais déjà — sous un autre nom. En React Native, ton JavaScript tourne dans Hermes et, pour afficher quelque chose, il ne dessine pas lui-même : il demande au système, à travers un pont, de créer et modifier des vues natives. Dans le navigateur, pareil : ton JS tourne dans V8 et passe par une interface — le DOM, deux sections plus bas — pour demander au moteur de rendu de mettre l'écran à jour. Le JS ne dessine jamais lui-même ; il pilote une machinerie d'affichage qui vit à côté de lui.

Une différence culturelle, quand même : sur mobile, tu compiles, tu soumets à un store, l'utilisateur installe. Sur le web, l'application est téléchargée à chaque visite (avec du cache, certes) et exécutée immédiatement, sans installation ni validation. C'est ce qui rend le web si rapide à déployer — tu pousses, c'est en ligne — et aussi pourquoi la performance de chargement y est une obsession : chaque kilooctet est re-téléchargé par quelqu'un, sur un réseau moyen. C'est une des raisons d'être des frameworks modernes (module sur la carte de Next.js).

Du texte aux pixels : le pipeline de rendu

Question d'entrevue classique, et excellente colonne vertébrale pour comprendre le navigateur : « Qu'est-ce qui se passe entre le moment où le HTML arrive et le moment où la page s'affiche ? ». Le serveur envoie du texte (un fichier HTML, des fichiers CSS) ; l'écran affiche des pixels. Entre les deux, le moteur de rendu déroule une chaîne de fabrication précise, le pipeline de rendu. Le tableau la donne en entier, avec ce que chaque étape fabrique et ce qui la fait rejouer — car après le premier affichage, le navigateur ne refait jamais tout : il rejoue seulement les étapes que ton changement a invalidées.

// (A) La carte du service choisi devient verte :
carte.style.backgroundColor = 'seagreen';

// (B) On insère un message de confirmation au-dessus du formulaire :
formulaire.before(messageConfirmation);

Le DOM est un arbre vivant

La pièce maîtresse, maintenant. La confusion la plus répandue — et une question piège d'entrevue — consiste à croire que « le DOM » est un synonyme chic de « le HTML ». Non. Le HTML est un fichier texte figé, celui que le serveur t'a envoyé. Le DOM est la structure en mémoire que le navigateur construit en lisant ce fichier, et cette structure est vivante : ton JavaScript la lit, la modifie, y greffe ou en coupe des branches, et le navigateur répercute à l'écran. Deux minutes après le chargement, le DOM d'une page interactive ne ressemble souvent plus du tout au HTML de départ.

Sa forme est celle d'un arbre généalogique : tout en haut le nœud racine document, puis <html>, <head> et <body>, puis toute ta page. Chaque balise est un nœud (node) avec un parent, éventuellement des enfants et des frères (siblings, qui partagent le même parent) ; même le texte à l'intérieur d'une balise est un nœud. Ce vocabulaire d'arbre revient sans arrêt : en CSS (les sélecteurs descendants), dans la propagation des événements (section suivante), et dans React (l'arbre de composants).

Quatre gestes couvrent l'essentiel de la conversation entre ton JavaScript et cet arbre : trouver un nœud, lire ou écrire son contenu, jouer avec ses classes CSS, et créer puis brancher de nouveaux nœuds. L'exemple vient de RendezVous : afficher un résumé du service choisi.

// La page contient : <select id="service">…</select>
// et un paragraphe vide : <p id="resume"></p>

// 1. TROUVER un nœud : querySelector accepte n'importe quel
//    sélecteur CSS ('#id', '.classe', 'form button'…) et retourne
//    le PREMIER nœud de l'arbre qui correspond.
const select = document.querySelector('#service');
const resume = document.querySelector('#resume');

// 2. LIRE / ÉCRIRE son contenu texte.
resume.textContent = 'Aucun service choisi pour le moment';

// 3. Jouer avec ses CLASSES CSS (le style reste dans le CSS,
//    le JS ne fait qu'activer/désactiver des étiquettes).
resume.classList.add('resume--vide');     // ajoute la classe
resume.classList.remove('resume--vide');  // la retire
resume.classList.toggle('resume--vide');  // bascule

// 4. CRÉER un nœud et le BRANCHER dans l'arbre.
const badge = document.createElement('span'); // orphelin, en mémoire
badge.textContent = 'Populaire';
badge.classList.add('badge');
resume.append(badge);   // branché comme enfant → visible à l'écran

À l'étape 3, les trois lignes forment un catalogue, pas une séquence : dans du vrai code on n'appelle qu'une de ces méthodes à la fois. Et note l'étape 4 : tant que badge n'est pas branché dans l'arbre avec append, il existe en mémoire mais n'apparaît nulle part — créer un nœud et l'afficher sont deux gestes distincts.

<!-- « Afficher le code source » -->
<p id="resume"></p>

<!-- Onglet Elements, quelques secondes plus tard -->
<p id="resume" class="resume--rempli">
  Vous avez choisi : Massothérapie
  <span class="badge">Populaire</span>
</p>

Les événements : la page te parle

Un DOM qu'on peut modifier, c'est bien ; encore faut-il savoir quand le modifier. C'est le rôle des événements. Le navigateur observe tout — un clic, une touche enfoncée, un champ modifié, un formulaire soumis, la page qui finit de charger — et pour chaque fait notable, il émet un événement sur le nœud concerné. Tu t'abonnes à ceux qui t'intéressent en fournissant une fonction — un callback, au sens du module sur le JavaScript asynchrone du guide Halterofit — et le navigateur l'appellera à chaque occurrence. C'est le grand patron du web : écouter, puis réagir.

L'outil d'abonnement s'appelle addEventListener et se lit comme une phrase : « sur ce nœud, quand tel type d'événement survient, exécute cette fonction ». Quand le navigateur appelle ta fonction, il lui passe l'objet event, un dossier complet sur ce qui vient de se passer — type d'événement, élément concerné, touche pressée, coordonnées du clic…

const select = document.querySelector('#service');
const resume = document.querySelector('#resume');

// « Sur select, quand l'événement 'change' survient, exécute ceci. »
select.addEventListener('change', (event) => {
  // event.target = le nœud qui a émis l'événement (ici le select).
  // Pour un select, .value est l'option actuellement choisie.
  const service = event.target.value;
  resume.textContent = 'Vous avez choisi : ' + service;
});

Personne n'« appelle » cette fonction dans ton code : tu la déposes, et c'est le navigateur qui l'exécutera, plus tard, à chaque changement du menu. On dit que le code est piloté par les événements (event-driven).

Deux propriétés de l'objet event se ressemblent et leur différence est une question d'entrevue récurrente. target est l'élément sur lequel l'événement s'est réellement produit — l'endroit exact du clic. currentTarget est l'élément qui porte le listener en train de s'exécuter. Quand on clique directement sur l'élément écouté, les deux coïncident. Mais si tu écoutes une carte entière et que le clic tombe sur un bouton à l'intérieur : target est le bouton (le point d'impact), currentTarget la carte (ton poste d'écoute). Pourquoi le listener de la carte se déclenche-t-il alors ? C'est la question de la propagation — section suivante.

// HTML de la carte :
// <article class="service">
//   <h3>Massothérapie</h3>
//   <button>Choisir</button>
// </article>

const carte = document.querySelector('.service');

carte.addEventListener('click', (event) => {
  console.log('target :', event.target.tagName);
  console.log('currentTarget :', event.currentTarget.tagName);
});

const select = document.querySelector('#service');
const resume = document.querySelector('#resume');

function afficherResume() {
  resume.textContent = 'Vous avez choisi : ' + select.value;
}

select.addEventListener('change', afficherResume());

Propagation, délégation, preventDefault

Voici le mécanisme qui explique l'exercice précédent. Quand un événement se produit sur un nœud, il ne reste pas sur place : il voyage dans l'arbre, en deux phases. D'abord la capture : l'événement descend de la racine (document) jusqu'au nœud cible, en traversant tous ses ancêtres. Puis le bouillonnement (bubbling, « la bulle qui remonte ») : il refait le chemin inverse, du nœud cible vers la racine. À chaque étage, dans les deux sens, les listeners des nœuds traversés peuvent se déclencher. En pratique, addEventListener écoute par défaut pendant la remontée — la capture sert à des cas avancés, rares. Retiens l'image simple : un clic sur un bouton « bouillonne » vers ses parents, jusqu'en haut de l'arbre.

Ce comportement est un cadeau : il permet la délégation d'événements. Plutôt que de poser un listener sur chacune des vingt cartes de service de RendezVous, tu en poses un seul sur leur conteneur commun, où tous les clics remonteront. Moins de listeners à gérer, et surtout — c'est le vrai argument — les cartes ajoutées plus tard par ton JavaScript sont couvertes automatiquement, puisque c'est le conteneur qui écoute.

// <section id="liste-services"> contient N cartes
// <article class="service" data-nom="Massothérapie">…</article>

const liste = document.querySelector('#liste-services');

liste.addEventListener('click', (event) => {
  // closest() remonte depuis le point d'impact jusqu'à trouver
  // un ancêtre (ou lui-même) qui correspond au sélecteur.
  const carte = event.target.closest('.service');
  if (!carte) return; // clic entre deux cartes : rien à faire

  afficherResume(carte.dataset.nom); // lit data-nom="…"
});

Dernière pièce : event.preventDefault(). Beaucoup d'éléments HTML ont un comportement par défaut câblé dans le navigateur — un lien navigue vers son adresse, une case se coche… et surtout un formulaire soumis recharge la page entière en envoyant ses données au serveur, héritage du web d'avant JavaScript. preventDefault() dit : « je prends le relais, n'exécute pas ton comportement par défaut ». C'est LE geste fondateur de tout formulaire moderne — on annule le rechargement, puis on traite la soumission en JavaScript (validation, envoi réseau, confirmation) sans quitter la page.

const formulaire = document.querySelector('#prise-rdv');

formulaire.addEventListener('submit', (event) => {
  event.preventDefault(); // stoppe le rechargement de la page

  // À partir d'ici, c'est NOUS qui gérons la soumission :
  // valider les champs, envoyer au serveur (module « HTTP & fetch »),
  // afficher la confirmation — sans jamais quitter la page.
});

Sans la première ligne, la page se recharge à la soumission et tout ton état JavaScript est perdu. Ce réflexe est si central qu'on lui consacrera un développement complet dans le module « Formulaires 1 — contrôlé ou non ».

element.addEventListener('click', (event) => {
  event.preventDefault(); // si l'élément a un comportement par défaut
  // ... réagir : lire des valeurs, modifier le DOM, appeler le réseau
});

L'event loop : qui exécute tes callbacks ?

Quand l'utilisateur clique, qui appelle concrètement ta fonction, et quand ? La réponse, tu la connais : la boucle d'événements (event loop) du module sur le JavaScript asynchrone du guide Halterofit (l'asynchrone : promesses et async/await). Rappel express : le JavaScript s'exécute sur un seul fil, avec une file de tâches ; la boucle prend la suivante, l'exécute jusqu'au bout, passe à la suivante. Un clic ne t'interrompt donc jamais en plein calcul : le navigateur dépose ton callback dans la file.

Ce module ajoute la pièce qui manquait : le rendu aussi passe par cette boucle. Entre deux tâches, le navigateur profite des moments libres pour dérouler son pipeline et rafraîchir l'écran — idéalement 60 fois par seconde. Conséquence : si un callback prend 500 ms, la boucle est occupée et rien d'autre ne se passe — pas de rendu, pas de réaction aux clics, pas de défilement : la page est gelée. C'est le « jank » que tu connais en React Native quand un calcul bloque le thread JS. Même cause, même remède : garder les callbacks courts et déléguer le lourd (au serveur, à un Web Worker — un fil JavaScript séparé fourni par le navigateur — ou en découpant le travail).

Pourquoi React existe

Tu sais maintenant tout faire à la main — et c'est précisément ce qui rend visible le problème que React résout. En vanilla, l'état de l'application n'existe nulle part en propre : il est éparpillé dans le DOM, dans le texte des nœuds. Fais grandir RendezVous (le service choisi apparaît dans le résumé, et dans le titre, et dans le prix, et il change les créneaux) et chaque événement doit penser à mettre à jour chaque endroit concerné ; un oubli et l'écran ment — « Massothérapie » dans le résumé, le prix de l'ostéopathie à côté. React répond par la formule que tu connais déjà (module sur le modèle mental de React) : UI = fonction(état). L'état sort du DOM, tu décris l'écran en fonction de lui, et à chaque changement React compare l'ancienne description à la nouvelle — la réconciliation — pour appliquer au DOM les mutations minimales. Toutes les manipulations de ce module (createElement, append, textContent, addEventListener) ont encore lieu ; c'est lui qui les orchestre, sans rien oublier et en groupant les écritures pour limiter les reflows. Rien de neuf pour toi : en React Native, c'était déjà ce mécanisme, avec l'arbre des vues natives à la place du DOM — seule la cible des mutations change (module « React web ↔ React Native : les ponts »).

Les DevTools : ton outil n°1

Sur mobile, inspecter ton app demande tout un attirail : Metro, Flipper, les React DevTools branchées sur le device. Sur le web, l'inspection est intégrée au navigateur, gratuite, à un clic droit de distance : les DevTools (clic droit → « Inspecter », ou F12). C'est l'outil numéro un du frontend, au quotidien comme en entrevue où « ouvre les DevTools et montre-moi » est une demande banale. Trois onglets font 90 % du travail :

• Elements (l'inspecteur) : l'arbre DOM vivant, en direct. Tu survoles un nœud, il se surligne dans la page ; tu modifies son texte, ses classes, son CSS, et tu vois le résultat instantanément. Sur une app React, il montre le DOM que React a produit — utile pour vérifier ce que tes composants génèrent vraiment.
• Console : tes console.log, les erreurs JavaScript avec leur trace, et un interpréteur où tu dialogues avec la page en direct — document.querySelector(...) y fonctionne tel quel.
• Network (réseau) : chaque requête émise par la page — HTML initial, CSS, JS, images, appels d'API — avec statut, durée et contenu des réponses. C'est ici que tu débogueras tes fetch (module « HTTP & fetch : parler au réseau »).

Prends l'habitude d'ouvrir les DevTools sur les sites que tu visites et de te promener dans l'onglet Elements. Lire le DOM de vraies pages en production — repérer l'arbre, les classes, ce qui change quand tu interagis — est un exercice de lecture parfait pour tes pauses.

window, document et les autres APIs du navigateur

Survol du paysage, pour savoir ce qui existe. Ton JavaScript vit sous un objet global, window, qui représente l'onglet lui-même. document — le point d'entrée du DOM — est une de ses propriétés, comme la quasi-totalité des services du navigateur. On appelle l'ensemble les Web APIs : des capacités fournies par la plateforme, au même titre que les modules natifs d'Expo donnent accès à la caméra sur mobile. Quelques-unes que tu recroiseras :

• fetch — parler au réseau ; le module « HTTP & fetch : parler au réseau » la reprend en profondeur côté web.
• localStorage — stockage clé-valeur qui survit à la fermeture de l'onglet. Le cousin très simplifié de ton MMKV : quelques chaînes, pas une base de données.
• history et location — l'URL courante et l'historique. C'est là-dessus que les routeurs modernes (dont celui de Next.js, module « Routing : segments, layouts, navigation ») construisent la navigation sans rechargement.
• setTimeout, requestAnimationFrame — planifier du code plus tard, déjà croisées avec l'event loop.

Un point conceptuel qui vaut d'être dit une fois : ces APIs ne font pas partie du langage JavaScript. Le langage, c'est la norme ECMAScript — variables, fonctions, promesses, tableaux. document, fetch et localStorage sont fournis par la plateforme qui héberge ton code : voilà pourquoi document n'existe ni en React Native ni dans Node.js. Autre plateforme, autres APIs, même langage — distinction qui éclairera une subtilité majeure de Next.js, où du code exécuté sur le serveur n'a pas accès au DOM (module « Server et Client Components »).

const largeurEcran = document.body.clientWidth;   // (1)

export function Bandeau() {
  const compact = largeurEcran < 600;             // (2)
  return compact ? 'Bandeau court' : 'Bandeau long';
}