¿Debo usar Vaadin Framework [cerrado]

https://stackoverflow.com/questions/1183801

19-09-2019
|

Pregunta

Sólo intenté jugar con Marco Vaadin y me parece muy fácil de usar.Además, lo que me gusta de su marco es que está construido sobre Kit de herramientas web de Google (GWT).

¿Qué opinas? ¿Debería seguir usando este marco o es mejor seguir con GWT?

Solución

Hola. Como un descargo de responsabilidad, trabajo para el desarrollo de la empresa Vaadin.

Vaadin utiliza GWT en una forma que tiene un conjunto de componentes precompilados en GWT. Puede, por supuesto, además, hacer sus propios componentes, si así lo desea. Sin embargo, el conjunto de componentes es bastante completa, y con frecuencia se puede personalizar para su propia necesidad. Esto significa que usted no tiene que volver a compilar el código de Java a JavaScript cada vez que cambie su aplicación. Usted acaba de combinar los componentes ya disponibles juntos.

El marco es accionado servidor, por lo que todo lógica se maneja en el lado servidor. Los componentes tiene dos partes, el cliente y el servidor de archivos. El lado del cliente es sólo una "visión" de prueba para el componente. Una vez que interactúa con él, se envía un mensaje al servidor que tal o cual fue presionado / escrito / etc. Después, el servidor decide lo que debe hacerse. Esto es para una mayor seguridad, porque no se puede "cortar" la lógica, ya que sólo una pequeña API destinado para el envío de solicitudes está disponible en el javascript. Esto puede ser en algunos casos un poco de equilibrio con la velocidad de la aplicación, pero no creo que es una mala manera. Peor reductores de velocidad son generalmente db consulta de ida y vuelta y tal, que no tiene nada que ver con la elección del marco de interfaz de usuario. La lentitud de las demos como sugerido puede ser porque estás lejos del servidor o hay una alta usuario golpeado por el momento. Probarlo en un entorno propio, cierre la aplicación final de la aplicación, para ver lo bien que funciona. Hay alguna aplicación listos que sólo puede desplegar para probarlo.

Creo que la elección se reduce a lo que está tratando de hacer. Vaadin es bueno para aplicaciones web, como se puede construir una aplicación Java normal y hacer la interfaz de usuario web dinámico para ello fácilmente. Si su algo hacer más de un sitio web tradicional, donde los usuarios sólo se ve la página - más activamente interactúa con él, entonces Vaadin no es el mejor camino a seguir. Ir con algunos otros marcos libres como rieles o un marco php, etc. Creo que se está haciendo más como una aplicación que está sugiriendo que está utilizando GWT ahora, para Vaadin debe ser bueno.

Haga más preguntas, aquí, en los foros vaadin o en el canal de IRC #vaadin @freenode y tal vez alguien le puede dar más razones de por qué o por qué no usar Vaadin.

Otros consejos

Después de casi 1,5 años el desarrollo de una aplicación no tan grande GWT, utilizando todas las mejores prácticas que he aprendido de la última Google I / O como MVP, EventBus, CommandPattern, etc. lo digo desde el fondo de mi corazón: después de pasar días tratando de hacer las cosas salen como mi equipo y el cliente quería tanto técnica como visualmente, incluso después de la liberación de UiBinder, Vaadin vino a mí como una luz al final del túnel.

Después de escribir casi mil acciones de caldera para el patrón de comando, otros mil presentadores y puntos de vista y otros mil controladores de eventos, etc .. No tener que hacer frente a casi el 75% de estas clases y que todavía mantiene un buen patrón de enfoque (appfoundation Agregar- on), un poco de sobrecarga de la red es aceptable. Con Vaadin, fuera de la caja, se obtiene buenos widgets, paginación, el enlace de datos, maquetación impecable. Todo esto para qué? Algunos más consumo de memoria en el lado del servidor.

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

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

!! Actualización 23 de febrero de 2011: No puedo expresar cómo uno debe ser consciente de las limitaciones de cada marco. Vaadin no es diferente. Uno debe ser consciente de que Vaadin abstrae cualquier forma de HTML o Javascript. Además, el código HTML resultante es muy pesada y se debe cuidar de la historia del estado cambia a sí mismo. Por lo tanto, ser conscientes de esos gastos cuando genere el proyecto.

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

Al igual que usted, me topé con esta publicación mientras pensaba qué pila/marco usar para un nuevo proyecto.¡Tuve una experiencia sólida con Play!(vale, en Scala, pero eso no es relevante aquí) pero los atractivos widgets y su perfecta integración con el lado del servidor + el desarrollo tipo Swing despertaron mi interés.Eso fue a finales de 2010, y como las respuestas me convencieron de darle una oportunidad a Vaadin, decidí volver y escribir la respuesta que me hubiera gustado leer aquí, especialmente.ya que la pregunta sigue siendo relevante hoy.Mientras tanto, Vaadin pasó de la versión 6 a la 7 con algunas mejoras notables que eran necesarias, ¡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

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

Elogio

En una frase, si le parece convincente la idea de migrar una aplicación de escritorio a un navegador mientras está completamente abstraído del mecanismo de solicitud/respuesta HTTP subyacente, entonces Vaadin es probablemente su candidato para crear una aplicación web.Su enfoque de programación tipo Swing puede ser muy sencillo para aquellos que se sienten más felices lejos del bajo nivel de HTML y JavaScript.De hecho, una nueva solicitud a su aplicación está iniciando una nueva instancia y el resto del flujo depende de usted y su lógica.Los enlaces vuelven a los viejos botones de navegación y usted es libre de componer sus diseños utilizando las numerosas plantillas integradas sin tener que modificar el HTML o el CSS.La API es generalmente bastante consistente y ciertamente está bien documentada (la Libro de Vaadin Es una lectura obligatoria.Hágalo a fondo, ya que hay muchas cosas disponibles, por ejemplo.vinculando sus beans a componentes y validadores, ...).Los widgets tienen una buena compatibilidad general entre navegadores, lo que garantiza un comportamiento consistente de su aplicación en una amplia gama de clientes.

Verificación de la realidad

Nos lo pasamos muy bien desarrollando y probando nuestras aplicaciones Vaadin.Las cosas se volvieron más claras y matizadas cuando lanzamos la primera versión y comenzamos a recopilar comentarios.Nos dimos cuenta de que En realidad, habíamos estado parcializados 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 ya casi no 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 retroceder, avanzar y recargar, pestañas ubicuas y, a veces, ventanas, y la idea básica de que la mayoría de las acciones desencadenan una solicitud HTTP y esperarán una respuesta..Este es el contrato implícito que cumplen los sitios web y en torno al cual se construyen.Por lo tanto, no deberíamos habernos sorprendido cuando los usuarios se quejaron de que no podían usar los botones atrás/adelante como estaban acostumbrados, o que las pestañas no funcionaban de la manera esperada.Y estuvimos de acuerdo.Rompimos el contrato invisible que vinculaba a usuarios y navegadores.En realidad, nosotros mismos estábamos implícitamente no usar nuestro navegador con la aplicación Vaadin de la misma manera que lo usamos con cualquier otro sitio web.Por supuesto, puede volver al libro mencionado anteriormente y leer detenidamente sobre cómo replicar una experiencia de navegación web con fragmentos de URL y verá que en realidad es más complicado de lo previsto. porque las aplicaciones de Vaadin tienen estado.Además, los paradigmas MVC o MVP sólo se imponen vagamente al desarrollador, a diferencia de Play!donde prácticamente no hay otra opción.No te lo tomes a la ligera, pero tu cerebro está acostumbrado a la pantalla blanca 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 lleve a una nueva página, el navegador lo reconoce mostrando el reloj de arena (o variaciones del mismo).Con AJAX, las solicitudes se colocan detrás de escena.Hoy en día hay lugares donde los ataques AJAX pequeños, casi quirúrgicos, se han convertido en la norma, pero aún no para actualizaciones importantes de la interfaz de usuario.
Las aplicaciones con estado presentan su parte de desafíos...y problemas.El equilibrio de carga (si le preocupa) 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 cortas en términos de UX.De hecho, no es raro que los usuarios vuelvan al formulario que iniciaron. horas atras para terminar su tarea.En teoría, esto también podría funcionar con Vaadin, pero tendrías que mantener vivas las sesiones durante mucho, mucho tiempo con la memoria bloqueada todo el tiempo y pensar detenidamente bien, esto escalaría w.r.t.usuarios concurrentes.

Las páginas con estado también son más difíciles de compartir para los usuarios, y mucho menos marcarlas (eso suponiendo que se trate de fragmentos de URL).
Finalmente, compartimos la impresión de que la interfaz de usuario es generalmente más lenta cuando la lógica está en el servidor.Por supuesto, siempre puedes crear un widget cargado con JavaScript del lado del cliente para reducir el número de viajes de ida y vuelta, pero inevitablemente tendrás que realizar algunas actualizaciones de la interfaz de usuario en el servidor.Según mi experiencia, el JS ya es bastante difícil de interpretar y ofrece una experiencia menor 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 la interfaz de usuario está activo después de que se publica una solicitud (es decir,acción del usuario en el lado del cliente, similar a obtener actualizaciones de la interfaz de usuario) y será accesible para usted a través de varios oyentes.Sin embargo, actualizar la interfaz de usuario desde subprocesos en segundo plano es más complicado (p. ej.enviando actualizaciones).Sin embargo, Vaadin 7 mejoró la situación a este respecto, especialmente con relativamente HTML más ligero generado.Se notaron mejoras significativas en la reactividad de la interfaz de usuario simplemente activando la compresión HTTP.

Conclusión

Así que hicimos una pausa y nos preguntamos qué nos parecía tan atractivo en el enfoque de Vaadin para empezar.El desarrollo inicial había sido un viaje relativamente fluido que produjo resultados rápidos, pero reelaborar algunos conceptos para adaptarnos a las expectativas de UX web nos dio una fuerte impresión de nadar contra corriente.Concluimos que la seductora idea de ser abstraído (¿ocultado?) del mecanismo de solicitud/respuesta HTTP resultó ser un arma de doble filo que reveló la verdadera falta de coincidencia de impedancia entre las aplicaciones web y las aplicaciones de escritorio.

En lugar de pretender que la web es una capa más, sentimos firmemente que uno debería aceptar su forma de funcionar. y esto comienza con tener una aplicación centrada en URL (según lo impuesto por Rails/Django/Play).Probablemente hayas oído a alguien decir que los datos sobreviven a la aplicación.Hoy en día, los recursos de 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 como favorito, ¿no?Por lo tanto, la separación básica de preocupaciones también debería aplicarse a este nivel.Probablemente esta sea la razón por la que 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 Play realizados 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 comenzaremos nuevos proyectos con ellas.Sin embargo, me quito el sombrero ante el equipo que creó un marco web Java de 360° técnicamente coherente, cohesivo y bien documentado que requiere muy poco conocimiento del funcionamiento interno de la web.Lo bueno es que incluso respaldan su marco con una empresa que vende servicios de consultoría.Estoy agradecido por la experiencia y por cómo me hizo reevaluar mis puntos de vista sobre las aplicaciones web.Seguiré de cerca su evolución, pero definitivamente necesitamos más control y granularidad.

Con suerte, algún día Vaadin se liberará de toda la arquitectura de servlet en la que depende para tener su propio servidor HTTP.Mejor aún sería un diseño MVC más profundamente arraigado en el marco.Pero eso es algo poco probable en el futuro previsible, ya que parece haber encontrado un nicho lucrativo entre los gorilas corporativos de Java experimentados que sólo confían en EE.Brillar.

TL;DR:Creo que Vaadin no entiende qué son las aplicaciones web y, lo que es más importante, cómo deberían comportarse.Ya es hora de que los programadores adopten la web y la forma en que los usuarios interactúan con ella (es decir,botón Atrás, botón recargar, pestañas y marcadores).Cuanto más se apegue una aplicación web a las solicitudes HTTP y la semántica (verbos), más probabilidades habrá de que coincida con las expectativas del usuario.Y esa es la clave.

EDITAR:Si tiene alguna experiencia con Python, le recomiendo probar Flask también para obtener una idea de la programación de aplicaciones web basada en REST y centrada en URL.

EDITAR 2:Si por alguna razón cree que debe utilizar un marco completo similar a Vaadin, pruebe Meteor.Es un marco basado en JavaScript (tanto frontal como posterior) que se ejecuta en Node.js con comunicación asincrónica a través de WebSocket (por lo tanto, una latencia menor que la solicitud/respuesta) y es reactivo de forma predeterminada.Varias cosas que no me gustan en Vaadin se han abordado en Meteor.Por ejemplo, la lógica para las actualizaciones de la interfaz de usuario se ejecuta en el cliente, lo que lo hace mucho más receptivo que en Vaadin.La gente de las comunidades de JavaScript y Java no se cruzan mucho, pero cuando oí hablar de ello por primera vez, el paralelo con Vaadin me llamó la atención de inmediato.Actualmente disfruta 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 escritorio.Pruébelo si también se dio cuenta de que Java no pertenece mucho al panorama de futuras aplicaciones web o si está cansado de esos largos ciclos de implementación en los que presionar actualizar es todo lo que necesita.Pero piénselo dos veces antes de vincular una aplicación completa a una sola biblioteca.

La charla habitual sobre Vaadin se refiere al conjunto de widgets y las preocupaciones acerca de la comunicación de ida y vuelta entre el cliente y el servidor.

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

Con Vaadin, se puede olvidar por completo (objetos de transferencia de datos) del DTO, los problemas de seguridad basadas en el protocolo, Hibernate excepciones carga diferida, etc.

Usted está en cierto sentido sólo escribir una aplicación de escritorio Java Swing regulares de edad, sólo se está utilizando un conjunto de herramientas de interfaz de usuario diferente de oscilación.

A partir de mi experiencia GWT requiere mucho código repetitivo y la interfaz de usuario cuando se construye complecated y rico lento. Por lo general, nos ocupamos de modelos de aplicaciones muy complejas que tiene muchos objetos de dominio con persistencia. Para llevar a todos estos datos al cliente tendrá que introducir modelo cliente independiente y ofrecer un mecanismo de conversión de datos. Hemos utilizado bulldozer para este fin y se necesita mucho tiempo para trazar sendas, crear convertidores personalizados y probar todas estas cosas.

Por otro lado, si no caen en manipulación excesiva y si la aplicación no es muy complicado que pueda tomar una ventaja de utilizar los recursos del cliente y tienen menos carga en el servidor. De esta manera es posible reducir drásticamente la comunicación con el servidor y obtener el software mucho más sensible.

Vadin parece muy revelador frinedly :) Pero un poco de miedo "masiva AJAX ataque" al servidor. Tengo experiencia en ZK y a menudo nos enfrentamos a los problemas de rendimiento cuando una operación trivial en la interfaz de usuario funciona lento, ya que requiere la comunicación con el servidor.

Wicket es otro buen marco, pero es más adecuado para los sitios web. Se puede trabajar con y sin AJAX, pueden ser indexados por los motores de búsqueda. Y lo más atractivo se trata de código HTML limpio -. No hay etiquetas personalizadas, no hay estructuras de control, estricta separación de las preocupaciones y sólo namigs wicketid específicas para componentes

Depende sobre todo de sus necesidades:

Si necesitas aplicación muy rápida y simple - utilizar GWT y utilizar los recursos del cliente
Si su aplicación es bastante complejo que Vaadin parece ser la mejor opción
Si su aplicación es pública y que necesita una habilidad para indexarlo para SEO que eligió peatonal incorporada.

La cosa es que, para el desarrollo serio, no puede olvidarse de nada, y mucho dtos solos .. Estoy abandonando la costura, y el concepto de interfaz de usuario del lado del servidor sólo porque desean un mayor control sobre lo que está pasando en el cable de vaadin .. problema para mí es precisamente que, teniendo estado en el lado del servidor ..

Hubo "preocupaciones" sobre peatonal incorporada utilizando sesiones para gestionar estados 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 es generalmente mal acerca de cómo medir potenciales (entre otras cosas) de un framework web. De JSF para Grails, por lo general toma un par de cientos de GB de memoria y archivos JAR de código abierto por lo menos una docena de superposición con la funcionalidad e ineficiente para conseguir una aplicación de producción en marcha. Mire a su alrededor y verá más empresas de alojamiento web no ofrecen una opción práctica de Java debido a la errática trayectoria tecnologías Java han dado por marcos web. GWT 2.1 sigue siendo un dolor de usar debido a la velocidad de compilación y se acaba poniendo serio con mesas y MVP de datos que deberían haber estado ahí desde el principio. Me gusta Wicket pero Vaadin parece prometedor ... pero saber cómo van los marcos de Java, estoy seguro de que van a disparar en el pie en algún momento, pero dudo que será a causa del procesamiento del lado del servidor pesada.

Para la construcción de buen aspecto de la interfaz de usuario, yo diría que este sería el camino a seguir. Además, está muy bien documentada.

He estado usando durante un par de semanas y I realmente como hasta ahora. Código es sólido, docs una buena re, construcción muy lógico, los resultados finales son excelentes.

Me encanta que en combinación con Hibernate para ordenar toda la base de datos de tedio.

Plus - Fácil de implementar (Con Tomcat puede acaba de subir un solo archivo .WAR a través de la interfaz web, no podría ser más fácil)

También vale la pena considerar como alternativa fuerte Apache Wicket para marcos de Java Web de interfaz de usuario orientada a componentes. Vaadin suena muy bien y no quiero ir en detrimento de esta discusión, pero la elección es una buena cosa. Hay algunos ejemplos con fuente vinculada de la página de inicio, e incluso más en el sitio de WicketStuff, y el excelente libro de Manning forma gran documentación de terceros.

echar un vistazo a la demo Vaadin construir con Maven: http://asolntsev.blogspot.com/2009/11/vaadin-demo.html

pensé Wicket era el camino a seguir, hasta que probé de hacer que funcione de manera eficiente y empecé una depresión (broma). Entonces, me pasa a GWT, que se veía bien, pero no es tan mucho código de placa de la caldera para escribir y la documentación no es tan grande ... -> La luz provenía de Vaadin: simples, operativos, no hay bichos hasta ahora ... !!!

En nuestra empresa, que es predominantemente una gran casa de Java SW (entre otras cosas) llegó a nosotros la oportunidad de crear una nueva web basada product.It era un conjunto de productos y había muchos equipos en tres países en desarrollo esto. Cuando se trataba de nuestro equipo que tenía la opción de usar Vaadin en beneficio de aprovechamiento de nuestro desarrollo java experience.I búsquedas en Google para que me ayude en mi decisión. También leí este post; Sin embargo he elegido contra el uso de Vaadin pesar de que muchos otros equipos eligieron Vadin. A continuación se presentan las razones de un e-mail que envío en ese momento antes de comenzar con el producto (A Vaadin o no). Esto es de mi opinión personal y la desconfianza de los marcos en general siempre está en mí en diversos grados. Así que sólo quería dar otra opinión sobre esta cuestión para el lector.

También fuimos en una juerga de aprendizaje aprender HTML, CSS, CSS Selectores, una lengua maravillosa JavaScript y bibliotecas JS, jQuery y Yui y creado el producto web en tiempo completo con interfaz gráfica de usuario y el cumplimiento del rendimiento; y yo personalmente estoy feliz y el equipo está tan bien, así como los usuarios.

Otros equipos que se tiró Vaadin también crearon sus productos a tiempo y supongo que son igualmente feliz. (Sólo que no saben la alegría de JavaScript que se están perdiendo :)).

Como alguien dijo, todas las abstracciones son abstracciones con fugas y cuando tuvieron que emigrar de Vaadin 6 a 7 Vaadin que tenían que hacer bastante re-trabajo y se tardó más tiempo de lo que se pensaba; aunque por supuesto se las arreglaron para moler y finsh ella; Todavía había un poco de retraso debido a this.Also Supongo que había algún problema con InvientCharts complemento que no estaba apoyando Vaadin 7 haciendo que los equipos de comprar ($$) el relacionado Vaadin Gráficos complemento y el cambio de eso ....

Para Vaadin o no

Con Vaadin parece que el subyacente JavaScript, HTML y CSS se generan de forma dinámica desde una aplicación de tipo Java Swing. Desde un punto purista sesgada y probablemente tonta de vista, una "Voy a generar código para usted" lema tal no da un buen olor de diseño. A menos que necesite una abstracción por qué atar con otro marco. Al igual que con cualquier marco de generación de código, que debería funcionar mejor para la abstracción del Vaadin tenía en mente, pero no es muy flexible; Creo que si hacemos la tecnología web es mejor que hacer en las herramientas y lenguajes de los cuales la tecnología ha despertado - bibliotecas saber, HTML, CSS y JavaScript / JavaScript en lugar de confiar en otro nivel de abstracción - el marco Vaadin. Esto puede sentirse ingenuo a un experto GWT o Vaadin desarrollador ya que supongo que los cumplidores de Google generan el código JavaScript más optimizado de sus seres codificado mano,, ayuda a gestionar mejor código entre varios equipos, etc (pero sobre todo cuando en desarrollo de aplicaciones web bastante biggish), mejor desarrollador la productividad, más fácil la depuración, etc. Sin embargo escrito en Java componentes para automóviles Vaadin y luego convertir a JS es que no se siente bien en que muchos de nuestros desarrolladores nunca va a aprender un lenguaje de programación muy importante - JavaScript para el desarrollo web (y ganando terreno rápidamente en el lado del servidor - Node.js ). Cuando se depende de los marcos para obtener su derecho como JavaScript entonces nunca va a sobresalir en ese idioma. Supongo que para una empresa con sede producto es importante conocer de primera mano el lenguaje de la web en su lugar. Como alguien comentó Java se ha convertido como el COBOL del año antaño y es imprescindible para la competencia acumulación de aprender otros idiomas importantes como JavaScript. Sin embargo, habiendo trabajado en JS para el poco tiempo que tengo, me he dado cuenta de que si codificamos con un poco de disciplina (patrón Module), prueba de toda lógica - unidad de JavaScript - JsTestDriver, y ejecutar JSHint, que es un lenguaje bastante potente para trabajar con y la productividad se pone mejor que Java una vez que se aprende. También la mayoría de los componentes del ejemplo importante - OpenLayers están escritos en JS y si es necesario se extienden estos o WORk con óptima que necesita saber JavaScript, o para el caso potentes bibliotecas como D3.js Así que en resumen, aunque hay una gran cantidad de ventajas en el uso de marcos Vaadin y, a la larga, tal vez utilizando JavaScript es importante?

Estoy usando Vaadin también. Aunque la aplicación no es muy grande, lo que me gustó de la experiencia fue que la API fue consistente, en general, bien documentado y dado que estaba desarrollando una nueva herramienta, que era capaz de poner hacia fuera las cosas para un muy exigente cliente en el mismo, o en algunos casos, mejores marcos de tiempo que las herramientas que se utiliza antes.

Muy pocos problemas. El único que en este momento es el cliente insiste en usar el IE 7 (no preguntar) y algunos de los dulces ojos colombófilo no funciona totalmente 100% en un componente complemento (cartografía).

Por cierto, no trabajo para vaadin ya sea: -)

He tratado Wicket y Vaadin tanto y si realmente intenta tanto durante algún tiempo, con en un mes usted sabrá que Vaadin es el camino a seguir y no Wicket, y punto. - Dheeraj G

Hemos visto Wicket donde trabajo pero nos encontramos en lugar de 9.000 archivos, podríamos tener más de 30.000. Tenemos cerca de 1.000 pantallas con nuestra aplicación principal de los servicios financieros y aunque peatonal incorporada se ve muy bien, es extremadamente difícil para convertir nuestro código Struts 1.3 a portillo. Nuestro arquitecto hizo un proyecto POC y sólo 3 pantallas añadió varios cientos de clases (muchos de ellos son para su reutilización). También es difícil Prototipo una pantalla con Wicket desde su html debe coincidir con el código de Java y viceversa.

Vaadin parece prometedor, pero será difícil de vender al equipo.

P.S. No importa cuán grande es un marco, nadie va a aprender si no se utiliza en la industria. Portillo ha estado alrededor por un tiempo, pero muy pocas empresas lo utilizan. La mayoría de los desarrolladores que hablo tienen que ver con el aprendizaje de un nuevo marco que es inútil en una hoja de vida.

La clave es Vaadin utiliza un diseño oscilación similar y ayuda a que empecé en Java usando Swing.

He utilizado Vaadin para desarrollar un giftadvisor en la empresa donde trabajo (no Vaadin;).

Vaadin le permite construir aplicaciones web de bienes por componentes Swinglike.

Si usted está preocupado acerca de ida y vuelta cliente-servidor por cada clic que tengo esto que decir: he creado un botón encima del ratón que cambia el aspecto del botón en sí, al pasar el ratón. Para ello, el marco tiene que ir al servidor y viceversa. Y funciona lo suficientemente rápido imo. Ver http://www.cadeau.nl/sophie de revisar lo que quiero decir.

Me gusta Vaadin, él las habitaciones mis necesidades y webdevelopment hace una brisa.

Saludos, Rob.

Empecé con Vaadin Hace sólo dos días y fue capaz de construir una pequeña aplicación CRUD en OSGi completos con la modularidad, el enlace de datos, servicios OSGi para la persistencia. Una cosa muy agradable es que mi completa interfaz de usuario es sólo 118 líneas de código y apoya las operaciones CRUD completas para una sencilla estructura de Java Bean.

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

Ver Tasklist Vaadin Ejemplo

No me importa el uso de estados en el lado del servidor. Es útil para sus fines. Con la computación en la nube hoy en día de almacenamiento y ancho de banda se están convirtiendo barato. Pero sí puedo ver su punto de una buena perspectiva de diseño, especialmente si quieres RESTify su aplicación. Pero yo creo que hay más ventajas que desventajas con respecto a Vaadin y similares. Una cosa importante, usted no tiene que retocar mucho acerca de sus aplicaciones web de un navegador específico llamémosle IE, JavaScript complejidades / CSS - especialmente si está orientada hacia el back-end como yo. Todas sus aplicaciones web se hace compatible a través de navegador sin tener que preocuparse de nada. Recuerde tiempo de desarrollo es más caro que el de almacenamiento y ancho de banda. Esa es mi opinión. =)

Licenciado bajo: CC-BY-SA con atribución

No afiliado a StackOverflow