Raisons de ne pas utiliser JSF [fermé]

Je suis nouveau sur StackExchange, mais j’ai pensé que vous seriez capable de m'aider.

Nous créons une nouvelle application Java Enterprise, remplaçant une solution JSP héritée. En raison de nombreux changements, l'interface utilisateur et certaines parties de la logique métier seront complètement repensées et réimplémentées.

Notre première pensée a été JSF, car il s’agit du standard de Java EE. Au début, j'ai eu une bonne impression. Mais maintenant, j'essaie de mettre en place un prototype fonctionnel et je suis vraiment préoccupé par son utilisation.

Tout d’abord, il crée le pire mélange pseudo-HTML / CSS / JS invalide et encombré que j’ai jamais vu. Cela viole chacune des règles que j'ai apprises en développement Web. De plus, cela combine ce qui ne devrait jamais être aussi étroitement lié: la mise en page, la conception, la logique et la communication avec le serveur. Je ne vois pas comment je pourrais étendre confortablement cette sortie, qu'il s'agisse d'un style avec CSS, de l'ajout de bonbons d'interface utilisateur (comme des raccourcis clavier configurables, des widgets glisser-déposer) ou autre chose.

Deuxièmement, c'est beaucoup trop compliqué. Sa complexité est exceptionnelle. Si vous me le demandez, c'est une piètre abstraction des technologies Web de base, paralysées et inutiles à la fin. Quels sont mes avantages? Aucun, si vous y réfléchissez. Des centaines de composants? Je vois en plus des milliers d'extraits de code HTML / CSS, des milliers d'extraits de code JavaScript et des milliers de plug-ins jQuery. Cela résout vraiment beaucoup de problèmes - nous ne l'aurions pas si nous n'utilisions pas JSF. Ou le modèle de contrôleur avant du tout.

Enfin, je pense que nous devrons recommencer dans deux ans, par exemple. Je ne vois pas comment mettre en œuvre notre première maquette d'interface graphique (en outre, nous n'avons pas d'expert JSF dans notre équipe). Peut-être que nous pourrions le pirater d'une manière ou d'une autre Et puis il y aura plus. Je suis sûr que nous pourrions pirater notre hack. Mais à un moment donné, nous serons bloqués. En raison de tout ce qui précède, le niveau de service contrôle JSF. Et nous devrons recommencer.

Ma suggestion serait de mettre en place une API REST en utilisant JAX-RS. Créez ensuite un client HTML5 / Javascript avec MVC côté client. (ou un peu de MVC ..) Au fait; De toute façon, nous aurons besoin de l’API REST, car nous développons également une interface partielle sous Android.

Je doute que JSF soit la meilleure solution de nos jours. Alors qu'Internet évolue, je ne vois vraiment pas pourquoi nous devrions utiliser ce «rake».

Maintenant, quels sont les avantages / inconvénients? Comment puis-je souligner mon point de ne pas utiliser JSF? Quels sont les points forts à utiliser JSF par rapport à ma suggestion?

Il y a au moins une très bonne raison de considérer JSF.

C'est une partie standard de la pile Java EE et sera donc disponible - et fonctionnera - dans TOUS les conteneurs Java EE pendant une très, très longue période. Et maintenu aussi, sans que vous ayez à le faire si vous avez adhéré strictement à la spécification Java EE.

Si cela vous préoccupe, vous devriez en tenir compte. La plupart des logiciels vivent plus longtemps que ne le pensent leurs concepteurs, surtout s'ils sont pris en compte lors de l'écriture.

Maintenant, quels sont les avantages / inconvénients? Comment puis-je souligner mon point de ne pas utiliser JSF? Quels sont les points forts à utiliser JSF par rapport à ma suggestion?

Vous semblez déjà avoir bien compris les inconvénients, et j’en ai quelques-uns à me dire (cela ne sépare pas suffisamment la mise en page et la logique, et le code HTML résultant est souvent atroce), mais pas d’accord sur d’autres (si vous utilisez Facelets, que je recommanderais vivement, le résultat devrait être valable).

Alors voici quelques avantages:

• Certaines bibliothèques de composants très puissantes, telles que PrimceFaces ou RichFaces, offrent de nombreuses fonctionnalités prêtes à l'emploi. Celles-ci peuvent vous faire économiser beaucoup de travail si elles couvrent vos besoins (pas tant que vous avez des besoins non négociables non couverts par eux).
• Composite Composites offre un moyen très propre de modulariser vos pages
• JSF s'intègre très bien avec le reste de Java EE
• AJAX via le re-rendu des composants est vraiment facile et pratique

Mais certainement aucun de ces avantages n’est si important que vous devriez utiliser JSF par rapport à un autre framework que votre équipe a déjà expérimenté.

JSF est un framework Web adéquat pour Java. Il s’agit d’un standard, ce qui signifie qu’il est pris en charge immédiatement par de nombreux grands fournisseurs (y compris ceux de FOSS). Il prend en charge les bibliothèques tierces (PrimeFaces, IceFaces, etc.). Cependant, il "bloque fondamentalement le Web" en raison de son caractère dynamique (et de beaucoup d'autres choses). Voir la comparaison faite par Matt Raible des infrastructures Web basées sur la machine virtuelle Java . JSF est généralement proche de la fin.

Éditer - avec JSF 2.2 - vous pouvez commencer à dire que cela ne casse pas le Web autant qu’il l’a fait. En fait, l'intégration HTML5 n'est pas si terrible :-).

Nous avions une ancienne application JSP / Struts 1.0. Nous avons ignoré Struts 2, JSF et tout ce qui s'est passé depuis Struts 1 et sommes passés à Spring 3.0. Il a le soutien (et une communauté active) de notre liste de souhaits - Eclipse IDE, MVC et REST. De plus, nous avons abandonné notre code Javascript cru / ajax pour jquery.

YMMV mais Spring a été une migration en douceur pour nous.