Plus de lourd dans notre client léger

Rappelons que le terme client lourd, pour faire simple, c'est un exécutable installé et exécuté sur votre ordinateur, qui a accés libre au système de fichier et qui gére sa mémoire comme il veut. Tandis qu'une application en client léger n'impose à l'utilisateur que d'avoir un navigateur web (éventuellement équipé de plug-ins ou de machine virtuelle)

La problèmatique est posée par cet extrait de wikipédia :

Contrairement au client léger, le client lourd ne dépend du serveur que pour l'échange des données dont il prend généralement en charge l'intégralité du traitement.

Les solutions client lourd sont également caractérisées comme étant des solutions très coûteuses tant au niveau de la maintenance que du déploiement et de la formation.

Alors, pourquoi utilise-t-on toujours des applications en client lourd ? Prenons en exemple trois besoins courants qui nécessitent une application évoluée.

• Une suite de bureautique mail - agenda - traitement de texte - tableurs,
  
• Le besoin de faire de la création graphique, retouche photo, montages vidéos
  
• Le besoin de créer le site web dynamique de la société.

Et prenons quelques solutions diverses à ces besoins :

• Exchange et Outlook, Lotus Notes, Gmail & Calendar
  
• Word, Excel, OpenOffice, Google Documents, Zoho
  
• Photoshop, Gimp, CorelDraw, Adobe Premiere
  
• Dreamweaver sur PHP, ASP, IIS & Visual Studio, Eclipse, Wordpress, Google sites.

Sans surprise, on voit que les applications purement web sont encore à la traine lorsqu'il s'agit d'utiliser intensivement les ressources et d'accéder rapidement à un gros volume de données. Par contre, elles sont plus présentes lorsque il s'agit d'applications collaboratives.

Mais cela change, des nombreux chantiers en effervesence veulent donner plus de puissance d'exécution au code s'exécutant dans le navigateur ; Tracemonkey , Chrome experiments , Flash, Flex, et pourquoi pas, quake 3 dans votre navigateur :) ...

Je vois de plus en plus de développeurs qui se mettent à lutter avec les ressources allouée par le navigateur. La 3d javascript , ça arrive... ici aussi mais attention ça consomme. Et sur celui-ici, tracez des formes sur le fond noir, qui croirait que c'est du javascript ?

Pour créer une application, il faut désormais se demander si :

• Mon application s'exécutera-t-elle dans un navigateur ou direct dans l'OS ?
• Les ressources qu'elle manipule se trouveront-elles en ligne ou sur le disque dur ?

L'espace qui sépare le monde des applications en lignes et celui des "traditionnels" exécutables locaux se réduit. On peut se demander alors, à long terme, que pourra faire un programme qui s'exécute en local et que ne pourra pas une application web accédée depuis un navigateur ?

Mais ne crions pas prématurément à la mort du client lourd. Google spreasheet, c'est pas encore Excel. Beaucoup de nos applications sont hybrides, afin de prendre le meilleur des deux mondes. Mais il y a un monde qui empiète de plus en plus sur le domaine réservé de l'autre...