¿Vale la pena Grails? [cerrado]

Esto es mitad perorata, mitad pregunta.

¿Vale la pena usar Grails? Estoy tratando de desarrollar una aplicación web basada en bases de datos relativamente simple. Mi experiencia está en Java, por lo que, naturalmente, Grails parecía una buena opción. Al principio pensé en usar Spring, JPA e Hibernate, pero lo he usado anteriormente y me he encontrado con todo tipo de tediosos trabajos de configuración y codificación. Grails se anuncia a sí mismo como resolviendo esto.

Mi mayor frustración con Grails son todas las pequeñas cosas que no funcionan. Lo que quiero decir es que no funciona como uno pensaría intuitivamente que debería. Es muy áspero en los bordes. Me encuentro con problemas constantemente. A veces es mi falta de comprensión de Grails, otras veces he descubierto errores legítimos de Grails.

Un problema importante es la falta de una buena integración de Eclipse. Hay un complemento Groovy y Grails, pero no hace mucho más que resaltar la sintaxis. Llamar a Groovy desde Java y viceversa es muy complicado de configurar . No tener un buen soporte IDE es un gran fastidio.

Lo que pasa es que me siento a intentar desarrollar mi aplicación web. Al final del día, me doy cuenta de que he pasado alrededor del 85% del día depurando problemas relacionados con Grails. Si no se trata de problemas de Eclipse, entonces es una carga ansiosa , buscar en la vista , relaciones de uno a muchos , comportamiento extraño de error de archivo vacío , un error extraño de propiedad / captador , simplemente sigue y sigue. Esta es solo una muestra de los problemas que encontré hoy. Mi última reunión con Grails produjo un montón de problemas diferentes.

A veces me pregunto si vale la pena. Tengo curiosidad por saber si otros han experimentado esto. ¿Hay personas que realmente utilicen Grails para desarrollar productivamente una aplicación web? ¿Existen otros marcos para el desarrollo web rápido que debería considerar?

Teníamos un equipo de 12 personas, todos desarrolladores experimentados de Java que aprendieron Grails de 0.6B y todavía estamos trabajando en proyectos basados ​​en Grails. No volvería a Java voluntariamente, y todos estamos aliviados de haber averiguado cómo llegar rápido a algún lugar con una aplicación de Grails.

Fue una lucha, no fue fácil y hubo frustración.

Sin embargo, entregamos algo muy rápidamente dados nuestros esfuerzos continuos. Hay errores, muchos de los cuales tienen soluciones.

He oído hablar de varios casos de desarrolladores que son buenos en Java que intentan sumergirse en encantamientos profundos y complejos de proyectos de Grails. Evitamos todo Java y nos fuimos puros Grails y Groovy. Nos aseguramos de comenzar de manera simple, construir la complejidad de la manera más manejable y práctica posible. No nos atrevimos a sumergirnos en lo más profundo y esperamos que nuestro conocimiento de Java sea suficiente para llevarnos.

Eventualmente habíamos creado algo enorme y complejo que funcionó fabulosamente y lo hizo mucho más rápido que escribir la versión pura de Java / Spring / Hibernate; y eso sin un soporte IDE decente y una situación mucho peor en términos de errores que la actual.

En lo que respecta al soporte de Eclipse, el único IDE real que se puede usar para Grails / Groovy es Intellij; el soporte de Eclipse está muy por detrás, lamentablemente: yo era un amante de Eclipse y estoy lejos de ser un converso de Intellij: el soporte de Grails / Groovy destruye todo lo demás aunque.

Sí, Grails es inmaduro comparado con Spring quizás. O hibernar. Y apostaría a que en los primeros 1,5 años de su existencia estuvieron igualmente plagados de problemas.

Siendo así, la responsabilidad recae sobre usted, para cuidar de mantener la complejidad al mínimo absoluto, para probar cuidadosamente primero (en nuestra opinión) y construir la complejidad gradualmente y con cuidado.

No existe una solución de código rápido con Java una vez que involucra Spring / Hibernate en la pila. La complejidad que encarna Grails es un reflejo de la propia complejidad de Spring / Hibernate. Si sientes que es mejor gastar tu tiempo haciéndolo con Java puro, no diría lo contrario ... Todavía tengo mis WTF, pero ahora que la curva de aprendizaje ha quedado atrás, creo que seguiré con Grails un poco más.

Disfruto mucho escribiendo aplicaciones de Grails por dos razones:

• No tengo que usar java
• Puedo usar java

Creo que después de familiarizarse con los griales, uno hace sus cosas con mucha rapidez y elegancia.

Tanto por el lado positivo. El lado negativo es el rendimiento, que me afecta en dos aspectos: la implementación y el desarrollo basado en pruebas.

No he logrado ejecutar más de 3 aplicaciones de Grails en un solo servidor (alquilado), porque rápidamente llegué a los límites de memoria y rendimiento. Simplemente se incluyen demasiados marcos.

Además, el testrunner de griales no merece ese nombre. Cuando ejecuto pruebas unitarias, deben realizarse en un instante, no en 10 o 20 segundos. Así que me encuentro todo el tiempo escribiendo lógica empresarial en Java simple, porque puedo probarlo mucho más rápido. Pero supongo que esto se puede solucionar con una mejor integración en el IDE (eclipse).

Creo que el apoyo de Spring a Grails será un gran impulso. Si alguien puede moverlo más allá de CRUD en la web, son esos tipos.

También creo que está alcanzando una masa crítica. Hay varios libros nuevos que llegarán al mercado en 2009. Creo que ayudarán a la tasa de adopción.

Estoy totalmente de acuerdo con los sentimientos de los carteles originales.

Somos una tienda Java + Spring y aprovechamos la oportunidad para probar Grails. Primero creamos una aplicación de prueba muy pequeña que resultó ser bastante simple de hacer y funcionó bastante bien. Los principales problemas que tuvimos aquí se debieron a nuestra falta de conocimiento con Groovy y Grails.

Tras este éxito (aumento de la confianza), decidimos intentar un proyecto un poco más grande. Esta ha sido una experiencia mucho más dolorosa. Como han mencionado otros, hemos descubierto todo tipo de errores y problemas que no aparecían de inmediato en la superficie. Los ciclos de reinicio de la aplicación se vuelven extremadamente dolorosos y, a menos que tenga una cobertura de prueba realmente buena, es una pesadilla hacer cualquier tipo de refactorización.

¡Realmente frustrante es que el código falle sin un solo mensaje de error! ¿Simplemente no funciona y no sabes por qué?

Me gusta la facilidad de uso de los complementos para JMS, Quartz y Remoting, por nombrar algunos. Elimina una gran cantidad de XML tedioso.

Casi me gusta GORM por su simplicidad, aunque también hemos tenido varios problemas.

No me gusta la naturaleza poco estricta de Groovy y el hecho de que tienes que ejecutar tu aplicación solo para poder detectar un montón de errores, me recuerda demasiado a PHP o Rails.

Al final del día, nos preguntamos si es posible escribir una pieza compleja de software manejable usando Grails ...

Tenemos una aplicación de Grails a punto de entrar en producción ... así que veremos.

Estamos usando grails + en la capa web + java con hibernate y spring en la capa de servicio. Son las tres capas clásicas (web, lógica, datos) donde la web es grial y la lógica se implementa en java. Como es habitual en Java, utilizamos objetos bean que representan los datos entre diferentes capas.

Funciona bastante bien y fue la mejor solución para nuestro caso, ya que los objetos bean ya estaban allí, así como la estructura de la base de datos. Según nuestra experiencia, creo que grails tiene un gran valor como capa de presentación web, pero me quedaría con java para escribir las reglas de negocio y conservar los datos de la aplicación, ya que grails "es" java, toda la integración grails-java es bastante sencillo.

Usamos eclipse para desarrollar la aplicación de Grails y su integración es deficiente, como dice la gente aquí. Pero, como una sugerencia de otro desarrollador, ejecutamos la aplicación Grails desde la línea de comandos y solo usamos eclipse para guardar los archivos fuente, y funciona bastante bien, ya que la aplicación se actualiza sobre la marcha.

Todavía no me siento cómodo usando griales en otros lugares que no sean la capa de presentación.

Tengo mucha más experiencia con Ruby on Rails que con cualquier cosa en el mundo de Java, así que vengo desde una perspectiva diferente. En general, Grails es mucho más tosco que Rails, en parte debido a su inmadurez y en parte porque se basa en dos marcos increíblemente complejos bajo las sábanas (Spring e Hibernate). Rails también tiene una comunidad mucho más grande.

Sin embargo, Groovy como idioma ha hecho grandes avances y es un placer trabajar con él. Gracias a las mejoras realizadas en Groovy 1.6, Grails es un poco más ágil que JRuby on Rails, y obtienes un soporte XML sorprendentemente bueno a través de GPath. Hay muchas características agradables que obtienes al estar en la JVM (como concurrencia y toneladas de código seguro para subprocesos), pero sin tener que perder el tiempo con Java (un lenguaje que no me importa mucho), así que estoy teniendo un Fue difícil convencerme a mí mismo de usar algo en la resonancia magnética.

Sin embargo, debo admitir que Python parece tentador.

En cuanto a tus problemas con Eclipse, no puedo ayudarte. Utilizo Vim y Emacs, principalmente porque no soporto el uso de IDE. Sin embargo, para lenguajes dinámicos como Groovy, Ruby y Python, no creo que los IDE realmente presenten ningún beneficio real, ya que no hay lugar para la generación de código o la necesidad de compilar. Tal vez intente trabajar sin IDE por un tiempo y vea si las cosas son más suaves.

Entonces, sí, creo que Grails vale la pena. Han hecho un gran trabajo al hacer que las cosas funcionen tan rápido como lo han hecho, y los equipos de Grails y Groovy están muy, muy dedicados.

¡Estoy totalmente contigo! Grails todavía se siente tan áspero en los bordes que es casi una broma compararlo con Rails. Si al menos el informe de errores fue un poco mejor. Pero supongo que probablemente también se deba a la gran cantidad de bibliotecas que usa debajo de las cubiertas. Una palabra: stacktrace! Tampoco soy un gran admirador del enfoque modelo-> db (Rails tiene db-> modelo). El andamio también deja mucho margen para mejoras. Entonces "no es necesario reiniciar" tampoco funciona como se anuncia. (No estoy seguro de qué es peor: tener que reiniciar todo el tiempo o, a veces, encontrar comportamientos extraños que desaparecen cuando reinicias) Y no me hagas comenzar con GORM. (Cuando se necesitan horas para encontrar una forma de lo que hubiera sido un SQL simple, comienza a preguntarse si todo este ORM realmente le ahorra tiempo). Tal vez siempre y cuando sea simple.

Quiero decir: sigue siendo una de las mejores opciones de un marco cuando vienes del mundo de Java. (Tanta basura inútil que se llama a sí misma un marco web) ... tiene potencial. Solo desearía que no se hubiera construido sobre tantas otras cosas complejas.

De todos modos, esperemos que estas cosas se solucionen. En este momento estoy al acecho en playframework.org, que también se ve muy elegante y prometedor.

Valdrá la pena cuando terminen el complemento de eclipse. Cuanto antes, mejor digo. Tratar de venderle cosas geniales a mi jefe no será sencillo hasta que eso suceda.

Encuentro que la mayor ventaja de Grails es que ya no tengo que preocuparme por la base de datos: el esquema se crea / actualiza automáticamente y la persistencia se realiza en gran medida por mí (no más escribir consultas SQL). Es un gran alivio. La otra cosa que es bastante buena es que una vez que se ha decidido por las plantillas para controladores y vistas, agregar nuevos objetos de dominio es bastante rápido. Aunque sospecho que al menos hará cambios continuos en sus vistas, ajustándolas a las existentes.

En cuanto al IDE, parece que IntelliJ es la mejor opción, pero estoy contento con Netbeans 6.5. Utilizo MyEclipse para todos los demás desarrollos, pero Netbeans ahora tiene un mejor soporte de Grails.

Era un usuario de Eclipse antes de comenzar a usar Grails. Rápidamente se hizo evidente que eso no iba a ser suficiente. Entonces probé Intellij y NetBeans. En ese momento, Intellij era mejor en lo que respecta a Groovy y Grails. Sin embargo, NetBeans era gratis y eso lo hizo lo suficientemente bueno para mí. Desde entonces, los tres han tenido nuevas versiones o nuevos complementos lanzados. Todavía estoy usando NetBeans debido al costo de Intellij. Con la adquisición de G2One por Spring Source, una de las expectativas es un mayor apoyo para Groovy y Grails en Eclipse. Esto será necesario para una mayor adopción.

Usar Grails para un nuevo proyecto es maravilloso. Gran parte del bagaje de Enterprise Java ya no es necesario. Me imagino que intentar portar algo sería difícil porque hasta que comprenda dónde están las fortalezas y debilidades de un marco, es difícil utilizarlo de manera eficiente. Se promete que el soporte JSP será más fácil en Grails 1.1, no sé si usar una versión beta mientras trato de asimilar un nuevo marco es una buena idea. Las pruebas también han pasado por una revisión importante para la nueva versión. Si el tiempo lo permite, puede considerar esperar, ya que la versión 1.1 debería ser muy pronto.

Si tienes la oportunidad de probar Grails en un IDE diferente al comenzar un proyecto desde cero, creo que lo verás de otra manera.

Acabo de comenzar a usar Grails en un nuevo proyecto ... no tener que escribir NINGÚN archivo xml y aún tener el poder de Spring e Hibernate es realmente sorprendente.

Sin embargo, use IntellijIDEA para el IDE, de hecho descubrí Grails a través del IDE (aunque podría estar sesgado, odio el eclipse).

Totalmente. Hay tantos frameworks de Java que el listón está bastante alto para los recién llegados, y es un testimonio de Grails que pudo superar en un espacio tan abarrotado.

Todavía tiene algunos bordes afilados, pero es solo cuestión de tiempo antes de que se enreden, el proyecto subyacente vale MUY mucho la pena.

Grails puede ser demasiado grande para su tipo de aplicación (según los numerosos archivos que creó en la primera inicialización y los recursos que necesita). Si está buscando algo simple, es posible que Grails no sea lo que está buscando. Si está buscando algo simple y que funcione, hasta ahora creo que django puede hacer bien su trabajo. Eche un vistazo a lo simple (cuántos archivos requiere) para crear una aplicación CRUD desde su tutorial . Desde aquí, sus aplicaciones se pueden escalar (relativamente) fácilmente a medida que crecen sus necesidades y requisitos.

No estoy seguro de que alguna vez puedan hacer que Grails esté bien, ¿sabes? Y por derecho me refiero a abordar todos los detalles (pequeños y grandes) que al final lo hacen sentir quebradizo y frágil. Ni siquiera estoy seguro de que haya un equipo de desarrollo real (es decir, más de 2 personas) detrás.

Cada vez que repito una característica de mis proyectos de Grails, tratando de mejorar algo, es el mismo flujo de trabajo: todo se desmorona, luego son cien ciclos de prueba de 'google', luego descubres la razón por la que no puedes hacer lo que quieres y haces otra cosa.

Al final, estás frustrado porque ni siquiera quieres tocar nada que corra. ¡Y las cosas que no van bien, las dejas caer!

Estoy considerando un cambio a Rails a través de JRuby. Eso puede ser lo mejor de ambos mundos: un marco web capaz con una comunidad activa y grande, un equipo dedicado de desarrolladores, una plataforma que no se basa en marcos cuestionables y complejos como Spring o Hibernate, un ciclo de lanzamiento rápido y ambicioso. Y JRuby porque, francamente, hay tantos activos de Java en mi mochila, no puedo simplemente tirarlos.

Si tu experiencia está en Java como dices. Debería echar un vistazo a Play Framework , es un marco web inspirado en Ruby on Rails con un ciclo de desarrollo muy corto, simplemente guarde su archivo fuente Java y actualice su navegador web. Y si desea probar otro idioma, Play Framework tiene un módulo que le permite usar Scala en su lugar.

Me gusta Play Framework porque es fácil de entender y tiene un buen rendimiento. También puede usar JPA e Hibernate para la capa ORM si lo desea.