java - GWT vs Flex vs?

ajax (12)

Mi compañía está tratando de migrar de una aplicación .NET a algo que se basa exclusivamente en la web y es muy "ajaxy". La aplicación .NET original es bastante interactiva, más o menos equivalente a Google Maps en lo que respecta a la interacción del usuario (zoom, panorámica, anotación de características en un mapa vectorial).

Nuestro desarrollador de .NET realmente se toma con Flex2 . Admitiré tener un sesgo de Java bastante fuerte. También tengo alrededor de un año de experiencia con GWT , y puedo hacer las cosas bastante rápido con él. Nuestra base de código es principalmente J2EE , por lo que GWT parece una opción natural para mí. No tengo experiencia con Flex, así que realmente no puedo hacer una recomendación a favor o en contra

Nuestros principales intereses en la selección de un marco son los siguientes:

prueba del futuro
funciona en todos los principales navegadores
experiencia de usuario rápida y receptiva
el código debe ser unitario de prueba
el código debe ser mantenible
velocidad y facilidad de desarrollo
admite gráficos vectoriales de algún tipo (SVG a más)

¿Tiene en cuenta los pros y los contras de estas dos tecnologías, o incluso recomienda una tercera opción?

Esta es realmente una pregunta de manzanas / naranjas. Con GWT, obtienes la pureza de escribir todo en Java. Irónicamente, el resultado final nunca se sentirá como algo más que un sitio web.

Con Flex, puedes escribir algo que se siente como una aplicación. Y, quizás lo más importante, con Flex, no hay NADA que no pueda hacer programáticamente, ya sea funcional o gráfico.

Si está desarrollando aplicaciones para una base de usuarios específica, Flex es un ganador por millas. Si está construyendo una red social masiva basada en lo que sea, GWT es definitivamente una mejor opción.

Estoy predispuesto hacia Flex, ya que he estado desarrollando Flash / Flex desde el año 2000. Sin embargo, para responder a su pregunta, realmente se trata del nivel de interactividad y complejidad que desea lograr.

Flex le permitirá hacer cosas que serían casi imposibles en un entorno de JavaScript (ASP.NET AJAX, jQuery, GWT), como simples gráficos en 3D. Construir interactividad compleja es realmente trivial en Flex. También es muy rápido y puede manejar muchos objetos animados a la vez. Flex puede comunicarse sin problemas con .NET o Java utilizando servicios web. La desventaja de usar Flex es que se siente como una aplicación integrada en su sitio web en lugar de algo que está estrechamente integrado.

Si va a seguir con un enfoque de JavaScript, generalmente sugeriría usar algo que no sea el idioma como jQuery. Pero como ya tienes experiencia con GWT, eso puede funcionar bien para tu proyecto. La desventaja es que GWT al final sigue siendo JavaScript, por lo que estará limitado por la velocidad y la interactividad de lo que es posible en un navegador.

Fui parte de un proyecto que usaba GWT, y me encantó, especialmente porque Java es mi principal lenguaje de programación de elección. No he usado Flex, así que solo te doy información sobre lo que he experimentado con GWT. Para comentar sobre algunos de tus requisitos

* a prueba de futuro: GWT ya ha estado allí por un par de años, y es continuamente respaldado por Google.
* funciona en todos los principales navegadores: si usó GWT, la programación entre navegadores nunca ha sido tan fácil. ¡GWT hace esto por ti!
* El código debe ser comprobable por unidad: sí, puede probar la unidad GWT, también es fácil depurar GWT.
* velocidad y facilidad de desarrollo: Ajax se hace mucho menos complicado gracias a GWT. Solo eso podría acelerar su desarrollo de RIA.

Aparte de estos, solo tengo que decir: ¡me encanta su grupo de Google! Es muy activo y podría encontrar mucha gente que podría ayudarlo en caso de que se quede atrapado en algo.

He usado ambas tecnologías desde hace un tiempo.

Futureproof: supongo que ambos tendrán éxito, pero se preferirá cada tecnología en diferentes situaciones. Por ejemplo, flex en empresas grandes (principalmente intranet) con el escritorio deseado como ui (Flex se puede usar en la parte superior de cualquier plataforma de servidor (jvm, .Net, php, ruby, coldfusion)). De lo contrario, GWT dominará en aplicaciones pequeñas a medianas con el backend jvm tradicional (tomcat + spring, etc.)

Funciona en todos los principales navegadores; ambos no son problemáticos de esta manera. Flex absolutamente excelente, cuando se instala el complemento flash no es necesario resolver ninguna compatibilidad entre navegadores (por supuesto ... el navegador es pasivo, cuando se ejecuta la aplicación flash :). Recuerdo que tuvimos algunos problemas menores con GWT y el traficante de problemas IE6, pero nada horrible ...

Experiencia de usuario rápida y receptiva: ambas son las mejores en su categoría. Flex creo que absolutamente la mejor de todas las soluciones RIA (quizás Silverlight, java fx puede ser solo competencia en richnest), especialmente integrada con LCDS con funciones geniales como gestión de datos, datos de servidor reales, etc. GWT es uno de los mejores en la categoría de marco ajax. Cuanto más rico y complicado que necesites, más razones tienes para usar flex que tienes. En cualquier caso, el JavaScript interpretado no puede ser más rápido y receptivo que el compilado actionscript / swf.

El código debe ser comprobable por unidad: sí, son muy comprobables.

El código debe ser mantenible, ambos excelentes, manteniendo actionscript es comparable a java (gwt), si usa un buen IDE, por ejemplo, Flex Builder.

Velocidad y facilidad de desarrollo, ambas perfectas si conoce a su personal. Todo depende de tu entorno. Para la curva de aprendizaje del desarrollador de java típico para flexionar será probablemente un poco más difícil (Necesita aprender un nuevo compilador / tiempo de ejecución y probablemente nuevo IDE o al menos nuevo complemento IDE de eclipse :). Algunos conocimientos de flash son un +, pero no son necesarios y solo suelen ser tareas específicas, como la construcción de sus propios componentes, etc.

Admite gráficos vectoriales de algún tipo (SVG a más): no recuerdo problemas, no tengo demasiada experiencia con esto, pero lo veré en el futuro cuando FXG se finalice.

Costos de desarrollo e implementación: el ganador es claro aquí. GWT. Flex fue desarrollado para obtener ganancias. Aunque el self es de fuentes abiertas, las mejores herramientas (Flex Builder, nuevo Flash Builder / Catalyst) y frameworks (LCDS) son comerciales y no son nada baratas. Mire la lista de precios de LCDS por CPU y sabrá de lo que estoy hablando. Con GWT, la mayoría de las herramientas / marcos de calidad son de fuentes abiertas o gratuitas al menos. Excepto algunos componentes avanzados como ext gwt y smartgwt EE. Obviamente puedes vivir sin ellos.

Las futuras pruebas se refieren más a la arquitectura que a una tecnología específica. Con la arquitectura adecuada, puede intercambiar fácilmente la tecnología de presentación. Me gusta Silverlight / MVVM aunque el patrón requiere un poco de planificación para soportar también HTML5.

Mi compañía se enfrentó a la misma decisión hace un año. ¿Has oído hablar de GXT http://extjs.com/products/gxt/ ? Finalmente elegimos GXT. Como desarrollador de .NET, hacer la transición de .NET a GXT fue genial. Desarrollamos un programa de gestión para toda la empresa con GXT / GWT. Las desventajas son que GXT es desarrollado por un equipo mucho más pequeño en comparación con Flex y la comunidad no es tan grande. Sin embargo, ofrece una experiencia impresionante en el navegador. Echale un vistazo.

No estoy familiarizado con GWT, pero estoy muy familiarizado con Flex. A pesar de que GWT está basado en Java (y parece que eres en gran medida una tienda de Java), recomendaría Flex en función de tus intereses listados:

Futureproof: los poderes de Flash de YouTube y un gran porcentaje de multimedia en la web ... lo han incorporado a las consolas de videojuegos e Intel está convirtiéndolo en cajas de seguridad. Va a estar aquí por mucho, mucho tiempo, y Adobe siempre ha mantenido una compatibilidad al 100% con sus reproductores Flash.
Funciona en todos los principales navegadores, sí. Y con Flash Player 10, eso también incluye sistemas Linux. Y con dolores de cabeza administrativos mínimos (mucho menos que Java, en mi opinión).
Experiencia de usuario rápida y receptiva: sí, aunque Java puede ser más rápido en algunos escenarios. Flash está optimizado para la reproducción de vectores, por lo que dado que ese es su objetivo, puede ofrecerle un mejor rendimiento que Java.
El código debe ser comprobable por unidad: sí, consulte FlexUnit.
El código debe ser mantenible, definitivamente. AS3 es un lenguaje serio, no un lenguaje de secuencias de comandos de juguete. Será muy familiar para los usuarios de C # o Java.
Velocidad y facilidad de desarrollo: por lo que está haciendo, podrá encontrar docenas de ejemplos de lo que describió exactamente: zoom y panorámica de imágenes vectoriales similares a Google Maps. El núcleo del tiempo de ejecución es un motor de gráficos bien diseñado, por lo que construir una aplicación de gráficos interactivos es su tarea natural.
Admite gráficos vectoriales de algún tipo (SVG a más); obviamente, Flash lo hace de forma nativa. SVG es compatible en la etapa de compilación (puede compilar en SVG pero no puede analizar SVG en tiempo de ejecución). Hay cadenas de herramientas disponibles que convertirán SVG a SWF para usted en tiempo de ejecución.

La única razón por la que vería el uso de GWT sería mantener su tienda Java en el servidor y el cliente ... pero, de nuevo, está buscando la mejor tecnología para el trabajo, ¿verdad? En ese caso, diría que Flash (y, en particular, el marco Flex) es el más adecuado para lo que quieres lograr.

Otro punto a tener en cuenta es que ni el iPhone ni Android actualmente son compatibles con Flash. Mucha más gente espera acceder a aplicaciones web en sus teléfonos.

Sé que preguntaste sobre GWT vs Flex, pero si tienes algo que decir sobre la decisión final, deberías considerar seriamente si te alejas de AJAX y ASP.NET. A pesar de lo que dicen Adobe, Microsoft y Sun, los RIA (Rich Internet Applications) aún no están listos para una experiencia de navegador de horario estelar, excepto en forma limitada (como reproductores de video).

Una aplicación completa escrita para el navegador, en la tecnología nativa del navegador , brindará la mejor experiencia posible al usuario y tendrá la mayor cantidad de recursos de desarrollo disponibles para mantenerla.

ASP.NET no va a ningún lado. Tampoco lo es Java o Flex. Pero para un alcance total, la mejor experiencia de usuario posible en general y la capacidad de mantenimiento (debido a que hay muchos más recursos de programación disponibles), no se puede superar una aplicación nativa basada en el navegador.

ASP.NET MVC es puramente basado en la web y muy Ajaxy. Deberías revisarlo. Es similar a Ruby on Rails (sin los rieles) y los desarrolladores (incluso los desarrolladores nuevos de ASP.NET) están bastante entusiasmados con él.

Si bien iPhone y Android aún no admiten flash, también debes tener en cuenta que Google crea aplicaciones para el teléfono móvil. Lo hacen porque la pantalla de los dispositivos móviles es mucho más pequeña que la computadora portátil / de escritorio típica. Por lo tanto, la falta de soporte flash no es un problema, ya que una aplicación específica proporciona una mejor experiencia de usuario.

Solo estoy medianamente familiarizado con Flex, pero he trabajado con GWT durante muchos años. Tuvimos que tomar una decisión similar hace algunos años (Flash vs GWT), pero por diferentes razones. Al final vimos las muchas ventajas de GWT sobre Flash (muchas de las cuales se aplican a Flex):

No todos nuestros clientes tienen flash, los números de penetración de Adobe son inútiles, usted necesita el suyo (que nosotros tenemos) para ver lo que sus clientes realmente tienen. En los mercados corporativos y educativos, la penetración es mucho más baja que los 90 altos que cita Adobe.
GWT es realmente compatible con múltiples navegadores y plataformas (Linux, Mac, Windows, Android, iPhone, etc.) mientras que el flash nunca lo será. Puede que no te importe eso, pero lo hicimos.
Flex es propiedad de la tecnología de Adobe, mientras que GWT es completamente de código abierto y personalizable
GWT se integra con el DOM, y todo lo demás en su página es mucho más fácil que flash y Flex do.
GWT está codificado en Java, y todos conocemos Java muy bien

Para abordar sus puntos específicos:

* futureproof

Nada es realmente a prueba de futuro, pero creo que tanto GWT como Flex serían bastante a prueba de futuro. Tal vez GWT un poco más porque es de código abierto.

* works on all major browsers

GWT funciona en Firefox (y en todos los navegadores gecko), Safari (y todos los navegadores Webkit), IE y Opera. Flex funciona en todos los navegadores, pero solo si se admite Flash, por lo que diría que GWT sale a la vanguardia.

* fast & responsive user experience

En las plataformas donde es compatible, Flex va a matar a GWT muerto para la experiencia del usuario. Simplemente no se puede competir con flash cuando se trata de suavidad y astucia.

* code should be unit testable

Ambos son fácilmente comprobables por unidad

* code must be maintainable

Cuando están bien codificados ambos son mantenibles

* speed & ease of development

Siempre y cuando estés familiarizado con ellos, diría que es mucho más.

* supports vector graphics of some sort (SVG a plus)

No puedo hablar por Flex, pero GWT admite gráficos vectoriales vía SVG, a través de bibliotecas de terceros.

Sun lanzó recientemente una nueva tecnología llamada JavaFX para este tipo de RIA. Es posible que desee verificarlo (javafx.com). Se supone que debe ejecutarse en Java 5 o superior, pero definitivamente no tendrá el tipo de penetración de cliente que Flash tiene. Sin embargo, creo que teniendo en cuenta sus requisitos para las pruebas, esta tecnología puede no ser adecuada en este momento.

Además, creo que Troy Gilbert cometió un error en su publicación. Específicamente, parece indicar que se ejecutará una aplicación GWT (por el cliente) en Java. Estoy casi seguro de que una aplicación GWT se escribe primero en Java y luego GWT la compilará en una biblioteca de JavaScript que el cliente ejecute.