Il y a 8 années -

Temps de lecture 5 minutes

Devoxx – Comparaison des Frameworks Web sur JVM


Nouvelle journée de Devoxx et cela commence plutôt bien avec une comparaison des Frameworks Web sur JVM par Matt Raible. Avec un accent Américain trés prononcé, et aprés une présentation « lessig style » trés appréciée, il présente le programme de la session : les candidats, les points de comparaison, la matrice et quelques graphiques.

Comment choisir ces fameux Frameworks Web qui sont, et c’est le moins que l’on puisse dire, assez nombreux. Et bien tout d’abord, il va falloir restreindre cette liste à quelques Frameworks et, pour chacun d’entre eux, prototyper une application. A partir de ces prototypes, il sera alors possible de créer une matrice comprenant différents critères qui seront notés pour chaque Frameworks. De là, on pourra faire ressortir les meilleurs prétendants, un petit document et faire nos recommandations. C’est ce qu’a fait Matt Raible durant cette présentation et voici ses résultats !

 
 

Matt fait un petit rappel sur les facteurs clés qui nous permettaient de choisir un Framework Web en 2007 (de son expérience) :

  • composant, requête ou RIA,
  • facilité de développement,
  • communauté autour du Framework,
  • roadmap et futur du Framework,
  • maintenance,
  • fonctionnalités.

Aujourd’hui, nous en demandons beaucoup plus à nos Frameworks Web et, pour Matt, nous passons de 6 à 20 ! Avec un peu d’exagération sur cette fulgurante croissance car certains points faisaient déjà parti de nos préoccupations en 2007 ; de là à dire que ce sont de nouveaux points… En tout cas, les voici au complet :

  • productivité du développeur,
  • perception du développeur,
  • courbe d’apprentissage,
  • santé du Framework,
  • disponibilité des développeurs (sur le marché),
  • offres d’emploi,
  • templating,
  • composants,
  • ajax,
  • plugins ou add-ons,
  • scalabilité,
  • support pour les tests,
  • i18n et l10n,
  • validation,
  • support du multi-langage (groovy, scala…),
  • qualité de la documentation / tutoriaux,
  • publications,
  • support de REST,
  • support mobile,
  • et degré de risque.

Bien sûr, nous pouvons remettre en cause certains points de cette liste et passer plusieurs journées à en débattre mais le débat n’est pas là. Matt assume que les choix qui sont fait sont les siens et il nous invite à participer pour ajouter des éléments à la liste ou lui indiquer pourquoi il se trompe sur telle ou telle appréciation. L’idée est ici de donner une base solide afin de pouvoir comparer sur plusieurs points importants de nos projets d’entreprise ces fameux innombrables Frameworks Web.

Roulement de tambour… voici la matrice ! (google spreadsheet)

Les gagnants de ce « concours » sont :

  • Spring MVC,
  • GWT,
  • Ruby on Rails (non JVM mais non exclu car très présent sur le marché),
  • Grails,
  • Wicket.

Vient ensuite une partie avantages / inconvénients pour chacun d’eux. Cette partie est à prendre avec des pincettes car les inconvénients relevés sont souvent surmontables (certains sont même juste des comportements par défaut modifiable par configuration !) mais encore une fois cela donne un overview de ce que font ou ne font pas ces Frameworks :

  • Spring MVC : configuration simple par conventions et annotations, intégration de plusieurs formats d’affichage (JSP, JSTL, FreeMarker, JSON, PDF…) et excellent support de REST mais pas de rechargement à chaud par défaut (toutefois possible avec JRebel ou Spring Roo), projet non ouvert à la communauté pour contribution (SpringSource mandatory) et pas de librairie ajax en bundle (ce qui peut aussi être vu comme un point positif car mise à jour des librairies Javascript non bloquée par le Framework) ;
  • GWT : code Java traduit en un Javascript extrêmement optimisé, apprentissage facile et rapide (petit bémol car sur ce point les développeurs Web n’ont pas forcément cette compétence du code Swing-like) et une communauté vibrante mais il faut connaître Java (alors que l’on produit du Javascript), compilation très lente et code difficile à tester ;
  • Ruby on Rails : apprentissage rapide pour tout développeur Web, documentation abondante et communauté de passionnés mais moins performant que les autres langages, langage dynamique = plus de tests pour éviter les cast exceptions au runtime et un manque d’outils de développement et de débugger comme dans le monde Java ;
  • Grails : transition facile depuis le monde Java, utlise Groovy et nombreux plugins mais Groovy vise directement les développeurs Java (ce qui peut bloquer d’autres développeurs), stack traces affreuses (dans le slide :-) ) et connaissances des sous-modules non nécessaires mais peut aider ;
  • Wicket : parfait pour les développeurs Java, binding des pages et des vues et communauté active mais pas ou peu d’offres d’emploi, stateful par défaut et templates HTML juste à côté des classes Java (ce qui ne va pas aider le graphiste).

Pour finir, nous avons droit à quelques jolis graphiques qui nous montre à quelle point Ruby On Rails est très présent au niveau de la communauté mais ainsi en terme d’offres d’emploi.

devoxx_stack_overflow
devoxx_charts

Matt a insisté sur deux points importants tout d’abord sur le fait que ce sont les développeurs qui devraient choisir leur framework web, plus les développeurs sont heureux, plus ils seront productifs. D’autre part, javascript n’est pas si difficile comme on l’entend souvent de la part des développeurs java, plus on le pratique, plus on l’apprécie, et c’est vital si l’on veut être sérieux pour le développement d’application web.

Cette méthode peut être appliqué dans votre entreprise pour choisir votre framework web :

  1. priorisez les fonctionnalités importantes de votre application
  2. sélectionnez ensuite 3 ou 4 Frameworks pour prototyper une application (1 semaine chacun), documentez
  3. calculez votre matrice et choisissez !

Publié par Romain Maton

Après trois années passées chez Improve Technologies, Romain est aujourd'hui consultant Java/JEE chez Xebia. Mission après mission, il s’est forgé une solide expérience en développement Web et logiciel. Il dispose ainsi d'une très large compétence sur l'emsemble de l'ecosystème JEE, que ce soit sur les bonnes pratiques d'architecture, sur les frameworks de développement ou sur les interfaces client riches. Inconditionnel du pair programming, certifié Scrum Master, c'est un fervent disciple des méthodes Agiles. Romain est aussi un contributeur actif de la revue de presse Xebia. Il traite de nombreux sujets tels que RIA, API Java, frameworks ou bien encore Scala.

Publié par Jean-Laurent de Morlhon

CTO @ Xebia France. Sur twitter avec @morlhon

Commentaire

7 réponses pour " Devoxx – Comparaison des Frameworks Web sur JVM "

  1. Publié par , Il y a 8 années

    Struts2 est aussi un gagnant dans cette matrice il me semble, mais il n’apparait pas dans le post.

    C’est dommage que tous les sujets de cette matrice soit pondérés de la même façon. Des points comme la facilité de test (pour le TDD), la productivité et la scalabilité me semblent plus importants que les jobs trends.

  2. Publié par , Il y a 8 années

    some numbers (at least about things i know) are simply wrong. take this (if at all) with a huge grain of salt.

  3. Publié par , Il y a 8 années

    I share your ‘astonishment’ Werner :-)

    Giving the same productivity to Spring MVC, Struts 2 and JSF (*). I have used them three and my productivity feeling was :

    Developer productivity : Spring MVC >> Struts 2 >>>> JSF 1

    … with the special disclaimer for JSF that investing a lot of energy for a high level framework on-top of JSF has an important cost in development, training and maintenance and thus lowers the productivity :-)

    Cyrille (Xebia)

    (*) I guess JSF implies JSF 1, otherwise, the version number would have been quoted.

  4. Publié par , Il y a 8 années

    @Nicolas : Effectivement Struts2 arrive a égalité avec Wicket, Matt étant trés actif sur le projet Struts2, il a sportivement laissé la place à Wicket.

    @Werner : This is Matt point of view, not some kind of absolute truth. You can cast you vote in this online form to weight your thought : http://bit.ly/webmatrixsurvey

    @Cyrille : I’m pretty sure lots of people would disagree with your ranking, although I personally agree with you.

  5. Publié par , Il y a 8 années

    Je ne suis pas fan du tout des comparatifs de Matt Raible en général.
    Que Vaadin ait une plus mauvaise note globale que Gwt est quand même assez absurde…

  6. Publié par , Il y a 8 années

    Quand je vois le classement de Lift en dernière position j’en conclus que l’auteur:
    – a tout simplement malencontreusement inversé les résultats.
    – ou bien n’a jamais utilisé Lift en dehors d’un helloworld.
    De plus, donner des points à certains frameworks par exemple pour la rubrique « Multi-language support(groovy/scala) » par rapport à ceux qui sont deja ecrits dans ces languages me laisse perplexe quant à la validité de cette matrice…

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Nous recrutons

Être un Xebian, c'est faire partie d'un groupe de passionnés ; C'est l'opportunité de travailler et de partager avec des pairs parmi les plus talentueux.