El kit de herramientas de GWT: cree potentes interfaces de JavaScript con Java

El kit de herramientas web de GWT, anteriormente conocido como kit de herramientas web de Google, es un conjunto de herramientas de desarrollo para crear y optimizar aplicaciones complejas basadas en navegador mediante el lenguaje de programación Java.

Lo que hace que GWT no sea "otra herramienta de Java para escribir aplicaciones web" es el hecho de que el corazón del kit de herramientas es un compilador que convierte Java en JavaScript (así como HTML y CSS), lo que permite a los desarrolladores escribir aplicaciones web front-end. mientras aprovecha todas las fortalezas de Java.

Incluso es fácil usar una combinación de Java y JavaScript, ya que GWT incluye una sólida arquitectura de interoperabilidad para interactuar con la plataforma web. Al igual que la interfaz nativa de Java (JNI) permite que la máquina virtual de Java (JVM) llame a rutinas específicas de la plataforma (por ejemplo, para acceder a funciones de hardware específicas o usar bibliotecas externas de otros lenguajes), GWT nos permite escribir la mayor parte de un aplicación en Java y luego, si es necesario, usar una API web específica, o aprovechar las bibliotecas de JavaScript existentes, para "volverse nativo" y saltar a JavaScript.

GWT nació como un producto de Google, pero pasó a ser de código abierto a finales de 2011 y, en la actualidad, se publica bajo la licencia Apache (Versión 2) con el nombre GWT Open Source Project . Está administrado por un comité directivo con representantes de varias empresas, incluidas Google, RedHat, ArcBees, Vaadin y Sencha, así como desarrolladores independientes de la comunidad.

GWT en el pasado y en el futuro

Google Web Toolkit se lanzó por primera vez en 2006. Se creó como una herramienta para ayudar a los ingenieros de Google a desarrollar sus complejas aplicaciones basadas en navegador, como AdWords, Google Wallet y Google Vuelos y, más recientemente, se está utilizando en el corazón de Aplicaciones de Google Sheets y Inbox.

En 2006, los navegadores (y los intérpretes de JavaScript) estaban lejos de estar estandarizados. El código front-end era lento, con errores y difícil de usar de manera confiable. Había una falta casi total de bibliotecas y marcos de trabajo de alta calidad para el desarrollo web. Por ejemplo, jQuery ni siquiera existía hasta este año. Entonces, para poder desarrollar aplicaciones web a gran escala, los ingenieros de Google decidieron aprovechar las herramientas y competencias existentes. Java era el lenguaje que mejor se adaptaba a sus necesidades, ya que era muy conocido y estaba perfectamente integrado en los IDE, como Eclipse, y así nació Google Web Toolkit.

El objetivo era más o menos ocultar las diferencias entre los navegadores y encapsular los trucos necesarios para escribir JavaScript eficiente dentro de un compilador de Java, dejando a los desarrolladores libres de la tiranía de los tecnicismos de los navegadores.

Por supuesto, durante la última década, la web ha cambiado; los navegadores se han vuelto más rápidos y han convergido en los estándares de implementación, y se han desarrollado muchos marcos de trabajo y bibliotecas front-end increíbles, incluidos jQuery, Angular, Polymer y React. Entonces, la primera pregunta que naturalmente podría hacer es: "¿GWT sigue siendo útil?"

En una palabra: Sí .

En el contexto del desarrollo web moderno, apuntar a los navegadores es inevitable y JavaScript se ha convertido en la lengua franca de las aplicaciones front-end. Pero, por supuesto, diferentes herramientas e idiomas se adaptan mejor a diferentes tareas. GWT, junto con un puñado de proyectos similares, tiene como objetivo apuntar a los navegadores sin limitar a los desarrolladores a usar JavaScript.

El desarrollo y empleo de herramientas de "compilación a la web" como GWT, en un futuro próximo, será facilitado por el llamado grupo WebAssembly del World Wide Web Consortium. No solo hay un amplio espacio para las herramientas que compilan en JavaScript, sino que este enfoque puede satisfacer una necesidad real en contextos que van desde descargar parte de la computación a los navegadores, reutilizar código y bibliotecas existentes, compartir código entre back-end y front-end. , empleando competencias y flujos de trabajo existentes y aprovechando características de diferentes idiomas (por ejemplo, escritura estática en el caso de GWT).

Se espera que GWT Project lance la versión 2.8 pronto, y la versión 3.0 está en desarrollo, con grandes mejoras en proceso:

• interoperabilidad reinventada con JavaScript
• compilador mejorado (casi totalmente reescrito)
• soporte Java de última generación (por ejemplo, lambdas)

En realidad, la mayoría de las funciones de GWT 3.0 ya están disponibles en el repositorio público de Git. Simplemente revise el tronco, aquí y compile GWT siguiendo la documentación aquí.

La comunidad GWT

Desde que GWT pasó a ser de código abierto en 2011, la comunidad ha asumido un papel fundamental en la evolución del proyecto.

Todo el desarrollo ocurre en el repositorio Git alojado en gwt.googlesource.com, y todas las revisiones de código se realizan en gwt-review.googlesource.com. En estas páginas, cualquier persona interesada en el desarrollo del Toolkit puede contribuir y ver en qué está trabajando la comunidad. Durante los últimos años, el porcentaje de nuevos parches de personas que no son Googlers ha aumentado de alrededor del 5 por ciento en 2012 a alrededor del 25 por ciento en el último año, lo que confirma la creciente participación.

Este año, la comunidad se ha reunido para algunas grandes reuniones en los EE. UU. y Europa. GWT.create, organizado por Vaadin, se llevó a cabo tanto en Munich, Alemania como en Mountain View, California en enero y contó con más de 600 participantes de docenas de países. El 11 de noviembre, en Florencia, Italia, celebraremos la segunda edición de GWTcon, una conferencia de GWT impulsada por la comunidad que estoy ayudando a organizar.

¿Para qué es adecuado GWT?

Una encuesta anual sobre el conjunto de herramientas de GWT, publicada por Vaadin, analiza la evolución del desarrollo de GWT, cómo se sienten los desarrolladores acerca del conjunto de herramientas, lo bueno, lo malo, etc. Esta encuesta también nos permite comprender para qué se utiliza el kit de herramientas, cómo está cambiando la comunidad de usuarios y las expectativas que tienen los desarrolladores para el futuro del kit de herramientas.

El Informe sobre el futuro de GWT para 2015 se puede encontrar aquí y deja en claro que GWT es muy popular para crear aplicaciones web a gran escala. Por ejemplo, en la página 14, dice: "La mayoría de las aplicaciones son aplicaciones comerciales que contienen muchos datos y se trabaja con ellas durante muchas horas al día".

Como era de esperar, es fácil concluir que el entorno natural de GWT es el campo de las aplicaciones web a gran escala, donde la mantenibilidad del código es importante y los grandes equipos se benefician de la estructura del lenguaje Java.

Por otro lado, mirando los puntos de referencia para el código generado por GWT (por ejemplo, en el discurso de apertura de la conferencia GWT.create del año pasado, en las páginas 7, 8 y 11) es fácil ver que, en términos de rendimiento y tamaño del código, el JavaScript compilado es asombrosamente impresionante. Si se usa correctamente, el rendimiento obtenido es comparable al mejor JavaScript escrito a mano. Como resultado, en realidad es factible emplear GWT para portar bibliotecas de Java a la web.

Esto ilumina otro escenario ideal para GWT. El ecosistema de Java está lleno de bibliotecas de alta calidad que no tienen una contraparte lista para usar en JavaScript. El compilador GWT se puede usar para adaptar dichas bibliotecas para la web. En otras palabras, GWT nos permite combinar bibliotecas disponibles tanto en Java como en JavaScript y ejecutarlas en el navegador.

Este enfoque se puede ver en el desarrollo de PicShare, donde mostramos cómo varias bibliotecas de Java que generalmente no se consideran para la web (por ejemplo, NyARToolkit) se pueden trasladar al navegador usando GWT y combinar con API web, incluidas WebRTC y WebGL, para obtener una herramienta de Realidad Aumentada completamente basada en la web. Tuve el orgullo de presentar PicShare en la conferencia GWT.create 2015 en enero pasado.

Bajo el capó: convertir Java en JavaScript

El kit de herramientas GWT es un conjunto de herramientas moderadamente complejo, pero cualquiera puede comenzar a usarlo en un santiamén, gracias a una integración sorprendentemente fácil de usar con Eclipse.

Crear una aplicación simple con GWT es relativamente fácil para cualquier persona con experiencia en proyectos de desarrollo de Java. Pero para comprender lo que “realmente está sucediendo”, vale la pena analizar los componentes principales del conjunto de herramientas:

• Transpilador de Java a JavaScript
• Entorno de tiempo de ejecución de Java emulado
• Capa de interoperabilidad

Compilador de optimización de GWT

Una descripción detallada de cómo funciona el compilador se vuelve muy técnica desde el principio, y no necesitamos profundizar tanto, pero vale la pena ver algunos de los conceptos generales.

Lo primero que debe comprender es que GWT compila Java en JavaScript mediante la traducción al nivel del código fuente. Es decir, la fuente de Java se traduce ( transpilado es el término técnico) a JavaScript. Esto contrasta con tener algún tipo de máquina virtual de Java escrita en JavaScript, que ejecuta el código de bytes de Java. (Esto es realmente posible, y es el enfoque utilizado por Doppio, pero no es así como funciona GWT).

En su lugar, el código Java se divide en un árbol de sintaxis abstracta (AST) que representa los elementos sintácticos del código. Luego se asigna a un Javascript AST equivalente (y optimizado), que finalmente se vuelve a convertir en código JavaScript real.

Sopesar los pros y los contras de la transpilación está lejos del objeto de esta publicación, pero permítanme observar que con este método, GWT puede aprovechar directamente los servicios de recolección de basura del intérprete de JavaScript, junto con cualquier otra característica nativa del navegador.

Hay algunas partes difíciles, por supuesto. Por ejemplo, JavaScript tiene solo un tipo numérico, que no puede contener el tipo entero long de 64 bits de Java, por lo que los tipos long requieren un tratamiento especial por parte del compilador. Además, el tipado estático de Java no tiene un significado directo en JavaScript, por lo que se debe tener especial cuidado para mantener, por ejemplo, las operaciones de encasillado equivalentes después de la transpilación.

Por otro lado, una ventaja fácilmente apreciable de la transpilación es que GWT puede realizar optimizaciones (tanto de tamaño como de rendimiento) a nivel de Java y de JavaScript. El código JavaScript estándar resultante puede incluso procesarse más en su proceso de implementación. Por ejemplo, una práctica común que ahora se ha integrado en la distribución estándar de GWT consiste en optimizar la salida de JavaScript por parte del transpilador utilizando el compilador de cierre de JavaScript a JavaScript altamente especializado (otro regalo de los dioses de Google).

La descripción más detallada del compilador GWT que conozco se puede encontrar en esta presentación de diapositivas y en la charla original de la que proviene. Aquí, puede encontrar detalles sobre otras características interesantes del proceso de compilación, como la capacidad de GWT para dividir el código, generando múltiples archivos de script separados para que el navegador los cargue de forma independiente.

El JRE emulado

El compilador de Java a JavaScript sería poco más que una novedad si no se complementara con una implementación de Java Runtime Environment (JRE), que proporciona las bibliotecas centrales en las que se basa casi cualquier aplicación Java. En términos generales, trabajar en Java sin, por ejemplo, colecciones o métodos de cadena, sería frustrante y, por supuesto, migrar estas bibliotecas es un trabajo titánico. GWT llena este vacío con el llamado JRE emulado.

El JRE emulado no es de ninguna manera una reimplementación completa de Java JRE, sino más bien una especie de selección de clases y métodos que pueden ser útiles (y utilizables) del lado del cliente. Las funcionalidades que se encuentran en Java JRE pero que no encontrará dentro de Emulated JRE se dividen en tres categorías:

• Cosas que no se pueden portar del lado del cliente. Por ejemplo, java.lang.Thread o java.io.File no se pueden implementar en un navegador con la misma semántica de Java. La página del navegador tiene un solo subproceso y no tiene acceso directo al sistema de archivos.

• Cosas que podrían implementarse pero que “costarían demasiado” en términos de tamaño de código, rendimiento o dependencias, y que la comunidad prefiere no tener dentro de GWT. Incluido en esta categoría, por ejemplo, está el reflejo de Java ( java.lang.reflect ) que requeriría que el transpilador mantuviera la información de clase para cada tipo, y eso haría que el tamaño del JavaScript compilado se disparara.

• Cosas en las que nadie tenía interés y por lo tanto no se han implementado.

Si sucede que el JRE emulado no se ajusta a sus necesidades (por ejemplo, necesita alguna clase que no se proporciona), GWT le permite escribir su propia implementación. Este poderoso mecanismo, disponible a través de la etiqueta <super-source> , permite evitar problemas al adaptar nuevas bibliotecas externas que usan partes del JRE no emuladas.

Puede ser demasiado complejo, o incluso imposible, proporcionar una implementación completa de algunas partes del JRE, por lo que, para tareas específicas, es posible que sus propias implementaciones no sigan estrictamente la semántica del JRE de Java, aunque funcionen en su caso específico. De hecho, si está considerando devolver sus clases al proyecto, recuerde que es de suma importancia para el JRE emulado que cada clase incluida siga la misma semántica del Java JRE original. Esto garantiza que cualquiera pueda recompilar el código Java en JavaScript y confiar en que obtendrá los resultados esperados. Siempre asegúrese de que su código se pruebe a fondo antes de devolverlo a la comunidad.

Capa de interoperabilidad

Para ser una herramienta eficaz para la producción de aplicaciones web del mundo real, GWT debe permitir que los desarrolladores interactúen fácilmente con la plataforma subyacente. Es decir, el navegador y el DOM.

Desde el principio, GWT se creó para admitir dicha interacción a través de la interfaz nativa de JavaScript (JSNI), lo que facilita el acceso a las API en el navegador. Por ejemplo, si utiliza funciones de sintaxis exclusivas del compilador GWT, puede escribir el siguiente código Java:

 public static native void nativeMethod(T1 a1, T2 a2, ...) /*-{ //place your JavaScript code here }-*/;

y eres libre de implementar el cuerpo del método en JavaScript. Incluso puede envolver objetos JavaScript en un JavaScriptObject (JSO) y hacerlo accesible en su código Java.

Un ejemplo de dónde entra en juego esta capa se puede encontrar en el contexto de la composición de la interfaz de usuario. La corriente principal de Java siempre ha utilizado el kit de herramientas Widgets estándar para crear elementos de interfaz de usuario, aprovechando la interfaz nativa de Java para acceder a los sistemas de entrada y ventanas del sistema operativo subyacente. La capa de interoperabilidad de GWT hace lo mismo, por lo que los Widgets tradicionales funcionan sin problemas dentro del navegador. La única diferencia es que, en este caso, el sistema subyacente es el navegador y el DOM.

Sin embargo, los marcos front-end nativos han mejorado rápidamente en los últimos años y hoy en día ofrecen ventajas significativas sobre los Widgets de GWT. A medida que estos marcos han crecido en sofisticación, los intentos de implementarlos en JSNI han expuesto deficiencias en la arquitectura de la capa de interoperabilidad. A partir de la versión 2.7, GWT presentó JsInterop, un nuevo enfoque basado en anotaciones de Java, que le permite integrar rápida y fácilmente sus clases de GWT con JavaScript. Ya no es necesario escribir métodos JSNI o clases JSO. En su lugar, simplemente puede usar anotaciones como @JSType o @JSProperty , lo que le permite trabajar con clases nativas de JavaScript como si fueran Java.

La especificación completa de JsInterop aún está en progreso, y las últimas actualizaciones solo se pueden probar compilando la fuente del repositorio de GWT. Pero ya está claro que esta es la nueva dirección que permitirá a GWT mantenerse al día con las plataformas web en evolución.

Un proyecto en curso que aprovecha JsInterop son los elementos de polímero gwt lanzados recientemente, que ponen a disposición de GWT todos los elementos de hierro y papel de Polymer. Lo interesante de esta biblioteca es que los desarrolladores no necesitan generar la API de Java a mano. El proyecto utiliza gwt-api-generator para generar la mayoría de las interfaces directamente analizando la biblioteca Polymer y las anotaciones JSDoc. Esto facilita mantener los enlaces actualizados.

Ultimas palabras

Con las mejoras en el compilador, la capa de interoperabilidad y el rendimiento y el tamaño del código generado en los últimos dos años, está claro que GWT no es solo "otra herramienta de desarrollo web", sino que está en camino de convertirse en un importante conjunto de herramientas de referencia para el desarrollo de aplicaciones web complejas a gran escala, e incluso podría ser una excelente opción para hacer que las aplicaciones más simples sean asombrosas.

Uso GWT a diario en mi trabajo como desarrollador y consultor, pero sobre todo me encanta GWT porque me permite superar los límites de las capacidades del navegador y mostrar que las aplicaciones web modernas pueden ser tan poderosas como las aplicaciones de escritorio.

La comunidad del Proyecto GWT es muy activa y constantemente se proponen nuevas bibliotecas, proyectos y aplicaciones basadas en GWT. En Florencia, la GWTcon2015 impulsada por la comunidad se reunirá el 11 de noviembre. Si se encuentra en la región, espero que venga y conozca a algunos de los principales desarrolladores y aprenda sobre todas las oportunidades para ser parte de la evolución de este increíble conjunto de herramientas.