Nous utilisons en ce moment Grails.
Ce que je peux dire, c'est que, comparé à RoR, je le trouve moins bien avancé/pensé. Exemple de la convention de mapping entre base de données et classes du domaine : dans RoR, un many-to-many à représenter par une table de jointure peut-être défini en tant que migration dans db/ ; donc pas de pollution du domaine... Dans Grails la jointure doit être représentée par une classe du domaine (ou alors faut se palucher les .hbm d'hibernate, donc on perd de l'intérêt de grails). Ceci n'est qu'un petit exemple parmi tant d'autre.
De plus, je confirme nettement rvalyi sur la lourdeur de groovy et sur les perfs de JRuby (pour l'avoir aussi utilisé) comparé à groovy. J'ai bien peur que la montée en charge d'une application Grails soit pour l'instant bien en deçà d'une application RoR et donc d'une application Web Java (JEE / spring).
Je voudrais aussi écrire que Grails, comme RoR, se positionne sur un marché différent des applications serveurs/web java "classiques" (JEE / spring). Ces derniers se positionnent sur la mise en oeuvre d'applications serveurs de classe entreprise (les grosses appli en résumé). Grails et RoR se positionnent plus sur le marché des petites et moyennes applications web ; ils sont, je pense, idéal pour concevoir une appli web perso (en lieu et place de PHP) qui prend pas la tête et qui soit facile à faire évoluer. Aujourd'hui, si je devais choisir entre RoR et Grails, je choisirais RoR (je trouve, pour les avoir utilisé tous les deux, que le langage Ruby est bien supérieur à Groovy, et de même le framework RoR vis à vis de Grails).
Maintenant, pour ceux qui recherchent un langage de script pour la JVM et que ne veulent pas utiliser Ruby (JRuby), je conseillerai de regarder plus du côté de Scala que de Groovy.
# Grails ... bof
Posté par Miguel Moquillon (site web personnel) . En réponse à la dépêche Sortie de Grails 1.0. Évalué à 3.
Ce que je peux dire, c'est que, comparé à RoR, je le trouve moins bien avancé/pensé. Exemple de la convention de mapping entre base de données et classes du domaine : dans RoR, un many-to-many à représenter par une table de jointure peut-être défini en tant que migration dans db/ ; donc pas de pollution du domaine... Dans Grails la jointure doit être représentée par une classe du domaine (ou alors faut se palucher les .hbm d'hibernate, donc on perd de l'intérêt de grails). Ceci n'est qu'un petit exemple parmi tant d'autre.
De plus, je confirme nettement rvalyi sur la lourdeur de groovy et sur les perfs de JRuby (pour l'avoir aussi utilisé) comparé à groovy. J'ai bien peur que la montée en charge d'une application Grails soit pour l'instant bien en deçà d'une application RoR et donc d'une application Web Java (JEE / spring).
Je voudrais aussi écrire que Grails, comme RoR, se positionne sur un marché différent des applications serveurs/web java "classiques" (JEE / spring). Ces derniers se positionnent sur la mise en oeuvre d'applications serveurs de classe entreprise (les grosses appli en résumé). Grails et RoR se positionnent plus sur le marché des petites et moyennes applications web ; ils sont, je pense, idéal pour concevoir une appli web perso (en lieu et place de PHP) qui prend pas la tête et qui soit facile à faire évoluer. Aujourd'hui, si je devais choisir entre RoR et Grails, je choisirais RoR (je trouve, pour les avoir utilisé tous les deux, que le langage Ruby est bien supérieur à Groovy, et de même le framework RoR vis à vis de Grails).
Maintenant, pour ceux qui recherchent un langage de script pour la JVM et que ne veulent pas utiliser Ruby (JRuby), je conseillerai de regarder plus du côté de Scala que de Groovy.