Cependant, ils ont rapidement perçu les limites de HTML en terme d'ergonomie d'application. Il n'est plus possible de faire facilement une interface telle qu'on pouvait l'imaginer en « Client/Serveur » (Gestion des onglets - Drag & Drop - Déplacer - Copier/Coller - Graphique dynamique - etc.).

A contrario, créer une interface « basique » mais permettant la saisie de masse reste un défi si l'on se contente du couple Browser-HTML (Les fonctionnalités telles que « Flèche Haute » - « Flèche Basse » ou encore l'autoskip ne sont pas gérées).

Aussi, des solutions dites Rich Client PlateForm (RCP) ont été déclinées avec pour objectif de pallier ces limites.

La première fut SWING (Client Java) complexe & lourde. Elle est tombée en désuétude remplacée par

d'autres, comme Flash, XDP qui ont montré leurs faiblesses et leur aspect complètement propriétaire.

Aujourd'hui, de nouvelles solutions émergent :

• JSF : Solution Java poussée par IBM en réponse à WebForm de la plate-forme .NET. IBM l'implémente dans les toutes nouvelles versions de son IDE WSAD & négocie avec SUN (propriétaire de Java) pour l'intégrer dans les nouvelles versions de J2EE.
  
• XUL : Solution XML, et donc à priori indépendante de la plate-forme (Java - .Net - Php) est portée par la communauté Mozilla. A ce jour, cette solution, Open Source, manque d'outils d'industrialisation, même si cela ne saurait tarder.
  
• SVG : Solution « vectorielle » est d'une complexité de mise en œuvre et de maintenance « redoutable », avec des performances qui peuvent être « faibles » sans un tuning important. Son principe est pourtant puissant, puisqu'elle propose de fabriquer un graphique vectoriel en ligne, le browser recevant une image avec des zones à pointer. C'est pourquoi, tout récemment, le W3C l'a intégré dans un projet SVG.RCC, qui manque aujourd'hui de maturité
  
• SWT : Solution implémentée par ECLIPSE. Ici, le browser est en fait remplacé par ECLIPSE qu'il faut considérer comme un « berceau » d'accueil de tout type d'application. Il faudra donc déployer ECLIPSE sur les postes voulant bénéficier de cette technologie (prévoir 1 Mo de RAM & un bon processeur).
  
• Etc.
  

Il reste donc à savoir laquelle sera considérée comme un standard (c'est loin d'être évident) et fournira un FrameWork (API - Outil - AGL) permettant d'industrialiser les développements.

En tout état de cause, il conviendra au minimum d'acquérir la compétence, d'intégrer les outils, de déployer les composants sur le client (cas de SWT) et au pire de migrer les applications existantes.

La question suivante est alors posée : HTML & JavaScript restent-ils des challengers potentiels ?

SALTO Consulting à travers ses expériences pense que oui à condition de construire un véritable FrameWork de Présentation masquant la complexité d'implémentation des JavaScript dans HTML et utilisant au mieux la puissance « méconnue » du DOM (Document Object Model) améliorant considérablement la maintenance & la performance.

Thierry LUCON