Pregunta Grails vs Roo: ¿por qué SpringSource está impulsando dos tecnologías muy similares?


SpringSource (ahora VMWare) tiene dos tecnologías muy similares: Grails y Spring Roo. He estado utilizando Grails, pero veo que SpringSource está trabajando activamente en algo que compite por esa tecnología y eso me preocupa por el futuro de Grails.

¿Alguien sabe cómo se relacionan estas tecnologías, se fusionarán o una de ellas será abandonada?

Además, ¿hay diferencias técnicas importantes entre Grails y Roo?


74
2018-01-05 07:56


origen


Respuestas:


SpringSourceEl objetivo es hacer lo más rápido y fácil posible para que las personas construyan, ejecuten y administren soluciones basadas en Spring. Tenemos ambos Grails y Spring Roo porque nos preocupamos profundamente por la productividad de los desarrolladores e, indudablemente, ambas de estas herramientas ofrecen un gran impulso a lo que los equipos pueden lograr durante la primavera.

Tenemos ambas tecnologías porque Roo y Grails son muy diferentes a nivel filosófico y de implementación (como ya se señaló en las otras respuestas). Cada tecnología aborda su lenguaje principal (Java o Groovy) y el modelo operativo (tiempo de desarrollo o tiempo de ejecución) con la filosofía de "¿cómo hacemos que la propuesta de valor sea increíblemente buena usando este lenguaje y la combinación de modelo operativo?". Como tal, verá que cada tecnología adopta un estilo diferente que maximiza esa combinación (Java + Dev-time de Roo o Groovy + Runtime de Grail) y los beneficios acordes.

Estas diferencias son realmente muy positivas, porque significan que la comunidad Spring puede elegir qué "sabor" de la solución de productividad prefieren. Si bien estas diferencias iniciales sobre la elección de idioma y el funcionamiento / tiempo de desarrollo son evidentes, la elección de Grails o Roo también se extiende a consideraciones más sutiles como las tecnologías predeterminadas utilizadas, modelo de interacción del usuario, soporte IDE, dependencias, estándares, hoja de ruta, extensiones, etc. Casi todas estas diferencias son una consecuencia natural de buscar la mejor solución para un estilo de lenguaje en particular.

Nuestro mejor consejo es considerar ambas soluciones. Cada uno tiene sus puntos positivos, pero existen diferencias entre los dos que harán que su experiencia general sea mejor con una tecnología u otra en un contexto determinado. Ambas guías de referencia detallan el beneficios respectivos de cada solución. Por supuesto, recuerde que la inversión de tiempo es mínima para probar ambos. En 10 minutos puede construir un proyecto en Roo o Grails, así que pruébelo y vea qué se siente más natural para usted dado sus antecedentes específicos y las necesidades del proyecto.


88
2018-01-08 21:22



La principal diferencia es que Roo es un marco puro de Java, mientras que Grails aprovecha tanto Groovy como Java. Ambos se basan en las bibliotecas principales de Spring y hacen uso de las populares bibliotecas de código abierto de Java.

Esta pregunta se formuló cuando se anunció Roo y Graeme Rocher (líder de Grails) dice que ambos marcos tienen un lugar en Spring y son compatibles por igual.

En todo caso, creo que Grails tiene un futuro mejor que Roo. Me encanta desarrollar con él y no veo ninguna desventaja de que no sea Java puro.


22
2018-01-05 10:04



Grails y Roo son muy diferentes. La primera gran diferencia es el lenguaje utilizado. Si bien puedes escribir código Groovy como el código Java tradicional, aún necesitas las dependencias Groovy para ejecutar aplicaciones Grails. Para ser lo más productivo posible en Grails también tiene que tener una comprensión de las características de Groovy que no son actualmente parte de Java tales como cierres. Otra diferencia es la filosofía que los marcos toman para generar código. Grails genera muchos métodos en tiempo de ejecución mientras Roo los genera a petición durante el proceso de desarrollo. Roo no tiene detrás de las escenas la aceptación mágica para el uso de la programación orientada a aspectos, y usted puede ver todo el código que genera Roo. Por ejemplo, en Roo debe utilizar un comando para que se genere métodos de búsqueda dinámicos como findByBook () y luego ver el código generado en los archivos .aj. En Grails, el método findByBook () se crea en tiempo de ejecución y no se puede ver el código generado. Roo también le permite dejar de utilizar el marco, si opta sin dejar de tener una aplicación que se ejecuta mediante la fusión de todo el código generado en los archivos .java normales. Entonces no tiene dependencias en ninguna biblioteca Roo ni en tiempo de ejecución ni en tiempo de diseño. Si decides que no te gusta Grails, no hay forma de que dejes de utilizar el framework mientras sigas teniendo una aplicación en funcionamiento.


19
2018-01-05 13:20



IMO los dos no son muy similares. Aunque hay similitudes, las siguientes son diferencias significativas:

  • Roo usa "Stock-Standard Java", Grails se basa en Groovy
  • Grails es un framework web, Roo no es

Roo es muy similar al sistema de línea de comandos de Grails (por ejemplo, create-app, create-domain-class, test-app escriba comandos encontrados en Grails). No me sorprendería ver algo de "polinización cruzada" entre esta parte del framework de Grails y Roo.


9
2018-01-05 10:06



Ben Alex de SpringSource habla sobre Roo en esta entrevista y le preguntan sobre Grails vs Roo. La principal diferencia, además de utilizar diferentes idiomas (Groovy vs Java como han mencionado otros) es que Roo es principalmente una herramienta de tiempo de desarrollo y Grails está más involucrado en tiempo de ejecución.


4
2018-01-05 10:12



En realidad no son tan similares. Roo lo hace mágico en el tiempo de compilación, donde Grails lo hace en tiempo de ejecución. Debido a que los proyectos de Roo no reciben ningún impacto de rendimiento en el tiempo de ejecución.

No veo cómo podrían fusionarse, ya que Grails se basa en Groovy y Roo en Java.


1
2018-01-05 11:59



¡Vi algunos comentarios en las listas de correo de Grails que indicaban que los autores creían que Roo existe solo como un trampolín para Grails! Sin embargo, personalmente estoy considerando un posible cambio de Grails a Roo. Creo que la principal diferencia es entre los lenguajes dinámicos y los tipados estáticos, para mí esto es enorme. Me encantan muchas funciones de Grails, pero prefiero la compatibilidad con IDE y la verificación en tiempo de compilación de un lenguaje estáticamente tipado. Algunos otros sienten exactamente lo contrario, por lo tanto caballos para los cursos. Dicho esto, el groovy estático actualmente se encuentra en gran desarrollo, así que quién sabe lo que depara el futuro.


1
2018-02-11 13:12



Teníamos un requisito en el que teníamos una aplicación en producción y se desarrolló en Spring MVC y la velocidad de desarrollo de nuevas funciones fue lenta. Tuvimos que explorar marcos alternativos como Grails y Roo. Personalmente, pasé cerca de un mes explorando cuál era mejor.

Si desea ver los detalles del análisis, visite @ http://krishnasblog.com/2012/05/08/roo-vs-grails/ 

Exploramos las siguientes características en ambos y nuestros hallazgos a continuación. El veredicto final no estamos seguros de que usemos ninguno, todavía estamos explorando


0
2018-04-18 10:34