La quête du Graal avec un cure-dent

Grails fait partie des framework haute productivité à la mode ces dernières années. J’étais plutôt motivé pour le tester histoire de sortir un peu de Play Framework pour lequel j’avoue avoir quelques craintes sur son futur (je détaillerais dans un futur billet). Du coup je me suis motivé pour l’utiliser au sein de Lateral-Thoughts sur une appli interne. Et pour être honnête, j’ai été plutôt déçu.

Avant d’aller plus loin je vais mettre les petites astériques habituelles histoire de m’éviter des insultes en pagailles dans les commentaires.

(*) Le reste de ce billet n’engage que moi, il fait suite à 2 semaines d’expérimentation sur le framework et peut très bien s’expliquer par un manque de connaissance sur Grails.

Je ne connaissais pas non plus Groovy, a part le peu que j’en utilise sur les templates Play Framework et dans le même temps je me suis aussi mis sur IntelliJ.

Changer d’IDE, changer de framework web, apprendre Groovy, ok c’est vrai que je mettais pas toutes les chances de mon côté.

En même temps il n’y a pas non plus des miliers de lecteurs ici pour craindre des représailles ^^

Maintenant que j’ai mis les gants, je vais ressortir les griffes.
Grails, framework haute productivité, j’y crois pas un instant. La caractéristique même d’un framework haute productivité devant être la rapidité de développement.

C’est vrai qu’on peut mettre ma difficulté à entrer dedans sur le dos de la nouveauté. En même temps j’ai déjà suffisamment fait de langages et de frameworks différents pour penser que 2 semaines ça aurait du être largement suffisant vu ce qu’il y avait à faire.

Voici une petite liste des gros points noirs que j’ai rencontrés :

  • le débuggage :

Juste l’enfer, en fait pendant un certain temps j’ai cru que la seule trace d’erreur que pouvait écrire Grails c’était : NumberFormatException For input string: « 1B »
Les messages d’erreurs sont imbitables la majorité du temps et les stack traces inutilisables. Être un langage dynamique n’excuse rien, PHP est capable de donner l’erreur et la ligne exacte depuis ces toutes premières versions…

  • Lenteur des tests unitaires

Rien que sur ce seul point j’ai détesté coder avec Grails. Je n’ai peut être pas trouvé la bonne de façon de faire mais j’ai tenté l’utilisation d’IntelliJ pour lancer les tests. Dans ce cas il se pose deux choix : le lanceur Grails ou le lanceur Junit.
Utiliser le lanceur Grails implique de passer 10 secondes pour un test. Impensable d’écrire des tests régulièrement et de devoir attendre 10 secondes à chaque fois. Quand au lanceur Junit, il met un peu moins de temps (3 sec quand même) mais ne permet pas de jouer tout les tests, notamment pas ceux portant sur le modèle. C’est un énorme STOP pour moi.

  • lenteur des templates

En DEV la compilation des JSP Grails est relativement lente. C’est même assez paradoxal de remarquer que les templates Groovy de Play sont plus rapide à s’afficher que les pages GSP de Grails. Ca ne reste que du ressenti mais la sensation de lenteur est très pénible. Enfin au moins les GSP supportent les modifs à chaud, contrairement au reste (Cf point suivant).

  • Les modifications à chaud

Depuis que je connais Play, les modifications à chaud font partie des critères obligatoires pour que je puisse qualifier un framework de “haute productivité”. Dans mon cas les modifications à chaud ont marché une fois sur 10. Les modifs dans les contrôleurs par exemple nécessitent presque à chaque fois un redémarrage.
Effectivement ça marche mieux avec les GSP mais bon, c’est aussi le cas des JSP depuis des années. En fait Grails a été moins efficace qu’un Spring MVC avec Tomcat et Jrebel.

Bon mais il y quand même des points un peu moins noirs:

Les GSP sont plus riches que les templates Play en terme de fonctionnalités et le fait d’être une surcouche sur des JSP permet d’utiliser toutes les taglibs classiques. Je reste un peu dépaysé avec mais je pense que je finirais par les apprécier.

GORM est plus expressif que JPA. Une fois pris en main la définition des objets du modèle est assez simple.
Cependant j’ai rencontré pas mal de soucis. Par exemple qu’il fallait utiliser save(failOnError : true) pour connaitre les erreurs au moment de sauver une entité. Pas très “straightforward” pour un débutant. Bon après ca reste du hibernate en dessous, forcément si on aime pas la magie, fallait pas 😉

Les plugins Grails sont assez nombreux et ont l’avantage d’être présent sur des repository qui ne dépendent pas de l’éditeur (en comparaison avec ceux de Play par exemple). En deux semaines je n’ai cependant pas eu l’occasion d’en utiliser donc je ne m’aventurerais pas trop sur le sujet.

La documentation est assez riche, c’est quand même Spring derrière. Par contre elle a un gros défaut, il lui manque un côté didactique pour qu’un débutant démarre un projet rapidement dessus. Le quick start est un peu trop léger, quand à la partie Tutorials elle ne comporte que des liens vers des blogs pas toujours mis à jour. Dommage, sur ce point le tutorial Yabe de la doc Play est un bel exemple de documentation didactique.

Juste avant de conclure j’ai envie de répondre a un troll que j’ai vu passer sur Twitter :

Euh, ouais, enfin l’adoption mainstream en entreprise je rigole doucement :

Et pour répondre au troll par un troll si les gars qui font du grails ne bloggent pas c’est surtout qu’ils passent leur temps a relancer leur serveur a chaque modif ou a lancer leurs tests unitaires qui prennent une minute 😉

Bon enfin tout n’est pas si horrible, il y a des bons points mais pas suffisamment à mon goût et surtout des points noirs rédhibitoires. Je ne doute pas qu’il soit possible de faire des choses puissantes ave mais mon besoin était simple et je n’ai pas eu la productivité escompté.

En fin de compte je le comparerais plutôt à un Spring MVC (utilisé en sous main). Et quitte à le comparer je préfère justement un Spring MVC bien configuré pour aller plus vite.

12 réflexions sur “La quête du Graal avec un cure-dent

  1. Le gros point fort de Grails à mon avis, c’est GORM. Et là, je pense qu’aucuns frameworks (play inclus) n’arrive à faire ce que propose GORM. Les Finders dynamiques, l’expressivité, et le code concis, c’est vraiment un point fort de Grails. Du côté des modules, tu as un ecosystème assez important, avec beaucoup de possibilités.

    Je recommande à chacun de tester. Il est très adapté sur des projets rapides, son scaffolding ou la partie CRUD est la plus puissante, bien plus puissante que ce que Play! fait. Ensuite, il a en effet d’autres inconvénients.

    Je défends un peu Grails, je comprends aussi ton ressenti.
    A chacun de se faire son opinion.

    Bon j’attends de voir les autres commentaires.

  2. Quelle version de Grails tu utilises ? On dirait que c’est la 1.0.4 à vue d’oeil, parce que dans Grails 2 t’as meme droit de modifier ton modèle métier a chaud hein, le temps de rechargement varie de 3 a 6s max car il s’agit d’un polling disque et non d’un écouteur natif (un plugin devrait y remédier).

    A propos des Tests unitaires, Grails 2 et les mixins permettent de vraiment aller vite et mock des trucs rarement supportés par d’autres frameworks java : taglibs, templates gsp, url mapping, controllers, criteria builders… Tu peux les lancer depuis intelliJ ce qui te prends environ 1 seconde a moins d’avoir un ide tournant sur Nokia 3310.

    Questions perfs, le dernier comparatif que j’ai fait en mode NIO et sans hibernate/sitemesh pour etre features 1-1 donnait un avantage de 10000req/s vs 11000 pour play 2 sur un microbench, le rapport était inversé dans une soumission de formulaire. Tu crois vraiment que VMware supporterait un framework sous performant ? Ca fait parti de leur stratégie le temps de réponse, tout leur stack, le cloud, tout converge pour ça, pourquoi ? Parce qu’un mec qui attend l’arrivée d’une page une seconde de trop va bouger de site, et ça les clients n’aiment pas 🙂

    Sinon pour mon tweet en anglais, t’as cité en réponse 3 sites francofrançais, exactement le pays où l’évangélisation est à la ramasse sévère. Je rappelle également que Play est français pour comparaison et cocorico, c’est un excellent framework qui mérite pas mal de ses louanges, normal qu’il rayonne plus. Et encore, que ce soit Grails ou Play, on est vraiment des petits joueurs comparés aux mastodontes en la matières, notamment RoR….

    Des clients j’en connais quelques uns : Grails est utilisé chez LinkedIn (je le mets en premier parce que c’est la mode), Sky, ministère de l’éduc, défense, santé, La poste, Areva, le CERN, HSBC, vodaphone, EMC, backend de lotterie en ligne, des startups aussi, Secret Escape, Kagilum etc. Je viens même de voir un lien sur l’utilisation Cloudbees http://blog.cloudbees.com/2012/03/cloudbees-platform-best-performers.html qui montre que quelques projets sont bien utilisés en Groovy/Grails finalement.

    Le framework a 7 ans, et la version 2 quelques mois. C’est un petit framework mainstream, car comme pour play et tous les autres webframeworks java, l’adoption ne sera jamais un standard de facto et ce quelles que soit les bonnes idées que nous proposons tous. De fait son audience cible les entreprises : packaging, api, frameworks sous-jacents, je ne crois pas que les entreprises soient prêtes à toutes jeter leur conteneur de servlet notamment ou à se sortir de leurs archis Spring. Il est certain que ça viendra cela-dit, c’est un cycle perpétuel.

    Et puis sa prise en compte dans les IDE date de 3 ans ou plus si on compte Netbeans, j’ai rarement eu des soucis avec le debugger -_-. Les stacktraces sont filtrées dans Grails 2 donc je vois pas comment elles peuvent être horribles (max 7 lignes). Sauf si tu changes les params par défaut ce dont je doute quand on commence avec le framework.
    La console intéractive (quand tu lances grails sans arguments) est ultra rapide, la encore tu peux lancer tes tests unitaires sans problemes. Je suis sûr que tu as utilisé Grails 1.0….

    Bref, un FUD moyen moyen, car il y a bien d’autres sujet ou Grails a des difficultés, mais la c’est vraiment useless.

  3. Le gros point fort de Grails à mon avis, c’est GORM. Et là, je pense qu’aucuns frameworks (play inclus) n’arrive à faire ce que propose GORM. Les Finders dynamiques, l’expressivité, et le code concis, c’est vraiment un point fort de Grails. Du côté des modules, tu as un ecosystème assez important, avec beaucoup de possibilités.

    Je recommande à chacun de tester. Il est très adapté sur des projets rapides, son scaffolding ou la partie CRUD est la plus puissante, bien plus puissante que ce que Play! fait. Ensuite, il a en effet d’autres inconvénients.

    Je défends un peu Grails, je comprends aussi ton ressenti.
    A chacun de se faire son opinion.

    Bon j’attends de voir les autres commentaires.

  4. Quelle version de Grails tu utilises ? On dirait que c’est la 1.0.4 à vue d’oeil, parce que dans Grails 2 t’as meme droit de modifier ton modèle métier a chaud hein, le temps de rechargement varie de 3 a 6s max car il s’agit d’un polling disque et non d’un écouteur natif (un plugin devrait y remédier).

    A propos des Tests unitaires, Grails 2 et les mixins permettent de vraiment aller vite et mock des trucs rarement supportés par d’autres frameworks java : taglibs, templates gsp, url mapping, controllers, criteria builders… Tu peux les lancer depuis intelliJ ce qui te prends environ 1 seconde a moins d’avoir un ide tournant sur Nokia 3310.

    Questions perfs, le dernier comparatif que j’ai fait en mode NIO et sans hibernate/sitemesh pour etre features 1-1 donnait un avantage de 10000req/s vs 11000 pour play 2 sur un microbench, le rapport était inversé dans une soumission de formulaire. Tu crois vraiment que VMware supporterait un framework sous performant ? Ca fait parti de leur stratégie le temps de réponse, tout leur stack, le cloud, tout converge pour ça, pourquoi ? Parce qu’un mec qui attend l’arrivée d’une page une seconde de trop va bouger de site, et ça les clients n’aiment pas 🙂

    Sinon pour mon tweet en anglais, t’as cité en réponse 3 sites francofrançais, exactement le pays où l’évangélisation est à la ramasse sévère. Je rappelle également que Play est français pour comparaison et cocorico, c’est un excellent framework qui mérite pas mal de ses louanges, normal qu’il rayonne plus. Et encore, que ce soit Grails ou Play, on est vraiment des petits joueurs comparés aux mastodontes en la matières, notamment RoR….

    Des clients j’en connais quelques uns : Grails est utilisé chez LinkedIn (je le mets en premier parce que c’est la mode), Sky, ministère de l’éduc, défense, santé, La poste, Areva, le CERN, HSBC, vodaphone, EMC, backend de lotterie en ligne, des startups aussi, Secret Escape, Kagilum etc. Je viens même de voir un lien sur l’utilisation Cloudbees http://blog.cloudbees.com/2012/03/cloudbees-platform-best-performers.html qui montre que quelques projets sont bien utilisés en Groovy/Grails finalement.

    Le framework a 7 ans, et la version 2 quelques mois. C’est un petit framework mainstream, car comme pour play et tous les autres webframeworks java, l’adoption ne sera jamais un standard de facto et ce quelles que soit les bonnes idées que nous proposons tous. De fait son audience cible les entreprises : packaging, api, frameworks sous-jacents, je ne crois pas que les entreprises soient prêtes à toutes jeter leur conteneur de servlet notamment ou à se sortir de leurs archis Spring. Il est certain que ça viendra cela-dit, c’est un cycle perpétuel.

    Et puis sa prise en compte dans les IDE date de 3 ans ou plus si on compte Netbeans, j’ai rarement eu des soucis avec le debugger -_-. Les stacktraces sont filtrées dans Grails 2 donc je vois pas comment elles peuvent être horribles (max 7 lignes). Sauf si tu changes les params par défaut ce dont je doute quand on commence avec le framework.
    La console intéractive (quand tu lances grails sans arguments) est ultra rapide, la encore tu peux lancer tes tests unitaires sans problemes. Je suis sûr que tu as utilisé Grails 1.0….

    Bref, un FUD moyen moyen, car il y a bien d’autres sujet ou Grails a des difficultés, mais la c’est vraiment useless.

  5. @Nicolas :
    Pour GORM, j’adhère sur l’expressivité, rien à dire. Par contre tu listes les finders dynamiques, la par contre je ne suis pas d’accord.
    C’est vraiment une question de goût que de dire que :

    Truc.findByAuthor();
    est plus pratique que
    Truc.find(« byAuthor »);

    En dehors de ca, oui pour dire que belongsTo se comprend bien que les affreuses annotations mappedBy de JPA et que addTo est plus simple que la gymnastique nécessaire en JPA.
    Bref, GORM +1

    Le scaffolding, idem, la partie CRUD de Grails m’a généré un code très propre et utilisable.

    @Stephane :
    c’était bien la version 2.0. Ca aurait été dommage de démarrer un nouveau projet sur une 1.x quand même ^^

    Pour le reste, sur les lenteurs attention, je parlais de lenteur en mode DEV pas en PROD. Je ne doute pas qu’une fois compilé ce soit effectivement plus efficace.
    Après je ne sais pas quoi dire, je constate ces lenteurs, elles sont réelles sur mon poste et j’ai pourtant une bonne machine. La on aura du mal à se démontrer le contraire via des commentaires sur wordpress ^^

    Quand aux tests, il me semble qu’on en revient a un problème important : la doc.
    Malgré toute la bonne volonté du monde je ne parviens pas à les faire jouer dans des temps honorables (j’ai un intel i7 et 8 gigas de ram pour la petite histoire). Donc il est possible qu’il y ait un truc magique que j’ai loupé mais pour le coup, la doc ne m’a pas aidé à mettre la main dessus.

    Et c’est peut être là le plus gros souci. J’ai décidé de moi-même de me lancer dans du Grails, pour cela j’ai été influencé par une présentation de Matt Raibles qui place Grails parmi les meilleurs frameworks. Je pars donc avec de bons a priori et je me permets de penser que je ne suis pas une trop grosse buse vu que j’ai déjà dompté d’autres frameworks en moins de 2 semaines. Et pourtant, je galère. Tu me parles de Mixins pour les tests mais le quick start ne m’a pas aiguillé dessus et aucune doc n’explique clairement comment mettre en place son environnement de dev de facon super optimisé.
    Pas méga cool pour un framework haute productivité, non ?

    Pour info, je suis pas tout seul a m’être posé certaines questions, par exemple sur la lenteur des tests : http://blog.marktye.com/2009/03/running-grails-unit-tests-in-intellij.html

    En tout cas merci pour les liens, ca me donnera peut être plus de tips pour m’améliorer.

    And last but not least, sur le tweet, faut pas le prendre mal, il m’avait amusé quand je l’ai vu passer et c’était plus dans l’esprit de chambrer un peu. Le côté mainstream je trouve ca un peu exagéré quand même mais je sais bien que Grails est populaire, c’est même pour ca que j’ai choisi de m’y mettre.

    Ce que je trouve dommage c’est que tu considères qu’il n’y a pas la un véritable problème. Pour un framework la prise en main par des geeks du dimanche c’est fondamental avant d’arriver en entreprise. De mon côté je n’ai pas été convaincu alors que je partais dans un super bon état d’esprit. Faut-il que ce framework ne puisse être compris qu’après avoir vu un de ces gourous coder dessus ?

  6. @Nicolas :
    Pour GORM, j’adhère sur l’expressivité, rien à dire. Par contre tu listes les finders dynamiques, la par contre je ne suis pas d’accord.
    C’est vraiment une question de goût que de dire que :

    Truc.findByAuthor();
    est plus pratique que
    Truc.find(« byAuthor »);

    En dehors de ca, oui pour dire que belongsTo se comprend bien que les affreuses annotations mappedBy de JPA et que addTo est plus simple que la gymnastique nécessaire en JPA.
    Bref, GORM +1

    Le scaffolding, idem, la partie CRUD de Grails m’a généré un code très propre et utilisable.

    @Stephane :
    c’était bien la version 2.0. Ca aurait été dommage de démarrer un nouveau projet sur une 1.x quand même ^^

    Pour le reste, sur les lenteurs attention, je parlais de lenteur en mode DEV pas en PROD. Je ne doute pas qu’une fois compilé ce soit effectivement plus efficace.
    Après je ne sais pas quoi dire, je constate ces lenteurs, elles sont réelles sur mon poste et j’ai pourtant une bonne machine. La on aura du mal à se démontrer le contraire via des commentaires sur wordpress ^^

    Quand aux tests, il me semble qu’on en revient a un problème important : la doc.
    Malgré toute la bonne volonté du monde je ne parviens pas à les faire jouer dans des temps honorables (j’ai un intel i7 et 8 gigas de ram pour la petite histoire). Donc il est possible qu’il y ait un truc magique que j’ai loupé mais pour le coup, la doc ne m’a pas aidé à mettre la main dessus.

    Et c’est peut être là le plus gros souci. J’ai décidé de moi-même de me lancer dans du Grails, pour cela j’ai été influencé par une présentation de Matt Raibles qui place Grails parmi les meilleurs frameworks. Je pars donc avec de bons a priori et je me permets de penser que je ne suis pas une trop grosse buse vu que j’ai déjà dompté d’autres frameworks en moins de 2 semaines. Et pourtant, je galère. Tu me parles de Mixins pour les tests mais le quick start ne m’a pas aiguillé dessus et aucune doc n’explique clairement comment mettre en place son environnement de dev de facon super optimisé.
    Pas méga cool pour un framework haute productivité, non ?

    Pour info, je suis pas tout seul a m’être posé certaines questions, par exemple sur la lenteur des tests : http://blog.marktye.com/2009/03/running-grails-unit-tests-in-intellij.html

    En tout cas merci pour les liens, ca me donnera peut être plus de tips pour m’améliorer.

    And last but not least, sur le tweet, faut pas le prendre mal, il m’avait amusé quand je l’ai vu passer et c’était plus dans l’esprit de chambrer un peu. Le côté mainstream je trouve ca un peu exagéré quand même mais je sais bien que Grails est populaire, c’est même pour ca que j’ai choisi de m’y mettre.

    Ce que je trouve dommage c’est que tu considères qu’il n’y a pas la un véritable problème. Pour un framework la prise en main par des geeks du dimanche c’est fondamental avant d’arriver en entreprise. De mon côté je n’ai pas été convaincu alors que je partais dans un super bon état d’esprit. Faut-il que ce framework ne puisse être compris qu’après avoir vu un de ces gourous coder dessus ?

  7. Je finis de faire mon blog sous Grails et je répond à cet article 🙂
    Je pensais être tombé sur un post de 2008 par là :o)
    Au fait, on peut utiliser l’extension de spring source toolsuite avec greclipse sous une distrib Indigo, pas besoin de payer une license IntelliJ.
    Mon fork d’archetype https://github.com/Igosuki/grails-maven-archetype permet de créer des plugins et des web apps (du détail en fait).
    Depuis la version 2 les plugins peuvent être packagés en Jar et sont donc compatibles avec Jdepot (pour les stacks anciennes comme celles des banques).
    Non décidément je sens une injustice !
    Pour les tests unitaires il y a une pléthore de plugins, et je dois avouer que Spock en groovy c’est vraiment du bonheur.

    Quand à Play, ils n’avaient qu’à pas faire croire que la version 1.0 était autre chose que du Alpha et ils auraient encore une User Base 🙂

  8. Je finis de faire mon blog sous Grails et je répond à cet article 🙂
    Je pensais être tombé sur un post de 2008 par là :o)
    Au fait, on peut utiliser l’extension de spring source toolsuite avec greclipse sous une distrib Indigo, pas besoin de payer une license IntelliJ.
    Mon fork d’archetype https://github.com/Igosuki/grails-maven-archetype permet de créer des plugins et des web apps (du détail en fait).
    Depuis la version 2 les plugins peuvent être packagés en Jar et sont donc compatibles avec Jdepot (pour les stacks anciennes comme celles des banques).
    Non décidément je sens une injustice !
    Pour les tests unitaires il y a une pléthore de plugins, et je dois avouer que Spock en groovy c’est vraiment du bonheur.

    Quand à Play, ils n’avaient qu’à pas faire croire que la version 1.0 était autre chose que du Alpha et ils auraient encore une User Base 🙂

  9. Concernant IntelliJ je voulais le tester de toute façon. Et puis j’avais entendu dire qu’il était le meilleur IDE pour Grails. Mais je tenterais STS pour comparer.

    Sur l’utilisation de Maven je suis un peu sceptique en fait. Autant je suis un pro maven quand il s’agit de l’utiliser sur de gros projets d’entreprise ou le besoin de standardisation est vraiment nécessaire, autant sur le projet que j’ai démarré j’ai l’impression que ce serait un peu overkill pour un apport minimal. Grails en ligne de commande m’a plu, je ne vois pas ce que Maven m’apporterait s’il sert juste à wrapper les commandes Grails.

    Et quand à Play tu es un peu injuste ^^ Non la version 1.x n’est pas une version alpha, pas plus que Grails 1.x par rapport à la 2.x. Ils ont pris le parti de changer beaucoup de chose et ne donne pas de piste pour la migration et c’est vrai que c’est un problème majeur.
    Mais c’est loin d’être la première fois que ca arrive pour des frameworks : maven 1 vers maven 2, tapestry sur chaque version majeure, struts 1 vers struts 2.
    Et on ne peut pas dire que maven 1, struts1 ou tapestry 4 aient été des versions alpha.

  10. Concernant IntelliJ je voulais le tester de toute façon. Et puis j’avais entendu dire qu’il était le meilleur IDE pour Grails. Mais je tenterais STS pour comparer.

    Sur l’utilisation de Maven je suis un peu sceptique en fait. Autant je suis un pro maven quand il s’agit de l’utiliser sur de gros projets d’entreprise ou le besoin de standardisation est vraiment nécessaire, autant sur le projet que j’ai démarré j’ai l’impression que ce serait un peu overkill pour un apport minimal. Grails en ligne de commande m’a plu, je ne vois pas ce que Maven m’apporterait s’il sert juste à wrapper les commandes Grails.

    Et quand à Play tu es un peu injuste ^^ Non la version 1.x n’est pas une version alpha, pas plus que Grails 1.x par rapport à la 2.x. Ils ont pris le parti de changer beaucoup de chose et ne donne pas de piste pour la migration et c’est vrai que c’est un problème majeur.
    Mais c’est loin d’être la première fois que ca arrive pour des frameworks : maven 1 vers maven 2, tapestry sur chaque version majeure, struts 1 vers struts 2.
    Et on ne peut pas dire que maven 1, struts1 ou tapestry 4 aient été des versions alpha.

Laisser un commentaire