javascript - los - ¿Debo usar Google Web Toolkit para mi nueva aplicación web?
que es toolkit (12)
Me gustaría crear una aplicación web AJAX interactiva respaldada por la base de datos que tenga un sistema de calendario personalizado (tipos específicos de eventos, edición). Esto implicaría bastante JavaScript y AJAX, y pensé en Google Web Toolkit para la interfaz y en Ruby on Rails para el lado del servidor.
¿Google Web Toolkit es confiable y bueno? ¿Qué riesgos ocultos podría haber si elijo Google Web Toolkit? ¿Se puede combinar fácilmente con Ruby on Rails en el lado del servidor? ¿O debería tratar de usar directamente una biblioteca de JavaScript como jQuery?
No tengo experiencia en desarrollo web, excepto algo de HTML, pero soy un programador experimentado (c ++, java, c #), y me gustaría utilizar solo herramientas gratuitas para este proyecto.
Definitivamente debería usar GWT para un nuevo proyecto (también es bastante fácil de usar en un proyecto anterior).
Mi experiencia es muy rápida de aprender y usar. El código compilado de JavaScript es mucho mejor que cualquier cosa que puedas escribir a mano y también funciona rápido.
Otro beneficio es la capacidad de depurar tu código (que es un infierno con javascript solo)
Escribí sobre algunas de las desventajas de GWT recientemente. Principalmente, las desventajas son: un ciclo de implementación largo para cambios en algunas partes de la aplicación y una curva de aprendizaje bastante empinada. Como programador experimentado de Java, el segundo debería ser un problema menor y si utiliza un servidor independiente, el primero también se mitiga (ya que se requiere una redistribución completa cuando se cambia la parte ''servidor'' de la aplicación).
Este blog tiene aportaciones de muchos usuarios experimentados de GWT y tiene algunos puntos de discusión. Personalmente tengo una gran experiencia con variados marcos de interfaz de usuario. Agregaré mis dos centavos. Veamos las ventajas y desventajas fundamentales de GWT
Ventaja fundamental
GWT lleva la programación de la capa web a JAVA. Entonces, las ventajas obvias de Java comienzan a entrar en juego. Proporcionará programación orientada a objetos. También proporcionará grandes revisiones de depuración y tiempo de compilación. Como genera HTML y Javascript, también tendrá la capacidad de ocultar cierta complejidad dentro de su generador.
Desventaja fundamental
La desventaja comienza desde la misma declaración. GWT lleva la programación de la capa web a JAVA. Si conoce JAVA, probablemente nunca buscará un idioma alternativo para escribir su lógica comercial. Es autosuficiente y genial. Pero cuando se trata de escribir configuraciones para una aplicación JAVA. Usamos archivos de propiedades, bases de datos, XML, etc. Nunca almacenamos configuraciones en un archivo de clase JAVA. Piensa bien, ¿por qué es eso?
Esto se debe a que la configuración es un dato estático. A menudo requiere jerarquía. Se supone que es legible. Nunca requiere compilación. No requiere conocimiento del lenguaje de programación JAVA. En resumen, es un juego de pelota diferente. Ahora la pregunta es, ¿cómo se relaciona con nuestra discusión?
Ahora, pensemos en una página web. ¿Crees que cuando escribimos una página web escribimos una lógica comercial? Absolutamente no. La página web es solo una configuración. Es una configuración de contenedores y campos jerárquicos. Necesitamos escribir la lógica comercial para los datos que serán capturados y mostrados en la página web y no para crear la página web.
El párrafo anterior hace una declaración muy fuerte. Esto explicará por qué las páginas web basadas en HTML y XML siguen siendo las más populares. XML es el mejor negocio para escribir configuraciones. Un marco debe permitir una clara separación de la página web de la lógica comercial (el objetivo del marco MVC). Al hacer esto, un diseñador web podrá aplicar sus habilidades de visualización y arte para crear páginas web de aspecto brillante simplemente configurando XML y sin preocuparse por las complejidades de un lenguaje de programación. Los desarrolladores podrán usar lo mejor de JAVA empresarial para escribir lógica comercial.
Finalmente, hablemos de las repercusiones en términos directos. GWT rompe este principio por lo que está destinado a fallar. El costo para desarrollar la aplicación GWT será muy alto porque necesitará programadores multiskill para escribir páginas web. La apariencia requerida será muy difícil de lograr. El tiempo de modificación de la página web será muy alto debido a la compilación innecesaria. Y, por último, dado que está escribiendo páginas web en JAVA, es muy fácil corromperlo con lógica comercial. Sin saberlo, introducirás complejidades que deben evitarse.
GWT es de muy alta calidad con una gran comunidad. Sin embargo, necesitas saber CSS si quieres ajustar el aspecto de las cosas (lo harás): CSS puede hacer gran parte del diseño, al igual que la web común si así lo deseas. Las bibliotecas como GWT-ext o ExtGWT pueden ayudar un poco, ya que tienen un aspecto impresionante "fuera de la caja", pero por un precio (tamaño extra para su aplicación).
GWT es un marco maravilloso con mucho potencial. Sin embargo, tenga en cuenta que aún es bastante nuevo. Hay algunos errores no resueltos que realmente pueden molestarlo, y generalmente requieren soluciones feos para pasar. La comunidad es excelente, pero es probable que tarde o temprano termines con algunos problemas que Google aún no puede responder.
Pero oye, digo ve por ello. El potencial de GWT es increíble, y apuesto a que el futuro será brillante.
Nuestro equipo hizo la misma pregunta recientemente y optamos por GWT, especialmente porque el plugin de diseñador hizo que trabajar con GWT fuera más accesible para los expertos que no pertenecen a Java en el equipo. Quien sea que haga esta elección, ¡cuidado! ¡NO uses el plugin GWT Designer! No se ha actualizado (al menos en un año, al parecer) para crear una aplicación GWT que sea compatible con IE8.
Nuestro equipo casi había completado nuestros diseños de aplicaciones, que funcionaban perfectamente en Chrome, FF y Safari. Luego explotaron en IE. IE 7 cargaría páginas parciales (pero no incluye compilaciones) e IE8 ni siquiera pudo cargar la aplicación. Simplemente colgó.
El complemento de diseñador tiene botones que permiten al usuario agregar widgets CellTable que no son compatibles con IE (CellTable, DeckPanel, Panel horizontal, Panel vertical, entre otros). Esto causará un dolor intenso cuando los diseños deban volver a realizarse en Java sin la ayuda del diseñador.
A los usuarios experimentados de GWT les encanta, pero el plugin de diseñador te matará.
RoR es en realidad una de las cosas con las que está hecho el GWT para funcionar bien, siempre y cuando uses REST correctamente. Está en el libro de Aplicaciones de Google Web Toolkit, y aquí puedes ver una demostración del libro usando este tipo de idea. Eso no quiere decir que no tenga ningún problema, pero creo que el soporte está definitivamente disponible.
Hay un buen proyecto para hacer que RoR / GWT sea fácil de encontrar aquí (licencia MIT). No he tenido la oportunidad de probarlo todavía, pero parece que se ha pensado mucho en ello. Una pega es que parece que aún no se ha probado completamente con 2.1 Rails, solo 2.0, por lo que puede encontrarse con algunos errores (probablemente menores y corregibles).
Si conoces JAVA y tienes un lugar donde puedes alojarlo (como un contenedor de tomcat o glassfish), te recomendaría mucho más que usar Ruby para el back-end. La razón principal es que luego puedes compartir todos tus objetos y usar el mecanismo integrado RPC. He hecho esto para muchos de nuestros proyectos y ahorra mucho tiempo, sin mencionar que el código es menos propenso a errores, porque no convierte sus objetos java a nada y luego regresa.
He vinculado mi GWT con Rails antes, usando la función to_json en Rails y luego leyendo el JSON en GWT. Todo es compatible, pero es mucho más molesto que solo hacer el back-end en JAVA.
Por supuesto, si tiene alojamiento barato, entonces los contenedores de Java están prácticamente fuera de discusión, en cuyo caso creo que Rails sería la mejor opción.
Si está buscando integrar GWT con backends que no sean Java, como ROR, PHP, etc., debe tener en cuenta que GWT 1.5 ahora es compatible con los tipos de JavaScript Overlay. Esta característica le permite escribir clases que se pueden mapear sobre la parte superior de los objetos nativos de JavaScript para proporcionar fácilmente métodos de acceso para las propiedades de esos objetos y otras funciones extendidas.
Vea este enlace para más detalles: Tipos de superposición de JavaScript
Por lo tanto, puede devolver los datos codificados JSON de su back-end a través de llamadas AJAX, analizarlos en un objeto JavaScript y luego acceder a los datos a través de su código Java GWT utilizando las clases de superposición que ha creado. O cuando renderiza su página, puede representar datos de configuración estáticos como objetos JavaScript y leerlos a través de este mecanismo, en lugar de tener que hacer una llamada AJAX para obtener los datos.
Si tienes experiencia en Java pero no en Javascript / CSS, entonces GWT va a ser un salvavidas (a menos que quieras aprenderlos, por supuesto). CSS tiene muchos pequeños detalles complicados. No es raro pasar medio día arreglando una desalineación de 2 píxeles que solo ocurre en IE6.
No estoy seguro de lo fácil que sería usar ROR para el back-end ... Es posible, estoy seguro, ya que la comunicación GWT ajax es solo servlets. Pero proporcionan una funcionalidad realmente agradable para pasar objetos Java de ida y vuelta que no podrá utilizar si su servidor no está utilizando Java.
También podría considerar Grails ("Groovy on Rails") que le brinda los beneficios de un framework de Rails y el uso de Java VM.
Puede codificar todo en Java usando GWT, y puede integrar librerías javascript de terceros existentes con él. Es muy bueno. Sin embargo, nunca he usado RoR, así que no puedo decir nada al respecto.