Le terme Asynchrone Javascript et XML (AJAX) ressemble à une bouchée, mais il décrit un concept simple : mettre à jour des parties d’une page Web sans recharger l’intégralité.
Avant cela, si vous vouliez de nouvelles données, vous attendiez. Vous avez cliqué sur un lien. L’écran s’est figé. La page est devenue blanche. Puis tout s’est chargé à nouveau.
AJAX a changé cela. Cela permettait aux navigateurs de communiquer avec les serveurs en arrière-plan. Vous pouvez taper une requête de recherche et voir les résultats apparaître instantanément. Pas de rechargement. Pas d’écran blanc. Juste des données.
Ce n’était pas une invention nouvelle. Il s’agissait d’une combinaison d’outils existants utilisés d’une manière nouvelle.
Les technologies de base derrière la conception Web asynchrone
AJAX n’est pas une technologie unique. C’est un flux de travail. Il s’appuie sur la coordination des technologies web standards.
Au cœur de celui-ci se trouve l’objet XMLHttpRequest. Il s’agit d’une fonctionnalité JavaScript intégrée. Il permet aux scripts côté client de lancer des requêtes HTTP (comme GET ou POST) vers un serveur. Le navigateur envoie la demande. Il n’attend pas la réponse avant de continuer à afficher la page. C’est la partie “asynchrone”.
Une fois que le serveur répond, JavaScript récupère les données. Il l’analyse. Il met à jour le modèle objet de document (DOM). L’utilisateur voit le changement sans jamais quitter la page.
“AJAX se distingue par une architecture où le code côté client orchestre la récupération, l’interprétation et l’adaptation de l’affichage en temps réel des données, sans rechargement général ni perte d’interactivité.”
Pendant longtemps, ces données étaient au format XML. D’où le nom. XML est verbeux. C’est lourd.
Plus tard, JSON (JavaScript Object Notation) a pris le relais. JSON est plus léger. C’est plus facile à traiter pour JavaScript. Les frameworks modernes comme jQuery et l’API fetch ont rendu ces requêtes encore plus simples à gérer. Mais le principe de base demeure : découpler l’interface utilisateur de la communication du serveur.
Pourquoi la compatibilité des navigateurs était importante
Au début, c’était difficile.
Tous les navigateurs ne prennent pas en charge XMLHttpRequest. Ou alors ils l’ont mis en œuvre différemment.
Internet Explorer 5 et supérieur a finalement rattrapé son retard. Mozilla Firefox a emboîté le pas. Safari et Chrome ont rejoint la fête plus tard. Aujourd’hui, tous les navigateurs modernes prennent en charge ces fonctionnalités de manière native.
Cette convergence a permis aux développeurs de créer des interactions complexes qui fonctionnent partout. Avant cela, vous deviez écrire du code hacky pour que les choses fonctionnent dans Firefox mais pas dans IE. Ou vice versa.
Désormais, l’accent est mis sur la logique et non sur les hacks de compatibilité.
Applications du monde réel qui définissent l’expérience
Vous avez utilisé AJAX des milliers de fois. Vous n’y pensez probablement pas.
Pensez à Gmail. Lorsque vous ouvrez une boîte de réception, vous ne rechargez pas la page pour lire un nouvel e-mail. Le client récupère les derniers messages en arrière-plan. Vous pouvez faire glisser, supprimer ou archiver. La page reste en place. Les données sont mises à jour.
Windows Live Hotmail a fait quelque chose de similaire dès le début. Google Maps l’utilise constamment. Vous faites un panoramique sur la carte. Le navigateur demande de nouvelles tuiles de carte. Ils apparaissent instantanément. Vous n’attendez pas le chargement d’une page complète.
LiveSearch est un exemple classique. Au fur et à mesure que vous tapez des mots-clés, le moteur de recherche interroge le serveur. Les résultats descendent. Vous cliquez sur un. La page passe au résultat. Tout cela se produit via des appels AJAX.
Les applications sont infinies.
- Sections de commentaires dynamiques
- Formulaires de sauvegarde automatique
- Téléscripteurs boursiers en temps réel
- Flux de défilement infinis
Ces fonctionnalités créent une sensation « d’application sur une seule page ». Le site se comporte davantage comme une application de bureau. C’est vif. On se sent vivant.
Le passage aux applications à page unique (SPA)
AJAX a ouvert la voie aux SPA.
Dans un site Web traditionnel, chaque clic correspond à un nouveau chargement de page. Le navigateur supprime l’ancien DOM et en crée un nouveau.
Dans un SPA, la page initiale se charge. JavaScript gère toutes les navigations ultérieures. Il échange le contenu de manière dynamique. L’URL peut changer, mais la page ne se recharge pas.
Cela nécessite un code côté client plus complexe. Vous devez gérer l’état. Vous devez gérer le routage. Mais l’expérience utilisateur est supérieure.
Les réseaux sociaux en dépendent. Lorsque vous publiez une mise à jour de statut, le flux est actualisé. Votre photo de profil se charge. Des notifications apparaissent. Rien de tout cela ne nécessite une recharge complète.
L’héritage de l’échange de données asynchrone
L’acronyme AJAX est quelque peu dépassé. Les développeurs utilisent rarement ce terme aujourd’hui. Nous appelons simplement cela « développement Web ».
Mais la technologie perdure. XMLHttpRequest est en grande partie remplacé par l’API fetch. JSON est le format de données standard.
L’impact est indéniable. Cela a accru les attentes des utilisateurs. Nous attendons désormais un retour instantané. Nous nous attendons à des transitions en douceur. Nous nous attendons à ce que les applications Web ressemblent à des logiciels natifs.
Si un site se recharge à chaque fois que vous cliquez sur un bouton, il semble cassé. Ça fait vieux.
AJAX a prouvé que le Web pouvait être bien plus que des documents statiques. Il pourrait s’agir d’une plate-forme pour des applications complexes et interactives.
L’évolution ne s’est pas arrêtée là. Des frameworks comme React, Angular et Vue se sont appuyés sur ces fondations. Ils automatisent les mises à jour du DOM. Ils gèrent l’État.
Mais l’idée de base est la même.
Parlez au serveur en arrière-plan. Mettez à jour l’écran. Gardez l’utilisateur en mouvement.
Nous sommes encore en train d’affiner cela. Des parchemins infinis. Collaboration en temps réel. Aperçus en direct. Les possibilités restent largement inexploitées.
Qu’est-ce qui vient ensuite ? Probablement moins de clics. Plus de streaming. Plus d’immédiateté.
La page reste. Les données bougent.
AJAX n’est pas magique. C’est un compromis.
Vous obtenez de la vitesse. Vous obtenez des interfaces utilisateur fluides. Mais vous avez aussi des maux de tête.
Le plus gros point de friction n’est pas le code. C’est la sécurité. Plus précisément, la Politique de même origine (SOP). Par défaut, les navigateurs verrouillent les requêtes AJAX. Ils ne parlent qu’au domaine sur lequel se trouve actuellement l’utilisateur. Cela empêche un script malveillant sur « evil.com » de voler des données sur le site de votre banque. C’est un mur dur.
Mais les développeurs devaient briser ce mur.
Saisissez CORS (Partage de ressources inter-origines). C’est le mécanisme qui permet à différents domaines de communiquer entre eux. Vous le configurez sur le serveur. Si vous le faites mal, vous exposez des données. Si vous le faites correctement, vous activez des applications modernes et distribuées. La barre est haute. La configuration doit être rigoureuse.
Ensuite, il y a l’historique du navigateur.
Lorsque vous mettez à jour une page sans recharger, l’URL ne change pas. Ou bien c’est le cas, mais l’utilisateur ne le sait pas. Refouler.” Rien ne se passe. Ou pire, la page se recharge et perd tout état. Cela brise le modèle mental de l’utilisateur.
Vous devez le réparer.
Gérez explicitement la pile d’historique. Utilisez l’API d’historique HTML5. Pousser les États. Écoutez les popstates. C’est fastidieux. C’est nécessaire. Avant cela, les gens utilisaient des hashbangs (#! ). Cela a fonctionné. Mais c’était compliqué.
L’accessibilité est un autre piège.
Le contenu dynamique ne s’annonce pas toujours aux lecteurs d’écran. Si vous échangez du texte via AJAX, la technologie d’assistance pourrait ne pas le remarquer. Vous devez mettre à jour les attributs ARIA. Vous devez déclencher des événements. Sinon, vous créez un site qui ne fonctionne que pour les utilisateurs de souris.
Le paysage change.
fetch prend le relais pour les requêtes XHR brutes. Il utilise des promesses. C’est plus propre. C’est moderne. Les WebSockets ajoutent une communication bidirectionnelle en temps réel. Vous n’avez plus besoin de voter. Vous recevez des mises à jour poussées.
Mais AJAX reste la base.
Il a introduit le modèle. Asynchrone. Modulaire. Non bloquant.
Le nuage bougea. Le mobile a pris le relais. Les applications Web progressives (PWA) exigeaient des capacités et de la vitesse hors ligne. Ils s’appuient tous sur ces principes fondamentaux.
AJAX est-il mort ? Non.
C’est juste la couche sous les outils les plus récents. La salle des machines.
Les développeurs optimisent toujours cela. Ils se soucient toujours de la gestion de l’État qu’elle nous a obligé à résoudre. L’innovation dans l’ingénierie des interfaces ? Il est construit sur ce socle historique.
Nous continuons à affiner l’expérience. L’objectif reste le même.
Rapide. Sensible. Discret.
Mais les enjeux sont désormais plus élevés. La sécurité est plus stricte. Les utilisateurs s’attendent à un comportement de type natif. Et le code doit être accessible à tous.
C’est un exercice d’équilibre constant. Celui que l’on ne termine jamais vraiment.
