Le constat est clair : fàce aux alternatives "modernes", Struts fait office de mammouth, au sens "pachiderme" du terme. Top de configuration et de classes à développer, même pour un simple hello world, alors pour coder une transaction de prise de commande étalée sur 5 écrans...Problème, la relève s'avère un peu trop prolifique. Faut-il suivre Struts², Spring MVC - selon une approche assez classique - faire le pari des "Ruby-on-Rails-like" (Grails, Sails, Trails et j'en passe) ou encore passer à tout autre chose (Wicket ?). Sans évoquer l'option JSF, avec ou sans jboss Seam, ou Google Web Toolkit. Et pourquoi pas du pur HTML + JavaScript + services REST ?
Alors ? J'ai du mal a me faire une opinion tranchée, surtout que je n'ai mis en oeuvre aucun de ses frameworks à une échelle significative.
Un constat cependant : en tant que prestataire de service, je dois convaincre mon client du bien fondé d'un choix. Sails (au hasard) est peut être très bien, mais quel dirigeant en a entendu parler ?
Deuxième aspect, la taille de la communauté et/ou la documentation disponible. De ce point de vue, Struts2 et Spring MVC sont les plus vendeurs, avec Seam et GWT.
Troisième point, la capacité d'adaptation des développeurs. Exemple de Grails : même si Groovy n'est pas bien compliqué, ça fait un langage de plus à connaître, et de nombreux mécanismes "auto-magiques" à apprendre. De ce point de vue le duck-typing est sans doute super pour les cracks, mais surtout source de bugs et de difficultés pour les autres, qui préfèrent le bon vieux "ctrl+Expace" pour obtenir la liste des méthodes disponibles.
Enfin, les possiblités de sortie. Si le framework ne suffit pas, comment faire ?
De cette réflexion, de mon point de vue Struts2 sort grand vainqueur :
Un constat cependant : en tant que prestataire de service, je dois convaincre mon client du bien fondé d'un choix. Sails (au hasard) est peut être très bien, mais quel dirigeant en a entendu parler ?
Deuxième aspect, la taille de la communauté et/ou la documentation disponible. De ce point de vue, Struts2 et Spring MVC sont les plus vendeurs, avec Seam et GWT.
Troisième point, la capacité d'adaptation des développeurs. Exemple de Grails : même si Groovy n'est pas bien compliqué, ça fait un langage de plus à connaître, et de nombreux mécanismes "auto-magiques" à apprendre. De ce point de vue le duck-typing est sans doute super pour les cracks, mais surtout source de bugs et de difficultés pour les autres, qui préfèrent le bon vieux "ctrl+Expace" pour obtenir la liste des méthodes disponibles.
Enfin, les possiblités de sortie. Si le framework ne suffit pas, comment faire ?
De cette réflexion, de mon point de vue Struts2 sort grand vainqueur :
- le simple nom "struts" est définitivement vendeur. Peut importe que le code n'ait rien à voir avec Struts 1, je sais que je n'aurais pas à batailler pour le vendre, ni à mon chef, no à mon client. Deux de mes plus gros soucis en moins ;-p
- la communauté webwork était assez limitée, celle de Struts est énorme, même si une grande partie reste utilisatrice de la première mouture. La doc et les bouquins sur le sujet commence à s'étoffer, et devrait atteindre le seuil critique.
- pour le développeurs lambda, passer à Struts2 va nécessiter de "désapprendre" Struts 1, mais comme struts 1 était trop souvent mal employé, ça ne sera pas si difficile ;-p. Le principe de base reste de type MVC, donc le fossé à franchir est raisonnable. Grails, JSF ou GWT nécessitent de revoir complètement les notions sur l'architecture d'une application web.
- quand à dépasser les limites de Struts2, le nombre impressionnant de "plugins" qui viennent le compléter parle de lui-même. Déjà, smartURL (futur codebehind) nous promet de réduire au strict minimum la conf nécessaire. Scope nous apporte du Seam-like, avec le support des conversations et la "bijection" des données manipulés. REST permet de coder facilement des service web léger (je n'ai rien vu pour SOAP), GWT permet de s'intégrer avec une IHM GWT, etc.
L'avenir me donnera peut-être tort (je viendrais alors éditer cet article pour effacer toute preuve), mais parier sur Struts2 n'est probablement pas le pire des choix, même si ce n'est pas non plus le plus courageux.Et JSF ? Un standard, ça devrait rassurer ! D'une part j'ai du mal à rentrer dans la logique de JSF (un peu compliqué tout ça), d'autre part je n'aime pas du tout les JSP "à la JSF", totalement illisibles à mon gout. Et avec Facelets ? Pour être honête, Facelets + Seam serait mon second choix, disons plus "engagé" que le très sage "passons de Struts 1 à Struts 2".
Pas simple tout ça ... d'un autre côté, on ne pourra pas se plaindre d'être forcé à utiliser une solution, comme c'était le cas avec ces magnifiques EJBs 1.x qui m'ont tant fait râler.
1 commentaires:
La réponse est là : http://archetypejs.org !
Pour moi la réponse ne se trouve pas dans des framework front côté server (vive ROME et DWR pour s'en passer), sacahant qu'on rajuote pleins de trucs côté client. Le mieu est donc d'apporter sur le client se qu'on cotoie côté serveur :)
Enregistrer un commentaire