Grails (maintenant) en vaut-il la peine?
Je sais qu'il s'agit d'un duplicata , cependant, le monde Grails a considérablement évolué depuis que cette question a été posée il y a plus d'un an, de même que le support de IDE dans Eclipse, donc, ne vous contentez pas de l'aveuglette. Ferme le.
Je pensais que la réponse était oui et je me suis lancé dans un nouveau projet avec Grails 1.2.0 et j'ai flirté avec les bits Groovy/Grails de STS Eclipse Integration .
Je pense que la question mérite d'être réexaminée après une année d'évolution du Grails, alors que la réponse était clairement mitigée.
Ainsi, en tant que développeur Web expérimenté en Java, j’ai ces questions et aimerais que mes hypothèses} _ soit contestée:
- Est-ce que Grails en vaut maintenant la peine contre Ruby ou roule le vôtre?
- At-il surmonté son départ en buggy?
- Confère-t-il vraiment des avantages rapides en termes de développement? (J'avoue que j'ai du mal maintenant, j'ai dépassé la configuration de base étendue pour créer mon application personnalisée qui n'est pas orientée liste et page)}
- Fonctionne-t-il pour les applications de production du monde réel? _ {(Il a l'air lourd)} _
- Le plug-in Eclipse est-il meilleur qu’il ne l’était et adapté à ses besoins? _ {(Je ne pense pas encore)} _
Merci
EDIT: J'apprends au fur et à mesure et j'ai quelques problèmes importants à surmonter pour vivre avec le framework - plutôt que les capacités de framework elles-mêmes. Je les ajoute parce que je pense qu’elles devraient faire l’objet de considérations. Elles sont basées sur mon expérience et mon opinion, et peuvent aider une personne qui essaie de décider s’il faut ou non aller au Graal. Je peux aussi montrer mon manque d’expérience avec le framework, donc rien de tout cela n’est censé être une critique absolue. Je suis un développeur expérimenté et voici ce que j'ai trouvé:
Le débogage est vraiment difficile. En fait, c'est presque impossible, surtout en tant que débutant dans la structure, c'est-à-dire lorsque vous avez le plus besoin de votre fidèle ami débogueur. J'ai passé beaucoup plus de temps que je n'aurais dû à rechercher les problèmes d'erreurs syntaxiques dans certaines parties du code relatives aux champs de domaine qui provoquent des défaillances silencieuses quelque part dans la pile.
La journalisation est franchement affreuse. Vous avez deux modes, "rien d’utile" et "une quantité démesurée de choses inutiles". Mon journal de débogage faisait 128 Mo après une seule demande de page et ne contenait aucune information sur mon erreur. Toute la question de l'exploitation forestière doit être réexaminée dans le cadre à mon avis.
Le STS Eclipse IDE a une valeur marginale. Autre que la syntaxe hilighting, il n’est pas très utile. Vous ne pouvez pas déboguer le code, il s'agit donc d'un éditeur glorifié. Les indications de code sont inégales et il n'y a pas de support GSP du tout à ma connaissance. Il s’agit également du plug-in Eclipse le plus lent que j’ai sur mon bureau - il faut environ 2 minutes pour commencer. C'est terriblement lent. Je suis revenu à un éditeur de texte (ce que toutes les vidéos de didacticiels en ligne font de même) et à certaines modifications de syntaxe personnalisées.
Je suis sérieusement préoccupé par les performances. Un peu trop tôt pour le dire, mais je me trouve déjà en train de peaufiner la base de données à cause de l'hibernation. C'est peut-être à prévoir, mais je dois vraiment garder mon modèle de domaine simple pour que les conventions produisent des requêtes performantes.
Et un dernier point, la convention selon laquelle votre modèle de domaine logique et votre modèle de base de données physique doivent être identiques n’est pas un défaut par défaut et il est peu probable que ce soit le cas dans le monde réel. Je sais que vous pouvez séparer les deux, mais cela crée un degré de complexité qui pourrait être évité si les conventions étaient étendues. Il existe une documentation insuffisante sur la composition et ce que vous devez faire pour que cela fonctionne dans la pratique .
J'utilise Grails depuis plus de 4 mois maintenant et je vais essayer de vous donner mon sentiment personnel à propos de Grails et de sa facilité d'utilisation.
Est-ce que Grails vaut maintenant la peine contre Ruby ou un autre rouleau?
Bien sûr, la réponse n’est pas «oui» ou «non» mais cela dépend . Cela dépend de vos exigences (avez-vous besoin d'être dans le monde Java?), De vos préférences également (préférez-vous le développement orienté domaine, préférez-vous Groovy ...)? Cependant, je peux répondre que Grails est une alternative sérieuse à Rails. Je pense que quelle que soit votre application Rails, vous pouvez également le faire avec Grails. Mais selon la nature de votre projet, cela peut prendre plus ou moins de temps. Encore une fois, si vous connaissez Rails mais pas Graals, Rails est l’option la plus sûre.
At-il surmonté son départ en buggy?
Oui . Si vous regardez mes messages initiaux (sur ce site ou sur d’autres), je me plaignais beaucoup des bugs Grails. Mais, vous devez juste vous rappeler que Grails est un peu rude sur le bord (ne pas utiliser trop l'héritage de domaine, par exemple) et une fois que vous êtes familiarisé avec le cadre, vous ne rencontrez pas trop de mauvaises surprises. Je ne dis pas que Grails n'est pas un buggy. C'est certainement plus que Rails. Mais aussi, il est plus utilisable qu'un buggy . Un conseil pour cela: utilisez le moins de plugins possible . Parce que beaucoup d'entre eux sont buggés et que certains ne sont pas compatibles entre eux. Donc, n'incluez pas le plugin grails sauf si vous êtes sûr que le plugin grails est à jour, non intrusif et testé (par vous-même).
Confère-t-il vraiment des avantages rapides en termes de développement?
Oui . Vous n'avez presque pas besoin de vous occuper de la conception de base de données. La configuration est presque terminée pour vous depuis le début grâce à Convention over Configuration. Votre application est facilement maintenable. Le seul inconvénient que je vois est un développement frontal qui n’est pas aussi riche que d’autres technologies (comme Rails ou ASP).
Fonctionne-t-il pour les applications de production du monde réel?
Je ne peux pas dire parce que je ne suis toujours pas allé sur mon site web mais je suis assez confiant, car sky.com utilise Grails et les sites attirent un trafic important - environ. 7 millions de pages vues par jour . Là encore, les performances dépendent beaucoup de l’architecture de votre application et de vos décisions en matière de conception.
Le plug-in Eclipse est-il meilleur qu’il ne l’était et adapté à ses besoins?
Aucune idée. J'utilise IntelliJ mais je suppose que ce n'est pas beaucoup mieux qu'il y a un an, selon les messages de plainte que je vois sur le royaume des Grails.
J'espère que ça aide.
A récemment lancé un projet Rails, il travaillait avec Grails.
Mon principal problème avec Rails, c'est qu'il y a beaucoup de choses complètement opaques pour le dev (que je déteste), et cela tend à augmenter lorsque vous commencez à ajouter plus de plugins/generators/libs/etc, car pour pouvoir les combiner, vous devrez corriger quelque chose. Vous avez l’impression que Rails + plugins ne sont qu’un piratage DSL géant qui commence à casser si vous utilisez une mauvaise combinaison de plugins + versions.
Avec Grails, bien que l'écosystème soit beaucoup plus petit, tout a tendance à être relativement cohérent. L’approche DSL n’est pas très utilisée, et en utilisant la conception conventionnelle mais ennuyeuse (je veux dire en utilisant des classes, des interfaces, etc. au lieu de DSL), il est bien plus facile de comprendre le fonctionnement de la plomberie.
Faites une comparaison un à un, voici comment cela se passe:
- Language Implementation: Je préfère Ruby à Groovy, bien que je ne connaisse pas très bien Ruby. Groovy se présente comme un langage à la bonne intention, à la mauvaise implémentation, où certaines des fonctionnalités sont soudées au-dessus de la syntaxe. Je fais référence à certaines classes spéciales qui ne semblent être là que pour permettre certains bidouillage.
- Fonctionnalités du framework: Rails est très en avance sur celui-ci. Vous pouvez configurer la plupart des aspects de Rails (ex: mises en page, modèles, concepteurs de packages css/js, validation, frameworks de test, etc.) de plusieurs manières. Grails est à la traîne à cet égard, bien que sa souplesse soit suffisante pour la plupart des cas d'utilisation.
- (Plugins): Rails a une tonne de plugins qui peuvent être considérés comme une bénédiction ou un cauchemar. Certains plugins ne sont pas maintenus, d'autres ne fonctionnent pas bien avec certaines fonctionnalités ou plugins et il y a beaucoup de forks. J'apprends à rester avec les plugins de base et les plus utilisés (authlogic, haml, etc.) Grails a d'excellents plugins pour les bases (autorisation/authentification, ORM, etc.) et quelques autres plugins pour des choses plus petites.
- Testing: Rails propose une multitude de tests, mais ce n'est pas forcément bon. Certains frameworks de test ne fonctionnent pas bien avec certains plugins, etc. Grails a moins de plugins de test, mais là encore, ils ont tendance à mieux s'intégrer à certains des plugins principaux (car il n'y a pas beaucoup de plugins à intégrer)
- Base de données: Grails gagne de loin.
- Je préfère modéliser mes classes de domaine au lieu de pirater ma base de données.
- Hibernate (qui est utilisé sous le capot) est à des années de son homologue Rails. Bien qu'il existe un datamapper for Rails (qui ressemble plus à Hibernate qu'à ActiveRecord), j'estime que ce n'est pas assez mature. Les Grails ont également migré via un plugin.
- Vous avez d'excellents implants de cache pour Hibernate (cache JBoss, EhCache, etc.) qui peuvent améliorer vos performances à travers le toit.
- Bibliothèques: Je pense que Ruby a beaucoup de bibliothèques pour des nouveautés telles que NoSQL ou les services Cloud, alors que Java en a une collection de librairies pour des applications plus anciennes comme le traitement Excel. N'oubliez pas que les bibliothèques Java sont généralement beaucoup plus rapides que Ruby
- Cutting Edge: Rails est plus un battage publicitaire, ce qui se traduit par plus de ressources derrière. Cela signifie que si vous essayez d'intégrer MongoDB ou Riak à Rails, il y a un bon changement que quelqu'un a déjà apporté. Grails est à la traîne, principalement parce qu'il n'est pas si populaire et que la communauté a tendance à se concentrer sur la résolution des problèmes quotidiens au lieu d'utiliser tout ce qui se passe à Edge, comme NoSQL, etc.
Voici un exemple:
- La plupart des plugins grails génèrent du code sous forme de modèles et/ou de services. Le reste est généralement géré par une bibliothèque. Vous pouvez inspecter le code de modèle/service, voir ce qu’il fait et le changer.
- La plupart des plugins Rails sont généralement connectés à l'API Rails, ce qui signifie que vous appelez une fonction ou un module, puis utilisez le DSL du plugin. Cela fonctionne très bien quand ça marche, mais quand ça casse, c'est horrible et vous finissez par avoir à patcher des trucs, ou à installer un plugin ou une version de plugin différente. Je devine qu'un Rails plus expérimenté est plus à l'aise avec cela, mais je ne le suis pas.
Conclusion:
- Si vous voulez saigner Edge, ne vous occupez pas des correctifs occasionnels, privilégiez une grande communauté et/ou si vous utilisez une base de données de type ActiveRecord, utilisez Rails. De plus, Ruby en tant que langue est très élégant
- Si vous privilégiez les conceptions à interface de classe plutôt que les DSL, préférez modéliser votre application à l'aide de modèles, n'avez pas besoin de fonctionnalités exquises et connaissez bien l'écosystème Java, utilisez Grails
Ça vaut vraiment le coup!
Nous utilisons Grails dans plusieurs projets, qui ont tous rencontré un grand succès pour les raisons suivantes:
Facile - C'est l'un des frameworks les plus simples que nous ayons jamais utilisé
Réutilisation du code hérité - Tout ce que nous avons à faire est d’obtenir notre code hérité et de le placer dans le dossier lib ou src et le tour est joué. Tout simplement génial pour nous.
Structure de base de données héritée - C'est un outil formidable si vous souhaitez générer des visualisations de données sur des bases de données héritées.
Maintenant, à propos de la viabilité:
Bugs: nous n'avons pas rencontré trop de bugs depuis la version 1.1 (la version 1.0 était trop boguée pour nous)
Outils: Netbeans s’améliore vraiment sur ce front, mais il n’est même pas proche d’autres outils comme Intellij IDEA (excellent support!). La même chose peut être dite à propos d'Eclipse.
Portabilité: nous n'avons jamais rencontré un seul problème dans nos projets.
Nous avons actuellement une demi-douzaine d'applications Grails en production, et bien que Grails soit différent des frameworks Java et demande un peu de temps d'apprentissage, il a porté ses fruits car nous avons utilisé des techniques Agiles. Détails:
- Nous utilisons IntelliJ. Ce n'est pas très cher et a été remboursé en quelques semaines pour nous.
- Les tests automatisés, l'intégration continue et le refactoring sont indispensables, comme pour tout code de langage dynamique. Si vous pratiquez déjà le TDD ou si vous avez au moins une couverture de code de test décente, cela n’ajoute pas de travail supplémentaire.
- Hibernate est fourni par défaut avec Grails, mais vous pouvez utiliser d'autres frameworks de persistance. Il y a 5 plugins de persistance autres disponibles aujourd'hui
- L’exploitation forestière n’était manifestement pas un sujet de préoccupation pour Graeme Rochers, mais elle n’a cessé de s’améliorer. Je n'ai cependant pas rencontré de problème pour lequel une erreur n'a pas été consignée (vous devez vous assurer de détecter correctement les exceptions dans votre code).
- Le débogage n'était clairement pas sur le radar (mais cela ne s'est pas amélioré). Nous ne comptons pas sur le débogage de toute façon.
Cela dit, comme pour toutes les nouvelles technologies, je recommande de réaliser des prototypes, des révisions de code, des programmes en paires et peut-être aussi de consulter.
Cela en vaut vraiment la peine. Je l'utilise depuis plus d'un an maintenant et j'adore ça. J'avais l'habitude d'éviter ces types d'outils rad, mais cela a changé ma façon de travailler. Avec la version 1.2, il s’est encore amélioré avec de meilleures informations de traçage de la pile (en particulier pour les GSP).
Le seul problème que j'ai eu avec la mise à l'échelle a été l'hibernation et son cache, qui n'est vraiment pas un problème de grails. Même ceux que je n'aime pas hiberner en général, la façon dont Grails l'enveloppe avec GORM est pour moi une œuvre d'art. Il est merveilleux de travailler avec l’aspect fermeture des critères.
Je n'ai pas encore trouvé quelqu'un qui soit expert en Grails et Rails et qui préfère Grails.
Si vous connaissez bien les deux, vous préférerez certainement Rails.
Grails fait généralement appel aux développeurs Java qui craignent un changement de plate-forme.
Dans ce cas, je pense que JRuby est probablement un meilleur moyen d’adopter une approche agile sur le legs vieillissant.
Ayant utilisé Grails pour un projet récemment, je souhaite partager nos expériences par rapport au développement d'applications J2EE standard.
Confère-t-il vraiment des avantages rapides en termes de développement?
Certainement, c'est le cas. Même si la voie de l'échafaudage est laissée tôt et que les conventions tiennent compte des besoins propres, la période de démarrage est très courte, car nous n'avons pas à nous soucier de nombreuses technologies différentes. Ce type de légèreté nous permet de travailler non seulement plus rapidement, mais aussi plus précis et plus propre.
Écrire des tags n'a jamais été aussi facile - alors qu'avec JSF, nous examinons d'abord si cela en vaut la peine, avec Grails, nous le faisons tout simplement. Travailler dans le cadre de tests et atteindre un taux de couverture élevé est également très facile, bien que les différents scénarios de tests et stratégies de moquage soient parfois incohérents et complexes.
Passer de Java à Groovy est un grand plaisir. Nous aimions avoir littéralement des listes et des cartes, des fermetures, des constructeurs, pour jeter notre implémentation de la "carte" de la chaudière en Java et pour écrire un code compact, significatif et ciblé.
Ce qui ralentit la vitesse de développement, c’est le support IDE pas si parfait, qui est également valable pour le plugin IntelliJ, que nous utilisons. La mauvaise, souvent vieille et même fausse documentation éparpillée sur différents endroits (contrecarrer la promesse "la recherche est terminée") entrave également le développement rapide. Nous avons donc souvent dû revenir à la lecture de code source, ce qui nous a fait peur par la suite des hiérarchies de classes Spring sous-jacentes.
Le débogage est vraiment difficile. Je n'ai jamais trouvé que c'était un gros problème. Vous pouvez soit attacher un débogueur et parcourir, soit coller une charge de println/logs dans le code pour déterminer ce qui se passe.
La journalisation est franchement affreuse. Je conviens que les traces de la pile fournissent généralement 4 pages d’informations inutiles, avec parfois des lignes informatives. Cependant, c'est un petit prix à payer pour un cadre aussi impressionnant.
Le STS Eclipse IDE a une valeur marginale. Eclipse a un support médiocre pour Grails. Utilisez IntelliJ si possible. Je suis un casse-tête, mais si mon entreprise me le permettait, je paierais volontiers l'argent pour IntelliJ.
Je partagerai mes trois années d'expérience de l'utilisation de Grails dans près de dix applications. Je ne peux pas comparer avec Ruby on Rails, je vais donc répondre à vos autres questions.
At-il surmonté son départ en buggy?
- Oui il a. J'ai rencontré quelques insectes Grails sur Grails 2.0.4/2.2.4.
Confère-t-il vraiment des avantages rapides en termes de développement?
- C'est assez simple à apprendre, facile à développer, je n'ai jamais vu une personne ayant une bonne connaissance du monde Java prendre plus qu'une semaine de travail pour connaître les bases. Aussi facile à entretenir. Et vous n'avez pas à vous soucier de votre base de données, assurez-vous simplement
Le plug-in Eclipse est-il meilleur qu’il ne l’était et adapté à ses besoins?
- Choisissez votre IDE avec beaucoup de soin. Eclipse m'a beaucoup aidé, mais il se bloque et cause plus de problèmes qu'il ne le devrait. J'ai choisi IntelliJ et au cours du mois d’essai, cela semblait être un meilleur choix. Dernièrement, j'utilise Sublime Text, quelques plugins et l'ancienne ligne de commande. Je ne me rends dans un IDE que dans des situations spéciales - pour utiliser son débogueur, par exemple.
Fonctionne-t-il pour les applications de production du monde réel?
- C'est un peu lourd. Faites des recherches sur vos choix de conception AVANT d’écrire vos modèles. Faites beaucoup de recherches sur la bonne conception de Grails. La plupart des choses que j'ai faites il y a deux ans, je peux comprendre comment l'améliorer depuis que j'ai plus d'expérience. Il gère bien les applications de production du monde réel mais, en fonction des erreurs que vous faites, Hibernate peut être un casse-tête.
J'utilise Grails depuis le tout début de la version 1.0-beta et je ne peux que vous recommander de commencer à prendre Groovy/Grails au sérieux si vous venez du magasin Java.
Si vous êtes un magasin Java et envisagez Ruby Rails, arrêtez-vous Grails. Si Grails ne fonctionne pas pour vous, vous pouvez toujours démarrer Rails.
Le plugin Grails Eclipse est de la merde. Il se bloque sans raison et ne supporte pas vraiment la flexibilité de Groovy. NetBeans et IntelliJ seraient bien meilleurs, mais je ne les ai pas encore essayés.
Est-ce que ça marche? Bien sûr que si. Même Ruby on Rails est performant, à condition d’avoir suffisamment de serveurs pour résoudre le problème. Je ne sais pas du tout comment Grails se compare à différents frameworks Java.
Confère-t-il vraiment des avantages rapides en termes de développement? Eh bien, il me manque encore beaucoup de bonnes choses Ruby/Rails. Il ne reconnaît pas automatiquement les paramètres de requête Date et Enum (là encore, Rails a également quelques problèmes avec les dates), TimeCategory devrait faire partie de la configuration standard mais ne le fait pas. Mais il y a aussi beaucoup de choses qui nécessitent remarquablement peu de configuration.
Ce n'est pas tout à fait là où Rails se trouve (j'ai particulièrement hâte de voir Rails 3), mais il est beaucoup plus agréable de travailler avec de nombreux frameworks Java. Malgré tout, la magie sous la surface va bien plus loin que dans Rails. Par exemple, le système de contraintes est vraiment puissant, mais il repose sur une énorme couche de choses impénétrables de Spring, et vraiment inflexible si vous voulez utiliser le même pouvoir de manière légèrement différente. Rails est plus facile à subvertir, IME.
Est-ce que ça vaut le coup? Oui. Est-ce un meilleur choix que quelque chose d'autre? Ça dépend.
Je vous suggère d'essayer vous-même. J'adore la flexibilité de Grails et la vitesse de développement. Cependant, comme vous pouvez voir l'expérience des autres personnes diffère. Je souhaite pouvoir développer des applications rapides pour mes clients à l'aide de la plate-forme Java et j'ai trouvé que Grails fonctionnait très bien pour nous.
J'ai également trouvé l'interface très flexible à développer. Je pense aussi que vous devez faire preuve de bon sens et choisir votre plugin avec soin. Je m'en tiens aux plugins supportés par springsource.
D'après mon expérience, Grails apporte quelques fonctionnalités très attrayantes sur la table qui valent vraiment la peine d'être apprises et utilisées.
- L'agilité - les choses que nous mettions des semaines à mettre en œuvre dans les projets J2EE classiques sont généralement une journée de travail avec le système de plug-in Grails. Des choses comme ajax, jquery ui, acegi, une implémentation reposante, un système de planification et beaucoup d’entre eux
- Les exécutions sur machine virtuelle qui soulagent le besoin d'apprendre un autre système d'exécution et ses particularités
Java comme la syntaxe et le sucre de syntaxe groovy. comme le meilleur des deux mondes. Vous pouvez commencer immédiatement avec Java au lieu d'apprendre la syntaxe d'un nouveau langage comme Ruby, puis lentement vous pouvez passer à une syntaxe groovy qui est robuste, simple et intuitive
Pour les responsables de projet, à moins qu’il n’y ait une raison impérieuse de ne pas utiliser de grail pour une raison quelconque (résistance de haut en bas, d’adopter une nouvelle technologie ou autre), je ne vois aucune raison pour que les grails ne puissent pas être utilisés ou non. moins essayé.
Pour répondre aux préoccupations concernant le débogage, ce n'est pas si difficile. Le débogage est facile si vous utilisez Netbeans IDE. Cela m'amène à un autre point à mentionner. Après quelques expériences avec tous les IDE, nous avons constaté que Netbeans était le plus apte à faire le travail. Il prend mieux en charge l’achèvement du code, la coloration syntaxique, le débogage, etc. À mon avis, STS n’est pas suffisant pour cela.
En ce qui concerne le plug-in Eclipse, continue à arriver, mais vous pouvez utiliser la version Eclipse de Spring Source (SpringSource Tool Suite)
http://www.springsource.com/products/sts
C'est assez correct comparé aux versions précédentes du plugin, et depuis que Spring Source a acquis la société responsable des Grails et des groovy, vous pouvez vous attendre à ce que STS s'améliore rapidement
Le plug-in Eclipse est-il meilleur qu’il ne l’était et adapté à ses besoins?
Il s’est nettement amélioré au cours de la dernière année. En décembre, j'ai assisté à la Groovy & Grails Exchange à Londres. Il y a eu une discussion intéressante sur l'intégration de Groovy & Grails dans Eclipse/SpringSource STS, voir la video .
De mon point de vue, Eclipse a gagné beaucoup de terrain. Actuellement, IntelliJ semble être légèrement en avance, mais cela pourrait changer dans les prochains mois.
Personnellement, j’ai appris RoR et l’ai utilisé pour quelques projets domestiques, mais j’ai ensuite basculé sur Grails, principalement parce qu’elle tourne sur la machine virtuelle; des goulots d'étranglement dans le code avant qu'ils ne deviennent un problème.
En général, je n'ai pas trouvé trop de différence dans la qualité des IDE utilisés par RoR par rapport à Grails. Bien que, pour être honnête, je programme sur Linux et n’ai pas essayé TextMate pour le développement RoR. Quand j'utilisais RoR, j'utilisais Netbeans.
En ce moment, je programme en utilisant STS et je trouve que l’utilisation de Grails est un plaisir, même si je trouve toujours que la détection/complétion de la méthode pourrait être améliorée.
Je suis un développeur Java à temps plein, mais j'utilise Rails pour mes projets de loisir. Nous avons évalué les Grails pour un projet au travail il y a un an. Mon expérience avec les grails m'a laissé un peu déçu et c'est la raison pour laquelle j'ai commencé à enquêter sur Rails. Après avoir utilisé les deux, mon impression est que même si groovy n’est pas loin de Ruby en tant que langue, Rails offre une expérience nettement améliorée par rapport au grail. Tout simplement, Rails semble résoudre beaucoup plus de problèmes du monde réel, en particulier si vous prenez en compte le nombre de bonnes pierres précieuses disponibles. Je pense notamment à la fourniture de services de recherche, de gestion des versions, de flux RSS, d'applications non crud, d'intégration aux services en nuage, etc. ..__ J'ai l'impression que Grails est proche du niveau de Rails 1.x. À la fin de ce mois, Rails 3 aurait dû être publié. Nous avons en fait décidé d’utiliser maintenant Rails au travail. En fin de compte, Grails est plus facile à prendre en main pour les développeurs Java, mais manque de la précision nécessaire pour couvrir un plus large éventail d’exigences de projet.
At-il surmonté son départ en buggy?
C'est toujours horrible. Je ne connais pas leur point de départ, mais la migration de Grails 2 à Grails 3 est toujours un cauchemar et ils brisent plus qu'ils ne résolvent.
Confère-t-il vraiment des avantages rapides en termes de développement?
J'ai passé une heure à faire les tests de Grails pour produire quelque chose dans la console (cela ne fonctionne pas immédiatement), même en Java, vous ne perdrez pas autant de temps à produire quelque chose à partir de tests.
Fonctionne-t-il pour les applications de production du monde réel?
Je ne connais toujours pas une seule entreprise célèbre qui construit quelque chose avec Grails.
Le plug-in Eclipse est-il meilleur qu’il ne l’était et adapté à ses besoins?
Je ne sais pas pourquoi quelqu'un utilise encore Eclipse, mais la prise en charge d'IntelliJ pour Grails 3 est simplement inutilisable.
Donc, répondant à la question principale:
Grails (maintenant) en vaut-il la peine?
Si vous ne pouvez pas vous permettre la licence Microsoft Access, peut-être. Pour de vrais projets, je resterais loin de Grails. C'est juste un enfant mort-né, en fait.
Je tiens à souligner deux autres considérations, l’utilisation de la mémoire et le marché du travail. L’application Grails utilise beaucoup de mémoire, particulièrement en mode de développement, par exemple. 600 Mo pour une application de taille moyenne. Lorsqu'il est déployé en mode de production, par ex. fichier war dans Tomcat, l’utilisation peut atteindre environ 500 Mo. Ceci est partiellement hérité de l'utilisation de Java.
En ce qui concerne le marché de l’emploi et selon ce que j’ai lu, il y a peu de demande pour les programmeurs Grails dans les avis de vacance de poste, par exemple, Django et Ruby on Rails.
Je dirais non. Il est encore trop gonflé, à mon humble avis, pour la plupart des utilisations, surtout si vous voulez seulement créer un prototype. Nous n'avons pas besoin de tout ce code, de toutes ces dépendances groupées avec grails pour créer une application Web. Vous n'avez pas besoin de ressort chaque fois que vous souhaitez créer une application Web. Regardez ce que vous essayez d'accomplir avant d'ajouter à votre pile tout un monde rempli de dépendances. Je pense qu'il est important de savoir en quoi consiste votre application.
Je recommande de regarder quelque chose comme ratpack, qui est beaucoup plus léger, presque comme une sinatra pour Ruby.
De mon expérience à la fin de 2013.
Avantages
- lorsque vous utilisez très peu des plugins et que vous limitez un ensemble de Grails no-s and never-s, l'expérience est plutôt fluide
Les inconvénients
- Le rafraîchissement (F5) est toujours un problème. Et c'est le plus énervant. Pour une raison quelconque, je devais redémarrer le serveur à chaque rafraîchissement 3 ou 4. Il existe un bogue de redémarrage bien connu: question1 , question2 , bien que cela arrive rarement.
- Bugs au niveau de la langue. Lorsque j'utilisais des classes internes statiques, j'avais toujours besoin de redémarrer le serveur lors d'une modification. Bien que la construction ne pose aucun problème, l’utilisation de la langue est limitée pour moi
- temps de démarrage, temps de construction, taille de l'application (70 Mo pour une petite application), utilisation de la mémoire
- débogage à distance uniquement, le débogage IDE est très instable