GWT, bendita monstruosidad avernal

La esperanza es el peor de los males, pues prolonga el tormento del hombre

F. Nietzsche

GWT, bendita monstruosidad avernal

26 de December del 2011 Implementación

Siempre he odiado involucrarme en la capa de vista de una aplicación por las deficiencias de sus lenguajes y la falta de opciones. HTML, JSP, JavaScript, CSS son las monturas de los jinetes del apocalipsis. Desde mi más tierna edad profesional me preguntaba…

Por qué no utilizar Java para la capa de vista?

Bendita solución.

GWT nació en 2006 de la necesidad de Google en proporcionar a sus usuarios interfaces ricas, claras, ligeras, intuitivas y sobre todo dinámicas. Dado que ninguna herramienta externa o lenguaje cubría sus necesidades, decidieron desarrollar su propia solución, que posteriormente convirtieron en código abierto, generando JavaScript a partir de código Java y solucionando problemas comunes como la internacionalización, la comunicación asíncrona, el histórico de navegación y la compatibilidad entre navegadores.

Y lo consiguieron, los resultados desde el punto de vista de usuario son muy buenos y el desarrollador se abstrae completamente de AJAX y JavaScript.

Monstruo avernal.

Sin embargo GWT no se imponía en el mercado, no se convertía en estándar, el número de proyectos y profesionales GWT no despegaba e incluso recientemente ha empezado a decaer.

¿Por qué? Yo no entendía la razón… hasta que he tenido que involucrarme profesionalmente. Quizás las lagunas que le encuentro a estas versiones de GWT sean debidas a mi desconocimiento de la propia tecnología y a mi escasa experiencia de un par de meses, lo que en el mejor de los casos sitúa a GWT como una tecnología con una curva de aprendizaje poco suave debida a su buena pero escasa documentación oficial, su gran número de rígidas convenciones (no documentadas) y sobre todo al enfoque erróneo en sus orígenes de aspirar a gestionar el proyecto en lugar de ser una simple herramienta más que se utiliza únicamente en la vista y en el controlador para las llamadas asíncronas.

Colaboración, intercambio y estandarizar: se debió crear una fundación sin ánimo de lucro y dotarla de fondos o colaborar con las existentes, para encontrar una solución común para resolver un problema común ajeno a sus negocios. Sin embargo Google buscó una ventaja competitiva sobre su competencia haciendo algo que no pertenece a su core de negocio, pan para hoy…

Las versiones v01.xx son muy “noventeras” : rígidas (pensadas para las necesidades de Google), implementa supuestamente el patrón MVP (a mí me parece una arquitectura de dos capas cliente-servidor), mini-manuales, sota caballo y rey, tu proyecto pasa a ser un proyecto GWT, el desarrollo será rápido pero cogido con chinchetas (si funciona no toques, por qué tocas?), el mantenimiento será infernal y las migraciones eternas. Salvando las distancias, recuerdan a Alfresco.

Las versiones v02.xx han mejorado enormemente : existe un plugin de Google para Eclipse, un plugin para Maven con el que colaboran Codehaus, Sonatype y Google, se creó GIN (Gwt Injection) para inyectar dependencias, es más flexibilidad, existe más documentación.

Sin embargo aún debe avanzar hacia una hipotética versión v03.xx más simple, más documentada, con menos convenciones para reconvertirlas en configuraciones, una simple herramienta del proyecto en lugar de ser el centro del proyecto, lo que facilitaría su integración para gestionar la Vista con otras herramientas MVC como Struts, Spring MVC o las que aparezcan en un futuro.

Ángel o demonio?

Depende de cómo lo utilices.

Si te estás planteando utilizar GWT para tu nuevo desarrollo, o migrar tu actual proyecto a GWT, no creo que sea una mala idea, pero antes de hacer nada profundiza, aprende, practica con una pequeña kata y sé consciente del riesgo que estás introduciendo en tu proyecto y de que la curva de aprendizaje será mayor de lo esperado.