C'est ainsi, la communauté informatique a besoin de ses jeux du cirque. Après l'affrontement pour le titre du meilleur mécanisme de persistance objet, place au combat que se livrent, d'un côté, les défenseurs du web enrichi et, de l'autre, les partisans du client lourd. Ce dernier regroupe l'ensemble des technologies 
dont le prérequis à l'exécution est le téléchargement du code de l'application sur le poste de l'utilisateur. On en distingue deux catégories : celles basées sur une machine virtuelle Java, et les autres. La première oppose deux bibliothèques de composants graphiques : SWT, promue par Eclipse - et IBM -, et Swing, poussée par Sun. La seconde héberge surtout Microsoft Winform . Net, Macromedia Flash, ainsi que tous les L4G propriétaires - Powerbuilder et Delphi en tête.
Il n'y a donc pas un seul client lourd, mais un ensemble d'environnements concurrents et incompatibles, qui se disputent le droit de rivaliser avec l'autre type de client - riche, celui-là -, porté par la technologie Ajax (1) . .
Le client Java en panne de standard
La proposition de Sun se distingue nettement des autres challengers, comme le montre une récente étude d'Evans Data Corporation sur l'adoption des technologies. En 2005, Java/Swing arrive en tête des outils de développement pour client lourd : 47 % des développeurs interrogés l'utilisent, soit 27 % de mieux qu'en 2004.
Si ce rapport ne concerne que les Etats-Unis, au vu du choix de Fiducia AG, l'Europe pourrait confirmer, sinon accentuer ce résultat. Cet hébergeur allemand de logiciels bancaires, en mode hébergé, déploie son logiciel client Java/Swing de 120 Mo sur plus de 100 000 postes clients avec Java Web Start au travers de bandes passantes souvent réduites à 64 Kbit/s.
Swing, appelons-le Hector (2) pour la métaphore mythologique, serait l'alpha et l'oméga des interfaces riches et de la transparence du déploiement. Peut-être, mais pas en l'état, car Hector souffre de ne pas être spécifiquement dédié aux applications de gestion. A tel point que rien n'empêche de bâtir sur ses fondations une console de supervision de centrale nucléaire ou un simulateur de cockpit d'avion de ligne. En théorie, c'est un gage de souplesse. En pratique, le coût pour spécialiser cette bibliothèque à l'informatique de gestion est prohibitif pour les projets de petite et moyenne envergure. D'où la pauvreté de l'offre de frameworks répondant au problème. Et pour cause : il manque un standard dédié au client Java - à l'instar de J2EE pour le serveur -, qui pérenniserait des investissements nécessairement importants. La notion de « conteneur client lourd » reste à inventer, et son modèle de programmation avec.
Ajax écartèle le modèle MVC
Si Hector entre dans l'arène en quête d'une plus grande reconnaissance, Ajax, le populaire, harangue la foule en délire. Ce n'est pas un outil, mais un modèle évolutionniste, qui s'appuie sur les standards existants et promet d'élever le web au rang des meilleures interfaces homme-machine. Mais la puissance d'Ajax ne s'exprimera pas si facilement. D'abord, parce qu'il écartèle le contrôleur du fameux modèle MVC (Model-View-Controller) entre le serveur et le client, sans pour autant en spécifier de substitut. Ensuite, parce qu'il repousse le HTML, les feuilles de style CSS, le Javascript et l'invocation asynchrone XML aux limites de leurs implémentations propriétaires par les navigateurs. Enfin, parce que la pléthore d'outils estampillés Ajax n'est pas le signe d'une grande maturité.
Le HTML pourrait ne jamais atteindre la richesse génétique du client lourd. Le prix à payer pour enrichir une interface web avec Ajax est une fonction exponentielle de la valeur ajoutée. Swing inverse cette formule, mais augmente l'investissement initial.
Ironie de l'histoire, Ajax vénère trop de dieux, alors que Hector s'en cherche un désespérément. Si l'on en croit la mythologie, il n'y eut qu'un seul combat entre ces deux héros. Combat qui ne vit ni vainqueur ni vaincu : à la nuit tombée, ils échangèrent leurs armes et firent la paix.
Aucun commentaire:
Enregistrer un commentaire