Vaut Grails ?

Question

C'est la moitié de coup de gueule, la moitié de la question.

Est-il utile d'utiliser Graal? Je suis en train de développer un moyen relativement simple de base de données de l'application web. Mon expertise est en Java, donc naturellement Graal semblé être un bon choix. Au début, j'ai pensé à l'aide de Spring, JPA et Hibernate, mais je les ai utilisés que précédemment et dans toutes sortes de fastidieux de configuration et de travail de codage. Graal s'annonce comme la résolution de ce.

Ma plus grande frustration avec le Graal est de toutes les petites choses qui ne fonctionnent pas. Ce que je veux dire, c'est qu'il ne fonctionne pas comme on pourrait intuitivement penser qu'il devrait. Il est très rugueux autour des bords. Je rencontre constamment des problèmes. Parfois, c'est mon manque de Graal compréhension - d'autres fois, j'ai découvert légitime Graal de bugs.

Un problème majeur est le manque de bonne intégration Eclipse. Il est Groovy et Graal plugin, mais il ne fait pas grand chose d'autre que de la syntaxe. L'appel de Groovy à partir de Java et vice versa est très pénible à configurer. N'ayant pas une bonne IDE de soutien est une grande déception.

Ce qui arrive c'est que je m'assois en essayant de développer mon application web. À la fin de la journée, je me rends compte que j'ai passé environ 85% de la journée de débogage Graal. Si elle n'est pas Eclipse problèmes, alors il est impatient de chargement, l'extraction dans la vue, un-à-plusieurs relations, bizarre fichier vide bug comportement, une étrange propriété/getter bug - il va juste sur et sur. C'est juste un exemple des problèmes que j'ai rencontré aujourd'hui. Mon dernier devoir de s'asseoir avec Graal a donné tout un tas de questions différentes.

Parfois, je me demande si ça vaut le coup. Je suis curieux de savoir si d'autres ont connu ce. Il y a des gens en fait l'utilisation de Graal de façon productive manivelle d'une application web? Il existe d'autres cadres pour le rapide développement web que je devrait prendre en considération?

Answer 1

Nous avions une équipe de 12 personnes, le tout assaisonné de Java senior devs qui ont appris Grain de 0.6 B et nous sommes tous encore en travaillant sur des projets basés sur le Graal. Je ne voudrais pas revenir à Java volontiers, et nous sommes tous soulagés d'avoir brisé le dos de la façon d'obtenir quelque part rapidement avec un Grain app.

C'était une lutte, il n'a pas été facile et il a été/est de la frustration.

Néanmoins, nous avons livré quelque chose de très rapidement compte tenu de nos efforts continus.. Il y a des bugs, nombreux, qui ont des solutions de contournement.

J'ai entendu parler de plusieurs cas de développeurs qui sont bons à Java d'essayer de plonger dans un profond, complexe incantations de Graal projets. Nous avons évité tous les produits Java et est allé pur-Graal et Groovy. Nous avons fait en sorte que nous avons commencé simple, construit la complexité comme manageably et en pratique autant que possible.. Nous avons eu l'audace de ne pas plonger dans le plus profond de la fin et j'espère que notre Java a été suffisant pour nous.

Nous avons eu finalement créé quelque chose d'énorme et complexe qui a fonctionné merveilleusement bien et n'a donc beaucoup plus rapide que l'écriture pure Java/Spring/Hibernate version; et c'est sans décent IDE de soutien et de loin le pire de la situation en termes de bugs qu'aujourd'hui.

En ce qui concerne l'Éclipse de soutien, la seule vraie IDE à utiliser pour le Graal/Groovy est Intellij - l'Éclipse de soutien est en retard, malheureusement: j'ai eu une Éclipse amant et je suis loin d'être un Intellij convertir - le Graal/Groovy appui coup tout le reste à l'écart.

Oui, le Graal est immature par rapport au Printemps peut-être. Ou Veille Prolongée. Et je parie que dans les 1,5 premières années de leur existence, ils étaient tout aussi lourde de problème.

Que l'être comme il est, place le fardeau de la preuve est sur vous, pour prendre soin de vous garder à la complexité du minimum absolu, à tester soigneusement les-première (à notre avis) et l'accumulation de la complexité progressivement et avec soin.

Il n'y a pas de code rapide de la solution avec Java une fois que vous vous impliquer Spring/Hibernate dans la pile. La complexité Graal incarne est un reflet de Spring / Hibernate complexité propre. Si vous vous sentez que vous avez le temps est mieux dépensé de le faire avec Java pur, je ne voudrais pas soutenir le contraire.. j'ai toujours mon WTFs mais maintenant que la courbe d'apprentissage abrupte est derrière moi, je pense que je vais coller w Grain un peu plus.

Answer 2

J'ai beaucoup apprécier l'écriture graal application pour deux raisons:

• Je n'ai pas à utiliser Java
• Je peux utiliser Java

Je pense qu'après avoir pris connaissance graal on obtient ses choses fait très rapidement et avec élégance.

Voilà pour le côté positif. Le côté négatif est de la performance, ce qui me frappe sur deux aspects: le déploiement et l'testdriven développement.

Je n'ai pas réussi à exécuter plus de 3 graal des applications sur un seul (loué) serveur, car j'ai rapidement atteint la mémoire et limites de performance. Il y a tout simplement trop de cadres inclus.

De Plus, le lanceur du graal n'est pas digne de ce nom. Quand je lance les tests unitaires, ils doivent le faire dans un instant, pas dans 10 à 20 ans. Donc, je me retrouve tout le temps de l'écriture de la logique métier dans la plaine de java, parce que je peux le tester beaucoup plus rapide. Mais je suppose que cela peut être abordé avec une meilleure intégration dans l'IDE (eclipse).

Answer 3

Selon moi, le support du ressort de Grails va être un coup de pouce. Si quelqu'un peut le déplacer passé CRUD sur le web, c’est les gars.

Je pense aussi que c’est d’atteindre une masse critique. Il y a plusieurs nouveaux livres qui vont frapper le marché en 2009. Je pense que ceux qui aideront le taux d’adoption.

Answer 4

Je suis totalement avec vous! Graal se sent toujours tellement rugueux autour des bords, que c'est presque une blague pour la comparer avec les Rails. Si au moins l'erreur de déclaration était un peu mieux. Mais je suppose que c'est probablement aussi en raison de l'énorme quantité de bibliothèques qu'il utilise sous les couvertures. Un seul mot: stacktrace! Je suis également pas un grand fan du modèle->db approche (Rails a db->modèle). L'échafaudage laisse aussi beaucoup de place pour des améliorations. Puis "pas de redémarrage nécessaire" ne fonctionne pas comme annoncé. (Je ne suis pas sûr de ce qui est pire - d'avoir à redémarrer tout le temps ou parfois de trouver des comportements bizarres qui disparaissent lorsque vous redémarrez) Et ne me lancez pas sur GORM. (Quand il faut des heures pour trouver un moyen de ce qu'aurait été une simple SQL vous commencez à vous demander si toute cette ORM vraiment vous permet d'économiser temps) Peut-être aussi longtemps comme il est simple.

Je veux dire: c'est toujours l'un des meilleurs choix d'un cadre, lorsque vous êtes dans le monde java. (Tellement de choses inutiles qui s'appelle elle-même un framework web) ...il a du potentiel. Je souhaite juste qu'il n'aurait pas construire au-dessus de tant d'autres plus complexes.

De toute façon espérons que ces choses rentrer dans l'ordre. Pour le moment, je suis tapi au playframework.org qui a aussi l'air très lisse et prometteur.