Groovy/Grails :: Ruby/Rails :: 2011 Etat du cadre
Oui, il existe plusieurs threads similaires, mais nous sommes maintenant en 2011 et beaucoup de choses ont changé.
Grails 1.3.6 s’est énormément amélioré par rapport à la v1.3 lorsque j’ai initialement essayé d’appréhender le framework (et que j’ai abandonné les temps de compilation lents et d’autres événements gémissants).
Après avoir passé quelques mois avec la dernière version, je suis impressionné. Protyper une application est un jeu d'enfant (GORM est génial!). En mode de développement, il n'est plus nécessaire de redémarrer, à moins que des modifications ne soient apportées aux classes de domaine. Groovy.lang est fantastique (rien à l’esprit, c’est comparé à ma vie professionnelle quotidienne en PHP).
Maintenant, il y a Ruby/Rails, que j'ai peu d'expérience au-delà de la lecture des documents Ruby et de l'exploration d'Active Record (à comparer avec GORM). Venant de PHP/Jquery, la syntaxe groovy est un gâteau, Ruby pas tellement, bien que accessible.
Ruby/Rails fait fureur, tandis que Groovy/Grails semble prendre de la vitesse.
J'aimerais entendre ce que les deux camps ont à dire (bienvenue provoquant une guerre de flamme): avantages/inconvénients des deux langages/cadres maintenant en 2011. Lorsque vous choisissez un cadre, il est important de savoir dans quoi vous vous engagez. les débutants en bénéficieront, et les experts pourront se défouler ;-)
Rails et Grails sont d'excellents frameworks avec leurs versions actuelles. Vous ne pouvez vraiment pas vous tromper avec l'un ou l'autre. Voici quelques points qui me semblent intéressants à leur sujet:
Des rails
- Rails (Ruby) ne s’adapte pas aussi bien que Grails (Groovy). Vous aurez besoin de plus de puissance pour exécuter votre application. Ce n'est pas un gros problème avec des options PaaS telles que EngineYard (et une option AWS BeanStalk Rails dans le futur), mais cela pourrait coûter un peu plus cher de faire fonctionner une application Rails par rapport à une application Grails (JRuby est également un option à bien).
- Rails est légèrement meilleur avec les alternatives NoSQL pour le moment, mais Grails rattrape rapidement son retard
- Rails a beaucoup plus de plugins, mais cela peut poser des problèmes si vous en utilisez qui ne sont pas maintenus (beaucoup d'entre eux ne fonctionnent pas encore avec Rails 3).
- Rails est plus mature et a plus de fonctionnalités en ce moment parce qu'il existe depuis plus longtemps
- Le support de Rails REST est incroyable
- Il y a beaucoup plus de "gros" sites Web de Rails que Grails
- Ruby est beaucoup plus populaire que Groovy - TIOBE
- Pas de dépendance à Oracle, ha! (Grails a évidemment besoin de la JVM)
Grails
- Grails s'intègre mieux avec la JVM que JRuby
- Grails GORM est meilleur qu'ActiveRecord (IMHO), bien que Rails 3 ait un peu ouvert la porte à d'autres options de persistance, mais tous les livres, tutoriels, etc. utilisent tous ActiveRecord.
- Les taglibs de Grails View sont meilleurs que <=% ...%> en vue
- Les plugins Grails sont bien documentés et indiquent clairement s'ils sont supportés par SpringSource ou non
- SpringSource investit massivement dans Grails
- Il y aura beaucoup plus d'emplois dans l'entreprise pour Grails que pour Rails à l'avenir, mais plus de startups utilisent Rails (où voulez-vous travailler?)
Ma perseption
- J'ai utilisé Rails il y a quelques années, je travaille actuellement sur un projet Grails
- Je les aime tous les deux mieux que Django (Python) ou Zend Framework (PHP)
- Je prévois d'apprendre l'ascenseur (Scala) suivant
Ma recommandation
- Si vous n'avez jamais fait de développement Java et travaillez sur un projet parallèle pour un site Web de petite à moyenne taille, utilisez Rails.
- Si vous travaillez dans une grande entreprise qui utilise Java, essayez de présenter Grails à votre direction en tant que "prochain framework Java" dans lequel ils devraient investir.
- Si vous travaillez sur "le prochain Twitter ou foursquare", alors vous êtes assez intelligent pour répondre à cette question vous-même! :)
La première fois que j'ai commencé un projet avec Rails, j'ai été vraiment surpris:
Comment puis-je séparer "référentiel" de "Service"? Oh mon Dieu: je dois mettre la logique métier sur les contrôleurs ... Je ne peux pas imaginer un grand projet avec Ruby on Rails: existe-t-il quelqu'un sur 37signals qui se souvient des bases de la séparation Business/Domaine/Référentiel. La structure des dossiers/classes de Rails ne s’occupe pas de cela.
Deuxième chaussette: "Active Record". Essayez de concevoir une couche métier complexe orientée objet et de la mapper à l'aide des modèles Rails (Active Record) ... vraiment: non.
6 mois plus tard, avec notre projet en cours d'exécution: R & R consomme 80% de son processeur (et de sa mémoire ...) avec Apache + passanger sur un serveur quad core ... et la base de données Postgresql est en vacances (3 à 4% de sa CPU). .. Oh mon dieu (nouvellement)
Mes anciennes applications ASP/VB6 étaient capables de servir des pages à 300 utilisateurs simultanés dans un contexte de backoffice réel avec des bases de données complexes et des entreprises complexes installées sur une machine autonome (un serveur central à processeur 2001).
Bien sûr, les conventions et la syntaxe Ruby sont très jolies ... et personne n’a besoin d’un compilateur (bon ... les tests unitaires sont utilisés pour ce type de souris 90% du temps ... juste pour résoudre le problème de la frappe disparue à chaque changement de code ... "S'il vous plaît, mon Dieu, prenez soin de mes fautes de doigts")
Première impession avec Grails:
- Un stack "cool" inspiré des Rails avec une puissance professionnelle basée sur le framework Spring (IoC, Hibernate, ...)
Et oui!!!
- Il existe une séparation propre domaine/service. Agréable!!!
- Vous pouvez éventuellement oublier Java.
Rails est assez mature, et son écosystème est énorme. Je ne connais pas Grails ni son support en ligne, mais le drapeau rouge que je vois dans votre message est que vous avez admis que Grails rattrape Rails.
Ruby est une joie absolue de travailler avec (et cela vient d'un vieux bidouillage C++ ... pourquoi, jadis, je programmais avec juste un clavier hexadécimal, jeune whippersnapper ... maintenant sortez de mon temps!).
Il y a des choses sur Ruby qui font qu'il est difficile de suivre parfois (méthode_missing je vous regarde) mais je suis sûr que cela peut être dit de n'importe quelle langue.
Moi? J'irais avec Ruby et Rails.
Eh bien pour les Grails, je pense toujours que même en rattrapant, il y a 2 choses principales que Rails n'aura pas de manière simple:
- mise à l'échelle
- des tonnes de bibliothèques Java matures au bout de vos doigts (personnellement des outils de géolocalisation, entre autres)
Ruby on Rails est remarquable - à l'instar du Pink Floyd de Web Dev.
Groovy on Grails en est une copie correcte - un peu comme le show australien Pink Floyd ...
BTW - Nous avons les deux au travail - et j'ai vu de nombreux développeurs Grails apprendre finalement Rails et s'y tenir.
J'ai aussi vu des développeurs de Rails apprendre le Grails, mais AUCUN d'entre eux ne l'a préféré.
Environ la moitié du temps, nos développeurs Java apprennent le Grails et se tiennent simplement à l'écart de Ruby.
IMHO - Si vous connaissez vraiment les deux assez bien, vous préférerez presque toujours Ruby et Rails.
Vous devez également prendre en compte votre IDE. Quand j'ai commencé avec Rails, c'était assez douloureux. Rubymine était super lente et s’est écrasée, tous ceux que je connais utilisaient textmate. Grails a STS (basé sur Eclipse) et vous donne toutes les fonctionnalités dont vous avez besoin.