Responderé como un ex ingeniero en Google, que trabajó con Closure y GWT dentro de la compañía y participó en la transferencia de su proyecto de uno a otro. No pretendo saber lo que el equipo de G + / Emerald Sea finalmente eligió Closure, por lo que esta es una suposición educada en el mejor de los casos.
El cierre habría sido la opción predeterminada para la mayoría de los grupos que realizan trabajos pesados de front-end. Ha estado en Google por más tiempo y tiene una base de código más grande y madura para construir. En última instancia, Closure sigue siendo Javascript, lo que significa que se podrían haber utilizado diferentes bibliotecas o marcos para prototipos y luego volver a portarlos a Closure (Por supuesto, todavía es posible en GWT, y de hecho hicimos tal cosa al portar a GWT; Java / La interoperación Javascript es problemática y roba GWT de muchas de sus abstracciones).
GWT es un poco más en bruto, y está a unas pocas capas abstraídas del DOM nativo y CSS / JS. Favorece las IU en forma de tablas y widgets en lugar de los componentes personalizados que usa G +, por lo que habría sido más difícil luchar con la biblioteca de widgets base de GWT en el diseño / comportamiento de las UI más elegantes como el selector de amigos y las galerías de fotos.
GWT también sufre un ciclo de desarrollo muy lento, aunque se compila en Javascript muy rápido (incluso optimizado para el navegador). Dado que GWT se compila , a partir de la fuente de Java, eso solo requiere significativamente más recursos que el código Javascript Closure sin procesar (que no tendría que “compilarse” hasta que esté listo para su lanzamiento). Supuestamente, la depuración es una de las fortalezas de GWT: le permite usar el depurador de su IDE con puntos de interrupción y observación de variables / pila, pero requiere una gran memoria / CPU para conectar el IDE al navegador y aún era ridículamente lento, mientras que la depuración en el navegador a través de inspector / Firebug era casi imposible dado el Javascript compilado y destrozado. Para mí, iterar una interfaz de usuario desde una página en blanco hasta el borrador tomó tal vez un día en Closure, pero más cerca de una semana en GWT.
- ¿Cuál es la diferencia entre la llamada de servicio web, las llamadas de API y las llamadas asíncronas como AJAX en el desarrollo web? ¿Cómo y cuándo usarlos?
- ¿Meteor sería una gran opción para construir una red social como Instagram?
- Entonces, estoy usando AJAX para hacer algo dentro de mi función, pero ¿cómo podría evitar que otros vean cuáles son las variables y dónde están publicando?
- ¿Cómo se implementa el cliente web de Quip?
- ¿Cómo alguien con poca o ninguna experiencia en creación de sitios web podría crear un sitio que sea similar a WikiAnswers?
No estoy tratando de insistir en GWT, sino simplemente señalar que no era la herramienta adecuada para G +. El nuevo front-end de Adwords, por ejemplo, está construido en GWT, lo que tiene mucho más sentido dada su interfaz altamente tabular y basada en informes. La ventaja de Java-as-a-single-development-language todavía se mantiene, y el Javascript generado por GWT sería tan rápido como cualquier JS codificado a mano, y tal vez también compilado Closure JS. Tampoco impide que el equipo construya componentes en GWT dentro de la interfaz de usuario de G + basada en Closure: Angry Birds, por ejemplo, es una aplicación de GWT en la tienda web de Chrome y supongo que sigue siendo una aplicación de GWT en el directorio de juegos de G + .
