Quels sont les principaux inconvénients de Java Server Faces 2.0 ?

Question

Hier, j'ai assisté à une présentation sur Java Server Faces 2.0 qui semblait vraiment impressionnante, même si je suis actuellement un heureux développeur ASP.NET MVC / jQuery. Ce que j'ai le plus apprécié dans JSF, c'est l'énorme quantité de composants d'interface utilisateur compatibles AJAX qui semblent rendre le développement beaucoup plus rapide qu'avec ASP.NET MVC, en particulier sur les sites à forte intensité AJAX. Les tests d'intégration sont également très intéressants.

La présentation n'ayant mis en avant que les avantages de JSF, j'aimerais également connaître l'autre côté de la médaille.

Mes questions sont donc les suivantes :

• Quels sont les principaux inconvénients de Java Server Faces 2.0 ?
• Qu'est-ce qui pourrait inciter un développeur JSF à envisager d'utiliser ASP.NET MVC au lieu de JSF ?

Answer 1

Les inconvénients de JSF 2.0 ? Honnêtement, en dehors de la courbe d'apprentissage relativement raide lorsque vous n'avez pas de solides connaissances de base sur les technologies de l'information et de la communication (TIC), les inconvénients sont nombreux. Développement Web de base (HTML/CSS/JS, côté serveur versus côté client, etc.) et les API de base de Java Servlet (demande/réponse/session, transfert/redirection, etc.), aucun inconvénient sérieux ne vient à l'esprit. JSF, dans sa version actuelle, doit encore se débarrasser de l'image négative qu'il a acquise au cours des premières années, durant lesquelles il présentait plusieurs inconvénients sérieux.

JSF 1.0 (mars 2004)

C'était la version initiale. Elle était encombrée de bogues, tant dans le noyau que dans les performances, que vous ne voulez pas connaître. Votre application web ne fonctionnait pas toujours comme vous l'aviez intuitivement prévu. En tant que développeur, vous vous enfuyiez en pleurant.

JSF 1.1 (mai 2004)

C'était la version de correction de bogues. Les performances n'étaient toujours pas très améliorées. Il y avait également un inconvénient majeur : vous ne pouvez pas intégrer le HTML dans la page JSF sans problème. Tout le HTML simple est rendu avant l'arbre des composants JSF. Vous devez envelopper tous les composants simples dans des fichiers <f:verbatim> afin qu'elles soient incluses dans l'arbre des composants JSF. Bien que cela soit conforme à la spécification, cela a fait l'objet de nombreuses critiques. Voir aussi a.o. JSF/Facelets : pourquoi n'est-ce pas une bonne idée de mélanger JSF/Facelets avec des balises HTML ?

JSF 1.2 (mai 2006)

Il s'agissait de la première version de la nouvelle équipe de développement JSF dirigée par Ryan Lubke. La nouvelle équipe a fait un travail remarquable. Des changements ont également été apportés à la spécification. Le changement majeur a été l'amélioration de la gestion des vues. Cela n'a pas seulement permis de détacher complètement JSF de JSP, de sorte que l'on puisse utiliser une technologie de vue différente de celle de JSP, mais cela a également permis aux développeurs d'intégrer du HTML pur et simple dans la page JSF sans avoir à s'embêter avec le langage <f:verbatim> tags. La nouvelle équipe s'est également attachée à améliorer les performances. Pendant la durée de vie de l'implémentation de référence Sun JSF 1.2 (dont le nom de code était Mojarra depuis la version 1.2_08, vers 2008), pratiquement chaque version a été livrée avec des améliorations (majeures) des performances en plus des habituelles corrections de bogues (mineures).

Le seul inconvénient sérieux de JSF 1.x (y compris la version 1.2) est l'absence d'une portée entre les éléments de type demande y session la portée de ce que l'on appelle conversation portée. Cela obligeait les développeurs à s'embêter avec des éléments d'entrée cachés, des requêtes inutiles à la base de données et/ou à abuser de la portée de la session chaque fois qu'ils voulaient conserver les données initiales du modèle dans la requête suivante afin de traiter avec succès les validations, les conversions, les changements de modèle et les invocations d'action dans les applications web plus complexes. La douleur pourrait être atténuée par l'adoption d'une bibliothèque tierce qui conserve les données nécessaires dans la requête suivante, par exemple MyFaces Tomahawk <t:saveState> composant, JBoss Seam l'objet de la conversation et Orchestre MyFaces cadre de conversation.

Un autre inconvénient pour les puristes du HTML/CSS est que JSF utilise les deux points. : comme caractère séparateur d'ID pour assurer l'unicité de l'élément HTML id dans la sortie HTML générée, en particulier lorsqu'un composant est réutilisé plus d'une fois dans la vue (templating, composants itératifs, etc.). Étant donné qu'il s'agit d'un caractère illégal dans les identificateurs CSS, vous devez utiliser la balise \ pour échapper aux deux-points dans les sélecteurs CSS, ce qui donne des sélecteurs laids et bizarres tels que #formId\:fieldId {} ou même #formId\3A fieldId {} . Voir aussi Comment utiliser l'ID de l'élément HTML généré par JSF avec les deux points " :" dans les sélecteurs CSS ? Toutefois, si vous n'êtes pas un puriste, lisez aussi Par défaut, JSF génère des identifiants inutilisables, qui sont incompatibles avec la partie css des normes Web. .

De plus, JSF 1.x n'était pas livré avec des fonctions Ajax. Ce n'est pas vraiment un inconvénient technique, mais en raison de l'engouement pour le Web 2.0 à cette époque, c'est devenu un inconvénient fonctionnel. Exadel a été le premier à introduire Ajax4jsf, qui a été développé de manière approfondie au cours des années et est devenu la partie principale de JBoss RichFaces bibliothèque de composants. D'autres bibliothèques de composants ont été livrées avec des fonctions Ajax intégrées, la plus connue étant la suivante ICEfaces .

À peu près à la moitié de la durée de vie de JSF 1.2, une nouvelle technologie de vue basée sur XML a été introduite : Facettes . Cela offrait d'énormes avantages par rapport à JSP, en particulier dans le domaine de la création de modèles.

JSF 2.0 (juin 2009)

Il s'agissait de la deuxième version majeure, avec Ajax comme mot à la mode. Il y a eu beaucoup de changements techniques et fonctionnels. JSP a été remplacé par Facelets comme technologie d'affichage par défaut et Facelets a été étendu avec des capacités de création de composants personnalisés en utilisant du pur XML (le soi-disant composants composites ). Voir aussi Pourquoi Facelets est préféré à JSP comme langage de définition des vues à partir de JSF2.0 ?

Les pouvoirs d'Ajax ont été introduits dans la saveur du <f:ajax> qui présente de nombreuses similitudes avec Ajax4jsf. Des annotations et des améliorations de la convention sur la configuration ont été introduites pour tuer le verbeux faces-config.xml dans la mesure du possible. En outre, le caractère séparateur d'ID du conteneur de nommage par défaut : est devenu configurable, ce qui soulage les puristes du HTML/CSS. Tout ce que vous avez à faire est de le définir en tant que init-param sur web.xml avec le nom javax.faces.SEPARATOR_CHAR et assurez-vous que vous n'utilisez pas le caractère vous-même dans les identifiants du client, par exemple - .

Enfin et surtout, une nouvelle portée a été introduite, la voir portée. Cela a éliminé un autre inconvénient majeur de JSF 1.x, comme décrit précédemment. Il suffit de déclarer le bean @ViewScoped pour permettre la portée de la conversation sans s'embêter à conserver les données dans les demandes (conversationnelles) ultérieures. A @ViewScoped bean vivra tant que vous soumettrez et naviguerez ultérieurement vers la même vue (indépendamment de l'onglet/fenêtre ouvert(e) du navigateur !), de manière synchrone ou asynchrone (Ajax). Voir aussi Différence entre les champs View et Request dans les managed beans y Comment choisir la bonne lunette de visée ?

Bien que pratiquement tous les inconvénients de JSF 1.x aient été éliminés, il existe des bogues spécifiques à JSF 2.0 qui pourraient devenir rédhibitoires. Le site @ViewScoped échoue dans les gestionnaires de balises en raison d'un problème d'œuf de poule dans la sauvegarde partielle de l'état. Ce problème est corrigé dans JSF 2.2 et reporté dans Mojarra 2.1.18. Aussi en passant des attributs personnalisés comme le HTML5 data-xxx n'est pas pris en charge. Ce problème a été corrigé dans JSF 2.2 grâce à la nouvelle fonctionnalité d'éléments et d'attributs passthrough. En outre, l'implémentation JSF Mojarra a sa propre série de problèmes . Un nombre relativement important d'entre eux sont liés à la le comportement parfois peu intuitif de <ui:repeat> le nouvelle mise en œuvre de la sauvegarde d'un état partiel y el champ d'application du flash mal mis en œuvre . La plupart d'entre eux sont corrigés dans une version 2.2.x de Mojarra.

À l'époque de JSF 2.0, PrimeFaces a été introduit, basé sur jQuery et jQuery UI. Elle est devenue la bibliothèque de composants JSF la plus populaire.

JSF 2.2 (mai 2013)

Avec l'introduction de JSF 2.2, HTML5 a été utilisé comme mot à la mode même si, techniquement, il n'était pris en charge que dans toutes les anciennes versions de JSF. Voir aussi JavaServer Faces 2.2 et le support HTML5, pourquoi le XHTML est-il encore utilisé ? . La nouvelle fonctionnalité la plus importante de JSF 2.2 est la prise en charge des attributs de composants personnalisés, ouvrant ainsi un monde de possibilités, telles que groupes de boutons radio personnalisés sans tableau .

En dehors des bogues spécifiques à l'implémentation et de quelques "petites choses ennuyeuses" comme l'impossibilité d'injecter un EJB dans un validateur/convertisseur (déjà corrigé dans JSF 2.3), il n'y a pas vraiment d'inconvénients majeurs dans la spécification JSF 2.2.

MVC basé sur les composants et MVC basé sur les requêtes

Certains pourraient opter pour le fait que le principal inconvénient de JSF est qu'il ne permet qu'un contrôle très fin du HTML/CSS/JS généré. Ce n'est pas le propre de JSF, c'est simplement parce qu'il s'agit d'un logiciel de type basé sur des composants MVC, et non un basé sur une demande (action) Cadre MVC. Si un degré élevé de contrôle de l'HTML/CSS/JS est votre principale exigence lorsque vous envisagez un framework MVC, alors vous ne devriez déjà pas vous tourner vers un framework MVC basé sur les composants, mais plutôt vers un framework MVC basé sur les requêtes comme Spring MVC . Vous devez seulement prendre en compte le fait que vous devrez écrire vous-même tout le code HTML/CSS/JS. Voir aussi Différence entre Request MVC et Component MVC .

Voir aussi :

• Quelle est la différence entre JSF, Servlet et JSP ? (juste pour comprendre les bases)
• Utilisation de JSF pour développer des mises en page CSS sans tableau (un autre mythe sur JSF)
• JSF vs HTML/CSS/JS/jQuery ordinaire (quand JSF est le mauvais choix)
• Modèles de conception dans les applications web (illustre l'idéologie derrière MVC)

Answer 2

Après avoir travaillé pendant 5 ans avec JSF, je pense que je peux ajouter mes deux cents.

Deux JSF majeur les inconvénients :

1. Grande courbe d'apprentissage. JSF est complexe, c'est tout simplement vrai.
2. Son composant nature. Les cadres basés sur les composants tentent de cacher la véritable nature du Web, ce qui s'accompagne d'un grand nombre de complications et de désastres (comme le fait de ne pas prendre en charge GET dans JSF pendant près de 5 ans).
   À mon avis, cacher les requêtes/réponses HTTP au développeur est une énorme erreur. D'après mon expérience, chaque cadre basé sur des composants ajoute de l'abstraction au développement Web, et cette abstraction entraîne des frais généraux inutiles et une complexité accrue.

Et mineur les inconvénients qui me viennent à l'esprit :

1. Par défaut l'ID de l'objet est composé des ids de ses parents, par exemple form1:button1.
2. Pas de moyen facile de commenter un fragment de page incorrect. Étiquette <ui:remove> a besoin d'un contenu syntaxiquement correct, qui est de toute façon analysé.
3. Composants tiers de qualité médiocre, qui ne vérifient pas, par exemple, l'état de l'environnement. isRendered() à l'intérieur de processXxx() avant de poursuivre.
4. Intégrer LESS et Sencha est difficile.
5. Ne joue pas bien avec REST.
6. Ce n'est pas si facile pour les concepteurs d'UX, car les composants prêts à l'emploi ont leurs propres styles CSS, qui doivent être écrasés.

Ne vous méprenez pas. En tant que framework à composants, JSF dans sa version 2 est vraiment bon, mais il est toujours basé sur des composants, et le sera toujours...

Jetez un coup d'œil à la faible popularité de Tapestry, Wicket et au faible enthousiasme des développeurs JSF expérimentés (ce qui est encore plus significatif). Et par contraste, regardez le succès de Rails, Grails, Django, Play ! Framework - ils sont tous basés sur l'action et n'essaient pas de se cacher du programmeur. vrai demande/réponse y caractère apatride de la toile.

Pour moi, c'est le principal désavantage du JSF. IMHO JSF peut convenir à certains types d'applications (intranet, formulaires intensifs), mais pour la vie réelle web l'application, ce n'est pas une bonne façon de faire.

J'espère que cela aidera quelqu'un dans ses choix en matière de front-end.

Answer 3

Quelques inconvénients qui me viennent à l'esprit :

1. JSF est un cadre basé sur les composants. Cela a des restrictions inhérentes qui qui ont à voir avec l'obéissance au modèle de composant.
2. AFAIK JSF ne supporte que le POST, donc si vous voulez un GET quelque part vous devez faire un simple servlet/JSP.
3. La plupart des composants essaient de fournir des abstractions sur des domaines tels que bases de données relationnelles et le front-end JavaScript, et souvent, ces abstractions sont "fuyantes" et très difficiles à déboguer.
4. Ces abstractions peuvent constituer un bon point de départ pour un développeur débutant ou pour quelqu'un qui n'est pas à l'aise dans un domaine particulier (par exemple, le JavaScript frontal), mais il est très difficile d'optimiser les performances, car plusieurs couches sont impliquées et la plupart des personnes qui les utilisent ne comprennent guère ce qui se passe sous le capot.
5. Les mécanismes de modélisation habituellement utilisés avec JSF n'ont rien à voir avec le fonctionnement des conceptions Web. Les éditeurs WYSIWYG pour JSF sont primitifs et, dans tous les cas, votre concepteur vous donnera du HTML/CSS que vous devrez passer des heures à convertir.
6. Des choses comme les expressions EL ne sont pas vérifiées statiquement et le compilateur et les IDE ne font pas un bon travail pour trouver les erreurs, donc vous vous retrouverez avec des erreurs que vous devrez attraper au moment de l'exécution. Cela peut convenir à des langages typés dynamiquement comme Ruby ou PHP, mais si je dois supporter le foisonnement de l'écosystème Java, j'exige le typage pour mes modèles.

Pour résumer : Le temps que vous gagnerez avec JSF, en évitant d'écrire le code passe-partout JSP/servlet/bean, vous le dépenserez x10 pour le faire évoluer et faire exactement ce que vous voulez qu'il fasse.

Answer 4

Pour moi, le plus gros inconvénient de JSF 2.0 est la courbe d'apprentissage, non seulement de JSF, mais aussi des bibliothèques de composants que vous devez utiliser pour qu'il puisse faire un travail utile. Considérez le nombre stupéfiant de spécifications et de normes que vous devez traiter pour être vraiment compétent :

• HTML dans ses différentes incarnations. Ne prétendez pas que vous n'avez pas besoin de le connaître.
• HTTP : lorsque vous n'arrivez pas à comprendre ce qui se passe, vous devez ouvrir Firebug et voir. Pour cela, vous devez savoir ceci.
• CSS -- Que vous le vouliez ou non. Ce n'est pas si mal, et il existe au moins quelques outils intéressants.
• XML -- JSF sera probablement le premier endroit où vous utiliserez les espaces de noms à ce degré.
• Spécification des servlets. Tôt ou tard, vous serez amené à appeler des méthodes de ce paquetage. En plus de cela, vous devez savoir comment vos Facelets sont transformés en XHTML ou autre.
• JSP (surtout pour que vous sachiez pourquoi vous n'en avez pas besoin dans JSF)
• JSTL (encore une fois, principalement pour faire face au cadre hérité)
• Le langage d'expression (LE) sous ses différentes formes.
• ECMAScript, JavaScript, ou tout autre nom que vous voulez lui donner.
• JSON - vous devriez le savoir même si vous ne l'utilisez pas.
• AJAX. Je dirais que JSF 2.0 fait un travail décent pour vous cacher cela, mais vous devez quand même savoir ce qui se passe.
• Le DOM. Et comment un navigateur l'utilise. Voir ECMAScript.
• Les événements DOM - un sujet à part entière.
• Java Persistence Architecture (JPA), c'est-à-dire si vous souhaitez que votre application dispose d'une base de données dorsale.
• Java lui-même.
• JSEE pendant que vous y êtes.
• La spécification relative à l'injection de dépendances dans le contexte (CDI) et la manière dont elle s'oppose à JSF 2.0 et est utilisée avec celui-ci.
• JQuery - J'aimerais vous voir vous en passer.

Une fois que vous avez terminé, vous pouvez passer aux spécifications propriétaires, à savoir les bibliothèques de composants et de fournisseurs que vous trouverez en cours de route :

• PrimeFaces (ma bibliothèque de composants de prédilection)
• RichFaces
• MesFaces
• ICEFaces
• EclipseLink (mon fournisseur JPA)
• Hibernate
• Soudure

Et n'oubliez pas le contenant ! Et tous ces fichiers de configuration :

• GlassFish (2, 3, etc)
• JBoss
• Tomcat

Donc -- C'EST FACILE ? Bien sûr, JSF 2.0 est "facile" tant que tout ce que vous voulez faire, ce sont les pages web les plus basiques avec les interactions les plus simples.

Pour dire les choses simplement, JSF 2.0 est le méli-mélo de technologies collées les unes aux autres le plus compliqué et le plus encombrant qui existe aujourd'hui dans l'univers des logiciels. Et je ne peux pas penser à quelque chose que je préférerais utiliser.

Answer 5

"JSF produira du HTML et du JavaScript de la couche de visualisation que vous ne pouvez pas contrôler ou modifier sans entrer dans le code du contrôleur."

En fait, JSF vous donne la flexibilité nécessaire, vous pouvez soit utiliser des composants standard/tiers, soit créer les vôtres, avec un contrôle total sur le rendu. C'est juste un xhtml dont vous avez besoin pour créer vos composants personnalisés avec JSF 2.0.