Java EE: Evolutions depuis 1 an et demi

Après une période à bosser sur mes projets, je reprends le clavier.

Une petite question toute innocente sur theserverside.com m'a replongé dans l'époque des grandes questions sur quelle techno de présentation Java EE utiliser (lien vers mon commentaire).

La situation générale s'est un peu éclaircie, bien que je pense toujours que l'univers Web est en période de transition:

• HTML vieillissant (avec une version 5 qui n'en finit pas d'être repoussée, et dont le contenu ne cesse de bouger)
• de plus en plus d'intérêt pour des pages plus riches et dynamiques; pour des sites professionnels, forte pression des clients pour en intégrer
  
• côté AJAX, quelques grandes bibliothèques javascript(jQuery, Dojo, Prototype, Scriptaculous et consors)
• de l'autre côté (plugin Adobe Flex et Microsoft Silverlight), une évangélisation à marche forcée, sauf pour JavaFX qui est complètement largué, et dont on peut être sûr que la récente version 1 sortie récemment n'aura rien à voir avec la prochaine version vu le peu de moyens qu'y a consacré Sun (d'ailleurs, ça rappelle ce qu'il s'est passé avec Flex 1 & 1.5 et Silverlight 1, très différents des versions actuelles, notamment au niveau conceptuel)
  
• des frameworks Java EE qui intègrent de facto ou à l'aide de wrapper/adapter l'AJAX et les technos javascript, et un écrémage au fur et à mesure de ces frameworks
  
• une tendance des navigateurs à décupler les performances des interpréteurs javascript

Au final, pour lancer un projet JEE, on a le choix pour la couche de présentation entre:

• Google GWT, qui évolue vite, qui s'appuie sur du HTML/Javascript donc pas besoin de plugin, mais dont la programmation s'éloigne pas mal des classiques JSP (ce qui est de toutes façons normal pour une techno de présentation Web riche, et c'est plutôt une bonne chose, d'ailleurs - gérer des formulaires HTTP et des urls va vite devenir la préhistoire des applis Web). Mais:
  • très lié à Google; même si le framework est Open Source, si Google arrête tout, qui va se plonger dans le code Google pour gérer la compilation de l'interface (écrite en Java dans le cas de GWT) vers chaque navigateur (voir chaque version de navigateur) ?
  • repose tout de même sur AJAX; or, AJAX est un hack du mode de fonctionnement classique request/response du HTTP, ce qui impose de multiples contraintes, et les échanges se font en mode texte, ce qui n'est pas très optimatal pour les échanges client/serveur. Cependant, étant donné que l'interface est écrite en Java, rien n'empêche Google de développé un compilateur de Java vers Flash/Silverlight/JavaFX, un peu à la mode d'OpenLaszlo (mais en plus performant...)
  Au final, GWT vaut vraiment le coup, même si le coût (d'apprentissage) n'est pas négligeable (mais je vous rassure, ça reste abordable et c'est très élégant).

• Apache Wicket, basé sur une logique de composants, framework séduisant et très soutenu par une communauté très active. J'ai pas grand chose à en dire, ce n'est pas un choix que je retiens personnellement parce qu'il se base trop sur du HTML pour la partie interface, et que pour moi ce n'est pas vraiment un choix d'avenir, mais les avantages sont aussi la simplicité et la courbe d'apprentissage moins abrupte que GWT (et Flex/Silverlight).
  

• JSF (avec Facelet et la couche intermédiaire JBoss Seam); là, je n'y crois plus trop. Trop compliqué, revu mais trop tard avec la version 2 qui sort cet hiver (ou pas...).

• Adobe Flex; le choix que j'ai fait pour mes nouveaux projets. Courbe d'apprentissage assez abrupte, nécessité d'avoir un plugin, même problème que GWT pour ce qui est du projet Open Source avec la dépendance à un éditeur (Adobe en l'occurence).
  Au bout d'un an, un développeur est capable de faire des choses vraiment biens, même si la logique de positionnement et redimensionnement des composants est ardue à comprendre lorsque l'on est habitué à faire des clients HTML (ça se rapproche des interfaces clients lourds comme le Swing, même si c'est tout de même beaucoup plus simple et élégant au niveau de la gestion des évènements).
  Et une fois que l'on maitrise un peu la techno, c'est que du bonheur (y compris pour le chef de projet, avec une productivité bien accrue par rapport aux frameworks MVC basé sur du HTML - Struts 1 & 2, Spring MVC...)
  

• Microsoft Silverlight; techno encore trop jeune, mais Microsoft met vraiment les moyens en ce moment. Sans doute promis à un bel avenir.
  

Pour passer rapidement sur les autres choix, certaines technos de bonne qualité ne vont, à mon avis pas tenir trop longtemps, par manque de visibilité ou par concept un peu dépassé:

• Tapestry, qui change du tout au tout entre les versions, et qui se dilue parmi les autres technos ci-dessus
  
• Struts 2, qui reste un choix lorsque l'on ne veut pas faire "le grand saut" vers une appli Web riche, mais qui est tout de même bien complexe et contraignant
  
• Echo, pas trop de visibilité, en perte de vitesse par rapport à GWT et Flex
  
• OpenLaszlo, pas assez de moyens par rapport à Flex (ils peuvent pas faire grand chose, malgré leur talent, face à une boite énorme comme Adobe, qui mise à fond sur Flex pour son futur)
• Spring MVC, Webworks... même problème que Struts 2: un peu dépassés
  

Au final, le paysage se clarifie un peu, mais reste assez flou. Je suis persuadé que le Web va évoluer vers une ou plusieurs technos riches et se détourner du HTML pour la plupart des sites professionnels. Google finira par faire son Flex/Silverlight, quitte à ce que ce soit du "Full Javascript" dans son navigateur Chrome, ou un plugin (native client, ou autre - par exemple un plugin similaire à celui développé il y a peu pour ajouter des conversations vidéos à Google Talk dans GMail).
Ce même HTML, du fait de sa simplicité, va certainement continuer à vivre pour les sites peu intéractifs.

Et en toutes franchise, je doute que ces technos riches qui vont changer le Web soit l'une de celles cités plus haut... on est encore en période de transition pendant quelques années.