Ajax

Ajax (également AJAX; abréviation de « Asynchronous JavaScript and XML ») est un ensemble de techniques de développement Web utilisant de nombreuses technologies Web côté client pour créer des applications Web asynchrones. Avec Ajax, les applications Web peuvent envoyer et récupérer des données d’un serveur de manière asynchrone (en arrière-plan) sans interférer avec l’affichage et le comportement de la page existante. En découplant la couche d’échange de données de la couche de présentation, Ajax permet aux pages Web et, par extension, aux applications Web, de modifier le contenu de manière dynamique sans avoir à recharger la page entière. En pratique, les implémentations modernes utilisent généralement JSON au lieu de XML.

Ajax n’est pas une technologie unique, mais plutôt un groupe de technologies. HTML et CSS peuvent être utilisés en combinaison pour baliser et styliser les informations. La page Web peut ensuite être modifiée par JavaScript pour afficher de manière dynamique – et permettre à l’utilisateur d’interagir avec – les nouvelles informations. L’objet XMLHttpRequest intégré, ou depuis 2017 la nouvelle fonction « fetch() » dans JavaScript, est couramment utilisé pour exécuter Ajax sur les pages Web permettant aux sites Web de charger du contenu sur l’écran sans actualiser la page. Ajax n’est pas une nouvelle technologie ou un langage différent, juste des technologies existantes utilisées de manière nouvelle.

L’histoire

Du début au milieu des années 90, la plupart des sites Web étaient basés sur des pages HTML complètes. Chaque action de l’utilisateur nécessitait qu’une nouvelle page complète soit chargée à partir du serveur. Ce processus était inefficace, comme en témoigne l’expérience utilisateur: tout le contenu de la page disparait, puis la nouvelle page apparait. Chaque fois que le navigateur rechargeait une page en raison d’un changement partiel, tout le contenu devait être renvoyé, même si seules certaines informations avaient changé. Cela a placé une charge supplémentaire sur le serveur et a fait de la bande passante un facteur limitant sur les performances.

En 1996, la balise iframe a été introduite par Internet Explorer; comme l’élément objet, il peut charger ou récupérer du contenu de manière asynchrone. En 1998, l’équipe Microsoft Outlook Web Access a développé le concept derrière l’objet de script XMLHttpRequest. Il est apparu sous le nom de XMLHTTP dans la deuxième version de la bibliothèque MSXML, livrée avec Internet Explorer 5.0 en mars 1999.

La fonctionnalité du contrôle ActiveX XMLHTTP de Windows dans IE 5 a ensuite été implémentée par Mozilla, Safari, Opera et d’autres navigateurs en tant qu’objet JavaScript XMLHttpRequest. Microsoft a adopté le modèle natif XMLHttpRequest à partir d’Internet Explorer 7. La version ActiveX est toujours prise en charge dans Internet Explorer, mais pas dans Microsoft Edge. L’utilité de ces requêtes HTTP d’arrière-plan et des technologies Web asynchrones est restée assez obscure jusqu’à ce qu’elle commence à apparaître dans des applications en ligne à grande échelle telles que Outlook Web Access (2000) et Oddpost (2002).

Google a déployé à grande échelle Ajax, cross browser conforme aux normes, avec Gmail (2004) et Google Maps (2005). En octobre 2004, la version bêta publique de Kayak.com a été l’une des premières utilisations à grande échelle du commerce électronique de ce que leurs développeurs appelaient à l’époque « la chose xml http ». Cela a accru l’intérêt pour AJAX parmi les développeurs de programmes Web.

Le terme AJAX a été utilisé publiquement le 18 février 2005 par Jesse James Garrett dans un article intitulé Ajax: A New Approach to Web Applications, basé sur des techniques utilisées sur les pages Google.

Le 5 avril 2006, le World Wide Web Consortium (W3C) a publié le premier projet de spécification pour l’objet XMLHttpRequest dans le but de créer une norme Web officielle. La dernière version de l’objet XMLHttpRequest a été publiée le 6 octobre 2016 et la spécification XMLHttpRequest est désormais un standard vivant.

Les technologies

(Le modèle conventionnel d’une application Web par rapport à une application utilisant Ajax. )

Le terme Ajax est venu pour représenter un large groupe de technologies Web qui peuvent être utilisées pour implémenter une application Web qui communique avec un serveur en arrière-plan, sans interférer avec l’état actuel de la page. Dans l’article qui a inventé le terme Ajax, Jesse James Garrett a expliqué que les technologies suivantes sont incorporées:

• HTML (ou XHTML) et CSS pour la présentation
• Le modèle d’objet de document (DOM) pour l’affichage dynamique et l’interaction avec les données
• JSON ou XML pour l’échange de données et XSLT pour la manipulation XML
• L’objet XMLHttpRequest pour la communication asynchrone
• JavaScript pour rassembler ces technologies

Depuis lors, cependant, il y a eu un certain nombre de développements dans les technologies utilisées dans une application Ajax, et dans la définition du terme Ajax lui-même. XML n’est plus requis pour l’échange de données et, par conséquent, XSLT n’est plus requis pour la manipulation des données. La notation d’objet JavaScript (JSON) est souvent utilisée comme format alternatif pour l’échange de données, bien que d’autres formats tels que du HTML préformaté ou du texte brut puissent également être utilisés. Une variété de bibliothèques JavaScript populaires, y compris JQuery, incluent des abstractions pour aider à exécuter les requêtes Ajax.

Désavantages

• Tout utilisateur dont le navigateur ne prend pas en charge JavaScript ou XMLHttpRequest, ou dont cette fonctionnalité est désactivée, ne pourra pas utiliser correctement les pages qui dépendent d’Ajax. Les appareils simples (tels que les smartphones et les PDA) peuvent ne pas prendre en charge les technologies requises. La seule façon de laisser l’utilisateur exécuter les fonctionnalités est de recourir à des méthodes non JavaScript. Cela peut être réalisé en s’assurant que les liens et les formulaires peuvent être résolus correctement et en ne reposant pas uniquement sur Ajax.
• De même, certaines applications Web qui utilisent Ajax sont conçues de manière à ne pas être lues par les technologies de lecture d’écran, telles que JAWS. Les normes WAI-ARIA fournissent un moyen de fournir des conseils dans un tel cas.
• Les lecteurs d’écran capables d’utiliser Ajax peuvent ne pas être en mesure de lire correctement le contenu généré dynamiquement.
• La politique de même origine empêche certaines techniques Ajax d’être utilisées dans les domaines, bien que le W3C dispose d’un brouillon de l’objet XMLHttpRequest qui activerait cette fonctionnalité. Il existe des méthodes pour contourner cette fonctionnalité de sécurité en utilisant un canal de communication interdomaine spécial intégré en tant qu’iframe dans une page, ou en utilisant JSONP.
• Ajax est conçu pour les communications unidirectionnelles avec le serveur. Si des communications bidirectionnelles sont nécessaires (c’est-à-dire pour que le client écoute les événements / changements sur le serveur), alors WebSockets peut être une meilleure option.
• Dans les navigateurs pré-HTML5, les pages créées dynamiquement à l’aide de requêtes Ajax successives ne s’enregistraient pas automatiquement avec le moteur d’historique du navigateur, donc cliquer sur le bouton « retour » du navigateur n’a peut-être pas renvoyé le navigateur à un état antérieur de la page compatible Ajax, mais peut être retourné à la dernière page complète visitée avant lui. Un tel comportement – naviguer entre les pages au lieu de naviguer entre les états de page – peut être souhaitable, mais si un suivi fin de l’état de la page est nécessaire, une solution de contournement pré-HTML5 consistait à utiliser des iframes invisibles pour déclencher des modifications dans l’historique du navigateur. Une solution de contournement implémentée par les techniques Ajax consiste à modifier l’identificateur de fragment d’URL (la partie d’une URL après le « # ») lors de l’accès à une page compatible Ajax et à surveiller les modifications. HTML5 fournit une norme API complète pour travailler avec le moteur d’historique du navigateur.
• Les mises à jour dynamiques des pages Web rendent également difficile la création de signets et le retour à un état particulier de l’application. Des solutions à ce problème existent, dont beaucoup utilisent à nouveau l’identifiant de fragment d’URL. D’un autre côté, comme les pages à forte intensité AJAX ont tendance à fonctionner en tant qu’applications plutôt qu’en tant que contenu, le bookmarking d’états intermédiaires a rarement du sens. Néanmoins, la solution fournie par HTML5 pour le problème ci-dessus s’applique également à cela.
• Selon la nature de l’application Ajax, les mises à jour de pages dynamiques peuvent perturber les interactions des utilisateurs, en particulier si la connexion Internet est lente ou peu fiable. Par exemple, la modification d’un champ de recherche peut déclencher une requête au serveur pour les recherches terminées, mais l’utilisateur peut ne pas savoir qu’une fenêtre contextuelle de fin de recherche est à venir, et si la connexion Internet est lente, la liste contextuelle peut apparaître à un moment inopportun , lorsque l’utilisateur a déjà procédé à autre chose.
• À l’exception de Google, la plupart des principaux robots d’exploration du Web n’exécutent pas de code JavaScript.Par conséquent, pour être indexée par les moteurs de recherche Web, une application Web doit fournir un autre moyen d’accéder au contenu qui serait normalement récupéré avec Ajax. Il a été suggéré qu’un navigateur sans tête peut être utilisé pour indexer le contenu fourni par les sites Web compatibles Ajax, bien que Google ne recommande plus la proposition d’exploration Ajax qu’ils ont faite en 2009.