Las cinco cosas que menos me gustan de Grails

Hace unos días comentaba las cinco cosas que más me gustaban de Grails y avisaba de que habría un post de continuación con las cinco cosas que menos me gustaban. Pues aquí está ese post. Creo que coincidí bastante con otros en las cosas que me gustaban (salvo GORM) pero me imagino que no coincidiré tanto en las que no me gustan. Es más difícil coincidir en lo que no te gusta, en parte porque quizás esté equivocado en algunas cosas y existan soluciones. Lo mejor de esto último es que espero comentarios que me hagan ver la luz :) Pero bueno, al grano:

• La falta de herramientas serias para soportar el trabajo de creación de aplicaciones: Esto es de largo lo que menos me gusta, y sinceramente una de las razones por las que quizás no volviese a empezar un proyecto con Grails. Porque seamos sinceros, Grails apenas tiene soporte de herramientas serias para desarrollo.
  
  Es cierto que existe la posibilidad de instalar un plugin para Eclipse, y soporte nativo en IDEA y en NetBeans. Pero la cruda realidad es que hoy por hoy estas herramientas no son más que un conjunto de scripts para ejecutar los comandos de grails, más reglas de coloreado, síntaxis, autocompletado y todas estas cosas. Poco más.
  
  Quizás aquí la frustración venga a raiz de usar Eclipse. También lo intenté con IDEA pero la verdad es que es bastante frustrante ver como comienzas a utilizar una tecnología y ves que desde hace casi un año apenas ha habido progresos en cuanto a herramientas de soporte. Uno se esperaría algo más de atención hacia esos aspectos. Aquí no se trata ya de trivialidades como coloreado o autocompletado, sino de hacer fáciles las cosas que son realmente más complicadas como son la integración con Java, la integración con builds existentes, el facilitar la depuración de aplicaciones tanto local como remota, el facilitar integración con JUnit y/o Spring o la ejecución de tests unitarios y de integración en el IDE, el detectar errores difíciles (ver último punto) de encontrar o el ofrecer refactorizaciones. Y en todo esto, Grails (aunque me atrevería a añadir "y compañía") hace agua.



• La obsesión por "pluginizar" y "grailsificar" Java: Grails está lleno de plug-ins. A fecha de escribir este post hay más de 100 plug-ins diferentes. Los hay de todos los tipos y colores: testing, gráficas, scheduling, búsquedas, etc. Todos estos plug-ins básicamente le dan a librerías existentes en Java un aspecto mucho más 'grails-friendly'. A parte de estos plug-ins, si echamos un vistazo al roadmap de Grails podemos ver que prácticamente todo el esfuerzo planeado se centra en acercar tecnologías ya existentes en Java a Grails, como por ejemplo el soporte de JCR, de JPA, de Portlets, JSP tags, etc.
  
  En todo esto, según mi opinión, hay una contradicción bastante importante. Veamos, el principal punto a favor y argumento utilizado desde siempre a favor de Grails frente a otras alternativas es que nos permite utilizar Java, se integra bien con Spring y Hibernate, y podemos reusar lo que ya hemos creado estos años atrás. Pues bien, partiendo de estas premisas y teniendo en cuenta que la mayor parte de las tecnologías ya se integran con Spring. ¿Por qué no investir en mejorar la integración Java/Grails y Java/Spring en lugar de perder el tiempo reinventando la rueda en forma de plugin o sopporte nativo en Grails?
  
  Por poneros un ejemplo, ¿de qué me sirve un plug-in de Quartz que no funciona bien y que tiene muchos conflictos con el modo en que Grails gestiona las sesiones de Hibernate si símplemente ya lo tengo y lo puedo utilizar desde Spring? Me contesto: me sirve de nada, para perder tiempo en bugs y más bugs de 'grailsificación' de la librería. Lo mismo pasa con por ejemplo Searchable, que a algunos les funciona y a algunos no (como nos pasó a nosotros), pero que sería mucho más fácil simplemente aprovechar Spring y su integración con Compass.
  
  Y ese es el gran problema. La mayoría de plug-ins que hay en el repositorio o bien funcionan para unos casos concretos o triviales, o bien se han quedado obsoletos y nadie los mantiene, o bien tienen conflictos con proyectos híbridos (java+groovy). Los menos, es decir los tres o cuatro más usados (como JSecurity, Searchable, ...), sí que van evolucionando y mejorando, pero al mismo tiempo van apareciendo plugins como Background Thread que nacen para solucionar problemas de otros plugins. El plug-in del plug-in :) Sea como sea, todos estos plug-ins comparten una característica: ya estaban implementados en Spring y funcionaban perfectamente.
  
  Yo aprecio realmente el esfuerzo de toda esta gente. Pero en mi opinión es una estrategia insostenible, y sería muchísimo más razonable el mejorar la integración con Spring y Hibernate y el centrar sus esfuerzos en la parte del cliente. Yo mantendría los plugins, pero sólo los relacionados con la parte del interfaz+controladores (como GrailsUI que sí es realmente útil) y me centraría mucho más en dicha parte y en facilitar la creación de RIAs. Eso sí que realmente iba a mover Grails hacia adelante.



• Los servicios: Al hilo del punto anterior, no le acabo de coger demasiado el punto a los Services en Grails. Nuestra aplicación Grails empezó con pocos servicios, que fueron aumentando a unos 10 o 15, y ahora se han vuelto otra vez 3 o 4. ¿A dónde se han ido? Pues de vuelta a Java. Los hemos tenido que migrar debido a las razones expuestas en los puntos anteriores, y sinceramente ahora al menos yo me siento muchísimo más productivo ya que no hay más bugs debidos a la integración con Grails y podemos usar nuestros IDEs productivamente. Personalmente creo que a fecha de hoy en cuanto a Grails, y en el caso de los servicios, es mucho más simple hacer el backend en Java, ya que hoy por hoy todo está prácticamente hecho y el soporte de los IDEs es sobresaliente y hay montones de herramientas y frameworks que reutilizar. ¿Hacer el backend en grails utilizando plug-ins en estado más que dudoso? No, gracias.
  



• El sistema de build y su falta de integración con Maven: Grails se construye con scripts escritos con Gant, que es como Ant pero para Groovy. A fecha de hoy la integración con Maven es prácticamente inexistente (aunque sí que hay un plugin para ejecutar tareas de grails desde Maven), y eso convierte en algo bastante engorroso el modularizar tu proyecto aprovechando todas las ventajas que Maven ofrece para esto. Para mi (y esto es una opinión muy personal), utilizar Ant, y por consiguiente Gant, es un atraso importante.
  
  Aunque eso sí, parece que hay buenas noticias en este frente, ya que justamente la semana pasada publicaban en la lista de Grails algunos avances respecto a "Mavenizar" Grails, y la verdad es que tiene mucha mejor pinta que lo que tenemos ahora. Han creado un nuevo arquetipo para crear aplicaciones Grails, lo que supongo que significará que podemos importar dependencias desde nuestro proyecto Grails, o utilizar nuestro proyecto como dependencias lo que ayudaría muchísimo en cuanto a la modularización e integración con otros proyectos.



• Todas esas cosas que no están escritas y que al final te acabas encontrando: Esto más que un problema exclusivo de Grails, es más un problema de cualquier tecnología nueva. Grails, como framework novedoso, está lleno de cosillas y particularidades (y sólo hay que echarle un vistazo a la lista de correo para darse cuenta) que te pueden dejar atascado durante un buen rato. A esto también contribuye que el lenguaje sea dinámico y que ofrezca ciertos "adelantos" para incrementar la productividad lo que inevitablemente establece determinadas restricciones en como se hacen ciertas cosas.
  
  Por poner un ejemplo, uno de los problemas con los que me encontré un día es que tenía una excepción rarísima al desplegar la aplicación, y en realidad no había hecho apenas ningún cambio. Lo poco que había cambiado era realmente inocente. ¿O no es inocente el añadir un atributo llamado lastUpdated a tu clase Java e intentar persistir eso en Hibernate con su correspondiente columnilla en base de datos? Pues sí, seguramente es muy inocente, pero en Grails no se puede porque dateCreated y lastUpdated son dos propiedades que se utilizan para hacer automatic timestamping. Este es el típico ejemplo de problemilla que te puede dejar atascado unas cuantas horas, o días, intentando descubrir que diablos pasa. Pero, no todo es malo, por suerte la lista de correo es muy activa, y es fácil recibir respuestas bastante rápidas.
  
  Otro ejemplo más. Las aplicaciones de Grails se pueden desplegar en ficheros .WAR que más tarde se pueden soltar en cualquier servidor de aplicaciones, como por ejemplo Tomcat. Al mismo tiempo, las vistas en aplicaciones Grails se crean mediante ficheros .GSP que son como ficheros .JSP pero en Grails. Lo natural para un desarrollador Java sería pensar que una vez desplegada tu apliación en Tomcat podrás editar tranquilamente los ficheros .GSP en tiempo real y ver los cambios sin reiniciar el servidor. Pues.... NO. Sorpresa, sorpresa. Por defecto no funciona así, y a no ser que reinicies el servidor no verás tus cambios actualizados, algo que nuevamente te tendrá ocupado un buen rato imaginando que puede estar pasando.
  
  Por cierto, que existe la posibilidad de habilitar la recarga de clases en tiempo real, pero curiosamente no la recomiendan demasiado porque degrada el rendimiento. Parece que la gente comenta en la lista de correo que esta degradación de rendimiento no es realmente demasiado terrible, pero a mi todo esto me suena un poco a letra pequeña, especialmente cuando es algo que no se comenta en la documentación. Claro, porque a fin de cuentas, ¿a quién le va a interesar eso de que se puedan modificar las clases sin reiniciar el servidor? Si total, todo el mundo puede reiniciar el servidor...

Bueno y estas serían las cinco cosas que más me molestan. La verdad es que, aunque no todo es malo, lo cierto es que me parecen problemas importantes. ¿Me arrepiento de haber utilizado Grails? No, porque es un concepto diferente que está muy bien para aprender nuevas formas de hacer aplicaciones. ¿Lo utilizaría de nuevo? Depende de la aplicación. Sigo creyendo que es muy productivo para un determinado tipo de aplicaciones, para prototipado rápido, y realmente muy bueno si nos centramos en vista+controlador. Pero lo cierto es que después de haber trabajado bastante con el, se me antoja como un framework algo limitado para proyectos más importantes que necesiten de todo los puntos que he comentado arriba.

¿Opiniones?