Ajax : une affaire de superdéveloppeurs

Faiblesse des outils, manque de standardisation, problèmes de performances... La figure emblématique du web 2.0 complique sérieusement la tâche des développeurs.

C'est un casse-tête pour les développeurs. Le chouchou du web 2.0, le bien nommé Ajax (Asynchronous Javascript and XML), complexifie la réalisation des pages HTML. N'en déplaise aux utilisateurs qui, eux, se réjouissent au contraire de travailler avec des interfaces dont la qualité approche celle des clients lourds. Pour comprendre ces difficultés, il faut revisiter les concepts sous-jacents. Elaboré il y a huit ans, Ajax se distingue par son caractère asynchrone : les traitements s'effectuent en tâche de fond sur le poste client, sans bloquer l'utilisateur, grâce à une optimisation des allers et retours avec le serveur.Le code est écrit en Javascript, un langage créé par Netscape sous le nom Livescript. Rebaptisé Javascript en 1995, sa syntaxe s'apparente à celle de Java. Mais la comparaison s'arrête là, tant les différences sont essentielles. Contrairement à son aîné, Javascript est un langage peu typé - autrement dit, pas toujours doté d'un mécanisme de déclaration du type de variable. Il en résulte des difficultés en matière de debugging, notamment pour identifier les erreurs ou automatiser le changement de la structure du code (refactoring). D'ailleurs, il n'existe quasiment aucun outil de debugging pour Javascript digne de ce nom. Plus généralement, le test de code souffre cruellement de l'absence d'outils spécifiques. Seul Parasoft a commencé à aborder récemment cette problématique.L'optimisation du code pose également problème. Mal conçu, celui-ci peut freiner la performance, jusqu'à rendre une page web inexploitable. Envoyés au navigateur sur le poste client, le code source et les bibliothèques utilisées transitent sur le réseau - à la différence d'autres langages de script (Python, PHP ou Perl), qui s'exécutent sur le serveur. Autre caractéristique : Javascript est un langage peu compact car interprété, et non pas compilé comme peut l'être Java. Par ailleurs, l'interaction avec l'utilisateur est susceptible de générer des opérations complexes, car elle modifie la page HTML, et donc le modèle d'objet (ou DOM, pour Document Object Model). Ce qui peut augmenter rapidement la consommation de puissance machine.

Sortir Javascript des pages HTML

Heureusement, plusieurs méthodes contournent ces écueils. Tout d'abord, mieux vaut ne pas incorporer le code Javascript dans les pages HTML et lier plutôt les fichiers de traitement. Cela évite d'alourdir la page en téléchargeant systématiquement tout le code Javascript. Ensuite, en réduisant le nombre de fichiers par page (à titre indicatif, un nombre compris entre cinq et vingt pages constitue un bon repère). Il faut aussi limiter le nombre de bibliothèques employées. Pour cela, une solution consiste à bâtir une bibliothèque de base qui partagera du code commun avec d'autres. Enfin, quand les bibliothèques sont distribuées selon deux versions - l'une complète, l'autre compacte -, en privilégiant la seconde lors du déploiement de votre site web.Dans Ajax, le mécanisme de communication entre le poste client et le serveur n'est pas normalisé. Rien d'étonnant, lorsque l'on sait que le procédé de création de XMLhttpRequest, l'objet chargé d'appeler le serveur de façon asynchrone depuis le poste client, est le fruit du travail de Microsoft, qui l'a implémenté pour la première fois en 1999 dans Internet Explorer version 5. Mozilla l'a intégré en 2002 dans sa version 1.0, tandis qu'Opera ne l'embarque que depuis 2005. C'est pourquoi ce mécanisme diffère d'un navigateur à l'autre, voire d'une version à l'autre. Ainsi, XMLhttpRequest est exposé comme un composant ActiveX dans les versions 5 et 6 d'Internet Explorer (IE), mais en tant qu'objet simple dans la dernière mouture du logiciel et au sein des autres navigateurs. Le consortium W3C travaille à normaliser cet objet. Une solution qui ne résoudra pas tout, car le format d'échange des données ne bénéficie pas d'une normalisation. Contrairement aux apparences, XML - et donc XMLhttpRequest - n'est pas obligatoire.

Des problèmes de fuite mémoire

Il est tout à fait possible de faire communiquer le serveur et le poste client au moyen d'autres formats, tels que CSV (Comma-Seperated Values), HTML, XHTML, ou JSON (Javascript Object Notation). Ce dernier présente l'avantage de rendre les données plus concises qu'en XML, ce qui accélère les échanges entre le serveur et le client. D'ailleurs, beaucoup de services web de Yahoo! sont désormais élaborés avec ce format.Le moteur d'exécution de Javascript dispose d'un mécanisme de ramasse-miettes. Il réalloue la mémoire qu'un objet n'utilise plus. Il arrive cependant que ce mécanisme ne fonctionne pas correctement. Après la fermeture d'une page web, les navigateurs provoquent parfois des fuites mémoire. C'est le cas d'Internet Explorer, quand il manipule des objets COM mal conçus qui forment une référence circulaire. De même, Internet Explorer et Firefox gèrent très mal la mémoire des événements listeners, c'est-à-dire les bouts de programme chargés d'écouter des événements particuliers tels qu'un clic de souris. Une solution consiste à suivre chaque listener afin de libérer la mémoire lorsqu'il n'est plus utilisé. Un travail qui diffère selon le navigateur - raison pour laquelle certaines bibliothèques Ajax apportent une solution par le biais d'une API (Application Programming Interface) spécifique.Bien évidemment, des environnements de développement pour Ajax commencent à émerger. Ils se révèlent précieux, mais encore très incomplets. Le plus souvent, ils comprennent des bibliothèques qui se limitent à la production de code Javascript côté client. Celles-ci sont livrées avec une série de contrôles à insérer dans les pages web : complément automatique (auto-complétion) qui limite la saisie au clavier, navigation par onglet, glisser/déposer, calendrier, etc. C'est notamment le cas de Yahoo! UI Library.Une autre approche consiste à écrire l'application uniquement côté serveur, et dans un autre langage. Quitte à ce que le code soit ensuite traduit par l'outil afin de générer du Javascript. C'est la méthode retenue par Google Web Toolkit, qui produit d'abord du code Java. Il devient possible par ce biais de contourner les grands écueils propres au développement en Javascript, et de profiter de la normalisation plus aboutie de Java. Mais quelle que soit la voie choisie, le développement Ajax demeure compliqué. Il nécessite de maîtriser un ensemble de technologies : XML, HTML, Javascript et/ou Java, DOM, CSS (Cascading Style Sheet), DHTML, etc. ' Cela implique également d'orienter le développement au sein d'une seule page, et non plus page par page ', analyse Régis Louis, chef produit chez Oracle. De nouvelles compétences techniques en [e-mail]

Un code pour chaque navigateur

L'une des conséquences apparaît dans son manque de portabilité d'un navigateur à un autre, voire d'une version à une autre. Le cas échéant, cela oblige à écrire un code spécifique, comme l'illustre l'exemple ci-contre. Un problème que l'on rencontre beaucoup moins avec Java, langage qui ne ressemble à Javascript que sur le plan de la syntaxe. En revanche, le mécanisme de détection du navigateur et de la version du navigateur client fonctionne bien.

www.01blog.fr/1900

2 questions à... : Nicolas Hamon, consultant formateur chez Lyria

Cet éditeur est spécialisé dans les outils de développement pour les interfaces homme/machine.

La compatibilité entre navigateurs est-elle un sujet spécifique d'Ajax ?
' En théorie, cette problématique est commune à tous les développements destinés au web. Il faut écrire du code qui fonctionne quel que soit le logiciel de navigation installé sur le poste client. Mais Javascript présente la particularité d'être un langage souple et plus ou moins formalisé. Ce qui n'est pas le cas, par exemple, de Java. Si bien qu'avec ce dernier on ne rencontre pas ce genre de souci. '

Comment s'assurer de la compatibilité d'Ajax avec les principaux navigateurs ?
' On procède de manière un peu empirique. En déterminant tout dabord quel navigateur sera employé en priorité par les utilisateurs. On développe alors sur cette base. Puis on mène des tests sur cette plate-forme cible. Il reste ensuite à adapter les développements pour tenir compte des spécificités de chacun des navigateurs. '