Ahora, con GWT 2, ¿cuáles son las ventajas sobre el wicket y de la misma manera?

Question

Aparte del argumento de la simplicidad de Wicket (es decir, Wicket es un sistema más simple en mi humilde opinión) y la capacidad de respuesta de GWT en el cliente (el estado del cliente de GWT y JavaScript - potencialmente complejo código del cliente) y el mayor potencial de escalado de GWT, ¿cuál es el argumento para usar GWT sobre Wicket?

Personalmente he hecho mucho desarrollo de Wicket, pero solo he echado un vistazo rápido a GWT hace mucho tiempo.

Answer 1

En mi opinión, la mayor ventaja de GWT es que le permite trabajar con un lenguaje de programación, Java, con todas las bondades que brinda.

Junto con CSS, forman un poderoso par.

---

para decirlo de otra manera, puede mayoría olvidar Javascript y HTML.

Si eso es una ventaja o no depende principalmente de sus habilidades y requisitos. Hemos tenido este mismo debate internamente y, al final, un equipo eligió Wicket y otro GWT.

Answer 2

me ocurren varias razones por las GWT es una mejor opción que Wicket, para aplicaciones web típica de negocio:

1. GWT es de Google. Esto puede ser injusto, pero tener una gran y respetada compañía de software detrás de una herramienta es una gran ventaja (más seguro apostar, más libros y recursos en línea, más soporte de terceros, mejor soporte IDE, ...).
2. Los marcos web centrados en servidores como Wicket están desactualizados. Los navegadores web modernos son muy potentes y lo son cada vez más, por lo que un marco web moderno debería ayudarlo a aprovecharlo.
3. La codificación directamente en HTML y Javascript nunca puede ser tan productiva como la codificación en Java (desde mi experiencia, al menos). Además, hay mejores herramientas para el código Java (depuradores, análisis estático, pruebas de unidades y cobertura de códigos, etc.).

Answer 3

No es justo comparar GWT con wicket (o similar) ya que realmente provienen de 2 campamentos diferentes. El primero es un marco para crear aplicaciones de front-end de JavaScript, mientras que el segundo es un marco clásico de aplicaciones web de Java.

Así que los puntos a continuación no son tanto como GWT vs.portillo pero lista bastante general que se compiló cuando decidimos utilizar GWT para avanzados aplicación web JavaScript/AJAX:

• esconde inconvenientes de JavaScript y soporte multi-navegador, permitiendo a desarrollar en Java y la compilación de navegador específica sabor de JavaScript automáticamente (esto no es completamente verdadero debido a la Ley de Extracciones Furtivas, pero es una razón importante por la cual se creó GWT en primer lugar - ver Reveling in Constraints);
• Java es preferido por muchos desarrolladores de Java cuando llega a la interfaz de usuario avanzada de JavaScript/AJAX;
• El entorno de desarrollo y las herramientas de Java son totalmente compatibles: Eclipse plugin, depurador, refactorización, modo alojado en Eclipse;
• Las pruebas JUnit son compatibles tanto con objetos simulados como en modo alojado;
• Integración limpia con el back-end de Java (GWT-RPC);
• Conjunto relativamente rico de widgets UI con aspecto uniforme;
• Disponibilidad de widgets, marcos, patrones y ejemplos de terceros (aún limitados y con una larga lista de deseos);
• El soporte de Google impulsa una aceptación/popularidad más amplia y un avance rápido del marco;
• marco de maduración con 1.6+ y próximos lanzamientos 2.0: (eventbus, controladores de eventos, arquitectura GUI con patrón MVP, optimización del compilador, etc.).

Answer 4

El genio detrás de GWT es que trabajas únicamente con java. Hicieron un gran trabajo con RPC haciéndolo casi transparente para el programador. Muchas veces sientes que estás codificando más como una aplicación de escritorio en lugar de una aplicación con un lado del cliente y del servidor verdaderamente definido.

Answer 5

Las ventajas son, básicamente, que GWT es una herramienta para compilar un cliente basado en JavaScript, por lo tanto, es más adecuado si desea un cliente basado en JavaScript.

Wicket se centra en el servidor, y si bien hace que sea bastante fácil insertar JavaScript en páginas sin estado, el manejo del estado del lado del servidor es el enfoque más natural.

Hay que tener en cuenta que las arquitecturas son muy diferentes.

Con GWT, su arquitectura se convierte en cliente-servidor, un cliente grueso en el navegador, realizando llamadas a 'procedimientos' (servicios) al servidor, enviando y recibiendo datos.

Con Wicket (y otros marcos de componentes del lado del servidor centrados, como JSF y la tapicería), la arquitectura es un 3-capa más 'tradicional' uno, y lo que está enviado y recibido son páginas o fragmentos de las páginas, no datos puros.

Si bien puede sin duda mezclar ambos para adaptarse a la otra arquitectura, simplemente no sería muy natural.

Las personas tienden a centrarse en "lo que es más fácil de usar" (que es completamente subjetivo, dependiendo de su fondo), o "que es más hermoso y tiene más componentes", pero no se debe subestimar la diferencia arquitectónica, que afecta el enfoque que debe tomar para manejar aspectos como seguridad y escalabilidad.

Answer 6

He estado involucrado en un proyecto basado en GWT durante los últimos meses. Yo estaba, habiendo sido parte del equipo de desarrollo de Wicket por años, esperando un cambio, y esperaba mucho de GWT (que siempre he promocionado como otro gran framework de Java).

Honestamente, estoy decepcionado cuando se trata de trabajar con GWT. Siento, de hecho, todo mi equipo, que la productividad tuvo un gran éxito. En teoría, GWT es genial. Pero cuando se toman en cuenta las peculiaridades y limitaciones del marco, los informes de errores mediocres (particularmente cuando se trata de errores de serialización), los largos tiempos de compilación (entre 3 y 10 minutos, y nuestro proyecto aún no es tan grande), el hecho de que, cuando todo está dicho y hecho, todavía necesita probar todos los navegadores y encontrar ajustes y soluciones, el hecho de que produce una enorme descarga inicial (casi un MB, que estamos reduciendo gradualmente, pero con mucho de esfuerzo), etc., etc., creo que Wicket es mucho más fácil y rápido de trabajar.

No odio trabajar con GWT. Todavía es mucho mejor que la mayoría de los frameworks de Java. Es solo que esperaba mucho más trabajando con eso; Incluso esperaba que fuera más agradable que Wicket. Pero al final, simplemente no es yo. Afortunadamente GWT 2.0 mejorará muchas cosas, y con suerte algunas de las peculiaridades del plugin de Eclipse también se arreglarán pronto.

Answer 7

Una ventaja de Wicket sobre GWT sería que Wicket puede manejar el caso en el que desea proporcionar una reserva para los clientes que no tengan habilitado JavaScript. GWT es un cerdo completo para Javascript, Wicket te permite degradar con gracia.

Answer 8

Hay algunas otras ventajas de wicket sobre GWT que encuentro.

1. GWT no funcionará con un navegador donde javascript ha sido deshabilitado. (esto es raro, sin embargo). Wicket siempre vuelve a las solicitudes HTTP normales si JavaScript no está disponible.
2. Las aplicaciones de GWT son de una página, lo que hace que los marcadores y el uso de las pestañas del navegador sean un poco difíciles. Con wicket eliges crear una aplicación de una página o varias aplicaciones de página. Puede hacer las páginas favoritas si lo desea.
3. En GWT, crear sus propios componentes no siempre es fácil. En wicket, dado que está trabajando con html sin formato, css e incluso javascript haciendo componentes personalizados es muy flexible. Incluso puede envolver un componente jquery o dojo existente muy fácilmente.
4. Dado que GWT implica la compilación java a javascript, solo puede usar las clases java que han sido emuladas por el compilador GWT. Esto puede ser limitante. Wicket es un marco del lado del servidor y puedes usar todo el java que quieras.
5. Trabajar con CSS y diseñadores web es mucho más fácil con wicket que GWT.

Answer 9

Soy un novato en GWT, pero después de un estudio, descubrí que GWT es "adecuado" para mi nuevo proyecto de aplicación web por su enfoque de cliente que me da ganas de codificar una aplicación de escritorio. Hoy tenemos un cliente de alto rendimiento listo para ejecutar la aplicación en el lado del cliente. Mi aplicación se puede hacer únicamente en Java, y la clase OOP java ofrece la posibilidad de construir nuestro propio marco de trabajo listo para usar para nuestro equipo.