Inscrivez-vous gratuitement à la Newsletter BFM Business
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 perspective.l.arbelet@01informatique.presse.frwww.01blog.fr/1900
Votre opinion