Je suis tombé il y’a quelques jours sur un article via DZone intitulé The top 8 reasons I don’t use Wicket.
Évidemment, avec un titre comme ça, il fallait que j’aille voir.
Cette personne (Dan, ou tieTYT dans les commentaires) énonce donc les raisons pour lesquelles elle n’aime pas Wicket. (J’aimerai dire que je pense n’avoir jamais vu autant de mauvaise foi chez quelqu’un (oui Greg, plus que moi encore))
Dans un premier temps, et c’est un peu choquant, il commence par parler de PHP. Il ne fait pas explicitement de comparaison entre Wicket et PHP, mais avouez que c’est bizarre de montrer comment on fait en PHP, puis ensuite en Wicket…
Certes, passons aux 8 points.
1. Documentation, documentation… documentation?
Cette personne se plaint du manque de documentation. Plus loin dans les commentaires, il cite par exemple le manque d’un quickstart a suivre bêtement quand on commence.
Certes la documentation n’est pas “parfaite”, cependant :
- un site
- un Wiki
- un Mailing List (ultra active), qui plus est, référencée via nabble, marmail et même google
- 3 Livres (Pro Wicket, Enjoying Web Development with Wicket et Wicket in Action (plus un en japonais il me semble mais bon…))
- le site wicketstuff.org avec notamment un ensemble d’exemple très complet
- la javadoc disponible en local via Maven (quand on se donne la peine de la récupérer), disponible de ce fait au sein même de notre IDE.
Franchement, il est gonflé le coco!
2. High learning curve
Là, le mec est pas très malin.
Je le cite :
- How do hide a dynamic tag? component.setVisible(false).
- How do I dynamically add a class attribute to the tag? component.add(new SimpleAttributeModifier(“class”, “classValue”));
- How do I dynamically add a CSS file to my template? webpage.add(HeaderContributor.forCss(“/path/to/my.css”);
- Do you see the problem? It’s subtle.
Le problème? Je n’en vois pas! Avec Wicket, tu traduit en java ce que tu dis en français (enfin presque).
Dans un sens, j’ai presque des doutes sur sa capacité à développer “Object Oriented”…
3. Different… not better, but different
Bon ben il préfère chercher une erreur pendant des heures dans un fichier html que trouver l’erreur que le compilateur java lui montre, c’est son choix…
Perso, je préfère cette façon de faire.
4. Lacking 3rd party library support
Là, je suis pas d’accord avec lui. wicketstuff.org regorge de projet tiers. Et qui sont, en général des composants réutilisables, facilement intégrables avec votre application.
5. Generate HTML or generate pain
Je crois que 5 mois ne lui ont pas suffit pour comprendre les concepts de Wicket…
Avec Wicket, tu limite volontairement le code généré en bistoufly, par contre tu peux quand même faire des choses sympa avec les notions comme “DynamicResource”.
6. Easier to maintain?
Là encore, c’est juste que si tu a été suffisamment malin pour bien codé “Object Oriented”, tu as toutes les cartes en main pour une maintenance aisée…
7. The “Great for web designers” myth
Sur ce point, je suis quasiment d’accord avec lui. Effectivement les “wicket:id” ca roule, un web designer peut comprendre. Cependant, les <wicket:panel>, <wicket:child> et autre <wicket:extend> risque de poser problème.
Il faudrait réussir à trouver un concept pour palier à ces limitations…
8. Search Engine De-optimization
Rha la la, le SEO (Search Engine Optimization). Mon point de vue sur la question : Si tu fais une application type Intranet ou “privée”, aucun besoin de s’en soucier. Si effectivement tu fais un application web “publique”, Wicket te propose des mécanismes de “Mounting” d’URL très performant qui son très bien compris par les google et consors. C’est juste qu’il faut effectivement bosser un peu… mais bon tu le fais une fois, après tu réutilise…
Conclusion
Si vous êtes arrivé jusqu’ici, vous aurez surement noter comme moi aussi je sais mettre de la mauvaise foi dans mes articles.
Au regard des commentaires de l’article, il apparait qu’il est assez difficile de faire parler ensemble des “pro” et des “anti”.
Le garçon n’aime pas Wicket, bon ben quoi dire de plus.
Je pense que chaque Framework Web touche un certain public de développeurs. Chacun est plus ou moins réceptif à telle ou telle “fonctionnalité” qu’apporte un Framework.
Là il s’avère que le garçon n’a pas compris le sens de certaines “fonctionnalités” de Wicket. Il préfère ce qu’apporte Stripes. C’est son choix.
Et dans un sens, c’est le premier post que je vois qui est contre Wicket. C’est donc que de plus en plus de monde s’y intéresse. Certes, il y aura des sceptiques, mais il en faut.
Moi je vais continuer à faire du Wicket, et à le promouvoir autour de moi, car c’est le seul framework actuellement (avec ASP.NET MVC mais chut c’est du .Net) qui me donne envie de bosser dessus.
Lancer un vieux troll pour faire parler de son site et générer du trafic est une technique rôdée et bien connue. Pour la peine je cliquerai même pas jusqu’à son site.
Tu pourras donner une définition pour “bistoufly”?
Ouai c’est pour ca que j’ai mis le lien DZone et pas le lien direct. Pour faire acte de protestation contre le troll!
L’utilisation du mot “bistoufly” ici est utilisé pour dire ne pas générer du code dans le html/css/javascript à la volée comme on le faisait dans Struts ou JSF (pas dans php car c’est pas la même chose, c’est un langage de script).
genre dans une JSP :
< % if (user == admin)
out.println("<h1>Bienvenue Admin</h1>");
%>
Ca c’est pas du tout dans la logique de Wicket. Il faut faire un composant qui le gère.
Et lui pour son cas, il voudrai dynamiquement écrire qqchose dans le css. Ce que tu peux faire mais avec une DynamicResource.
(je sais pas si j’ai été clair :p)
Et puis bon à quelques rares exceptions près, si on a besoin d’écrire dynamiquement dans la feuille de style c’est qu’il y a un problème de conception quelque part.
J’ai lu son article, j’ai aussi lu les commentaires associés. Le bonhomme se braque pas mal ce qui, de mon point de vue, le décrédibilise un peu.
Ouai, tout à fait d’accord, même si à certains moments, Igor et Mateï parfois sont un peu agressifs…
Il devait chercher le buzz, Igor l’a bien aidé :p
Moi qui ne connait pas grand chose dans la “programmation client léger” (pour être générique), je pense que Wicket est trés accessible. Bon, mais j’ai aussi (je crois) de bonnes connaissances en POO et je crois que sans ça, ça serait loin d’être évident.
En même temps, ce serait aussi stupide que de connaître unique que le C et de se lancer dans un gros projet en C++… :sauteunravin:
Bonjour,
Je commence immédiatement par préciser que je rédige ce commentaire avec très présent à l’esprit que je ne suis qu’un très récent développeur objet : j’ai commencé sur un projet Java utilisant Wicket il y a moins de 1 an ! Mais par contre, au cours de 12 années d’expérience de développement d’applications Web, j’ai pu utiliser de nombreuses technologies et produits (cgi, asp, php, smarty, adaptations de cms et produits de ecommerce).
A lire l’article dont il est question ici, j’ai regretté qu’il manque de fond et surtout il aurait sans doute nécessité une réflexion un peu plus poussée. Je n’aurai cependant pas la prétention d’apporter tous les compléments ici, mais quelques points m’ont interpelés et je souhaitais en faire part dans la discussion.
- Documentation : il me parait tout à fait indéniable que Wicket a de très lourds manques de ce côté là ! Même si en effet il existe des choses, il faut souvent aller beaucoup fouiller pour des choses simples ! Et on tombe bien souvent sur de la documentation rédigée par un utilisateur, pas complète et obsolète… et ce sur le wiki officiel même ! Au final les sources principales d’information sont le source même et la mailing list.
Le framework avance vite et les ressources sont sans doute limitées, on peut le comprendre. Mais le manque de documentation officielle et structurée est criant, c’est absolument indéniable.
- Je suis assez mal à l’aise avec le sentiment que j’ai eu de prime abord et dont je n’arrive pas à me détacher : en utilisant Wicket on a l’impression que le dev Java fait tout, en oubliant complètement les intégrateurs HTML, dev front-end, admin, etc.
L’argument “Wicket probably decreased my template code by 4x but increased my Java code by 4x” me parait vraiment un point important. J’ai l’impression tenace que l’on arrive à tout faire en Java, et ce n’est vraiment pas bon pour la vie de l’application : chacun a son rôle et son domaine d’intervention, et le développeur Java ne devrait pas avoir à se préoccuper de CSS, cache, …
Maintenant que ça soit de la faute des développeurs utilisant Wicket ou que ça soit le framework qui y pousse, c’est à voir…
- Facile de mettre de l’Ajax de partout… Et de produire un site inutilisable ! “Don’t break the web”…
- Coder les traitements sur onSubmit et les actions Ajax directement en Java est très agréable ! Mais ça induit un peu de lourdeur pour l’intégration de choses front end que le développeur Java doit conserver des maquettes statiques… (cas récent : ajouter une lightbox d’attente après change d’une DtopDdownChoices)
- On a le moyen d’intégrer des datepicker directement pas exemple, et on lit très clairement sur la mailing list que les dev ne veulent pas que Wicket devienne une biblioth_que de widgets… La position là-dessus est à mon sens assez bancale.
Aussi, au jour le jour, le sentiment que Wicket est jeune :
- la gestion des url… l’argument revient et revient…
- surcharge des css : pas toujours évident
- quelque chose qui m’a scié : pour gérer convenablement des menus de navigation en ul/li il faut bricoler à la main !!!!
- génération de JS dynamique : côté bricolo encore
- séparation du code Java, des fichiers markup et des ressources : mériterait plus de flexibilité
Bref, pour l’instant (et je répète que j’ai bien conscience que mon expérience Java comme Wicket nécessite plus de temps pour être très pertinente) je trouve Wicket difficile et long à apprendre, souvent lourd pour du “quotidien”.
Si je compare avec des solutions de séparation templates / code que j’ai pu expérimenter il y a quelques années, Wicket me parait bien trop lourd et pas assez clair dans les séparations.
Je me souviens il y a quelques années où Tapestry avait le vent dans les voiles et Wicket n’était encore qu’un petit joueur en montée.
Tous ceux qui avaient quelque chose de négatif à dire à propos de Tapestry étaient immédiatement virés de bord avec des “il n’a rien compris” ou alors “pourquoi diable voudrait-on faire ça?”
Je me souviens aussi d’un post de HLS (l’auteur de Tapestry) qui critiquait très aggressivement Wicket, en disant avec arrogance que Wicket n’en était rendu qu’à ce qu’était Tapestry 0.0.1.
Maintenant que Wicket a gagné beaucoup de terrain, voilà que ce sont tous les Wicket fanboys qui virent toute critique avec des “il n’a rien compris” et “personne n’a besoin de faire tel feature.”
Je trouve que Dan a tenté de son mieux de faire valoir ses points, avec des explications détaillées et précises. Au lieu de l’écouter et tenter de l’aider, des gens aggressifs comme Igor lancent des “you clearly do not understand OO.”
Stripes gagne beaucoup de terrain ces jours-ci et la communauté est très accueillante et prète à aider les nouveaux. Je ne peux qu’espérer quece virage vers l’arrogance sera évité.
J’ai remarqué que Eelco s’est beaucoup calmé en termes d’aggressivité et d’attaques personnelles gratuites. Il répond plutôt avec diplomatie et tact, ce qui engendre des discussions techniques beaucoup plus intéressantes, au lieu de flames wars de geeks qui veulent montrer que la leur est plus grosse que la tienne.
Il n’est pas trop tard. Wicket est certainement un excellent framework. Il a ses forces et ses faiblesses. Rendez-vous compte que ce n’est pas un marteau en or dans un monde remplis de clous. Gardez l’esprit ouvert, l’image de votre communauté est tout aussi importante que les avantages techniques de votre framework.
Cheers,
Freddy
Pour ma part, si je pouvais reprocher une chose à wicket, c’est son évolution trop rapide. Je suis de nombreuses fois tombé sur des exemples qui correspondaient parfaitement à mon besoin, mais qui suite à une nouvelle version de wicket étaient devenus complètement différents au point de vue implémentation.
Mais un manque de doc? Non! Ma principale source était markmail! Et puis c’est ça qu’est fun, on ne peut pas être parmi les “précurseurs” (si j’ose dire, des milliers d’autres sont passés là avant, je sais), et profiter de la documentation abondante d’une techno éprouvée et adoptée par la majorité.
Bastoune46> Mais un manque de doc? Non! Ma principale source était markmail!
Oui, la liste de diffusion est active, mais nous parlions de documentation ! Regardez par exemple chez Yahoo pour la YUI : vous avez de la documentation à foison ET à jour, ET une communauté très active fédérée via un blog et un groupe Yahoo officiels.
D’ailleurs, tout a fait d’accord avec Frédéric Daoud sur l’importance qu’a la communauté et le rôle que l’équipe de développement doit jouer…
@ Grego :
> Lancer un vieux troll pour faire parler de son site et générer
> du trafic est une technique rôdée et bien connue.
Tu parlais de Nico ? ^^
Enfin j’avoue je répond a ce qui est dit ici sans avoir eu le courage ou la curiosité d’aller lire l’article original, honte a moi.
@Bastoune
+1 sur le coup de la doc dépassée … maintenant je ne trouve pas cela génant si l’on comprend ce que l’on fait et si l’on est pas feignant on s’en sort
Et puis une Quickstart il en existe un super : noocodecommit :p
@Nico
“bistoufly” c’est le code spaghetti c’est ca ? … c’est pas justement le genre de trucs qu’on cherche a banir dans toutes les archis web par le principe MVC notamment ? megaLol … Wicket complique la production de code de m&#@e
bein pour le coup, Pierre et Frédéric donnent des arguments bien mieux construit que ce fameux Dan. Mais je suis p-e de mauvaise fois :p
Exemple appliqué vécu hier, assez criant sur la documentation pas à la hauteur du framework.
Je cherchais comment personnaliser les messages de validation. Par exemple remplacer :
“le champ ‘dob’ est obligatoire”
Par :
“Veuillez saisir la date de naissance !”
C’était en effet bien tout prévu dans le framework, et de manière plutôt élégante et flexible.
Mais : mis 2h à trouver ce qu’il était possible de faire grace à la lecture du source, déduction de javadoc mal formulé, et des extraits de documents publiés par des utilisateurs sur leurs blogs.
Voilà qui fait râler…
bonjour,
Je développe sur la plateforme J2EE depuis 2002 et j’ai manipulé de près ou de lien tout ce qui existe en terme de framework web.
Personnellement, je trouve que wicket comme stripes sont ce qui se fait de mieux dans ce domaine, wicket est plus complet que stripes mais ces deux framework sont vraiment proche dans l’esprit
Je suis d’accord avec Kokoni, Pierre et Frédéric, vos commentaires sont plus constructifs que ceux de Dan. J’ai eu l’occasion de présenter/former 3 personnes récemment, et effectivement, ils ont eu des soucis pour trouver de la doc.
Elle est présente, mais surement trop fouillis. Par contre, prenant l’exemple de jQuery, qui est très complète, certains contributeurs sont presque à plein temps sur l’écriture de cette doc.
On le voit aussi sur nos projets, la doc c’est un sujet sensible (car nécessaire) mais chronophage (donc souvent sous-estimé)
Ensuite, concernant l’arrogance des leads developers (et peut être moi aussi parfois), c’est souvent des problèmes de communications. Le fait de s’approprier quelque chose, nous atteins directement quand quelqu’un le critique.
Je n’ai jamais essayé Stripes (d’ailleurs faut que je trouve le temps de regarder ça prochainement), mais je trouvé en Wicket, le Framework Web Java qui me permet de développer rapidement, simplement et de façon élégante des applications évoluées tout en prenant du plaisir à le faire. Ce que je n’avais pas ressenti depuis fort longtemps (la faute à Struts et à JSF).
Un framework trouvera son public naturellement. Il ne pourra pas fédérer tout le monde. Ceux dont la déception sera trop grande aura vite fait de le critiquer, cependant il n’en reste pas moins un très bon framework, qui si il s’améliore sur ses points faibles, risque bien de devenir un grand framework.