Styles

jeudi 6 août 2009

AJAX et Performance : un oxymore

N'avez-vous pas l'impression qu'AJAX (Asynchronous Javascript and XML) nous ramène en un temps où les ressources matérielles étaient chères et lentes, où les compilateurs ne savaient rien optimiser et qu'il était difficile de fiabiliser son code ? Développer en Ajax, c'est retrouver le bidouillage d'antan, quand il fallait lutter à chaque pas contre les limites du système cible. Oui, ce satané Javascript qui a plus à voir avec Lisp qu'avec Java, est bien la cause de ce problème. Où plutôt la mise en œuvre de ce langage dans un paradigme (AJAX) créé dans le but unique de palier aux problèmes d'un autre paradigme (le Web) pour obtenir des applications d'un paradigme historiquement éprouvé (le Client-Serveur).

En effet, les technologies supportant l'AJAX sont plus qu'inefficaces, elles sont inappropriées. Les navigateurs Web ne sont pas conçus à la base, pour être des plateformes d'exécution d'application.
Javascript a été mis en place dans les navigateurs (Netscape Navigator à l'origine) pour palier à l'aspect statique des pages et du protocole orienté document qu'est HTTP.

Pour que Javascript s'exécute rapidement, il a donc fallu implémenter un interpréteur très simple et ne réalisant que peu d'optimisations. On ne retrouve pas en Javascript les optimisations que l'on considère comme évidentes dans n'importe quel autre compilateur :

Il faut donc coder en Javascript d'une manière spécifique, en connaissance de cause. Cette leçon nous est donnée par Douglas Crockford dans sa présentation « Ajax Performance ». Il nous donne quelques exemples puis exprime la philosophie générale de l'optimisation Ajax : Alors qu'il est logique de penser qu'il faut toujours essayer d'avoir des algorithmes de complexité en O(1), O(log n) plutôt que O(n), O(n2) ou O(en), l'important est d'avoir n le plus petit possible quelque soit la complexité. Le client Ajax n'est là que pour présenter une vue réduite des données du serveur.

Ce qui est étonnant c'est l'intitulé de la série de présentation de Douglas qui s'appelle « Javascript : the good parts ». Je comprend bien qu'il veuille prêcher pour sa paroisse, son langage de prédilection, mais heureusement qu'il a un œil critique sur sa technologie fétiche et montre bien qu'il faut aller bien loin pour trouver de « bons côtés » à Javascript. Il a du vouloir attirer tous les zélotes de l'Ajax et du javascript à sa présentation pour mieux leur montrer les limites de leurs croyances. Car toute « nouvelle » technologie , s'apparente plus à l'émergence d'une secte qu'à une avancée scientifique majeure. AJAX n'est plus très nouveau d'ailleurs.

Heureusement la réalité est toujours là et les « bonnes pratiques » informatiques sont toujours d'actualité même en Javascript. Douglas ne fait que reprendre à raison les principes éprouvés de l'optimisation de code.

On a beau critiquer Javascript, on peut aussi l'apprécier pour ses aspects qui le différencient tant de Java justement, comme par exemple : l'héritage par prototype, la programmation fonctionnelle que l'on peut en faire, notamment, grâce aux fonctions d'ordre supérieur. Le Javascript est, de fait, un des langages les plus utilisés aujourd'hui.

Ça peut être amusant de faire de l'Ajax (c'est d'ailleurs quelque chose que nombre de développeurs réalisaient il y a de cela déjà bien longtemps, avant même qu'on y mis un nom dessus) mais franchement, aujourd'hui, ce qui est le plus productif c'est de ne carrément pas coder du tout : utiliser des outils pour générer les interfaces graphiques et des applications.

Qu'on le veuille ou non, le coût d'un développeur français est tellement élevé par rapport à un développeur indien (7 à 10 fois son prix) par exemple qu'il devient complètement improductif de lui demander de développer à la main des applications Ajax.

En france, à Montpellier, il y a PC SOFT (un nom de boîte qu'on imagine sans hésitation sortir des années 80) qui produit WEBDEV dans le même esprit que WINDEV. Parmi mes collègues développeurs, rare sont ceux qui préconise de développer avec de tels outils de génération d'application. J'ai l'impression qu'ils disent cela parce que WINDEV est vieux et que tout ce qui est vieux en informatique devient plus ou moins ringard.

Personnellement, leur nouvel outil WEBDEV semble intéressant pour produire des applications Web / AJAX sans coder quoi que ce soit. Pour la plupart des petites et moyennes applications, c'est largement suffisant car ce sont essentiellement des applications de gestion de l'information. Dans le cas de besoins spécifiques, on peut toujours développer spécifiquement une extension et l'intégrer à l'application.

Il existe aussi Oracle Application Express pour la génération automatique d'application au dessus d'une base Oracle sans écrire une seule ligne de code. Ce composant est souvent disponible chez les client qui ont achetés des licences database serveurs, sans qu'ils le sachent vraiment. Le client paie cher des technologies dont seulement 10% sont réellement utilisées (et ces 10% se retrouvent souvent aussi bien en Open Source...)

Tout cela va dans le sens de considérer XML, HTML, CSS et Javascript comme étant du binaire illisible qu'il s'agit de traiter uniquement via des outils de haut-niveau et des ateliers de génie logiciel (AGL). Seul les développeurs de composants et d'atelier logiciels ont à se pencher sur ces technologies au jour le jour.

Aucun commentaire: