JSF je t’aime, moi non plus

Cet article fait partie d’une série d’article sur les technologies incluses dans Java EE 6. Vous pouvez également lire l’article d’introduction de cette série : Java EE 6 ici et maintenant.

le Pilori

Le meilleur outil pour parler technologies ?

Il est certaines technologies qui déclenchent les passions. Elles recèlent en elles le potentiel de polariser les opinions et laissent peu de gens modérés ou indifférents à leur sujet. Elles vont parfois jusqu’à déclencher des guerres de religion (on a les combats que l’on peut) dans lesquelles s’embarquent quelques consultants IT.

JSF fait assurément partie de ce petit groupe d’outils ou de frameworks voués aux gémonies par les uns ou portés aux nues par les autres.

Autant l’avouer tout de suite, je suis plutôt pro-JSF, tout en essayant de garder une certaine objectivité à son endroit. Bien que cette technologie m’ait fait beaucoup souffrir lorsque j’ai commencé à l’utiliser en 2005, elle m’a aussi bien des fois agréablement surpris ou jeté dans des abîmes de frustration à d’autres. Autant dire que j’ai entretenu des rapports oscillant entre l’amour et la haine avec JSF.

Cependant, j’ai récemment commencé un projet avec JSF 2 et je dois admettre que, au risque d’écorner l’équanimité dont j’aime à faire preuve : “JSF 2 ça déchire grave”.

Vis ma vie avec JSF – un retour d’expérience

J’ai commencé à m’intéresser à JSF en 2004. Faisant exclusivement des développements web, ma stack d’alors était composée de Spring 1.0.1, de Struts 1.2 et d’iBatis 2. Struts me plaisait bien mais je trouvais qu’il me manquait quelque chose pour enrichir mes interfaces utilisateur. Bien sûr, j’utilisais les Jakarta taglibs d’Apache pour avoir des bibliothèques de tag JSP un peu plus étoffées et en développait moi même, mais ça restait globalement anémique. J’ai donc commencé à explorer JSF pendant la deuxième moitié de 2004 en parallèle de mes projets et ai eu l’opportunité de mettre ce savoir faire en pratique dès 2005 avec JSF 1.1 sur un beau projet. Autant l’avouer, le passage de la théorie à la pratique s’avéra être une douche froide : la technologie telle quelle, sortie de la boîte, était quasiment inutilisable pour un vrai développement d’interface avec du HTML. Et en même temps, certains aspects de la technologie étaient assez magiques comme les listeners qui permettaient de réagir à des événements sur l’interface ou tout le système de conversion et de validation qui bien qu’un peu lourd était bien conçu.

Ce premier projet fut pour moi une leçon de frustration ponctué de : “ça marche presque” ou de “dommage, ça avait l’air puissant mais, c’est inutilisable”. J’arrive tout de même à livrer mon appli (je me serais clairement planté si j’avais dû composer avec des graphistes et des webdesigners) et mon client, satisfait, m’en commande une seconde reprenant et étendant certaines fonctionnalités de la première. Là, j’ai un gros doute : est-ce que je repars de 0 avec quelque chose de plus classique ? Ou est-ce que je m’entête en essayant de trouver comment combler les 5% de fonctionnalités manquantes à la techno pour qu’elle soit productive ? Ayant des délais assez large, je prends le parti d’explorer la deuxième piste en me disant que si je ne trouve rien, j’aurais toujours le temps de repartir de zéro. C’est à ce moment là, que je découvre (grâce à tous les développeurs ayant souffert avant moi) le projet Facelets qui constitue la première lueur d’espoir dans ce désert de frustration qu’était JSF. Facelets en levant le frein du templating, rend la technologie utilisable sans camisole de force et capitonnage des murs. Je livre donc ce second projet beaucoup plus sereinement que le premier, même si tout n’est pas parfait.

A cette époque (début 2007), la version 1.2 de JSF est sortie et fait officiellement partie de Java EE 5, je croise de nombreux petits projets, mais n’ayant pas eu une expérience sans reproche avec JSF, je laisse la techno de côté, jusqu’à ce que je tombe dans JBoss Seam. Et là, je trouve le sésame. Seam débloque enfin JSF et le rend élégant et productif en comblant ses lacunes et corrigeant ses défauts. Après pas mal de petits projets et surtout deux gros menés avec ce framework, je peux affirmer que c’est l’un des mélanges les plus productif de l’éco système Java.

Bilan pré JSF 2 : JSF c’est génial quand y ajoute la techno de templating Facelets et le framework Seam sans oublier une bonne bibliothèque de composants comme Richfaces, Primefaces ou Icefaces. Ca fait beaucoup de choses à apprendre et maitriser pour une simple techno d’IHM. Et puis, que dire d’une technologie standard devant s’appuyer sur des solutions, certes Open Source, mais propriétaires pour être utilisable ?

Mais il semblerait que d’autres pensaient comme moi, car comme par magie, tous ces défauts ont été gommé avec la version 2 de JSF. Facelets fait désormais partie intégrante de la spécification et les apports de Seam pour JSF ont été intégrés. Mais j’y reviendrai plus loin.

Pourquoi tant de haine ?

Une perception de JSF assez juste à l'époque mais qui perdure injustement

Je pense avoir déjà donné un début de réponse à cette question dans le paragraphe précédent. Au delà d’un ressenti empirique et personnel, il me parait intéressant de synthétiser les anathèmes un peu primaires de tous les “Hate Boys” qui ont alimentés les rubriques “JSF sucks” que l’on retrouve dans la quasi totalité des sites liés à Java (je ne mets pas de lien sur ces sites histoire de ne pas contribuer à leur pagerank). Certains de ces reproches étaient bien fondés, d’autre un peu plus une question d’appréciation personnelle ou de mauvaise foi.

Mauvais paris sur l’évolution du Web

Gardons à l’esprit que les débuts de la conception de JSF remontent à 2001 et qu’à cette époque là, il était assez difficile d’imaginer le Web tel qu’il est aujourd’hui. Il s’agit d’une époque où l’applet java est toujours une solution client viable et où javascript n’est qu’une technologie de seconde zone à qui on délègue au mieux la vérification des champs des formulaires.

Les gens travaillant sur la première spécification de JSF, ont donc clairement raté les évolutions REST et Ajax du Web, obsédés qu’ils étaient de faire un Swing pour internet. Cela conduit à deux gros défaut

L’utilisation d’un technologie de templating ignorant HTML

Là, rien à dire. C’est une erreur grossière qui a coûté beaucoup à la réputation de JSF. La technologie de templating par défaut de JSF 1.X est basée sur JSP et n’accepte que des tags JSF  (le tag f:verbatim permet royalement d’intégrer du HTML au sein de JSF, mais rien pour intégrer des composants JSF dans du HTML). L’arrivée de Facelets et la possibilité de modifier la technologie de templating dans JSF a corrigé cette énorme lacune. Mais le côté un peu amateur du projet Facelets et le manque de soutien officiel de l’Expert Group JSF ont fait que Facelets est resté pendant longtemps confidentiel ou source d’interrogation sur la pérennité du mélange.

L’activation du cycle de vie JSF seulement à partir d’un POST HTTP.

Autre grossière erreur de conception : considérer que seul le POST HTTP peut être le point de départ d’un traitement complet côté serveur. Je reviens un peu plus loin sur le cycle de vie JSF, mais en gros, celui-ci a besoin d’être activé pour que la partie serveur soit sollicitée. Cette limitation en plus de complexifier inutilement les développements a eu des effets secondaires désastreux pour la réputation du framework. Il en découlait l’impossibilité d’avoir des URL bookmarkables par exemple ou l’impossibilité de réagir de manière élégante à la sollicitation d’une url sécurisée (la jonction entre une éventuelle partie servlet/jsp et une partie JSF entrainait de grosses coutures dans les applis avec obligation d’avoir recours à des mauvaises pratiques).

De nombreuses solution tierces (Seam en tête) ont apporté une solution à cette grosse lacune. Là encore, la polyvalence de JSF a permis d’apporter ces corrections de manière élégante et en greffant naturellement des extensions aux points prévus dans la spécification. Néanmoins, avoir recours à l’une de ces solutions consistait souvent à retomber sur une technologie propriétaire qui n’était pas toujours compatible avec des extensions ou bibliothèque de composants d’autres tiers.

Le cas AJAX

monsieur-propre-est-mort-L-1.jpg

L'accolyte d'Ajax

Entre 2001 et 2004, période de conception de JSF,  le concept de communication asynchrone entre le browser et le serveur est encore une excentricité que personne (à part Google) ne considère vraiment sérieusement. C’est l’âge d’or de Corba et IIOP et peu de gens envisagent que le web devienne une plateforme applicative riche. On ne peut donc pas trop blâmer l’Expert Group JSF de ne pas avoir anticiper ce besoin en limitant la spécification aux seules commandes POST et un peu GET pour dialoguer entre client et serveur.

Néanmoins, ce manque a dû être comblé par des tiers de manières très variées rendant les diverses bibliothèques de composants faisant de l’Ajax totalement incompatibles les unes avec les autres.

L’écosystème de la frustration

Très tôt de nombreux éditeurs se sont emparé de JSF pour proposer des bibliothèques de composants. Il suffit d’aller jeter un coup d’oeil sur JSF matrix pour se rendre compte , que cette technologie a inspiré beaucoup de monde. Cet aspect aurait pu jouer en faveur de JSF, mais malheureusement les limitations ou lacunes évoquées ci-dessus ont gravement morcelé l’eco-système : chaque éditeur apportant ses propres solutions pour combler ces manquements, les différentes bibliothèques de composants sont devenues très rapidement incompatibles entres elles. Ainsi, la spécification JSF a donné lieu à un morcellement et à la création de Framework de composants parallèle comme ADF Faces ou Ice Faces ou dans une moindre mesure Rich Faces. L’intérêt de la technologie devenant dès lors,très secondaire, puisqu’il était possible de monter un véritable écosystème.

Le cycle de vie JSF

Pour finir sur des notes positives, j’aimerai revenir sur des reproches nettement plus injustifiés rencontrés chez les détracteurs de JSF. Au centre de ces critiques, le cycle de vie JSF. Ces critiques qu’on pourrait globalement intituler : “je n’aime pas JSF, parce qu’il ne fait ce que je veux”, sont assez voisines de celles que l’on croise concernant une autre technologie bâtie autour d’un cycle de vie : Maven. J’en conclus que la plupart des développeurs préfèrent adapter une technologie à ce qu’ils savent plutôt que de l’apprendre et de voir si leur fonctionnement standard convient à leurs besoins.

En effet, le cycle de vie de JSF est central dans la technologie et l’ignorer c’est clairement aller au devant de beaucoup de problèmes rédhibitoires. JSF ne propose pas de bidouillages ou raccourcis genre scriplet permettant de faire l’économie de l’apprentissage de la technologie. Toutefois, si le cycle de vie est incontournable, il propose de nombreux points d’extension. C’est d’ailleurs grâce à cette extensibilité que JSF a pu être sauvé : les développement des différentes solutions palliatives ont su tirer parti de cet extensibilité pour proposer des add-ons élégants à JSF 1.

Un beau cycle de vie qui rachète beaucoup de choses

Les performances

JSF a souvent été critiqué pour ses “mauvaises” performances. Sans aller jusqu’à dire que c’est un foudre de guerre, je pense que beaucoup de choses fausses ont été écrites sur le sujet et que les problèmes de lenteur de JSF sont souvent due à une mauvaise connaissance du framework (cycle de vie et fonctionnement de certains composants). Débattre sur ces questions n’est pas l’objet de cet articles, néanmoins, je vous renvoie vers cet article très intéressant de Dan Allen sur l’optimisation de datatable dans une appui JSF / Seam qui montre qu’en se penchant sur le sujet, on peut diviser les temps de réponse par 10.

JSF malgré tout

Après ce réquisitoire aux allures définitives, vous êtes en droit de vous demander pourquoi je n’ai pas mis JSF à la poubelle comme beaucoup l’ont fait depuis longtemps. Au delà d’un simple entêtement, j’ai de bonnes raisons d’avoir persévéré dans cette technologie.

La communauté

La taille de la communauté autour de JSF est tout simplement énorme. C’est assez difficile de s’en rendre compte parce qu’en France, cette technologie est plutôt marginalisée au profit de Struts et de Spring MVC avec JSP ce qui fait qu’un adepte de JSF se sent parfois aussi esseulé qu’un fan de Daniel Guichard égaré dans un concert de Rammstein.

Néanmoins, il suffit d’aller sur Internet pour voir que les sites spécialisés et blogs sur JSF pullulent. On peut citer rapidement JSF central ou JSF Tutorials ou encore tous les site d’éditeurs de bibliothèque de composants que vous retrouverez sur JSF Matrix. Cette communauté est plutôt enthousiaste et constructive. Elle s’organise également beaucoup autour des grandes bibliothèques de composants JSF comme ICEfaces (l’une des première solution d’IHM pour Java full Ajax, sortie en 2005), RichFaces ou le plus récent mais très efficace PrimeFaces. Jusqu’à l’arrivée de JSF 2.0 ces communauté étaient assez étanches puisque choisir une bibliothèque rendait quasiment impossible d’utiliser les composants d’une autre. Depuis un an ces communautés s’ouvrent les unes aux autres, enrichissant encore plus l’éco-système.

L’or sous la boue

La lecture du début de cet article pourrait laisser penser que JSF est une technologie définitivement handicapée à la naissance. En fait ce qui a sauvé cette technologie tient au fait que son noyau est extrêmement bien pensé et hyper paramètrable. Ce noyau permet de changer la technologie de rendu, d’intervenir dans le cycle de vie des requêtes ou de changer de technologie pour le binding des objets côté serveur. Ce qui a plombé JSF, c’est que les choix par défaut de configuration de la techno étaient mauvais ou nettement incomplets. Les solutions tierces autour de JSF sont la meilleure démonstration de cette qualité intrinsèque de la spécification : elles se greffent toutes de manière naturelle à la technologie pour la compléter ou palier à des parties déficientes. ICEFaces qui s’approprie totalement le cycle de vie de JSF ou Seam 2.X qui l’enrichit  pour gommer tous ses défauts illustrent parfaitement cette ouverture dans la technologie.

Bien sûr, celui qui passe rapidement à côté de la techno ou qui la subi sans chercher à comprendre ne retiendra que la couche boueuse, mais il suffisait de creuser pour voir l’or à l’intérieur.

La solution composants / événement “standard”

Oui je sais : “on ne doit pas choisir une technologie parce qu’elle est standard”, je connais le refrain souvent rabâché par certains développeurs qui ne veulent pas bousculer leurs habitudes. Je suis globalement d’accord avec ce constat, mais je pense qu’il faut aussi ne pas refuser par principe une technologie parce qu’elle est standard. JSF est désormais un bon standard et même si cette technologie n’est pas adaptée à tous les besoins, je pense qu’il est fortement souhaitable que tous développeur d’applications web java la connaisse ne serait-ce que pour avoir un point de comparaison avec la technologie retenue sur leur développement.

Pour JSF (comme pour beaucoup de technologies Java EE) l’intérêt premier d’être un standard et d’avoir une spécification, c’est de disposer de plusieurs implémentations. JSF dispose de deux implémentations : celle de référence par Oracle : Mojarra et celle d’Apache : MyFaces. Ces deux implémentations sont de très bonne qualité et permettent aux développeurs de choisir le moteur le plus performant pour leur projet. L’émulation qui nait de l’existence de ces deux projets est bénéfique pour tout le monde et si votre implémentation contient un bug qui vous gêne, vous pouvez toujours basculer sur l’autre (c’est du vécu).

Seam, le framework aux belles coutures

Seam

Je parle beaucoup de Seam, mais ce framework a apporté beaucoup à Java EE. En proposant une approche plus moderne de l’injection de dépendance et en palliant à quasiment tous les défauts de JSF 1.X, ce framework joue le rôle de chaînon manquant dans l’histoire de Java EE.

Pour plus d’information sur le sujet vous pouvez toujours lire Les rendez-vous manqués de Spring qui revient sur ce point. Quoiqu’il en soit, les créateurs de Seam ont décidé de contribuer la majeure partie du framework à Java EE et d’en faire une spécification (CDI) et des améliorations pour JSF. Ces améliorations, plus celles d’autres vendeurs membres de l’expert group JSF 2.0, font de cette nouvelle spécification une vraie réussite.

JSF 2.0 :  un nouveau départ

Je ne vais pas faire une revue détaillée des nouveautés et évolutions de JSF 2.0. D’autres l’ont fait bien mieux que moi (et j’ai déjà perdu 80 % de mes lecteurs avec la longueur de mon post), je vous recommande donc la série d’articles écrits par les membres de l’Expert Group JSF 2.0 sur Java Lobby. Je reviendrais juste sur les aspects principaux de ces évolutions.

Standardisation de Facelets

J’ouvre le bal avec une non-nouveauté. Le Facelets de JSF 2 est peu ou prou celui que l’on utilisait avec JSF 1.X. L’énorme nouveauté, c’est qu’il s’agit désormais du langage de templating par défaut de JSF. Parler des bienfaits de Facelets sur la conception et le découpage d’une interface ainsi que le partage des rôles entre monteurs HTML et développeurs pourrait nous embarquer encore quelques dizaines de paragraphes que je réserve a un autre post. Toujours est-il que cette standardisation, stabilise JSF et constitue la reconnaissance officielle de l’Expert Group  du ratage du templating dans JSF 1.0

Le vrai support du get et ses conséquences

Bon, ok : “support du get”, vous pouvez ricaner (mais pas trop). Là encore, ce gros trou dans la raquette JSF était comblé depuis longtemps par des solutions tierces (je vous ai parlé de Seam ?), mais là ça y ‘est vous pouvez écrire un truc du genre :

<f:metadata>
 <f:viewParam name="orderid" value="#{commandHandler.orderId}"
 required="true"
 requiredMessage="You should provide an order id" />
 <f:event type="preRenderView" listener="#{commandHandler.initOrder}" />
</f:metadata>

ainsi les paramètres de l’URL peuvent maintenant être récupérés à l’ouverture de la page et un traitement peut être lancé dans la foulée. Traitement pouvant le cas échéant rediriger vers une page d’erreur en cas d’échec.

Ajax

Ajax fait enfin partie intégrante de JSF, il s’intégre au cycle de vie nativement et il est possible de l’invoquer soit par appel javascript soit par un tag JSF. Le rafraichissement partiel des vues JSF est supporté et le support de technologies évoluée comme Atmosphere est inclus dans MyFaces et devrait l’être bientôt dans Moraja.

Les composants Facelets

Le développement de composants JSF était une tâche assez fastidieuse dans JSF 1. Elle devient plus aisée dans JSF 2 grace à la sauvegarde d’état partiels mais surtout grâce à Facelets qui permet de créer un type de composants assez simple : les composites. Il s’agit en fait de morceaux de vues (pages) JSF très paramétrable et ré-utilisables. Ce concept permettra par exemple de créer un tag jsf pour inclure une applet flash ou un effet jQuery  qui doit se répèter (bulle d’aide).

Intuitive et versatile, cette approche qui existait déjà dans les versions antérieures de facelets donne une souplesse appréciable dans la conception d’interfaces et fait de JSF une vraie technologie “Légo” modulaire.

Un monde de composants interopérables

Amélioration de interactions avec le cycle de vie JSF

Le cycle de vie JSF n’a pas fondamentalement évolué depuis JSF 1. Ce qui change beaucoup, ce sont les outils pour interagir avec lui. le tag <f:event> permet de réagir à un événement survenant dans une phase donnée (comme dans l’exemple de récupération de paramètre donné ci-dessus). Ces événement peuvent également déclencher des appels javascript ou du code Java de manière beaucoup plus naturelle qu’auparavant. Le cycle de vie devient donc plus facile à adapter à des besoins particuliers ce qui rend le framework encore plus polyvalent.

De plus la gestion des exceptions est enfin intégrée (Seam again), et il est possible d’aiguiller automatiquement vers une page d’erreur JSF ou JSP en cas de soucis dans un traitement.

Une navigation améliorée et simplifiée

Amélioration en provenance de Seam à nouveau. Les règles de navigation conditionnelles permettent de rendre plus souple la navigation dans les vues JSF et les actions dans les tags JSF peuvent désormais être soit des vues de destination soit des outcomes qui seront traités par le processus de navigation sans avoir besoin de passer par l’invocation du code.

Conclusion : JSF 2 le mélange équilibré de l’IHM Web ?

Pour conclusion, j’évoquerai les approches antagonistes actuelles entre les frameworks qui prônent le do it yourself concernant la partie IHM (Ruby on Rails, Play!, Spring MVC) et ceux qui livrent des approches de composants riches laissant peu de contrôle sur le code produit (GWT ou Vaadin par exemple). Ces deux perceptions ont leurs avantages et inconvénients et je me garderai bien de trancher sur le sujet.

Simplement, je remarque que JSF 2.0 est une solution qui permet de jouer sur les deux tableaux, en permettant de développer soit même des composants réutilisables de manière très simple et/ou d’avoir recours à des bibliothèques très riches de composants haut niveau qui vont produire des interfaces riches sans que l’on ai à maitriser  HTML 5, CSS3 ou Javascript.

Pour ceux qui se demandent encore pourquoi JSF est  la technologie standard d’IHM web de Java EE 6, je pense que la réponse se trouve beaucoup dans cette souplesse et que, même si JSF a encore des progrès à faire, il a le mérite de proposer la bonne péréquation entre la conception d’interfaces simples et la création de client Web riches.  Une synthèse presque parfaite des frameworks web Java en quelque sorte.

TwitterFacebookGoogle+LinkedIn
  • http://twitter.com/geoffray_ippon Geoffray Gruel

    JSF or not JSF ???

    • http://www.next-presso.fr Antoine Sabot-Durand

      JSF c’est clair :-) ! Mais pas de façon zélote : restons lucides et mesurés c’est juste du “bits and bytes” comme dirait mon boss.

  • Cdorot

    Merci pour cet article intéressant – je suis également pro-JSF et me reconnaît dans la difficile prise d’apprentissage que tu décris – bien que ayant commencé à l’époque de JSF 1.1 et 1.2 où il était déjà possible de bénéficier de la technologie Facelets. J’ai réalisé principalement 2 projets avec cette techno, pour le premier on n’a pas fait un changement brutal et à coté de JSF et Facelets on retrouvait toujours les bonnes vieilles JSP et JSTL – le second a permis d’être beaucoup plus proche des intentions de ce framework en optant pour du XHTML coté vue. A cette époque, la création de composants revêt un aspect très complexe et nous décourage rapidement de créer nos propres composants (on est dans un context de time to market très court et l’on ne peut pas investir dessus) – on choisit donc Richfaces pour ses composants riches, cette librairie riche nous apporte bien des services à partir du moment où les comportements attendus sont très simples mais les interractions entre composants freinent considérablement notre productivité (il est possible qu’à ce moment là nous n’avions pas encore intégré les bonnes pratiques de développement par composants dans un environnement web) – on développe à ce moment la avec la version 3.3 de RichFaces … Les manques de ces premières versions de JSF semblent avoir eu un écho au niveau de l’expert Group sur JSF et la version 2 qui a déjà plus d’un an apparaît comme une solution élégante : à tester ;-) Richfaces 4 lui aussi semble offrir de nouvelles orientations pour le développement de composants web (notamment avec son CDK).
    Enfin petit dernier clin d’oeil par rapport à mon expérience personnelle, je me souviens plusieurs fois avoir été frustré par la complexité de faire de l’asynchrone avec ses propres js, c’était pourtant l’argument marketing qui résonnait comme un “vous voulez faire du RIA avec Java, optez pour du JSF”. Cette complexité était du au fait que toute modification du DOM effectuée coté JS nécessitait une mise à jour de l’état du DOM coté serveur.

    L’article est très bon, comme d’habitude :-)

    • http://www.next-presso.fr Antoine Sabot-Durand

      Merci Cédric.
      Oui, j’ai oublié de parler de la difficulté à développer des composants dans JSF 1.X. Ton retour sur ce point est intéressant.

  • Rgirodon

    Très bon article, mais dont je ne partage pas du tout les conclusions.
    Je suis clairement du côté des frameworks qui prônent le “do it yourself” pour la vue.
    Ou plutôt le “do it yourself with jQuery, jQueryUI, and some plugins”.

    • http://www.next-presso.fr Antoine Sabot-Durand

      Justement. JSF permet de “packager” l’expertise de quelques uns sur JQuery par exemple pour livrer des composants réutilisables aux autres. JSF2 livre des API Javascripts permettant de tirer le meilleur des 2 mondes. Maintenant je suis d’accord qu’utiliser JSF 2 sur un site Web grand public mérite réflexion pour des problèmes de scalabilité.

  • Alexandre de Pellegrin

    Comme il y a des pro JSF ici, voici un appel au NON! Je n’apprécie pas les templates JSF, Ca me donne des boutons. Je préfère largement les produits “Swing like” à la Vaadin, Wicket ou GWT. Reste une chose intéressante : quelque soit le framework, la problématique du choix reste entière en 2011; question de suivi, de pérennité et (surout) de productivité. Et la multiplication des couches techniques à appréhender est un frein à l’adoption d’une techno. Mon idéal est donc d’avoir un framework qui se comporte à la swing sans avoir à mettre les mains dans les templates de pages, les javascripts maison, les appels à jquery, à de l’ajax, etc… Une seule techno pour tout! Et là dessus, j’ai ma petite idée. Avec HTML5, il y a le “fameux canvas”. Si on y regarde d’un peu plus prêt, on y voit que le mécanisme de paint() est proche d’AWT. Dès lors, pourquoi ne pas imaginer dans le futur des frameworks n’utilisant plus le POST HTTP de formulaires complets mais plutôt des appels au serveur totalement asynchrones et évènementiels et de l’affichage dans le canvas. Fini le templating, fini les js : c’est le framework qui se chargerait de tout. Le navigateur deviendrait un terminal légitime pour l’affichage d’applications de gestion et non plus un machin qu’on tord à longueur d’année pour y faire rentrer à coup de tatane des ERP full web. Du coup, j’ai fait un petit test. J’ai porté une appli swing en HTML5 avec JWT (http://www.webtoolkit.eu/jwt). OK, je sais : c’est le vieux mythe du swingman. Curieusement, j’ai eu un résultat plus que satisfaisant. Alors à mon avis, JSF ou pas, pour ce qui est des applications de gestion webisées, il risque d’y avoir du changement dans les années à venir.

    • http://www.jroller.com/dmdevito Dominique De Vito

      A une époque, on entendait parler de la sortie d’une Java Browser Edition, histoire notamment de dégraisser le mammouth JRE. Cette Edition n’est jamais sortie.
      A contrario, j’ai plaisir à penser que Google a, en qque sorte, grillé la priorité à SUN car GWT peut être vu (IMHO) comme une implémentation de cette Java Browser Edition ; ce que j’ai écrit dans mon billet “Google has released a (kind of) Java Browser Edition with GWT” http://www.jroller.com/dmdevito/entry/google_has_released_a_kind

      Certes, au départ, cette Java Browser Edition a la sauce GWT ne contenait pas d’implémentation de Swing. Mais, avec HTML5, on aura peut être des surprises avec les nouvelles “Java Browser Edition” à venir… En effet, l’élément Canvas pourrait être utilisé pour implémenter Swing coté client.
      Une des surprises à venir concerne notamment JavaFX qui va être une sorte de GWT-bis, mêlant les technos Java et HTML.

      Dans cette course des titans, JSF semble jouer en seconde zone. Sur le devant de la scène, on a soit une approche HTML/CSS/JS, exploitant la force de ces standards (ex: jQuery), soit une approche Java, exploitant la force de ce langage (ex: typage statique). JSF me semble un peu le cul entre 2 chaises, et de ce fait, souffrant de l’intégration de plusieurs couches dont la complexité d’intégration n’a pas été (ou pu être ?) trop masquée.

      Affaire à suivre…

  • LUDE

    J’ai eu l’occasion de travailler sur plusieurs projets JSF 1.1 ou 1.2. Même si JSF 2.0 apporte son lot d’amélioration (notamment l’écriture des composants qui était une horreur) ma conviction personnelle est que cette technologie n’est pas adpatée pour des sites grands publics (avec support de nombreux navigateurs) à cause du trop grand nombre de couches d’abstraction (trop éloigné du web) et de la complexité de développer/déboguer un composant. Je ne pense pas que les bibliothèques de composants JSF soient autant testées sur tous les navigateurs que des Ext-JS/SmartGwt etc. Aussi le stockage de l’arbre des composants côté serveur (par défaut) n’en fait pas une solution scalable. Seam également encourage aussi de stocker toujours plus d’état avec les conversations.

    Je préfère largement aujourd’hui une architecture SOFEA avec des clients Web lourds (GWT/JQuery) qui gèrent l’état lié à la navigation pour la scalabilité et aussi pour le support de clients mobiles. Avoir une même page facelet et des renderers différents en fonction du channel est une utopie.
    Pour un intranet avec un support d’un nombre limité d’utilisateurs et de navigateurs, JSF permet d’être très productif, je suis plus sceptique pour des sites grand publique.

  • Jp Encausse

    Merci pour cette article très intéressant, je comprends le besoin d’un Framework pour construire des IHM et ne pas réinventer la roue sur chaque projet, malheureusement la souplesse demandé à JSF & co impose de réinventer un système de balisage. Si je caricature ce n’est plus mais . Les pauvres webdesigner …

    Je préfère l’approche qui consiste a corriger l’existant: HTML5/CSS3/JavaScript. Ou a l’inverse avoir des composants beaucoup plus figé. Lors de la conf Google GWT il y a qq année j’avais été choqué par l’argument “On fait tout” en effet dès qu’il manque qqch il faut tout coder en pseudo javascript dans une enveloppe GWT.

    Bref je crois plus dans des framework tel que Prototype, LESSCSS, BluePrint, … qui auront tendance a disparaître avec l’amélioration du langage.

  • Hery Deslandes

    Excellent article, je souhaiterais rajouter quelque chose concernant les incompatibilités entre les librairies de composant JSFs: on ne peut embarquer 2 librairies comme icefaces et richfaces alors que cela devrait être possible.

    Sinon, j’apprécie énormément JSF, nous l’utilisons avec RichFaces et je suis particulièrement impressionné par la rapidité de mise en place de la couche WEB. J’ai été obligé de désinstaller Primefaces car cela perturbait Richfaces.
    Pour la partie admin du site, c’est du GWT/Vaadin mais cette techno manque encore un peu de maturité et si c’était à refaire, je pense que ce serait du full JSF.

  • http://www.jroller.com/dmdevito Dominique De Vito

    Je me semble que les technos GUI web se rapprochent les unes des autres.
    cf. “Intégration facile de maquette Html en GWT 2″ http://www.insideit.fr/post/2011/01/03/Retour-d-exp%C3%A9rience-d-un-projet-GWT-:-3-Int%C3%A9gration-facile-de-maquette-Html-en-GWT-2

    Pour GWT, on peut maintenant partir d’une maquette HTML que l’on enrichit de tags HTML spécifiques GWT : cela ressemble (vu de loin) à JSF, non ?

    Vu le rapprochement de ces différentes technos, il manque, je trouve, un grand papier (ou tableau comparatif) pour faire plus finement le distinguo entre (par ex) JSF, GWT et Tapestry…

    A vue de nez, si je devais faire la comparaison entre JSF et GWT, je serais tenté d’écrire la chose suivante:
    - JSF maintient coté serveur une représentation des données coté client (avec un cycle de vie, ce qui permet, par ex, de greffer des listeners ad hoc), ce qui n’est pas le cas de GWT orienté service.
    - la techno de binding vue/modèle par défaut pour GWT est Java, tandis qu’elle consiste en les facelets/JSP pour JSF.
    - la webapp développée avec GWT peut être compilée “comme un tout”, ce qui permet la cross-compilation (de Java vers JavaScript, mais cela pourrait être un autre langage cible), tandis que JSF est clairement orientée webappp. De ce fait, GWT peut être plus facilement utilisé par ex pour développer des extensions de navigateur ; GWT a déjà été utilisé pour développer une extension Chrome et pourrait l’être aussi pour développer une extension Firefox, cf. http://www.jroller.com/dmdevito/entry/gwt_and_jetpack_are_going

    A corriger et/ou compléter ?