2009-08-06 14 views
27

Soy un desarrollador web de Java desde hace mucho tiempo y como la mayoría de los desarrolladores web he usado bastante JavaScript. Aunque no odio JavaScript como muchos otros desarrolladores de Java, todavía soy consciente de sus fallas.¿Alguien ha usado GWT y puede decir que realmente cumple lo que promete?

GWT es una forma de escribir javascript mediante java. Como conozco ambos idiomas desde hace mucho tiempo, soy bastante escéptico sobre esta afirmación. Quiero decir, me está costando creer que realmente puedas crear aplicaciones web dinámicas completas de Java con una rica GUI usando solo GWT. Es por eso que estoy preguntando si alguien tuvo la oportunidad de trabajar con GWT en un proyecto a gran escala. Si es así, me gustaría escuchar lo que piensan de él.

+4

¿Por qué cerrar? Esto me parece una pregunta interesante. –

+2

Algunas personas tienen la mala costumbre de hacer clic en 'cerrar' si simplemente no les gusta la pregunta. No creo que esto sea subjetivo ni argumentativo en absoluto –

+2

¿Terminaste usando GWT? ¿Entregó? – HDave

Respuesta

38

He escrito aplicaciones de tamaño bastante grande en GWT, y debo decir que estoy aún más impresionado por GWT que cuando comenzó el proyecto. Mi "sensación" general de la plataforma es que las cosas están bien pensadas, y no hacen las cosas a menos que puedan hacerlo bien, y pueden hacerlo bien en todos los navegadores (¡los usuarios de IE siguen siendo sus usuarios!)

Ahora, tenga en cuenta que lo que GWT realmente destaca es la creación de aplicaciones de estilo de página grande, altamente dinámicas y de una sola página. Si su objetivo es mejorar una página de otra manera estática con algunos efectos de Javascript, que GWT es enorme exageración (gquery puede cambiar esto, pero yo no tengo experiencia con gquery)

Algunas de las características que me gustan son:

  • La capacidad de compartir código entre el lado del servidor y el lado del cliente. (Si su lado del servidor está escrito en Java, por supuesto). No esperaba usar esto mucho al principio, pero en la práctica, realmente puede ahorrar mucha duplicación de código. Sin embargo, me parece que, en general, esto solo funciona con código que se ha escrito con GWT en mente; usar códigos que no se escribieron con GWT en mente a menudo no funciona bien. Esto se debe a que GWT solo tiene un subconjunto de las clases en el JDK, y en javascript, debe preocuparse por el rendimiento mucho más que por el lado del servidor.
  • Su objetivo es lograr el javascript más rápido, más rápido de lo que escribiría a mano (porque si lo escribiera a mano, el código no se podría mantener).La desafortunada realidad es que los navegadores que mucha gente usa tienen motores JavaScript increíblemente lentos, por lo que el rendimiento de su código de JavaScript es muy importante. El compilador de Gwt es un compilador de optimización real: aplicará métodos en línea, interne todas sus cadenas. desvirtualice sus llamadas a métodos siempre que sea posible, etc. Debido a que está compilando para cada navegador y configuración regional, el compilador también puede alinear el código específico del navegador y el idioma local. Este Google I/O presentation tiene algunos puntos de referencia en algunas diapositivas.
  • También sprites automáticamente las imágenes para reducir al mínimo el número de peticiones HTTP necesarias, una vez más mejorar la velocidad de su sitio. GWT 2.0 le permitirá combinar archivos arbitrarios juntos.
  • la mayor parte de los archivos creados por GWT tienen una fuerte almohadilla, como su nombre, y que le permite administrar los archivos que se almacenan en caché para siempre, pero no se preocupan por las personas que tienen versiones antiguas si el archivo cambia
  • El código de división en GWT 2.0 es muy impresionante y sería muy difícil de hacer a mano. A medida que el tamaño de la aplicación crece, tratar con el tamaño de su javascript importa más y más, y lo que necesita para poder dividirlo en trozos
  • Usted está codificando en un lenguaje de tipos estáticos. Sé que algunas personas prefieren tipado dinámico, pero me gusta comparar este debate para los emacs vs debate VI - hay un montón de gente inteligente en ambos campos, y argumentando en Internet no va a cambiar la preferencia de nadie
  • Usted Llegue a utilizar muchas de las excelentes herramientas que existen en el ecosistema de Java, que en general son mucho más maduras que las herramientas de JavaScript equivalentes. - junit, entornos de desarrollo Java, depuradores java, refactorización, etc
+3

Ah, y supongo que las mayores desventajas son: - el tiempo de compilación - el modo alojado es excelente, pero actualmente no puede usarlo para el navegador no predeterminado del sistema - GWT 2.0 y el modo alojado fuera de proceso deberían solucionarlo. - El lenguaje Java puede ser prolijo a veces, aunque eso dista mucho de ser sorprendente. (gwt para Scala sería terriblemente agradable :)) – Chi

2

Lo he visto brevemente para una aplicación anterior en uno de mis trabajos, y debo admitir que fue muy impresionante. Todo el código fue escrito en Java, y el javascript fue construido maravillosamente.

Tenía AJAX, páginas dinámicas, las obras. También hay complementos para él, como el marco Ext GWT.

Definitivamente vale la pena investigar y probar, pero es posible que el ciclo de desarrollo no "se sienta bien", por lo que puede optar por utilizar JavaScript regular.

+3

buen punto sobre el entorno de desarrollo "sentir". GWT es definitivamente solo para aquellos que disfrutan/toleran las restricciones de un lenguaje como Java. –

4

Al igual que con cualquier herramienta, debe utilizarse correctamente. Uno puede manejar un martillo hábilmente y construir algo bueno, o simplemente agitarlo en las cosas y hacer más daño que bien.

Google Wave, creo, se ha convertido en el prototipo de "lo que es posible" con GWT.

Todavía es bastante difícil encontrar buenos patrones de diseño GWT porque la tecnología es demasiado nueva, por lo que puede dañar los esfuerzos para desarrollar una aplicación web muy rica y de gran escala en GWT. Antes de comenzar dicho proyecto, recomendaría buscar ejemplos del patrón model-view-presenter (MVP) y asegúrese de usarlo, o algo así, como base para el flujo de control de su aplicación web. Una cosa buena de GWT, y escribir su código en Java, es que el alto grado de abstracción y desacoplamiento necesario para una implementación limpia de MVP es bastante fácil (gracias al compilador).

5

Si usted tiene familiaridad con JavaScript y Java, que realmente están perfectamente adaptadas para obtener el máximo provecho de GWT. Lo que muchas personas no se dan cuenta es que GWT tiene muchas capas y que usted puede decidir realmente en cuáles de esos niveles desea trabajar.

Por ejemplo, a veces escribo directamente en la biblioteca DOM para proyectos. Es muy similar a escribir código JavaScript, excepto que puede usar un IDE correctamente y obtener el poder de un compilador. Del compilador obtengo verificación de tipo estático, muchas optimizaciones buenas del compilador y (en realidad, mi favorito para mantener el código) las aserciones del modo de depuración. Nadie realmente tiene mucha capacidad para hacer afirmaciones, pero es muy agradable poder compilar un modo de depuración que realiza chequeos costosos para desenterrar errores y luego apaga el modo de depuración y hace que el código simplemente se evapore. (No solo desaparecen las afirmaciones afirmativas, sino que también se compila todo el código accesible desde los asertos).

Otras veces, escribo código en la biblioteca de UI de GWT. Ese código se parece un poco al código swing o SWT, por lo que es más cómodo para los desarrolladores de Java puro. Al trabajar en este nivel, no tiene que preocuparse tanto por el DOM y, por lo general, es posible construir una aplicación sin escribir ningún JavaScript. Ocasionalmente se encuentra con un error donde algo no funciona de manera consistente en un navegador en particular. La gente de GWT considera esos errores.

Puede tipo de elegir qué nivel de abstracción que desea trabajar. Hay compensaciones en cada nivel, pero GWT debería apoyarlas.

Además, la divulgación completa: Soy el tipo en el video que Chi vinculado anteriormente, por lo que se podría decir que estoy muy apegado a GWT.

3

He creado dos aplicaciones GWT bastante sustanciales en mis tres años en Google. Entrega lo que promete: mis aplicaciones fueron mucho más interactivas y mucho más atractivas que mi conocimiento de Javascript y mi herramienta de Javascript me hubiera permitido producir usando otras herramientas.

También encontré las aplicaciones más interactivas y más divertido que las alternativas del lado del servidor puramente había utilizado antes de trasladarse a la misma.

No está libre de verrugas, pero es un entorno muy productivo para hacer el tipo de aplicaciones que hago.

Y mire la presentación de Kelly. Esto, y algunos de los otros de I/O, dan una idea muy clara de lo que puede hacer GWT. Rápidamente tendrá una buena idea de si es la herramienta adecuada para la tarea que está visualizando.

1

he estado desarrollando una aplicación de campo verde en GWT durante un año y que ha sido sorprendentemente agradable. El subconjunto de Java utilizado en GWT causa algunos dolores de cabeza pero nada importante después de todo. No tenía mucho conocimiento de JavaScript cuando me uní al proyecto, pero creo que no fue un problema.

Los problemas comunes relacionados con GWT que he encontrado tenían generalmente algo que ver con el marco Ext GWT/GXT o la integración FCKEditor.

1

Simply GWT rocks google está haciendo "google wave" completamente en GWT.

4

Creo GWT hace lo que dice en la lata ...

5 razones para elegir GWT:

  1. la tapicería puede ser demasiado complicado y la curva de aprendizaje es bastante empinada para los nuevos desarrolladores que están comenzando \ unirse al equipo. Esp. en proyectos más grandes.

  2. Descubrí que podía desarrollar aplicaciones "más ricas" con GWT, ya que mi fortaleza no es Java. Para poder implementar una funcionalidad similar usando Tapestry, tendría que escribir Javascript a mano, lo que luego se convertiría en una pesadilla de mantenimiento.

  3. Compatibilidad con el navegador, me pasaba mucho tiempo intentando que mi escritura a mano Javascirpt funcionara en todos los navegadores (como dije, el Javascript no es mi fortaleza :-) El compilador de GWT me oculta de esto, lo que resulta en mí pasar más tiempo escribiendo características.

  4. Back button blues, el detector de historial de GWT maneja el botón de retroceso de los navegadores en comparación con Tapestry.

  5. GWT tiene una huella más pequeña porque solo se envían los datos a través del cable para refrescar toda la página.

La lista es interminable, pero en general, estoy muy feliz de haber hecho el cambio y no han mirado atrás desde entonces.

1

No sabía mucho Javascript cuando traté de crear mi sitio web. De hecho, es por eso que postergué la creación del sitio web.

Para mí, GWT marcó una gran diferencia, ya que me permitió crear un sitio web dinámico y multiproveedor que, sin duda, no habría sido capaz de crear sin poner mucho esfuerzo en aprender Javascript.

0

que he hecho un par de proyectos a lo largo de unos años y es fantástico. Volver al marco basado en JS/JSP/request es realmente horrible.

No quiero renunciar a las comprobaciones de tiempo de compilación, pruebas de unidad en mi IDE, refactorización IDE, etc., compartiendo código entre diferentes niveles, conjunto sólido de widgets, marco increíblemente bien pensado.

Puede hacer tanto más mucho más rápido de una manera sostenible.

0

Hay una curva de aprendizaje empinada, pero para las aplicaciones de la interfaz de usuario realmente dinámicas, no hay forma de que pueda compilar de forma manual en javascript de manera eficiente. Lo que quiero decir en particular es, por ejemplo, una interfaz de aplicación para un servicio donde todos los campos de búsqueda y los tipos de resultados y la longitud eran completamente desconocidos. Para este tipo de cosas, un tiempo de ejecución dinámico definido ui, no hay nada mejor que GWT en mi opinión.

Los inconvenientes son la empinada curva de aprendizaje (especialmente para los programadores Java no swing, tipos de solicitud y respuesta tradicionales servlet api y gals) y quedar acorralados en GWT una vez que tome esa decisión.

Cuestiones relacionadas