jquery gwt extjs gxt gquery

jquery - ¿Todavía es pertinente para GWT para nuevos proyectos?



extjs gxt (5)

Diríjase a: la página de ejemplo de GWT , que muestra ejemplos reales de aplicaciones GWT

Solo lea sobre la naturaleza súper pesada de estos ejemplos.

GWT no es tan liviano, y dudo que haya sido diseñado para crear un marcador de fecha. GWT es algo completamente distinto a jQuery también. Es quizás más comparable a JSF2 que a jQuery. La pregunta "debería usar GWT o jQuery" podría responderse como:

si quieres agregar datapickers, algunos efectos, una tabla ordenable, un autocompletar aquí y allá. Probablemente deberías ir con jQuery.

Si desea averiguar si desea usar GWT como el mecanismo de plantilla / motor frontend, debe considerar otros que sean realmente comparables. Cuando se habla de Java, probablemente JSF2 es tu única opción. Y la curva de aprendizaje de JSF es abrupta.

Estoy cavando más profundo y encontré una publicación triste:

http://polygoncell.blogspot.mx/2013/07/gwt-for-new-project-no-thanks.html

Llegué a esta página porque estaba leyendo sobre los próximos proyectos, como AngularJS, Backbone, aplicaciones de una sola página (SPA): en resumen, Google eliminó GWT. GWT ahora es de código abierto, porque lo abandonaron. Ahora AngularJS obtiene un gran empuje por google.

EDITAR a nuestra querida Andrew me dijo que "probara mi punto"

aquí está el algoritmo para usar para evaluar si una técnica es competitiva.

1) Vaya a su sitio de trabajo favorito

2) Busque {tecnología que le interese} trabajos

3) Verifique el número de aperturas, requisitos de tecnología relacionados, etc.

4) Repita los pasos 2 y 3 para tecnologías competitivas

5) Evaluar

hoy 19. de mayo de 2016, en upwork busqué puestos de trabajo GWT .

Empleos: 23.

angularjs trabajos angularjs .

Empleos: 1338. Eso es correcto. mil trescientos treinta y ocho.

punto probado?

La pregunta ¿Por qué debería usar jQuery en lugar de GWT? puede estar desactualizado (como sus respuestas). Y la most of the otras preguntas relacionadas con SO también pueden estar desactualizadas hoy en día. Entonces, actualicemos el estado del arte sobre la relevancia de GWT para nuevos proyectos.

GWT es más maduro hoy en día

Desde 2009, preguntas / respuestas, GWT ha evolucionado y algunos frameworks JS están disponibles en Java:

  • GwtQuery para jQuery (gQuery)
  • GXT para ExtJS (ex ExtGWT)
  • Smart GWT ha reemplazado a GWT-ext
  • ... y seguramente más ... (no dude en añadir)

Y aún más, el código Java se puede convertir a bibliotecas JS independientes: gwt-exporter

Pero los marcos JS de bajo nivel pueden ser suficientes

Pero cada vez que leo más, veo a los desarrolladores web aconsejar que den la espalda a GWT y que usen directamente frameworks JS ( Firebug , complementos IDE para frameworks JS ...).

Productividad

Sin embargo, me gusta la idea de desarrollar y depurar usando el mismo IDE (Eclipse, Netbeans, IntelliJ IDEA ...). Creo que seré más productivo ... También debería pensar en Documentation and Community (reactividad del foro en cuanto a esta pregunta SO) ...

Preguntas

  1. ¿Para qué tipo de nuevo proyecto de 2014 debería considerarse (o no) GWT?
  2. ¿Hay alternativas pertinentes a GWT para facilitar el desarrollo y la implementación de aplicaciones web AJAX?
  3. ¿Cuáles son el modo y la tendencia actual?

Mi caso específico

Acabo de completar un POC (de una aplicación web de intranet) basado en los scripts http.server.HTTPServer llamadas (POST) de Python3 ( http.server.HTTPServer ) (algunos procesos en C ++) y la recuperación de datos JSON. Algunos JS (sin marco) en la página web para renderizar. Entonces me pregunto cuál es la mejor opción para la próxima iteración.

Pero responda esta pregunta sobre otros casos también. Preferiría que una pregunta / respuesta general fuera útil para mucha más gente.

ACTUALIZACIÓN octubre de 2015

GWT parece menos activo porque no hay un nuevo lanzamiento desde hace 11 meses. Pero en el pasado hasta 13 meses entre las versiones 2.4 y 2.5 . El espejo repo de Git sigue siendo muy activo. Por otra parte, GWT es extensible, y las nuevas características pueden provenir de las librerías GWT sin necesidad de una nueva versión del framework GWT. Consulte, por ejemplo, las bibliotecas de GWT móviles más comunes y los ciclos de liberación correspondientes. ¡Mientras tanto, la tendencia es usar Node.js en todas partes! La adopción de GWT para nuevos proyectos realmente depende de las habilidades / motivación de los desarrolladores y la duración del proyecto (rotación / capacitación / mantenimiento). Algunos otros criterios como la reutilización del código fuente disponible y el tiempo de comercialización también pueden tenerse en cuenta ... Consulte las respuestas a continuación excelentes.

GWT es pertinente. Tiene 130,000 desarrolladores usándolo. Si no me crees, solo mira [GWT regresa en 2015] [blog.xam.de/2014/02/gwt-is-coming-back-in-2015.html] y otra pregunta de stack stack que habla de esto GWT no debería ser su primera opción porque agrega mucha complejidad.

¿Para qué proyectos es bueno GWT? GWT es mucho más complicado :

  • Java es un lenguaje más difícil que hace que sea difícil escribir código incorrecto
  • Compilar a javaScript agrega complejidad
  • GWT fue construido desde cero para aplicaciones web extremadamente complicadas
  • la comunidad GWT tiende a priorizar la experiencia del usuario y el rendimiento sobre la experiencia del desarrollador más que la comunidad javaScript

Sin embargo, es un código más fácil de mantener, es Java, es más rápido y puedes reutilizar tu código en jvm y iOS si usas J2ObjC

hay algunas razones muy convincentes para usar GWT - Java
- reutiliza tu propio código desde otras plataformas. Por ejemplo, la bandeja de entrada de Google reutiliza la mayoría del código de Android en la web usando GWT y vuelve a usar el código en iPhone (gracias a J2ObjC) y en el servidor (gracias a la capacidad de la JVM de ejecutarse en muchas plataformas diferentes). - utilice las bibliotecas y herramientas de Java, los desarrolladores de Java - muchos desarrolladores prefieren Java a js y tienen buenas razones para preferirlo - construido desde cero para aplicaciones web complicadas y de rendimiento. - El código de Java es más limpio y más fácil de mantener

GWT ha ido bajando de acuerdo con las tendencias de Google y, de hecho, las tendencias laborales, pero javaScript y jQuery también están disminuyendo. No sé por qué todas estas tecnologías están cayendo. Mi teoría es que hay muchos frameworks nuevos que están robando desarrolladores de GWT y javaScript. No creo que esto necesariamente signifique que javaScript y GWT estén muriendo. Esto no es más que el resultado de tener mucha más competencia.

Gran respuesta de Steffen. Comencé a tipearlo como un comentario, pero descubrí que escribí más de lo que esperaba, por lo que es una respuesta por separado. No buscando puntos ...

Solo quería agregar 1 punto subjetivo mío. La realidad es que la mayoría de los desarrolladores son los llamados desarrolladores backend sin conocimiento, experiencia y lo más importante deseo de desarrollar web frontend. La realidad del mercado estadounidense de TI es que la mayoría preferiría Java en su currículum sobre JS, PHP, Python y otros idiomas exóticos. El motivo es la compensación. A los desarrolladores de Java, en promedio, se les paga más. No estoy seguro acerca de otros países.

Así que la mayoría de los desarrolladores de una empresa serían desarrolladores de Java (o .NET, que está fuera de esta conversación). Para que funcionen en la interfaz de usuario, debes usar una tecnología compatible con Java, que sería JSP o GWT. JSP requeriría aprender las bibliotecas de JS para que la interfaz sea más o menos presentable.

Obviamente, si desea impresionar al público con una interfaz de usuario única, debe usar bibliotecas JS que permitan una mayor personalización. Tanto JSP como GWT funcionarían ya que la mayoría del trabajo se hará en JS. Como mencioné anteriormente, pocas compañías habrían experimentado desarrolladores de JS en el personal.

La mayoría de las aplicaciones están escritas para uso interno, no para público. Según lo que describió, su caso de uso puede pertenecer a esta categoría.

Las herramientas internas que no están orientadas al público a menudo tienen una funcionalidad más compleja que los sitios web públicos, pero sus requisitos de diseño son más relajados siempre que la funcionalidad esté allí y sea conveniente para el uso interno.

En este caso, puede salirse con la suya con GWT, que es menos extraño para los desarrolladores de Java que jQuery y una biblioteca de alto nivel como GXT con un tema estándar.

GWT con GXT para nosotros fue una forma fácil y rápida de crear un conjunto de aplicaciones internas. Con el equipo de desarrolladores de Java que tiene nuestra compañía, nunca nos acercaríamos a la calidad o incluso a la integridad de los proyectos dentro del mismo período de tiempo.

Para el punto 1, puedo darle algunos criterios que usaría:

Cuando se utilizan marcos basados ​​en JavaScript, generalmente se es muy rápido en la creación inicial del código. En mi experiencia, eres mucho más lento cuando se trata de mantenimiento (corrección de errores, nuevas características, refactorizaciones) ya que el soporte de herramientas no es tan bueno como lo es para los lenguajes estáticos. Entonces, para proyectos de mayor o mayor duración siempre elegiría GWT por Java y sus verificaciones de compilador / ecosistema / herramienta. Creo que se beneficiará de una mayor eficiencia y escalado en el desarrollo a lo largo del tiempo, ya que no tendrá problemas extraños debido al tipado dinámico. Para proyectos más pequeños que no vivirán demasiado tiempo o no necesitarán grandes refactorizaciones, JavaScript Frameworks puede ser un gran impulso en la velocidad de desarrollo.

Las necesidades de depuración en el contexto de su plataforma objetivo también son un criterio para mí. Depurar el código GWT es muy bueno siempre que tenga un navegador que sea compatible con DevMode o al menos se pueda usar con los nuevos mapas basados ​​en fuentes basados ​​en SuperDevMode. Por ejemplo, Safari en MacOS X no es compatible. Para dispositivos móviles, puede eliminar JavaScript de forma remota en Android Chrome, pero hasta donde sé, esto no es posible para GWT.

Otro criterio para mí es el tamaño del equipo y la tasa de rotación. Las herramientas basadas en Java (IDE, comprobadores de calidad de código, ...) ayudan a los desarrolladores, especialmente a los nuevos, a navegar a través del código de otros desarrolladores. Esto también es cierto para otros lenguajes de tipos estáticos, pero usted solicitó GWT / Java.

La siguiente es la pregunta de pila ... GWT resuelve fácilmente el cliente y la parte de comunicación remota si usa un contenedor de servlets en el lado del servidor. También es fácil combinarlo con tecnologías empresariales maduras de Java (JPA, EJB, Spring framework, ...). Esta es una gran fortaleza si necesitas / quieres tener la pila. Si va a ser políglota sin JVM en su lado del servidor (como se mencionó anteriormente), este no es para usted.

Claro, hay más criterios para los marcos de GWT y JavaScript.

Y la gran pregunta es acerca de las preferencias. JavaScript tiene conceptos realmente agradables (por ejemplo, Closures) pero también es un riesgo debido a su tipado dinámico. ¿Cuál prefieres?

En cuanto al punto 2:

No estoy seguro de si existe una alternativa real para GWT que proporcione características y herramientas similares. La mayoría de los otros marcos se centran en un solo aspecto (Widgets, optimización, enlace de datos, comunicación remota, soporte de navegador, I18n, ...). Eso no significa que otros marcos sean malos, pero normalmente se necesita una combinación de marcos diferentes para obtener la funcionalidad que proporciona GWT.

En cuanto al punto 3:

  • Definitivamente echaré un vistazo a TypeScript debido a la mejor capacidad de mecanografía e interoperabilidad con JavaScript
  • Por lo que recuerdo, Dart tiene un objetivo similar
  • El árbol de hoja perenne es JQuery, pero dependiendo de sus necesidades hay buenas alternativas. Pero eso es muy subjetivo
  • Para widgets, Twitter Bootstrap ( http://getbootstrap.com/ ) es bueno si su forma de hacer las cosas está bien para usted. Incluso hay una versión de GWT ( http://gwtbootstrap.github.io/ )

Supongo que para responder al punto 1, tendrías que ver cuál es tu situación actual y cuáles son tus objetivos.

Si tiene un equipo de desarrolladores que han utilizado Java la mayor parte de sus carreras, probablemente pueda esperar unos buenos 6 meses para que aprendan los paradigmas de JavaScript. Si tienes experiencia en idiomas como Groovy o Clojure, probablemente puedas reducir ese tiempo un poco. Entonces, si no espera que el proyecto dure más de un año más o menos, entonces GWT probablemente sea el camino a seguir.

Por el contrario, si tienes un equipo de desarrolladores de JS, pueden encontrar que el sistema de tipado estático es bastante frustrante y aprender a utilizarlo de forma efectiva podría llevarles medio año. Entonces, si este es el caso, entonces probablemente no desee usar GWT para ningún proyecto nuevo donde la curva de aprendizaje supere la productividad.

No estoy muy seguro de lo que el punto 2 está preguntando. Si está preguntando sobre frameworks de pila completos, supongo que podría encontrar algo usando nodejs, aunque no creo que tenga suficiente experiencia para asesorar sobre eso.

En el punto 3, donde trabajo, parece que nos estamos moviendo hacia el uso de frameworks JS (AngularJS en particular) con algunos (nuevos) servidores / servicios escritos en Python y Groovy, y los sistemas heredados aún en Java. También tenemos un par de servicios escritos en Clojure.