En 2009, le choix de JSF pour développer une nouvelle application RIA Java EE s’impose. Plus besoin de perdre son temps avec du Struts, struts-layout, struts-menu et du JavaScript. Pas question de perdre son temps à apprendre la nouvelle version de Struts, la 2.0 qui ne cherche qu’à mimer du JSF.
La version JSF 1.2 est mature et les composants conformes à la version 2.0 sont en route (prévue avant la fin de la l’année).
Reste la question cruciale du choix de jeux de composants JSF.
Les principaux prétendants au trône sont : IceFces et Richfaces ?
Le choix reste difficile, même en déroulant la liste classique de critères:
· conformité aux standards JSF
· open source,
· nombre de composants offerts
· support d’AJAX
· richesse fonctionnelle
· intégration avec Facelets
· pérennité : taille de l’entreprise qui le supporte
· maturité
· nombre de téléchargement annoncé
· taille de communauté
· nombre d’entrée dans le forum de discussion
· activité Jira
· fréquence des versions
· documentation
· outillage
· …
Dans la majorité des projets, que j’ai observés, le choix entre ces deux implémentations n’a finalement pas été fondé sur un écart visible dans la réponse à cette liste de critères. Le coté subjectif ou la constatation d’une difficulté avec l’un entraine le choix de l’autre.
C’est là où la présentation des résultats « Performance Report of Server Side RIA Frameworks » devient intéressante.
L’étude, réalisée par un membre de l’équipe ZK, et avait pour objectif, montre la supériorité de ZK par rapport aux autres framework RIA. L’étude a développé trois applications web avec 3 technologies différentes ZK, IceFces et Richfaces. Et a réalisé des mesures de monté en charge.
Ce qui est intéressant, du point de vue JSF, c’est que cette étude pointe du doigt les grandes lacunes de IceFaces : la performance et l’empreinte mémoire sur le serveur.
Icefaces est 2 fois plus lent que RichFaces (dans le tratiement des grilles par exemple)
IceFaces présente un défaillance importante de point de vue empreinte mémoire sur le serveur : il consomme trop de mémoire.
Consommation mémoire (coté serveur)
Et
Vue ces résultats, en restant dans un choix JSF, IceFaces perd de sa crédibilité
Bien sûre, JSF aussi prend « un coup sur la tête » faces à d’autres alternatifs (ZK, ou GWT), mais ceci est un autre sujet
Articles
6 commentaires :
Bonjour,
L'article est complètement biaisé du fait qu'il ait été publié par un membre de l'équipe ZK...
Sans vouloir prendre parti mais simplement pour contre balancer un peu les choses il faut savoir qu'Icefaces (avec très peu de configuration) offre des performances très honorables avec gros volumes de données et un nombre d'utilisateurs simultanés conséquent (>1000). Evidemment les paramètres utilisés pour le test doivent refléter la réalité (serveur d'application weblogic ? données encapsulés en session scope ou reuqest scope, etc...).
Bref, Icefaces n'est absolument pas à écarter dans les choix possibles, bien au contraire.
Bien à vous,
Sébastien
tout à fait,
la même remarque reste valable pour RichFaces
Khaled
Apres avoir travaille pendant 6mois sur Icefaces je me rends compte que le framework a vraiment beaucoup de lacunes en terme de performance. D'ailleurs je songe actuellement a migrer vers autre chose...
ça sera super, si vous pourriez en dire un peu plus, sur le sujet en guise de partage de "problèmes", des fois c'est plus utile que le partage de solutions toutes faites ...
peut être aussi que si on change l'application on aura d'autres résultats, les lacunes en termes de performance peuvent êtres causés par des choses qu'on sous estime et qui sous une grande chargent font la différence
Akram
Les deux solutions sont comparables.
Pourquoi autant d'NRJ pour copier la facette innovatrice de .NET. Innovatrice pourtant lourde et limitée.
Sur les demos on peut remarquer, qu'une fonction qui prend <100ms a exécuter sur une framework de base JS prend > 2-3 sec sur ICE ou RICH. C'est 30 ou 40 fois plus lent.
Une architecture qui a pour but d'améliorer l'interface client ne devrait jamais poller le serveur pour savoir quoi faire. C'est une perte de ressource infinie.
La décision est claire. Faites apprendre une vrai JS Framework a vos developeurs et augmenter votre R&D, pour donner les gains aux utilisateurs.
Enregistrer un commentaire