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


55

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é?


11
Pensé que GWT murió.
Aaron McIver

1
@ Aaron, ¿en serio?
Jas

10
No recomiendo GWT personalmente. La mentalidad que lo obliga a trabajar para aplicaciones de escritorio, pero le dará problemas para tratar de pensar de esa manera en las funciones HTML. Soy fanático de hacer coincidir el paradigma de codificación con el problema en cuestión, y la abstracción se interpone en mi camino. Es por eso que cada vez que comencé a evaluarlo, decidí no usarlo.
Berin Loritsch

2
@Jas Experience fue hace un par de años; en su infancia y se sentía muy crudo en ese momento. Ha cambiado? Tal vez ... pero lentamente estoy tratando de aprender los fundamentos de los marcos en lugar de confiar en los marcos en sí. Al final del día, es una picadora de carne para producir JS; No es que sea algo malo, pero no en un lugar donde quiero poner mi esfuerzo. Muchos de estos marcos se eligen debido a la falta de conocimiento de la tecnología X o algo del mismo ... pero eventualmente necesitará tener conocimiento de la tecnología X en algún momento ... también podría tomar esa ruta primero.
Aaron McIver el

10
Estoy muy bien informado en JS, escribí algunas cosas bastante serias allí, sin embargo, ahora estoy ejecutando un proyecto muy crítico y no puedo permitir que el personal junior pierda tiempo debido a los errores inducidos por el cambio de contexto de decir Java a JS. Entonces, por favor, si tiene algún ejemplo del mundo real de por qué GWT no funcionó para usted, entonces descríbalo, de lo contrario no perdamos el tiempo con discusiones hipotéticas y de colores muy subjetivos.
Jas

Respuestas:


84

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.


2
Reconocí algunas de las razones por las que elegimos Wicket sobre GWT, felicitaciones a la presentación.
biziclop

12
-1 para FUD, mi experiencia con GWT utilizada para aplicaciones a pequeña y gran escala ha sido mucho más positiva que negativa. Y no he encontrado ninguno de estos "problemas", por lo tanto, el comentario de FUD. Incrustamos con éxito widgets generados por GWT en páginas HTML muy complejas con muy poco esfuerzo. Si sabe lo que está haciendo, es maravilloso, si no quiere considerar que podría haber una nueva forma mejor de hacer las cosas, siga esta "respuesta" e ignore este comentario.

99
@Jarrod Estos no son "problemas" para encontrar, sino descripciones claras de la naturaleza de GWT. Donde sea relevante, los califiqué como negativos específicamente dentro de los objetivos de nuestro proyecto. Si tiene una experiencia alternativa, no dude en escribirla. Hasta entonces, la única información no probada es su afirmación de que GWT es "nuevo y mejor". Por cierto, desde que escribí esta respuesta, la empresa (para la que ya no trabajo) rechazó más de un año de trabajo de varios ingenieros y reescribió el proyecto sin GWT. En menos tiempo
Nicole

1
@JarrodRoberson Estoy de acuerdo con NickC, sería genial leer un informe igualmente detallado de sus experiencias.
funkybro

8
@NickC "En menos tiempo" para reescribir un proyecto no cuenta como un gran golpe para GWT IMO; cualquier proyecto en el que básicamente esté repitiendo lo que se ha hecho antes, incluso en un marco o lenguaje diferente, debería tomar "menos tiempo".
funkybro

24

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

Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.