Dev se acerca a complejas interfaces de usuario de JavaScript [cerrado]

Estoy tratando de comprender el panorama de diferentes enfoques y mejores prácticas, en torno al desarrollo de JavaScript complejo del lado del cliente.

No estoy seguro de qué etiquetar esta clase de aplicación, quizás AJAX o RIA pesadas (pero no complementos como Flash / Silverlight). Me refiero a aplicaciones web con estas características:

• Emular UX de escritorio rico / nativo en JavaScript
• Contiene la mayoría / todos los comportamientos en JS del lado del cliente, utilizando el servidor como una API de datos (Plantillas JSON / Html).

Esto contrasta con el uso del servidor web para la representación de la interfaz de usuario, que produce todo el HTML en un modelo de actualización de página.

Algunos ejemplos son:

• Google Docs / Gmail
• Mindmeister
• Rastreador Pivotal

A medida que avanzamos hacia HTML5, puedo ver este estilo de desarrollo RIA, con JavaScript pesado, cada vez más común y necesario para competir.

PREGUNTA: ¿Cuáles son los enfoques comunes que surgen en torno a la gestión de este tipo de desarrollos pesados ​​de JS?

El código del lado del cliente, a medida que una aplicación crece en funciones, es endiabladamente complicado. Hay problemas para escalar un esfuerzo de desarrollo en varios equipos con JS sin formato (o eso escucho, y puedo creerlo).

Google ha abordado el problema mediante la creación de GWT que compila desde un lenguaje de nivel superior (Java) a JS, apoyándose en la infraestructura de desarrollo existente que tiene el lenguaje de nivel superior (Eclipse, herramientas de refactorización de tipado fuerte), junto con abstracción de compatibilidad del navegador y otros problemas lejos del desarrollador.

Hay otras herramientas, como Script # para C # que hacen algo similar. Todo esto pone a JS más en el papel de un IL (lenguaje intermedio). es decir. "Ya nunca escribes en ese 'lenguaje de bajo nivel'".

Pero esta 'compilación a JS' no es el único enfoque. No es aparente que GWT sea el enfoque dominante ... o de hecho lo será.

¿Qué están haciendo las personas con JavaScript de cliente enriquecido? Algunas preguntas orientadoras:

• ¿La mayoría de las tiendas elaboran JS manualmente (encima de bibliotecas como jQuery et al)?
• ¿O hay muchos enfoques diferentes, sin una mejor práctica clara emergente?
• ¿La mayoría de las tiendas están evitando el desarrollo a escala RIA a favor del modelo más simple para desarrolladores del lado del servidor / redibujado de página? Si es así, ¿durará esto?
• ¿Compilar a JS es quizás una tendencia futura emergente? ¿O esto está mal dirigido?
• ¿Cómo gestionan la complejidad y la refactorización del cliente JS?
• ¿Modularización y distribución del trabajo entre equipos?
• La aplicación, aplicación y prueba de patrones del lado del cliente como MVC / MVP, etc.

Entonces, ¿cuáles son las tendencias emergentes en nuestro futuro de JavaScript pesado y HTML5?

¡Gracias!

La mayoría de las aplicaciones web que veo (y los desarrolladores web con los que he hablado) que se están moviendo en esta dirección están usando jQuery como su base.

Todo el razonamiento detrás de GWT (y lenguajes de varios niveles similares) es que JavaScript es demasiado inestable / demasiado frágil / demasiado cambiante para que lo usen los "programadores reales". Pero si tiene un marco que maneja los bits flakey / fragile / changeable para usted, entonces no hay razón para agregar esa capa adicional de complejidad.

Solo es mi opinión…

Yo diría que GWT es arriesgado. Una vez que decidiste usarlo, estás atascado con él. Básicamente significa que trata su marcado, DOM y algunos aspectos de CSS como un entorno de ejecución. Se está volviendo muy difícil mezclar JavaScript escrito manualmente con GWT a medida que su código de cliente se vuelve cada vez más sofisticado. GWT tiene métodos nativos, pero son bastante limitados en términos de posible aplicabilidad. Esa es una gran compensación y es una gran apuesta.

Google intenta vender GWT como un entorno de ejecución de plataforma X muy rápido con una integración decente del lado del servidor. Pero como otros ya señalaron, ya no es el caso: JQuery y YUI son tan rápidos si no más rápidos. Y es mucho más fácil perfilar y optimizar sus páginas cuando se ensamblan manualmente para que tenga un control total sobre CSS, marcado y JavaScript.

GWT intenta ocultarle la plataforma subyacente, lo que en realidad podría ser una forma incorrecta de hacer las cosas. Muchos de los llamados marcos de componentes web hicieron lo mismo. Se suponía que debía escribir código derivado de XML ambiguo con EL y etiquetas personalizadas. El resultado sería un desastre de HTML mal formado con pequeños trozos de JavaScript asqueroso esparcidos por todo el lugar. Las páginas eran lentas, con errores y totalmente imposibles de mantener.

En nuestro proyecto actual utilizamos Stripes, un marco de trabajo basado en acciones de bajo nivel, y JQuery en el lado del cliente. Es muy fácil hacer Ajax una vez que ve claramente todas las piezas de un rompecabezas: aquí está su código del lado del servidor que funciona con datos. Aquí está su código del lado del cliente: para la recuperación de datos y para hacer que las cosas sucedan en una página. Aquí está su CSS, aquí está su marcado, aquí está su plantilla: todo está limpio y desacoplado. Fácilmente extensible, pirateable, sintonizable y depurable. Me encanta.

Me encanta JQuery con su actitud hacia la velocidad y la simplicidad. Me encanta YUI3 por su modularidad y widgets integrales. Me encanta YUI CSS por darme consistencia en todos los navegadores. Me encanta JavaScript para Good Parts. Me encanta Java por dejarme hacer mi trabajo.

¡Solo BESE, y estarás bien!

He escuchado estas llamadas "aplicaciones de una sola página".

Este es un nuevo entorno, y las reglas aún no están totalmente escritas. Trabajé en una aplicación relativamente importante de una sola página el año pasado (2010), y estas son las herramientas que utilizamos.

El back-end era Java, que usaba servlets para proporcionar un servicio JSON, que la página solía enviar en última instancia el pedido preparado. Este servicio también se utilizó para algunos pasos de validación y fijación de precios.

El código de front-end era javascript. Utilizamos jQuery para manipular los elementos de la página, Pure para crear plantillas y RequireJs para dividir el código en módulos. (La herramienta de compilación de RequireJs se utilizó para proporcionar descargas más óptimas).

Escribimos nuestras pruebas usando qUnit , y tuvimos una prueba de jUnit que usó htmlunit para ejecutar cada prueba de qUnit, luego raspar la salida para obtener resultados y pasar o fallar en función del estado de pase / falla de qUnit. Esos se agregaron a nuestras pruebas de jUnit para el back-end y llegaron a nuestro ci, usando Hudson / Jenkins .

Trabajo en una aplicación de este tipo, construida sobre Ext JS. La aplicación está organizada de forma modular. Los diferentes módulos se implementan como componentes autónomos que se limpian por sí mismos cuando se eliminan de la jerarquía de componentes Ext. Los cargadores bajo demanda cargan componentes adicionales justo antes de que sean necesarios (un archivo js = un componente).

He descubierto que este enfoque no es tan difícil de escalar. Los únicos límites reales con los que me he encontrado están relacionados con tener demasiados elementos DOM en el árbol al mismo tiempo en IE. La solución es descargar estratégicamente partes ocultas de la aplicación. Debido a que toda la manipulación DOM se produce a través de la jerarquía de componentes Ext, el DOM se abstrae casi por completo y el desarrollo sigue siendo sencillo.

Personalmente, creo que los frameworks como jQuery son vitales no solo para lidiar con las variaciones en los diferentes navegadores, sino también para ocultar esas diferencias para que no agreguen ruido al código. Herramientas como GWT, Websharper y otras van más allá y definitivamente tienen un lugar, pero me pregunto si es solo una capa adicional de indirección en la mayoría de los casos.

Algo que me sorprende que nadie haya mencionado son las pruebas unitarias. Ahora se acepta generalmente que las aplicaciones complejas del lado del servidor deben tener pruebas unitarias automatizadas y creo que ya ha llegado el momento en que el JS en aplicaciones RIA es lo suficientemente complejo como para necesitar pruebas unitarias, junto con la arquitectura / código que lo hace posible.

Sin embargo, a diferencia de las aplicaciones complejas del lado del servidor, mi instinto basado en lo que veo y escucho es que la gran mayoría de las aplicaciones complejas del lado del cliente no tienen absolutamente ninguna prueba unitaria (no estoy hablando de pruebas de selenio aquí, pruebas unitarias reales).

Creo que la próxima tendencia emergente será la introducción de pruebas unitarias (y un código que sea comprobable por unidades). Habiendo completado un proyecto con una cantidad moderada de JavaScript no probado en la unidad, espero que sea el último.