ruby on rails - ¿Vale la pena Grails(ahora)?

ruby-on-rails groovy (21)

¿El plug-in de Eclipse es mejor de lo que era y es adecuado para su propósito?

Definitivamente había mejorado mucho en el último año. En diciembre asistí al Groovy & Grails Exchange en Londres. Hubo una gran charla sobre la integración de Groovy & Grails en Eclipse / SpringSource STS que se ha grabado, vea el video .

Desde mi punto de vista, Eclipse ganó mucho terreno. Actualmente IntelliJ parece estar un poco adelantado, pero eso podría cambiar en los próximos meses.

Sé que esto es un duplicate , sin embargo, el mundo de Grails ha avanzado considerablemente desde que se formuló la pregunta hace más de un año, al igual que el soporte IDE en Eclipse, así que por favor no lo cierres ciegamente.

Pensé que la respuesta era sí y me había embarcado en un nuevo proyecto con Grails 1.2.0 y había coqueteado con los bits de Groovy / Grails de la Integración Eclipse de STS .

Creo que la pregunta merece una nueva visita después de un año de la evolución de Grails, cuando la respuesta fue definitivamente mixta.

Por lo tanto, como experimentado desarrollador web de Java, tengo estas preguntas y agradeceré que mis suposiciones se cuestionen:

¿Valía la pena ahora Grails contra Ruby o la propia?
¿Ha superado su mal funcionamiento?
¿Concede realmente beneficios rápidos de desarrollo? (Admito que estoy luchando ahora que ya pasé la extensa configuración de línea base para hacer mi aplicación a medida, que no está orientada a listas y páginas)
¿Funciona para aplicaciones de producción del mundo real? (Se siente pesado)
¿El plug-in de Eclipse es mejor de lo que era y es adecuado para su propósito? (Todavía no creo)

Gracias

EDITAR: Estoy aprendiendo sobre la marcha y tengo un par de inconvenientes importantes sobre vivir con el marco, en lugar de las capacidades del marco. Estoy agregando estos porque creo que deben ser consideraciones y se basan en mi experiencia y opinión, y pueden ayudar a alguien que está tratando de decidir si va o no. También puedo mostrar mi falta de experiencia con el marco, por lo que nada de esto se entiende como una crítica abierta. Soy un desarrollador experimentado y esto es lo que he encontrado:

La depuración es realmente difícil . De hecho, es casi imposible, especialmente como principiante en el marco, que es cuando más necesita a su fiel amigo depurador. He pasado mucho más tiempo de lo que debería para rastrear problemas de errores sintácticos en alguna parte del código relacionado con campos de dominio que causan fallas silenciosas en algún lugar de la pila.

La tala es francamente horrible . Tienes dos modos, "nada útil" y "una cantidad excesiva de cosas inútiles". Mi registro de depuración fue de 128Mb después de una solicitud de una sola página y no contiene nada sobre mi error. En mi opinión, toda la cuestión de la explotación forestal necesita reconsideración en el marco.

El IDE Eclipse de STS tiene un valor marginal . Aparte de la sintaxis hilighting no es de mucha utilidad. No puede depurar el código por lo que es un editor glorificado. Las sugerencias de código son fragmentarias y no hay soporte de GSP en absoluto por lo que puedo ver. También es el complemento de Eclipse más lento que tengo en mi escritorio, en aproximadamente 2 minutos para iniciarlo. Es sorprendentemente lento. He vuelto a un editor de texto (que notará que todos los videos tutoriales en línea también lo hacen) y algo de sintaxis personalizada hilighting.

Tengo algunas preocupaciones serias sobre el rendimiento . Es demasiado pronto para decirlo, pero ya estoy empezando a modificar la base de datos debido a la hibernación. Tal vez sea de esperar, pero realmente tengo que mantener mi modelo de dominio simple para que las convenciones generen consultas de rendimiento.

Y una última, la convención de que su modelo de dominio lógico y su modelo de base de datos física debe ser idéntico no es un defecto inteligente y es poco probable que sea el caso en el mundo real. Sé que puedes separar los dos, pero crea un grado de complejidad que, creo, podría evitarse si se extendieran las convenciones. No hay documentación adecuada sobre la composición y lo que debe hacer para que funcione en la práctica .

¿Ha superado su mal funcionamiento?

Aún es horrible. No sé su comienzo, pero la migración de Grails 2 a Grails 3 sigue siendo una pesadilla y están rompiendo más de lo que resuelven.

¿Concede realmente beneficios rápidos de desarrollo?

Pasé una hora haciendo las pruebas de Grails para generar algo en la consola (no funciona de la caja), incluso en Java no pasarás tanto tiempo para sacar algo de las pruebas.

¿Funciona para aplicaciones de producción del mundo real?

Todavía no conozco una sola compañía famosa que esté construyendo algo con Grails.

¿El plug-in de Eclipse es mejor de lo que era y es adecuado para su propósito?

No tengo idea de por qué alguien todavía está usando Eclipse, pero el soporte de IntelliJ para Grails 3 es simplemente inutilizable.

Entonces, respondiendo la pregunta principal:

¿Vale la pena Grails (ahora)?

Si no puede pagar la licencia de Microsoft Access, tal vez. Para proyectos reales, me mantendría alejado de Grails. Es solo un niño muerto, de hecho.

¡Realmente lo vale!

Estamos utilizando Grails en varios proyectos, todos ellos con gran éxito por las siguientes razones:

Fácil - Es uno de los frameworks más fáciles que hemos usado
Reutilización del código heredado: todo lo que tenemos que hacer es obtener nuestro código heredado y colocarlo en la carpeta lib o src y listo. Simplemente genial para nosotros.
Estructura de base de datos heredada: es una herramienta increíble si desea generar visualizaciones de datos en bases de datos heredadas.

Ahora, sobre la viabilidad:

Errores: no nos hemos enfrentado a muchos errores desde la versión 1.1 (la versión 1.0 era demasiado falsa para nosotros)
Herramientas: Netbeans realmente está mejorando en este frente, pero ni siquiera está cerca de otras herramientas como Intellij IDEA (¡excelente soporte!). Lo mismo se puede decir sobre Eclipse.
Portabilidad: nunca enfrentamos un solo problema en nuestros proyectos.

Ahora tenemos media docena de aplicaciones de Grails en producción, y aunque Grails es diferente de los frameworks de Java y requiere algo de tiempo de aprendizaje, ha valido la pena porque hemos utilizado técnicas Agile. Detalles:

Usamos IntelliJ. No es muy caro y ha sido pagado en unas semanas por nosotros.
Las pruebas automatizadas, la integración continua y la refactorización son una necesidad, como para todo el código de lenguaje dinámico. Si ya practicas TDD o al menos tienes una cobertura de código de prueba decente, entonces no agrega ningún trabajo adicional.
Hibernate viene por defecto con Grails, pero puede usar otros marcos de persistencia. Hay 5 plugins de persistencia disponibles hoy
La tala no era una preocupación en la mente de Graeme Rochers, pero ha mejorado constantemente. Sin embargo, no me he enfrentado a un problema donde no se registró un error (debe asegurarse de detectar excepciones correctamente en su código)
La depuración claramente no estaba en el radar (pero esto no ha mejorado). No confiamos en la depuración de todos modos.

Dicho esto, al igual que con todas las nuevas tecnologías, recomiendo hacer prototipos, revisiones de códigos, programación de pares, y tal vez usar algunas consultas también.

Comencé recientemente un proyecto de Rails, había estado haciendo algunas cosas con Grails.

Lo principal de Rails es que hay muchas cosas que son completamente opacas para el desarrollador (que odio), y esto tiende a aumentar cuando comienzas a agregar más plugins / generators / libs / etc, porque para combinarlas Tendrás que arreglar algo. Tienes la sensación de que los rails + complementos son solo un hack de DSL gigante que comienza a romperse si usas una combinación incorrecta de complementos + versiones .

Con Grails , aunque el ecosistema es mucho más pequeño, todo tiende a ser relativamente constante. El enfoque DSL no es muy usado, y al usar un diseño convencional pero aburrido (me refiero al uso de clases, interfaces, etc., en lugar de DSL) es mucho más fácil entender cómo funciona la instalación de tuberías.

Haciendo una comparación de 1 a 1, así es como funciona:

Implementación del lenguaje : prefiero Ruby a Groovy, aunque no conozco a Ruby tan bien. Groovy se siente como un lenguaje de buena intención y mala implementación, donde algunas de las características están soldadas en la sintaxis. Me refiero a algunas clases especiales que parecen estar ahí solo para permitir algún truco.
Características del marco : Rails está muy adelante en este caso. Puede configurar la mayoría de los aspectos de Rails (por ejemplo: diseños, plantillas, css / js empaquetadores, validación, pruebas de marcos, etc.) de varias maneras. Grails se está quedando atrás en esto, aunque es lo suficientemente flexible para la mayoría de los casos de uso.
Complementos : Rails tiene una tonelada de complementos que pueden verse como una bendición o una pesadilla. Algunos complementos no se mantienen, otros no funcionan bien con alguna función o complemento y hay muchas aplicaciones. Estoy aprendiendo a usar los complementos básicos y más utilizados (authlogic, haml, etc.) Grails tiene complementos excelentes para los conceptos básicos (autorización / autenticación, ORM, etc.) y algunos otros complementos para cosas más pequeñas.
Pruebas : Rails tiene un montón de maneras de probar, pero esto no es necesariamente bueno. Algunos frameworks de prueba no funcionan bien con algunos complementos, etc. Grails tiene menos plugins de prueba pero, de nuevo, tienden a integrarse mejor con algunos de los plugins principales (porque no hay tantos plugins para integrar).
Base de datos : Grails gana por lejos .
- Prefiero modelar mis clases de dominio en lugar de piratear mi db.
- Hibernate (que se usa debajo del capó) está a años de distancia de su contraparte Rails. Aunque hay un mapeador de datos para Rails (que es más similar en naturaleza a Hibernate que ActiveRecord), creo que no es lo suficientemente maduro. Los griales también tienen migraciones a través de un complemento.
- Tiene excelentes aplicaciones de caché para Hibernate (caché JBoss, EhCache, etc.) que pueden aumentar su rendimiento a través del techo
Bibliotecas : siento que Ruby tiene muchas bibliotecas para cosas nuevas como servicios NoSQL o en la nube, mientras que Java tiene un montón de bibliotecas para cosas más antiguas como el procesamiento de Excel. No olvide que las bibliotecas de Java suelen ser mucho más rápidas que Ruby
Cutting edge : Rails es más exagerado, lo que se traduce en tener más recursos detrás. Esto significa que si intenta integrar MongoDB o Riak con Rails, hay un buen cambio que alguien ya ha logrado. Grails se está quedando atrás, principalmente porque no es tan popular, por lo que la comunidad tiende a concentrarse en resolver problemas cotidianos en lugar de utilizar todo el material de última generación como NoSQL, etc.

Aquí hay un ejemplo:

La mayoría de los complementos de Grails generan código en forma de modelos y / o servicios. El resto generalmente lo maneja una biblioteca. Puede inspeccionar el código de modelo / servicio, ver qué hace y cambiarlo.
La mayoría de los complementos de Rails generalmente se conectan con la API de Rails, lo que significa que terminas llamando a alguna función o incluyendo algún módulo, y luego usas la propia DSL del complemento. Esto funciona muy bien cuando funciona , pero cuando se rompe es horrible y terminas teniendo que parchar algunas cosas, o instalar un plugin diferente o una versión de complemento. Supongo que un desarrollador Rails más experimentado se siente más cómodo con esto, pero yo no.

Conclusión:

Si quieres mejorar, no te molestes con parches ocasionales, favores a una gran comunidad y / o no te moleste usar DB de estilo ActiveRecord, ve con Rails . Además, Ruby como lengua es muy elegante
Si prefiere diseños de interfaz de clase en lugar de DSL, prefiera modelar su aplicación a través de modelos, no necesita características exquisitas y está familiarizado con el ecosistema de Java, vaya con Grails

Compartiré mi experiencia de 3 años usando Grails en casi diez aplicaciones. No puedo comparar contra Ruby on Rails, así que responderé a tus otras preguntas.

¿Ha superado su mal funcionamiento?

Sí lo tiene. He experimentado algunos errores de Grails en Grails 2.0.4 / 2.2.4.

¿Concede realmente beneficios rápidos de desarrollo?

Es bastante fácil de aprender, fácil de desarrollar, nunca vio a nadie con un buen conocimiento del mundo Java tomar más de una semana de trabajo para conocer los conceptos básicos. También es fácil de mantener. Y no tienes que preocuparte demasiado por tu DB, solo asegúrate de que estés listo

¿El plug-in de Eclipse es mejor de lo que era y es adecuado para su propósito?

Elija su IDE con mucho cuidado. Eclipse me ayudó mucho pero se cuelga y causa más problemas de lo que debería. Fui a IntelliJ y en el mes de prueba me pareció una mejor opción. Últimamente uso Sublime Text, algunos complementos y la antigua línea de comandos. Solo voy a un IDE en situaciones especiales: para usar su depurador, por ejemplo.

¿Funciona para aplicaciones de producción del mundo real?

Es un poco pesado Investigue mucho sobre sus elecciones de diseño ANTES de escribir sus modelos. Investigue mucho sobre el buen diseño de Grails. La mayoría de las cosas que hice hace dos años puedo darme cuenta de cómo hacerlo mejor ahora porque tengo más experiencia. Maneja bien las aplicaciones de producción del mundo real, pero dependiendo de los errores que cometas, Hibernate realmente puede ser un dolor de cabeza.

De mi experiencia a finales de 2013.

Pros

cuando usas muy poco de los complementos y confinas un conjunto de Grails no-s y never-s, es una experiencia de desarrollo bastante fluida

Contras

La actualización (F5) siempre es un problema. Y esto es lo más molesto Por alguna razón, tuve que reiniciar el servidor en cada 3ª-4ª actualización. Hay un error de reinicio bien conocido: question1 , question2 , aunque ocurre raramente.
Errores de nivel de lenguaje. Cuando utilicé clases internas estáticas, siempre tuve que reiniciar el servidor en un cambio. Aunque no hay problemas con la construcción, el uso del lenguaje es limitado para mí
tiempo de inicio, tiempo de compilación, tamaño de la aplicación (70 megas para una aplicación pequeña), uso de la memoria
solo depuración remota, la depuración IDE es muy inestable

El plugin Eclipse de Grails es una mierda. Se cuelga sin ningún motivo, y realmente no es compatible con la flexibilidad de Groovy. Se rumorea que NetBeans e IntelliJ son mucho mejores, pero aún no los he probado.

¿Funciona? Claro que lo hace. Incluso Ruby on Rails funciona, siempre y cuando arrojes suficientes servidores al problema. Sin embargo, no tengo idea de cómo se compara Grails con varios frameworks Java.

¿Concede realmente beneficios rápidos de desarrollo? Bueno, sigo perdiendo muchas cosas buenas de Ruby / Rails. No reconoce los parámetros de solicitud de fecha y de Enum automáticamente (de nuevo, Rails también tiene algunos problemas con las fechas), TimeCategory debe ser parte de la configuración estándar pero no lo es. Pero también hay muchas cosas que requieren una configuración notablemente pequeña.

No es exactamente donde Rails está (estoy particularmente ansioso por Rails 3), pero es mucho más agradable trabajar con él que muchos frameworks Java. Aun así, la magia debajo de la superficie es mucho más profunda que en Rails. Por ejemplo, el sistema de Restricciones es realmente poderoso, pero está construido sobre una gran capa de material de primavera impenetrable, y realmente inflexible si quieres usar esa misma potencia de una manera ligeramente diferente. Rails es más fácil de subvertir, IME.

¿Vale la pena? Sí. ¿Es una mejor opción que otra cosa? Eso depende.

En cuanto al plugin de eclipse, sigue llegando, pero puedes usar la versión de eclipse de Spring Source (SpringSource Tool Suite)

http://www.springsource.com/products/sts

Es bastante decente en comparación con las versiones de plugins anteriores, y como Spring Source ha adquirido la compañía responsable de Grails y Groovy, puede esperar que STS mejore rápidamente.

En mi experiencia, Grails trae algunas características muy atractivas sobre la mesa que definitivamente hacen que valga la pena aprender y usarlas.

Agilidad: las cosas que solíamos tomar semanas para implementar en proyectos J2EE convencionales generalmente son un día de trabajo con el sistema de plugins de Grails. Cosas como ajax, jquery ui, acegi, implementación relajada, sistema de programación y muchos de ellos
Se ejecuta en JVM lo que alivia la necesidad de aprender algún otro sistema de tiempo de ejecución y sus idiosincracias
Java como sintaxis y groovy sintaxis de azúcar. como lo mejor de ambos mundos. Puede comenzar de inmediato con Java en lugar de aprender la sintaxis de un nuevo idioma como Ruby y luego, lentamente, puede pasar a la sintaxis maravillosa, robusta, fácil e intuitiva
Para los gerentes de proyecto, a menos que exista una razón convincente para "no usar" los griales por alguna razón (resistencia de más arriba, para adoptar nueva tecnología o algo así), no veo ninguna razón por la cual los griales no se pueden usar o en menos probado.

Para responder a la preocupación sobre la depuración, no es tan difícil. La depuración es fácil si usa Netbeans IDE. Eso me lleva a un punto más para mencionar. Después de algunos experimentos con todos los IDE descubrimos que Netbeans es el más adecuado para hacer el trabajo. Tiene mejor soporte para la finalización de código, resaltado de sintaxis y depuración, etc. En mi opinión, STS no es lo suficientemente bueno para eso.

Habiendo usado recientemente Grails para un proyecto, quiero compartir nuestras experiencias en comparación con el desarrollo de aplicaciones J2EE estándar.

¿Concede realmente beneficios rápidos de desarrollo?

Definitivamente, lo hace. Incluso si el camino del andamiaje se deja antes y las convenciones se anulan para las necesidades propias, el período de puesta en marcha es muy corto, ya que no tenemos que preocuparnos por muchas tecnologías diferentes. Ese tipo de ligereza nos hace trabajar no solo más rápido, sino también más preciso y limpio.

Escribir etiquetas nunca fue más fácil, mientras que con JSF primero deliberamos sobre si vale la pena el esfuerzo, con Grails simplemente lo hacemos. Trabajar con testdriven y lograr una alta tasa de cobertura también se hace bastante fácil, aunque los diferentes casos de prueba y las estrategias de burla a veces son inconsistentes y con errores.

Cambiar de Java a Groovy es un gran placer, nos encantó tener literas de listas y mapas, cierres, constructores, para tirar nuestra implementación de "mapas" de placas de calderas en Java y para escribir códigos compactos, significativos y enfocados.

Lo que ralentiza la velocidad de desarrollo es el soporte IDE no tan perfecto, que también es válido para el plugin IntelliJ, que usamos. La documentación mala, a menudo vieja e incluso incorrecta, diseminada en diferentes lugares (frustrando la promesa de que "la búsqueda ha terminado") también obstaculiza el rápido desarrollo. Por lo tanto, a menudo teníamos que recurrir a la lectura del código fuente, y luego nos asustaban las jerarquías subyacentes de la clase Spring.

He estado usando Grails desde los primeros días 1.0 beta y solo puedo recomendar que comiences a tomar en serio a Groovy / Grails si vienes de la tienda de Java.

Si eres una tienda de Java y consideras Ruby Rails, detente - ve a Grails. Si Grails no funciona para usted, siempre puede iniciar Rails.

He estado usando Grails durante más de 4 meses y trataré de darle mi opinión personal sobre Grails y su usabilidad.

¿Valió la pena ahora Grails frente a Ruby u otro?

Por supuesto, la respuesta no es ''Sí'' o ''No'', pero depende . Depende de sus requisitos (¿necesita estar en Java World?), De sus preferencias también (¿prefiere el desarrollo orientado al dominio, prefiere Groovy ...)? Sin embargo, puedo responder que Grails es una alternativa seria a Rails. Creo que cualquiera que sea su aplicación Rails, también puede hacerlo con Grails. Pero dependiendo de la naturaleza de su proyecto, podría tomar más o menos tiempo. Nuevamente, si está familiarizado con Rails pero no con Grails, Rails es la opción más segura.

¿Ha superado su mal funcionamiento?

Sí . Si echas un vistazo a mis mensajes iniciales (en este sitio web u otros), me quejaba mucho sobre los errores de Grails. Pero solo debes recordar que Grails es un poco rudo (por ejemplo, no usar demasiado la herencia del dominio) y una vez que estés familiarizado con el framework, no experimentarás demasiadas malas sorpresas. No estoy diciendo que Grails no tenga errores. Sin duda es más que Rails. Pero también es más útil que con errores . Un consejo para eso: use la menor cantidad de complementos posible . Porque muchos de ellos tienen errores y algunos no son compatibles entre ellos. Por lo tanto, no incluya el complemento Grails a menos que esté seguro de que el complemento de Grails es actualizado, no intrusivo y probado (usted mismo).

¿Concede realmente beneficios rápidos de desarrollo?

Sí . Casi no necesita lidiar con el diseño de DB. La configuración casi está hecha para usted desde el principio gracias a la Convención sobre configuración. Su aplicación es fácilmente mantenible. El único inconveniente que veo es el desarrollo del front-end que no es tan rico como otras tecnologías (como Rails o ASP)

¿Funciona para aplicaciones de producción del mundo real?

No puedo decirlo porque todavía no fui a mi sitio web en vivo, pero estoy bastante seguro ya que sky.com está utilizando Grails y los sitios atraen un tráfico significativo: alrededor de 7 millones de páginas vistas por día . De nuevo, el rendimiento depende mucho de la arquitectura de la aplicación y de las decisiones de diseño.

¿El plug-in de Eclipse es mejor de lo que era y es adecuado para su propósito?

Ni idea. Estoy usando IntelliJ pero supongo que no es mucho mejor que hace un año según los mensajes quejándose que veo en el reino de Grails.

Espero que ayude.

Personalmente, aprendí RoR y lo usé para algunos proyectos hogareños, pero luego cambié a Grails, principalmente porque se ejecuta en la JVM y, por lo tanto, espero hacer uso de la plétora de programas de rendimiento / perfil Java, que deberían ayudar a identificar cualquier cuellos de botella en el código antes de que se conviertan en un problema.

En general, no he encontrado demasiada diferencia en la calidad de los IDE utilizados por RoR vs Grails. Aunque, para ser justos, estoy programando en Linux y no he probado el desarrollo de TextMate for RoR. Cuando estaba usando RoR, usé Netbeans.

En este momento estoy programando usando STS y estoy descubriendo que es un placer usarlo con Grails, aunque todavía encuentro que la detección / finalización del método podría funcionar mucho mejor.

Quiero señalar dos consideraciones más, uso de memoria y mercado de trabajo. La aplicación Grails requiere mucha memoria, especialmente en modo de desarrollo, por ejemplo, 600 Mb para una aplicación de tamaño medio. Cuando se implementa en modo de producción, por ejemplo, archivo de guerra en Tomcat, el uso puede ser de aproximadamente 500 Mb. Esto se hereda en parte del uso de Java.

En cuanto al mercado de trabajo, y por lo que he leído, hay poca demanda de programadores de Grails en anuncios de vacantes de empleo en comparación con, por ejemplo, Django y Ruby on Rails.

Soy un desarrollador de Java a tiempo completo, pero uso rails para mis proyectos de hobby. Evaluamos los griales para un proyecto en el trabajo un año atrás. Mi experiencia con Grails me dejó un poco decepcionado y esta fue la razón por la que comencé a investigar los rieles. Habiendo usado ambos mi impresión es que a pesar de que Groovy no está muy lejos del rubí como lenguaje, los rieles proporcionan una experiencia significativamente mejorada sobre los griales. Simplemente, los rieles parecen resolver muchos más problemas del mundo real, particularmente cuando se tiene en cuenta la cantidad de gemas buenas que están disponibles. Estoy pensando en cosas como, proporcionar búsqueda, control de versiones, rss, aplicaciones no crud, integración con servicios en la nube, etc. Tengo la impresión de que el valor de los griales es aproximadamente el nivel de los rieles 1.x. A finales de este mes, los rieles 3 deberían haberse liberado. De hecho, hemos decidido avanzar hacia el uso de rieles en el trabajo. Al final, es más fácil elegir Grails para los desarrolladores de Java, pero en última instancia no tiene el refinamiento necesario para cubrir una gama más amplia de requisitos del proyecto.

Sugeriría que lo intentes por ti mismo. Me encanta la flexibilidad de Grails y la velocidad de desarrollo. Sin embargo, como puede ver, la experiencia de otras personas es diferente. Quiero ser capaz de desarrollar aplicaciones rápidas para mis clientes utilizando la plataforma Java y he descubierto que Grails funciona muy bien para nosotros.

También encontré la interfaz muy flexible para desarrollar. También creo que debes usar el sentido común y elegir cuidadosamente tu complemento. Me atengo a los complementos compatibles con springsource.

Todavía tengo que encontrar a alguien que sea experto en Grails and Rails y que prefiera Grails.

Si los conoces bien, es casi seguro que prefieras Rails.

Grails normalmente atrae a los desarrolladores de Java que temen el cambio de plataforma.

En este caso, creo que JRuby es probablemente una mejor manera de adoptar un enfoque ágil sobre el legado antiguo jvm.

Vale mucho la pena. Lo he estado utilizando durante más de un año y me encanta. Solía evitar este tipo de herramientas rad, pero ha cambiado mi forma de trabajar. Con la versión 1.2, ha mejorado aún más con una mejor información de rastreo de pila (particularmente para GSP).

El único problema que he tenido con el escalado ha sido la hibernación y su caché, que realmente no es un problema de grial. Incluso aquellos que no me gustan hibernan en general, la forma en que los griales lo envuelven con GORM es una obra de arte para mí. El aspecto de cierre de criterios es maravilloso para trabajar.

Yo diría que no. Está demasiado hinchado, imho, para la mayoría de los usos, especialmente si solo quieres prototipos de algo. No necesitamos todo ese código, todas esas dependencias empaquetadas con griales para hacer una aplicación web. No necesita la primavera cada vez que desea ejecutar una aplicación web. Mira lo que estás tratando de lograr antes de agregar todo un mundo lleno de dependencias a tu pila. Creo que es importante saber de qué se compone tu aplicación.

Recomiendo mirar algo parecido a una petaca, que es mucho más ligera, casi como sinatra para rubí.

La depuración es realmente difícil. Nunca he encontrado que esto sea un gran problema. Puede adjuntar un depurador y abrir paso, o pegar una carga de println / logs en el código para determinar qué está pasando.

La tala es francamente horrible. Estoy de acuerdo en que los rastros de pila generalmente proporcionan 4 páginas de información inútil, con la línea ocasional que es informativa. Sin embargo, es un pequeño precio a pagar por un marco tan impresionante.

El IDE Eclipse de STS tiene un valor marginal. Eclipse tiene poco apoyo para Grails. Use IntelliJ si es posible. Soy un tacaño, pero si mi empresa me lo permitiera, pagaría con mucho gusto el dinero por IntelliJ.