¿Cuándo no usar Google Web Toolkit? [cerrado]

Estoy considerando el uso de GWT en un importante proyecto interno de desarrollo de aplicaciones web, es decir, su mayor ventaja para mí es la compilación cruzada de Javascript que (al menos en teoría) ayudaría a mi equipo a reducir el tamaño de la pila tecnológica en uno .

Sin embargo, después de haber sido quemado antes (como la mayoría de los desarrolladores), me gustaría saber de los programadores que realmente lo usaron en cualquier problema con GWT que pudiera obstaculizar o limitar su uso dentro de un determinado dominio de problemas.

¿Cuáles son los argumentos en contra del uso de GWT y por qué?

Soy bueno y malo para responder esta pregunta, bueno, ya que lo he usado antes, y malo, ya que tenía bastante experiencia con HTML / CSS / JavaScript antes de trabajar con GWT. Esto me dejó enloquecido al usar GWT de una manera que otros desarrolladores de Java que realmente no conocen DHTML pueden no haber estado.

GWT hace lo que dice: abstrae JavaScript y, hasta cierto punto, HTML en Java. Para muchos desarrolladores, esto suena genial. Sin embargo, sabemos, como lo expresa Jeff Atwood, todas las abstracciones son abstracciones fallidas (vale la pena leer si se considera GWT). Con GWT, esto introduce específicamente los siguientes problemas:

Usar HTML en GWT apesta.

Como lo dije, hasta cierto punto, incluso abstrae HTML. Suena bien para un desarrollador de Java. Pero no lo es. HTML es un formato de marcado de documento. Si quisiera crear objetos Java para definir un documento, no utilizaría elementos de marcado de documento. Es enloquecedoramente detallado. Tampoco está lo suficientemente controlado. En HTML hay esencialmente una forma de escribir <p>Hello how are <b>you</b>?</p>. En GWT, tiene 3 nodos secundarios (texto B, texto) unidos a un Pnodo. Puede crear primero la P o crear primero los nodos secundarios. Uno de los nodos secundarios podría ser el resultado de retorno de una función. Después de unos meses de desarrollo con muchos desarrolladores, tratar de descifrar cómo se ve su documento HTML rastreando su código GWT es un proceso que induce dolor de cabeza.

Al final, el equipo decidió que tal vez usar HTMLPanel para todo HTML era el camino correcto. Ahora, ha perdido muchas de las ventajas de GWT de tener elementos fácilmente disponibles para el código Java para enlazar fácilmente los datos.

Usar CSS en GWT apesta.

Al adjuntar a la abstracción HTML, esto significa que la forma en que tiene que usar CSS también es diferente. Podría haber mejorado desde la última vez que usé GWT (hace unos 9 meses), pero en ese momento, el soporte de CSS era un desastre. Debido a la forma en que GWT te hace crear HTML, a menudo tienes niveles de nodos que no sabías que fueron inyectados (cualquier desarrollador de CSS sabe cómo esto puede afectar dramáticamente el renderizado). Había demasiadas formas de incrustar o vincular CSS, lo que resultaba en una confusión de espacios de nombres confusos. Además de eso, tenía el soporte de sprites, que de nuevo suena bien, pero en realidad cambió su CSS y tuvimos problemas con sus propiedades de escritura que luego tuvimos que sobrescribir explícitamente más tarde, o en algunos casos, frustraron nuestros intentos de igualar nuestra mano. CSS codificado y tener que rediseñarlo de manera que GWT no lo arruine.

Unión de problemas, intersección de beneficios

Cualquier idioma tendrá su propio conjunto de problemas y beneficios. Si lo usa es una fórmula ponderada basada en esos. Cuando tienes una abstracción, lo que obtienes es una unión de todos los problemas y una intersección de los beneficios. JavaScript tiene sus problemas, y comúnmente se burla entre los ingenieros del lado del servidor, pero también tiene algunas características que son útiles para el desarrollo web rápido. Piense en cierres, sintaxis abreviada, objetos ad-hoc, todo lo que hace Jquery (como las consultas DOM por el selector CSS). ¡Ahora olvídate de usarlo en GWT!

Separación de intereses

Todos sabemos que a medida que crece el tamaño de un proyecto, es fundamental tener una buena separación de las preocupaciones. Una de las más importantes es la separación entre visualización y procesamiento. GWT hizo esto realmente difícil. Probablemente no sea imposible, pero al equipo en el que estaba nunca se le ocurrió una buena solución, e incluso cuando pensábamos que lo habíamos hecho, siempre teníamos una fuga en la otra.

Escritorio! = Web

Como @Berin Loritsch publicó en los comentarios, el modelo o la mentalidad GWT está diseñada para aplicaciones vivas, donde un programa tiene una pantalla viva estrechamente unida a un motor de procesamiento. Esto suena bien porque eso es lo que muchos sienten que le falta a la web. Pero hay dos problemas: A) La web está construida en HTTP y esto es inherentemente diferente. Como mencioné anteriormente, las tecnologías creadas en HTTP: HTML, CSS, incluso la carga de recursos y el almacenamiento en caché (imágenes, etc.), se han creado para esa plataforma. B) Los desarrolladores de Java que han estado trabajando en la web no cambian fácilmente a esta mentalidad de aplicación de escritorio. La arquitectura en este mundo es una disciplina completamente diferente. Los desarrolladores de Flex probablemente serían más adecuados para GWT que los desarrolladores web de Java.

En conclusión...

GWT es capaz de producir aplicaciones AJAX rápidas y sucias con bastante facilidad utilizando solo Java. Si rápido y sucio no suena como lo que quieres, no lo uses. La compañía para la que trabajaba era una compañía que se preocupaba mucho por el producto final, y su sentido del pulido, tanto visual como interactivo, para el usuario. Para nosotros, los desarrolladores front-end, esto significaba que necesitábamos controlar HTML, CSS y JavaScript de una manera que hacía que usar GWT fuera como tocar el piano con guantes de boxeo.

Utilizamos GWT para una gran aplicación web de administración electrónica (SOA en el backend) que tiene un uso intensivo. La antigua interfaz de usuario estaba en DHTML, pero tuvimos problemas con la compatibilidad del navegador, la optimización del rendimiento y el proceso de desarrollo, por lo que buscamos alternativas.

Nuestros requisitos han sido:

• capa de interfaz de usuario del lado del cliente para minimizar la carga del servidor
• compatibilidad del navegador
• RIA basada en la web
• Optimizaciones de rendimiento fáciles.
• No es necesaria la instalación de complementos de cliente, debería funcionar con una instalación de Windows simple

Elegimos GWT y nunca me arrepiento. El nuevo equipo tenía poca o ninguna experiencia en DHMTL y, por lo tanto, el proceso de desarrollo Java de GWT fue muy útil. Lo que obtienes de la caja es:

• compatibilidad del navegador
• Proceso de desarrollo basado en Java y reutilización de código
• minimización fácil de solicitudes (paquete de imágenes, ...)
• almacenamiento en caché fácil y agresivo (las nuevas aplicaciones están completamente en caché en el lado del cliente)
• fácil compresión de todos los recursos (incluso con js en IEs con errores anteriores)
• y mucho más, mucho que mencionar aquí

Nuestra aplicación emite solo una solicitud al servidor al inicio. En el lado negativo es que GWT (y también Android) tienen un diseño pobre fuera de la caja, pero de todos modos si aplica su propia apariencia, tiene que adaptar el CSS. Alternativamente, puede usar varias bibliotecas de componentes para GWT que facilitan la aplicación de estilos y temas adecuados.

Para mí no tiene sentido que tal vez el HTML DOM no sea tan bueno como el hecho a mano, esto nunca fue un problema. Cuando desarrollo en C ++, no miro el código ensamblador generado. Cuando desarrollé en GWT nunca hubo una razón para que yo mirara el código JS y solo una vez una razón para mirar el DOM y hacer algunas refactorizaciones.

Para mí, GWT es la única opción cuando se trata del desarrollo de RIA y espero que GWT tenga un futuro brillante. Vea la declaración de misión en:

[1] http://code.google.com/intl/de-DE/webtoolkit/makinggwtbetter.html#introduction

Pero no debe mencionarse que Google no usa GWT en muchos de sus proyectos internos y que en este momento hay algunos rumores sobre el futuro de GWT, vea

[2] http://googlewebtoolkit.blogspot.com/2011/11/gwt-and-dart.html
[3] https://plus.google.com/105933370793992913359/posts/bLfSagtziBC