Grails or Play! para un ex desarrollador RoR?

Question

Planeo comenzar a aprender un framework web Java (me encanta la API de Java) Ya he usado Rails y Django.

Quiero algo cerca de Java pero sin toda la complejidad de J2EE.

que he encontrado 2 marcos que podría ser bueno para mí:

Grails

Griales ve muy bien, se utiliza maravilloso que es mejor que Java para aplicaciones web (creo ..), pero es más lento que los frameworks basados ​​en Java puro (Hibernate, Strut, Spring) Parece bastante simple de implementar (enviar .war y está bien!), ¡el GSP es genial! Es un poco más difícil de depurar (necesita reiniciar el servidor en cada modificación y stacktraces contiene una mezcla de trazas Java y Groovy que no siempre es la más fácil de entender)

Play!

Este marco también se ve genial; es más rápido que Grails (usa Java) pero realmente no me gusta cómo usa Java, modifica el código fuente para transformar las llamadas a propiedades como setXXX/getXXX, no me gusta eso ... El framework también tiene un caché función que Grails no tiene. Realmente no me gusta el motor de plantillas. También es más sencillo depurar (no es necesario reiniciar el servidor, las trazas de pila son más claras)

¿Qué recomienda? Estoy buscando algo fácil de aprender (tengo mucha experiencia Ruby, no tanto experiencia en Java pero me encanta la API Java), con todas las funciones (Eso no es un problema con toda la Biblioteca Java disponible, pero si es un paquete y integrado prefiero), tiene buena escalabilidad y no es demasiado lento (más rápido que Ruby) Idealmente, me gustaría utilizar un marco con una comunidad decente para encontrar soporte fácilmente.

PS: No estoy interesado en JRuby on Rails

Answer 1

Sugeriría Grails. Tiene una comunidad más grande que el marco de juego (~ 350 complementos que cubren casi todas las necesidades básicas). Además, Grails está escrito casi por completo en Java, simplemente te permite usar Groovy para la implementación específica de tu dominio.

Si se encuentra con un problema de rendimiento donde las páginas geniales que ha creado son el cuello de botella, siempre puede cambiar a una implementación de Java. Entonces estás en el mismo barco que hubieras estado con el framework Play todo el tiempo. Ha optimizado su tiempo de desarrollo al posponer la codificación de las cosas en Java hasta que sepa que realmente necesita hacerlo (lo que, en mi experiencia, es muy raro).

Tampoco estoy seguro de dónde escuchó que necesita reiniciar su servidor para cada modificación, pero eso no es cierto en realidad. Grails admite la recarga de controladores/gsps/services/domain objects, etc. sin reiniciar el servidor.

Las stacktraces mixtas pueden ser un poco largas, pero los proveedores de herramientas (como Intellij) han realizado algunas mejoras recientes que eliminan todas las porciones de stacktrace que no te importan.

He estado usando grails desde los .5 días y he estado muy contento con la plataforma.

Answer 2

También hay Lift en Scala.
Imho scala es el mejor lenguaje de tipado estático y el ascensor es un marco bastante agradable (para un lenguaje tipado estático).

Answer 3

Si ha usado Ruby y Python anteriormente, probablemente disfrutará de Grails mejor que Play. Es muy difícil volver a Java una vez que estás acostumbrado a estos lenguajes dinámicos.

Answer 4

tomar en cuenta que la Play! framework now supports using Scala como de 1,1

Answer 5

he pasado de Grails para jugar y nunca miraron hacia atrás. Mi mayor problema con Grails fue la solidez general y la usabilidad del desarrollador. La mayoría de las veces me pica el hecho de que Grails pega la pila habitual de Spring MVC e Hibernate mientras trata de ocultar este hecho y de darte una API de Rails (opinión personal mía). El problema con esto es que, una vez que algo va más allá de las muestras triviales, se rompió fácilmente y no funcionó para mí. Desarrollarlo fue como caminar sobre los huevos (para mí). Cada vez que busqué en Google la documentación de una función que necesitaba, no me redireccionaban a muestras, tutoriales, blogs, sino a Grails JIRA, que me explicaba por qué la función no funcionaría para mi caso de uso y que el error no se resolvió desde dos versiones antes del Estaba usando

Si bien esa no es la experiencia general de cada desarrollador (no estoy escribiendo esto para criticar a Grails, sino para compartir mis experiencias aquí), necesitaba algo que me ayudara y no se interpusiera en mi camino o rompiera sobre mí cuando más lo necesitaba. Eso es cuando encontré Play y rápidamente migré mi aplicación a ella después de que me enteré (alrededor de la versión ~ 1.0).

Hasta ahora ha sido un gran viaje y por primera vez en mi carrera de desarrollo web, he dejado de buscar en otros marcos tratando de encontrar algo que me gustaría tener.

Si tuviera que cerrar con una cosa que Play funcionó mejor que Grails, al menos para mí, sería el hecho de que la Play está construida desde cero con la usabilidad del desarrollador en mente. No sacrifica la facilidad de uso para las palabras de moda de la empresa. Tiene las agallas para tirar lo que no encaja en este paradigma (por ejemplo, abandonar los tiempos de ejecución basados ​​en servlets durante el desarrollo para un cambio más rápido). Está dispuesto a hacer concesiones para garantizar asombro. Y eso es algo que solo he visto en comunidades como Rails o Django antes de encontrar Play.

Answer 6

Según mi experiencia con Play, es un gran marco. Mis características favoritas son el sistema de control genial y el sistema de plantillas, ambos son simples pero ricos en funciones y potentes.

Sin embargo, la ventaja más importante de Play es sin duda el ciclo de rápido desarrollo, en el que prácticamente no se necesita volver a cargar los cambios de código. Pero si no tienes cuidado, esta grandeza no durará mucho, y la lentitud eventualmente se infiltrará en tu código.

¿Por qué es eso? Con Play hay un uso común de algunos complementos con una inicialización bastante pesada, notablemente EJB (Hibernate) y Spring. La inicialización de estos complementos se vuelve a ejecutar en cada cambio de código antes de que se cargue el nuevo código. Como resultado de esto, a medida que su modelo y la configuración de su sistema crecen, esta pesada inicialización comienza a ralentizar seriamente su desarrollo. En el sistema que utilicé, 20 segundos fueron un tiempo de inicio típico en una máquina virtual que se ejecuta en una computadora portátil kickass.

Lo que puede hacer para evitar esto depende de su aplicación, p. si está construyendo una aplicación NoSQL, entonces el complemento EJB no debería darle problemas. Spring se puede reemplazar con un plugin de Java codificado personalizado, que en mi humilde opinión también es más fácil de mantener, o ejecutar un script de Groovy si la capacidad de guionización es tan importante. En cualquier caso, tenga cuidado con estos problemas y elimínelos mientras es joven, y asegúrese de no ejecutar sus propias inicializaciones voluminosas en cada actualización.