Groovy / Grails :: Ruby / Rails :: 2011 Etat du framework

Oui, plusieurs threads similaires existent, mais nous sums maintenant en 2011, et beaucoup de choses ont changé.

La version 1.3.6 de Grails s’est considérablement améliorée par rapport à la version 1.3 lorsque j’ai initialement essayé d’apprendre le framework (et a abandonné pour ralentir les temps de compilation et autres événements induisant des groans).

Ayant passé quelques mois avec la dernière version, je suis impressionné, prototyper 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, sauf pour les modifications apscopes aux classes de domaine. Groovy.lang est fantastique (en tête, cela est comparé à ma vie professionnelle en PHP).

D’un autre côté, il y a Ruby / Rails, avec lequel j’ai peu d’expérience au-delà de la consultation des documents de Ruby et de l’exploration d’Active Record (à comparer au GORM). Venant de PHP / Jquery, la syntaxe groovy est cake, ruby ​​pas tellement, mais accessible.

Ruby / Rails fait fureur, alors que Groovy / Grails semble prendre de la vitesse à part entière.

J’aimerais savoir ce que les deux camps ont à dire (la guerre des langues induite par la guerre est la bienvenue) à propos des avantages / inconvénients des deux langs / frameworks en 2011. Lorsque vous choisissez un framework, il est important de savoir dans quoi vous vous engagez. à ce sujet, les débutants en bénéficieront, et les experts pourront s’exprimer; -)

Rails et Grails sont tous deux d’excellents frameworks avec leurs versions actuelles. Vous ne pouvez vraiment pas vous tromper non plus. Voici quelques choses que je trouve intéressantes à leur sujet cependant:

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 les options PaaS comme EngineYard (et, espérons-le, une option AWS BeanStalk Rails à l’avenir), mais il pourrait coûter un peu plus cher d’exécuter une application Rails qu’avec une application Grails (évidemment JRuby option à bien).
  • Rails est légèrement meilleur avec les alternatives NoSQL actuellement, mais Grails rattrape rapidement son retard
  • Rails a beaucoup plus de plugins, mais cela peut causer des problèmes si vous en utilisez qui ne sont pas maintenus (beaucoup d’entre eux ne travaillent pas encore avec Rails 3).
  • Rails est plus mature et a plus de fonctionnalités à ce moment-là
  • Le support de Rails REST est incroyable
  • Il y a beaucoup plus de “grands” sites web Rails que Grails
  • Ruby est beaucoup plus populaire que Groovy – TIOBE
  • Pas de dépendance sur Oracle, ha! (Grails a évidemment besoin de la JVM)

Grails

  • Grails s’intègre à la JVM mieux que JRuby
  • Grails GORM est meilleur qu’ActiveRecord (IMHO), bien que Rails 3 ait ouvert la porte un peu pour d’autres options de persistance, mais tous les livres, tutoriels, etc. utilisent ActiveRecord
  • Les taglibs Grails View sont meilleurs que <=% ...%> dans la 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 de tâches pour Grails que 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 projette d’apprendre ensuite Lift (Scala)

Ma recommandation

  • Si vous n’avez jamais fait de développement Java et que vous travaillez sur un projet parallèle pour un site Web petit à moyen, optez pour Rails
  • Si vous travaillez dans une grande entreprise qui utilise Java, essayez de lancer Grails dans votre gestion en tant que “prochaine infrastructure Java” dans laquelle ils devraient investir.
  • Si vous travaillez sur «le prochain twitter ou le prochain carré», 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 “repository” de “Service”? Oh mon Dieu: je dois mettre la logique métier sur les contrôleurs … Je ne peux pas imaginer un vrai gros projet avec Ruby on Rails: y a-t-il quelqu’un sur 37signals qui se souvient des bases de la séparation de Business et Domain / Repository? La structure des dossiers / classes de Rails ne s’en occupe pas.

  • Deuxième chaussette: “Active Record”. Essayez de concevoir une véritable couche orientée object complexe et mappez-la à l’aide des modèles Rails (Active Record) … vraiment: ne le faites pas.

  • 6 mois plus tard, avec notre projet en cours: R & R consum 80% de CPU (et de mémoire …) en utilisant apache + passanger sur un serveur quad core … et la firebase database Postgresql est en vacances (3-4% de CPU). .. Oh mon dieu (nouvellement)

    Mes anciennes applications ASP / VB6 capables de servir des pages à 300 utilisateurs simultanés dans un contexte de backoffice réel avec de véritables bases de données complexes et des activités complexes installées sur une machine autonome (un serveur de cœur de processeur 2001).

Bien sûr, les conventions et la syntaxe Ruby sont adorables … et personne n’a besoin d’un compilateur (eh bien … les tests unitaires sont utilisés pour ce ménage 90% du temps … juste pour résoudre le typage disparu à chaque changement de code … “S’il vous plaît, programmation dieu, faites attention à mes fautes de doigts”)

Première saisie 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 au domaine / service. AGRÉABLE!!!
  • Vous pouvez éventuellement oublier Java.

Rails est assez mature, a un écosystème énorme pour aller avec. Je ne suis pas familier avec Grails ou son support en ligne, mais le drapeau rouge que je vois dans votre message est que vous avez admis que Grails jouait au rattrapage de Rails.

Ruby est un plaisir absolu avec lequel travailler (et cela à partir d’un ancien hack C ++… pourquoi, à l’époque, je ne programmais qu’un clavier hexadécimal, un jeune whippersnapper… maintenant, arrêtez-moi!).

Il y a des choses à propos du rbuy qui rendent difficile à suivre à certains moments (method_missing, je vous regarde) mais je suis sûr que cela peut être dit à propos de n’importe quelle langue.

Moi? J’irais avec ruby ​​et rails.

Eh bien pour les grails, je pense toujours que même rattraper son retard, il a deux choses principales que les rails n’auront pas d’une manière facile:

  • mise à l’échelle
  • des tonnes de bibliothèques java matures au bout des doigts (geotools entre autres)

Ruby on Rails est remarquable – comme le Pink Floyd du web dev.

Groovy on Grails en est une copie décente – un peu comme le spectacle australien Pink Floyd …

BTW – Nous avons les deux au travail – et j’ai vu beaucoup de développeurs Grails finir par apprendre Rails et s’y tenir.

J’ai également vu des développeurs de Rails apprendre Grails, mais AUCUN d’entre eux ne l’a préféré.

Environ la moitié du temps, nos développeurs Java apprennent Grails et restnt à l’écart de Ruby.

IMHO – Si vous connaissez vraiment bien les deux, vous préférerez presque toujours Ruby et Rails.

Vous devez également tenir compte de votre IDE. Quand j’ai commencé avec les rails, c’était très douloureux. Rubymine était super lent et écrasé, tout le monde utilisait textmate. Grails a STS (basé sur éclipse) et vous donne toutes les fonctionnalités dont vous avez besoin.