java - starters - Debo usar Vaadin Framework

vaadin flow starter (19)

Después de casi 1.5 años desarrollando una aplicación GWT no tan grande, usando todas las mejores prácticas que aprendí de la última Google I / O como MVP, EventBus, CommandPattern, etc. Digo esto desde el fondo de mi corazón: después de pasar días intentando Para que las cosas funcionen como mi equipo y cliente querían tanto técnica como visualmente, incluso después del lanzamiento de UiBinder, Vaadin vino a mí como una luz al final del túnel.

Después de escribir casi mil acciones repetitivas para el patrón de comando, otros mil presentadores y vistas y otros mil manejadores de eventos, etc. No tener que lidiar con casi el 75% de estas clases y mantener un buen enfoque de patrones (add-on de aplicación), una pequeña sobrecarga de red es aceptable. Con Vaadin, listo para usar, obtienes buenos widgets, paginación, enlace de datos, diseño impecable. ¿Todo esto por qué? Un poco más de consumo de memoria en el lado del servidor.

Creo que puedo decir que esto es aceptable porque no estoy construyendo el próximo Facebook o algo así. Todavía puedo manejar miles de usuarios simultáneos por servidor mediano y, sin embargo, mantener viajes de ida y vuelta de baja latencia.

Con Vaadin, puedo construir una buena aplicación con casi la mitad de líneas de código y aún la aplicación parece más completa. :-)

!! ACTUALIZACIÓN 23 de febrero de 2011: No puedo estresar cómo uno debe conocer las limitaciones de cada marco. Vaadin no es diferente. Uno debe saber que Vaadin abstrae cualquier forma de HTML o JavaScript. Además, el HTML resultante es muy pesado y usted debe encargarse usted mismo del cambio de estado del historial. Por lo tanto, tenga en cuenta esos gastos generales cuando construya su proyecto.

Intenté jugar con Vaadin Framework y me parece muy fácil de usar. Además, lo que me gusta de su marco es que está construido sobre Google Web Toolkit (GWT) .

¿Qué piensas, debería continuar usando este marco o es mejor seguir con GWT?

Empecé con Vaadin hace solo dos días y pude construir una pequeña aplicación CRUD en OSGi completa con modularidad, enlace de datos, servicios OSGi para persistencia. Una cosa realmente agradable es que mi UI completa solo tiene 118 líneas de código y admite operaciones CRUD completas para una estructura simple de Java Bean.

También es bueno que Vaadin funcione perfectamente en OSGi. Ya es un paquete y encontré un pequeño puente de Neil Bartlet que hace que vaadin sea extremadamente fácil de usar en OSGi.

Ver Ejemplo de Vaadin de la lista de tareas

En nuestra empresa, que es predominantemente una gran casa SW de Java (entre otras cosas), se nos presentó la oportunidad de crear un nuevo producto basado en la web. Era un conjunto de productos y había muchos equipos en tres países desarrollando esto. Cuando se trataba de nuestro equipo, tuve la opción de usar Vaadin para aprovechar mi experiencia de desarrollo de Java. Busqué en Google para ayudarme en mi decisión. También leí esta publicación; Sin embargo, elegí no usar Vaadin, aunque muchos otros equipos eligieron Vadin. A continuación se detallan los motivos de un correo electrónico que envío en ese momento antes de comenzar con el producto (Vaadin o No). Esto es desde mi punto de vista personal y la desconfianza en los marcos en general siempre está en mí en diversos grados. Así que solo quería dar otra opinión al lector sobre esta pregunta.

Bueno, fuimos a una juerga de aprendizaje aprendiendo HTML, CSS, Selectores de CSS, un lenguaje maravilloso JavaScript y JS libs, JQuery y YUI y creamos el producto web a tiempo con la GUI completa y el cumplimiento del rendimiento; y yo personalmente estoy contento y el equipo está tan bien como los usuarios.

Otros equipos que tomaron el camino de Vaadin también crearon sus productos a tiempo y creo que son igualmente felices. (Solo que ellos no conocen la alegría de JavAScript, faltan :)).

Como alguien dijo, todas las abstracciones son abstracciones con fugas y cuando tuvieron que migrar de Vaadin 6 a Vaadin 7 tuvieron que hacer un buen trabajo y le tomó más tiempo de lo que nadie pensaba; aunque, por supuesto, lograron molerlo y sacudirlo; Todavía hubo un poco de retraso debido a esto. También creo que hubo algún problema con el complemento InvientCharts que no era compatible con Vaadin 7, lo que hacía que los equipos compraran ($$) el complemento Vaadin Charts relacionado y lo cambiaran por eso ....

Vaadin o no

Con Vaadin parece que los JavaScript, HTML y CSS subyacentes se generan dinámicamente desde una aplicación de tipo Java Swing. Desde un punto de vista tendencioso y probablemente tonto, el lema "generaré código para ti" no da un buen olor a diseño. A menos que necesite una abstracción, ¿por qué vincularse con otro marco? Al igual que con cualquier marco de generación de código, debería funcionar mejor para la abstracción que Vaadin tenía en mente, pero no muy flexible; Siento que si hacemos tecnología web, lo mejor es hacerlo en las herramientas y lenguajes que la tecnología ha despertado, es decir, bibliotecas HTML, CSS y JavaScript / JavaScript en lugar de depender de otro nivel de abstracción: el marco Vaadin. Esto puede parecer ingenuo para un desarrollador experto de GWT o Vaadin ya que supongo que los complementos de Google generan el JavaScript más optimizado que los codificados a mano, ayuda a administrar el código mejor entre varios equipos, etc. (pero principalmente al desarrollar aplicaciones web bastante grandes), mejor desarrollador productividad, depuración más fácil, etc. Sin embargo, escribir componentes en Java para Vaadin y luego convertirlos automáticamente a JS no me parece correcto ya que muchos de nuestros desarrolladores nunca aprenderán un lenguaje de programación muy importante: JavaScript para desarrollo web (y obtener tracción rápidamente en el lado del servidor - Node.js). Cuando confíe en los marcos para tener su JavaScript correcto, entonces nunca se destacará en ese idioma. Supongo que para una compañía basada en productos es importante aprender de primera mano el lenguaje de la web. Como alguien comentó, Java se ha convertido en el COBOL de antaño y es imprescindible que la competencia se desarrolle para aprender otros idiomas importantes, como JavaScript. Sin embargo, habiendo trabajado en JS durante el poco tiempo que tengo, me he dado cuenta de que si codificamos con cierta disciplina (patrón de Módulo), probamos toda la lógica - unidad JavaScript - JSTestDriver, y ejecutamos JSHint, es un lenguaje bastante poderoso para trabajar con , y la productividad es mejor que Java una vez que se aprende. También la mayoría de los ejemplos importantes de los componentes - OpenLayers están escritos en JS y si necesita ampliarlos o trabajar de manera óptima, necesita saber JavaScript, o para el caso, poderosas librerías como D3.js Así que, en resumen, hay una gran ventaja Al usar Vaadin y frameworks, a largo plazo tal vez usar JavaScript es importante?

Estoy usando Vaadin también. Aunque la aplicación no es grande, lo que realmente me gustó de la experiencia fue que la API fue consistente, generalmente bien documentada y dado que estaba desarrollando una nueva herramienta, pude generar cosas para un cliente muy exigente de la misma manera, o en algunos casos, mejores tiempos que las herramientas que utilicé antes.

Muy pocos problemas. El único en este momento es que el cliente insiste en usar IE 7 (no preguntes) y algunos de los caramelos más elegantes no funcionan totalmente al 100% en un componente de complemento (gráficos).

Por cierto, tampoco trabajo para Vaadin :-)

He intentado con Wicket y Vaadin, y si realmente prueban ambas durante algún tiempo, con un mes sabrán que Vaadin es el camino a seguir y no Wicket, punto. - Dheeraj G

He usado Vaadin para desarrollar un asesor de gif en la empresa para la que trabajo (no Vaadin;).

Vaadin le permite crear aplicaciones web reales integradas de Swinglike.

Si está preocupado por el viaje de ida y vuelta cliente-servidor por cada clic, tengo que decir lo siguiente: Creé un botón de mouseover que cambia el aspecto del botón en yes, mouseover. Para esto, el marco debe ir al servidor y volver. Y funciona lo suficientemente rápido. Vea http://www.cadeau.nl/sophie para ver lo que quiero decir.

Me gusta Vaadin, satisface mis necesidades y hace que el desarrollo web sea muy sencillo.

Saludos, Rob.

Hemos analizado Wicket, donde trabajo, pero encontramos en lugar de 9,000 archivos, podríamos tener más de 30,000. Tenemos casi 1.000 pantallas con nuestra aplicación principal de servicios financieros y, aunque Wicket se ve muy bien, es extremadamente difícil convertir nuestro código Struts 1.3 en Wicket. Nuestro arquitecto hizo un proyecto POC y solo 3 pantallas agregaron varios cientos de clases (muchas son para reutilización). También es difícil protoear una pantalla con Wicket ya que su html debe coincidir con el código de Java y viceversa.

Vaadin parece prometedor, pero será una venta difícil para el equipo.

PD No importa cuán grande sea el marco, nadie lo aprenderá si no se usa en la industria. Wicket ha existido por un tiempo, sin embargo, muy pocas compañías lo usan. La mayoría de los desarrolladores con los que hablo están preocupados por aprender un nuevo marco que es inútil en un currículum.

La clave es que Vaadin usa un diseño tipo Swing y es útil que comencé en Java usando Swing.

La conversación habitual sobre Vaadin tiene que ver con el conjunto de widgets y las preocupaciones sobre la comunicación de ida y vuelta entre el cliente y el servidor.

Pero en mi opinión esto pasa por alto el aspecto más importante (quizás revolucionario) de Vaadin: elimina por completo la tarea de diseñar e implementar la comunicación cliente-servidor que generalmente se requiere para las aplicaciones AJAX (la "A" y la "X" en AJAX) .

Con Vaadin, puede olvidar por completo los DTO (objetos de transferencia de datos), los problemas de seguridad basados en protocolos, las excepciones de carga diferida de Hibernate, etc.

En cierto sentido, solo está escribiendo una aplicación de escritorio antigua Java Swing, solo que está usando un juego de herramientas de interfaz de usuario diferente de Swing.

Lo he usado por un par de semanas y realmente me gusta hasta ahora. El código es sólido, hace una buena construcción, muy lógica, los resultados finales son excelentes.

Me encanta combinarlo con Hibernate para resolver todo el tedio de la base de datos.

Además, es fácil de implementar (con Tomcat solo puede cargar un solo archivo .WAR a través de la interfaz web, no podría ser más fácil)

Lo que pasa es que, para un desarrollo serio, no puedes olvidarte de nada, mucho menos de dtos ... estoy abandonando la costura, y el concepto de ui del lado del servidor solo porque deseo un control más fino sobre lo que está pasando ... el problema de vaadin para mí es precisamente eso, teniendo estado en el lado del servidor ...

No me importa usar estados en el lado del servidor. Sirve su propósito. Con el cómputo en la nube, el almacenamiento y el ancho de banda actuales se están volviendo baratos. Pero sí, puedo ver su punto de vista desde una buena perspectiva de diseño, especialmente si desea RESTIFICAR su aplicación. Pero creo que hay más pros que contras con respecto a Vaadin y similares. Una cosa importante es que no tienes que ajustar mucho tus aplicaciones web para un navegador específico, vamos a llamarlo IE, para complejidades de Javascript / CSS, especialmente si estás orientado hacia el back-end como yo. Todos sus webapps se vuelven compatibles en el navegador sin tener que preocuparse de nada. Recuerde que el tiempo del desarrollador es más costoso que el de almacenamiento y ancho de banda. Esa es mi opinión. =)

Oye. Como descargo de responsabilidad, trabajo para la compañía que desarrolla Vaadin.

Vaadin usa GWT de una manera que tiene un conjunto de componentes precompilados en GWT. Por supuesto, también puede hacer sus propios componentes si así lo desea. Sin embargo, el conjunto de componentes es bastante completo y, a menudo, se puede personalizar para su propia necesidad. Esto significa que no tiene que volver a compilar su código de Java a JavaScript cada vez que cambie su aplicación. Simplemente combina los componentes ya disponibles.

El marco es impulsado por el servidor, por lo que toda la lógica se maneja en el lado del servidor. Los componentes tienen dos partes, archivo de cliente y servidor. El lado del cliente es solo una "vista" ficticia para el componente. Una vez que interactúa con él, envía un mensaje al servidor de que esto o aquello fue presionado / escrito / etc. El servidor luego decide qué se debe hacer. Esto es para aumentar la seguridad, ya que no se puede "piratear" la lógica, ya que solo una pequeña API para enviar solicitudes está disponible en el javascript. Esto puede ser en algunos casos un pequeño intercambio con la velocidad de la aplicación, pero no creo que sea tan malo. Los peores baches de velocidad suelen ser consultas de ida y vuelta en db, que no tienen nada que ver con la elección del marco de la interfaz de usuario. La lentitud de las demos como se sugiere puede deberse a que está lejos del servidor o hay un gran número de usuarios afectados en este momento. Pruébelo en un entorno propio, cierre la aplicación final de su aplicación para ver qué tan bien funciona. Hay alguna aplicación lista que puedes implementar para probarla.

Supongo que la elección se reduce a lo que estás tratando de hacer. Vaadin es bueno para aplicaciones web, ya que puedes construir una aplicación Java normal y hacer la interfaz de usuario web dinámica para ello fácilmente. Si está haciendo algo más que un sitio web tradicional, donde los usuarios solo ven la página, más que interactúa activamente con ella, entonces Vaadin no es la mejor manera de hacerlo. Vaya con algunos otros frameworks gratuitos como rails o un framework php, etc. Creo que está haciendo más una aplicación ya que está sugiriendo que está usando GWT ahora, por lo que Vaadin debería ser bueno.

Haga más preguntas, aquí, en los foros de Vaadin o en el canal irc #vaadin @freenode y tal vez alguien pueda darle más razones de por qué o por qué no utilizar Vaadin.

Para construir UI de buen aspecto, diría que este sería el camino a seguir. Además, está muy bien documentado.

Pensé que Wicket era el camino a seguir, hasta que traté de hacerlo funcionar de manera eficiente y comencé una depresión (broma). Luego, cambié a GWT, que se veía genial, pero hay tanto código de placa de caldera para escribir y la documentación no es tan buena ... -> La luz vino de Vaadin: simple, operacional, no hay errores hasta el momento ... !!!

También vale la pena considerar a Apache Wicket como una alternativa fuerte para los frameworks UI de Java basados en Component. Vaadin suena genial y no quiero restar importancia a esta discusión, pero la elección es algo bueno. Hay algunos ejemplos con una fuente vinculada desde la página de inicio, y aún más en el sitio de WicketStuff, y el excelente libro de Manning constituye una excelente documentación de terceros.

eche un vistazo a la versión demo de Vaadin con Maven: http://asolntsev.blogspot.com/2009/11/vaadin-demo.html

Descargo de responsabilidad : no estoy afiliado a ninguna de las bibliotecas mencionadas a continuación, pero sé que las conozco bastante bien.

Al igual que usted, me encontré con esta publicación al considerar qué pila / marco utilizar para un nuevo proyecto. ¡Tuve una sólida experiencia con Play! (bueno, en Scala, pero eso no es relevante aquí), pero los widgets atractivos y su perfecta integración con el servidor + el desarrollo de Swing like despertaron mi interés. Eso fue a finales de 2010, y como las respuestas me convencieron para probar a Vaadin, decidí regresar y escribir la respuesta que me hubiera gustado leer aquí, especialmente. ya que la pregunta todavía es relevante hoy. Mientras tanto, Vaadin pasó de la versión 6 a la 7 con algunas mejoras notables que se necesitaban, Play! pasó de la versión 1 a la 2 y yo (+ un pequeño equipo) completé una pequeña cantidad de proyectos exitosos con ambos marcos.

Creo que la comparación es interesante porque ambos marcos

ejecutar en la JVM y puede aprovechar su abundante ecosistema
no podría estar más en desacuerdo con su enfoque de las aplicaciones web y lo que a usted, como desarrollador, debería interesarle, y
en menor medida, cómo se relacionan con Java EE.

Alabanza

En una frase, si encuentra convincente la idea de portar una aplicación de escritorio a un navegador mientras se abstrae por completo del mecanismo subyacente de solicitud / respuesta HTTP, entonces es probable que Vaadin sea su candidato para hacer una aplicación web. Su enfoque de programación de Swing puede ser muy fácil para aquellos que están más alejados de la baja calidad de HTML y JavaScript. Una nueva solicitud para su aplicación está comenzando una nueva instancia y el resto del flujo depende de usted y su lógica. Los enlaces vuelven a los viejos y buenos botones de navegación y puedes componer tus diseños usando las muchas plantillas integradas sin tener que modificar el HTML o el CSS. La API generalmente es bastante consistente y está bien documentada (el Libro de Vaadin es una lectura obligatoria. Hazlo a fondo, ya que hay muchas cosas disponibles, por ejemplo, unir los frijoles a componentes y validadores, ...). Los widgets tienen una buena compatibilidad general entre navegadores, lo que garantiza un comportamiento uniforme de su aplicación en una amplia gama de clientes.

Verificación de realidad

Nos lo pasamos muy bien desarrollando y probando nuestras aplicaciones Vaadin. Las cosas se volvieron más claras y más matizadas cuando lanzamos la primera versión y comenzamos a recopilar comentarios. Nos dimos cuenta de que en realidad habíamos sido parciales en algunos aspectos fundamentales , a saber:

En 201x, la mayoría de los usuarios han tenido un largo historial de uso de la web, y pocos de ellos apenas usan aplicaciones de escritorio. El punto clave aquí es que los navegadores estandarizaron la interacción UX con enlaces de hipertexto, un botón de retroceso, avance y recarga, pestañas ubicuas y, a veces, ventanas, y la idea básica de que la mayoría de las acciones activan una solicitud HTTP y esperan una respuesta . Este es el contrato implícito que los sitios web respetan y en torno al cual están construidos. Por lo tanto, no deberíamos habernos sorprendido cuando los usuarios se quejaron de que no podían usar los botones retroceder / avanzar como solían hacerlo, o que las pestañas no funcionaban de la manera esperada. Y estuvimos de acuerdo. Rompimos el contrato invisible vinculando usuarios y navegadores. De hecho, nosotros mismos implícitamente no usamos nuestro navegador con la aplicación Vaadin de la misma forma que lo usamos con cualquier otro sitio web. Por supuesto, puede volver al libro mencionado anteriormente y leer detenidamente al replicar una experiencia de navegación web con fragmentos de URL y verá que en realidad está más involucrado de lo anticipado porque las aplicaciones de Vaadin son estables . Además, los paradigmas MVC o MVP solo se imponen de forma imprecisa al desarrollador, en contraste con Play! donde prácticamente no hay otra opción. No tome esto a la ligera, pero su cerebro se utiliza para la pantalla en blanco brillante que se muestra durante una fracción de segundo después de un cambio de página. Cuando los usuarios hacen clic y esperan que se les tome una nueva página, el navegador confirma mostrando el reloj de arena (o sus variaciones). Con AJAX, las solicitudes se colocan detrás de escena. Hoy hay lugares donde las pequeñas y casi quirúrgicas huelgas de AJAX se han convertido en la norma, pero no para las principales actualizaciones de UI todavía.
Las aplicaciones con estado traen su parte de desafíos ... y problemas. El equilibrio de carga (si está preocupado) para uno es más complicado. El concepto de transacción es completamente diferente ya que las sesiones de Vaadin abarcan muchas solicitudes y, por lo tanto, son largas en contraste con el enfoque basado en REST, pero relativamente de corta duración en términos de UX. De hecho, no es raro que los usuarios vuelvan a un formulario que comenzaron hace horas para finalizar su tarea. Esto podría, en teoría, trabajar con Vaadin también, pero tendrías que mantener las sesiones con vida durante mucho, mucho tiempo, con la memoria bloqueada todo el tiempo y pensar cuidadosamente que esto escalaría a los usuarios concurrentes.
Las páginas de estado también son más difíciles de compartir para los usuarios, y mucho menos de marcadores (eso suponiendo que haya tratado con fragmentos de URL).
Finalmente, compartimos la impresión de que la IU generalmente es más lenta con la lógica del servidor. Por supuesto, siempre puede crear un widget cargado con JavaScript del lado del cliente para reducir el número de viajes de ida y vuelta, pero inevitablemente tendrá que realizar algunas actualizaciones de UI en el servidor. El JS ya es bastante pesado para interpretar en mi experiencia y ofrece una menor experiencia en dispositivos móviles (conozco TouchKit, pero aún así: las aplicaciones HTML5 en dispositivos móviles simplemente no me sirven). Además, tenga en cuenta que el hilo de UI está activo después de que se publique una solicitud (es decir, acción del usuario en el lado del cliente, similar a tirar de las actualizaciones de UI) y será accesible para usted a través de varios oyentes. Sin embargo, la actualización de la interfaz de usuario de los hilos de fondo es más complicada (por ejemplo, empujar las actualizaciones). Sin embargo, Vaadin 7 mejoró la situación en este aspecto, especialmente con HTML relativamente más ligero generado. Se detectaron mejoras significativas en la reactividad de la interfaz de usuario simplemente al activar la compresión HTTP.

Conclusión

Así que hicimos una pausa y nos preguntamos qué nos pareció tan atractivo en el enfoque de Vaadin para empezar. El desarrollo inicial había sido una marcha relativamente suave, produciendo resultados rápidos pero la reelaboración de algunos conceptos para acomodar las expectativas de UX web nos dio una fuerte impresión de nadar contracorriente. Llegamos a la conclusión de que la seductora idea de ser abstraído (¿oscurecido?) Del mecanismo de solicitud / respuesta HTTP demostró ser un arma de doble filo que reveló el desajuste de impedancia real entre las aplicaciones web y las aplicaciones de escritorio.

En lugar de pretender que la web es otra capa, sentimos fuertemente que uno debería adoptar la forma en que funciona y esto comienza con una aplicación centrada en la URL (como lo imponen Rails / Django / Play). Probablemente hayas escuchado a alguien decir que los datos sobreviven a la aplicación. Hoy en día, los recursos de las URL hacen referencia a los datos, por lo que se podría decir con seguridad que las URL sobreviven a los datos. Después de todo, son lo que la gente marca, ¿verdad? Por lo tanto, la separación básica de las preocupaciones también debería aplicarse a este nivel. Esta es probablemente la razón por la cual la web se hizo tan popular en primer lugar. Así que revisamos nuestra aplicación para estructurarla más en torno a un controlador central que responde a las acciones a la jugada realizadas en distintas rutas de recursos.

Por ahora, mantenemos nuestras aplicaciones Vaadin, pero debido a algunas de estas limitaciones y al cambio de paradigma fundamental, no iniciaremos nuevos proyectos con él. Sin embargo, diríjase al equipo que construyó un framework web Java de 360 ° técnicamente coherente, bien documentado y que requiere muy poco conocimiento del funcionamiento interno de la web. Por el lado positivo, incluso respaldan su marco con una empresa que vende servicios de consultoría. Estoy agradecido por la experiencia y por cómo me hizo volver a evaluar mis puntos de vista sobre las aplicaciones web. Seguiré de cerca su evolución, pero definitivamente necesitamos más control y granularidad.

Esperemos que algún día Vaadin se libere de toda la arquitectura de Servlet de la que depende para tener su propio servidor HTTP. Mejor aún sería un diseño MVC más profundamente enraizado en el marco. Pero eso es algo poco probable en un futuro previsible, ya que parece haber encontrado un nicho lucrativo entre los gorilas experimentados de Java que solo juran por EE. Brillar.

TL; DR : Creo que Vaadin no entiende qué son las webapps y, lo que es más importante, cómo deben comportarse. Se trata de que los programadores abrazen la web y cómo los usuarios interactúan con ella (es decir, botón de retroceso, botón de recarga, pestañas y marcadores). Cuanto más cerca se quede una aplicación web de las solicitudes HTTP y la semántica (verbos), es más probable que coincida con las expectativas del usuario. Y esa es la clave.

EDITAR : si tienes alguna experiencia en Python, te recomendaría probar también Flask para obtener una idea de la programación de aplicaciones web basadas en REST basadas en url.

EDIT 2 : Si por algún motivo sientes que debes usar un framework tipo Vaadin de pila completa, entonces prueba Meteor. Es un marco basado en JavaScript (frond y back end) que se ejecuta en Node.js con una comunicación asincrónica que ocurre a través de WebSocket (por lo tanto, menor latencia que la solicitud / respuesta) y es reactiva por defecto. Una serie de cosas que no me gustan en Vaadin se han abordado en Meteor. Por ejemplo, la lógica de las actualizaciones de la interfaz de usuario se ejecuta en el cliente, lo que la hace mucho más receptiva que en Vaadin. La gente de las comunidades JavaScript y Java no se cruzan mucho, pero cuando escuché por primera vez, el paralelismo con Vaadin me golpeó de inmediato. Actualmente goza de bastante impulso en la comunidad por razones similares a las que hicieron popular a Vaadin, es decir. la capacidad de crear aplicaciones web similares a las de un escritorio. Pruébelo si también se dio cuenta de que Java no pertenece mucho a la imagen de futuras aplicaciones web o si está cansado de esos largos ciclos de implementación cuando basta con actualizar. Pero piénselo dos veces antes de vincular una aplicación completa a una sola biblioteca.

Desde mi experiencia GWT requiere mucho código repetitivo y lento cuando se construye UI completa y rica. Normalmente tratamos con modelos de aplicaciones bastante complejos que contienen muchos objetos de dominio persistentes. Para llevar todos estos datos al cliente, deberá introducir un modelo de cliente separado y proporcionar un mecanismo de conversión de datos. Hemos utilizado Dozer para este fin y lleva mucho tiempo mapear cada archivo, crear convertidores personalizados y probar todo esto.

Por otro lado, si no cae en una sobreingeniería y si la aplicación no es muy complicada, puede aprovechar los recursos del cliente y tener menos carga en el servidor. De esta forma, puede minimizar drásticamente la comunicación con el servidor y obtener un software mucho más receptivo.

Vadin se ve muy desarrollador frinosamente :) Pero tengo un poco de miedo al "ataque masivo de AJAX" al servidor. Tengo experiencia en ZK y muchas veces enfrentamos problemas de rendimiento cuando una operación trivial en la IU funciona lentamente porque requiere comunicación con el servidor.

Wicket es otro buen marco, pero es más adecuado para sitios web. Puede funcionar con y sin AJAX, puede ser indexado por los motores de búsqueda. Y lo más atractivo es el código HTML limpio: sin etiquetas personalizadas, sin estructuras de control, separación estricta de las preocupaciones y solo namigs wicketid específicos para los componentes.

Depende principalmente de tus necesidades:

Si necesita una aplicación súper rápida y sencilla, use GWT y utilice los recursos del cliente
Si su aplicación es bastante compleja, Vaadin parece ser la mejor opción
Si su aplicación es pública y necesita una capacidad para indexarla para SEO, elija Wicket.

Hubo "inquietudes" sobre Wicket al usar sesiones para administrar estados de componentes y escalabilidad similares a los argumentos sobre Vaadin y el procesamiento del lado del servidor. He aprendido en los últimos 10 años que la comunidad Java generalmente está equivocada sobre cómo medir el potencial de un framework web (entre otras cosas). Desde JSF a Grails, generalmente se necesitan unos cientos de GB de memoria y al menos una docena de archivos jar de código abierto con funcionalidades superpuestas e ineficientes para ejecutar una aplicación de producción. Mire a su alrededor y verá que la mayoría de las empresas de alojamiento web no ofrecen una opción java práctica debido a la ruta irregular que las tecnologías de Java han tomado para los marcos web. GWT 2.1 todavía es difícil de usar debido a la velocidad de compilación y se está poniendo serio con MVP y tablas de datos que deberían haber estado allí desde el principio. Me gusta Wicket pero Vaadin parece prometedor ... pero sabiendo cómo funcionan los frameworks de Java, estoy seguro de que se dispararán en el pie en algún momento, pero dudo que sea por el gran procesamiento del lado del servidor.