¿Es buena idea la representación de IU del lado del cliente a través de Javascript?

Question

El enfoque "clásico" del desarrollo web ha sido durante algún tiempo un thin client y un servidor grueso: el servidor genera HTML y lo escupe para que el navegador solo lo represente. Pero con los navegadores actuales (y también debido a la disponibilidad de buenas bibliotecas y marcos) JavaScript ahora funciona. Los desarrolladores web ahora pueden suponer que su código JavaScript funcionará y dejarán de molestar.

Esto ciertamente abrió nuevas posibilidades para el desarrollo web. Las aplicaciones ahora podrían estar compuestas principalmente de contenido HTML devuelto por el servidor y representado por el navegador con cierta manipulación de la interfaz de usuario que se realiza desde el lado del cliente. El cliente podría incluso consultar el servidor para obtener nuevos datos para actualizar partes de la interfaz de usuario. ¿Pero podemos ir por el otro lado? Una aplicación ciertamente puede diseñarse como un servidor que solo escupe el JSON más minimalista unido a un cliente de JavaScript grueso responsable de construir y controlar toda la interfaz de usuario. Sí, este enfoque puede romper las URL en serio en la medida en que las personas ya no pueden enviar punteros, pero es posible diseñar su camino alrededor de eso (y para algunas aplicaciones, como el correo electrónico y los lectores de feeds, esto ni siquiera importar).

¿Qué opinas? ¿Alguna vez has probado ese enfoque? ¿Las cosas se vuelven demasiado lentas? ¿Los navegadores modernos son capaces de manejar esa cantidad de código Javascript? ¿Existen diferencias significativas entre las implementaciones de los navegadores que aún muerden al desarrollador desaconsejado incluso con las últimas bibliotecas? ¿Para qué tipo de aplicaciones cree que es adecuado este enfoque? ¿Es realmente adecuado para cualquier cosa?

Answer 1

Estoy al final de la construcción de este tipo de aplicaciones. Es una GUI de ExtJS además de los servicios web JSON-RPC de Zend Framework, que implementa un portal de gadgets similar a iGoogle.

Ventajas:

• interfaz de usuario muy sensible, ExtJS le da una gran experiencia de usuario.
• Comunicación cliente-servidor muy predecible. Todo es json (fácil de depurar). Hay un manejo de errores estandarizado inherente en la API (al menos así es como lo diseñé).
• El frontal es reemplazable. Podría escribir una aplicación C++ sobre el mismo servidor back-end. La separación entre el front-end y el back-end en las líneas cliente-servidor significa que es más fácil realizar pruebas de forma independiente.
• Tienes la oportunidad de vivir y respirar javascript, que es genial si te gusta.

Desventajas:

• usted tiene que vivir y respirar Javascript, que aspira si lo odias. En nuestro caso, esto significó una gran reorientación del equipo de desarrolladores porque éramos muy pesados ​​en PHP.
• Todo vive en un único DOM de larga vida, por lo que debe estar alerta con la administración de la memoria y asegurarse de que las cosas se limpien correctamente. Además, cargar demasiada UI hace que IE se vaya "¡ay !, ay, estás lastimando mi cerebro".
• No se ejecuta una consulta rápida para buscar una opción en el medio de la generación de la interfaz de usuario. Las limitaciones de diseño del programa de vivir en el cliente son desalentadoras al principio. Te acostumbras, pero es un poco un obstáculo.
• Cargando todo lo que javascript significa que sus usuarios necesitan tener conexiones rápidas y navegadores modernos.

El motivo principal para que lo hiciéramos fue ofrecer una mejor experiencia de usuario. Los usuarios esperan una experiencia similar a la de un escritorio, y no se puede entregar a través de un servidor de ida y vuelta. Tenemos que cumplir eso ahora, pero no se puede negar que existen grandes desafíos con un enfoque como este. En general, estoy satisfecho.

actualización (septiembre de 2013):

Aún utilizando esta arquitectura y sigue pensando que es la arquitectura adecuada si usted está construyendo una aplicación web real (no sólo una página web con algunas características dinámicas). Nuestro equipo y producto ahora es mucho más grande (cerca de 500,000 líneas de código), pero la arquitectura se ha escalado sin problemas. Ahora hay muchos frameworks javascript escalables realmente buenos (angulares, brasas, ...), por lo que es más fácil que nunca adoptar esta forma de trabajar.

Debido @rwoo preguntó: algunos retos que aún tenemos:

• carga bajo demanda de código JS resulta ser un problema más complicado de lo previsto. Es importante incluir esta parte en tu arquitectura.
• Hemos tenido que integrar la validación jshint automática en un enlace precompromiso en subversión porque js es demasiado tolerante con los errores de sintaxis y a menudo no se da cuenta de esto hasta que el producto llega al cliente.
• Como la base de datos se encuentra al otro lado de una solicitud de servicio web, debe diseñar cuidadosamente su API de servicio web o terminará con un rendimiento malo debido a la espera de demasiadas solicitudes XHR. Esto es solvente, pero desafiante, y no se vuelve más fácil con el tiempo.
• Si bien con el marco correcto, los problemas entre navegadores se minimizan, no desaparecen del todo, lo que significa que debe probar en todos los navegadores, todas las versiones. Es tanto trabajo que tiene que automatizarlo usando algo como selenio, y resulta que esto es más difícil de hacer con una interfaz de usuario procesada del lado del cliente que con una interfaz de usuario procesada del lado del servidor.

Answer 2

Herramientas como Google GWT hagan lo que describan, renderice gran parte del lado del cliente en javascript. Parte del diseño de grano grueso todavía se baja usando HTML, pero los bits interesantes se hacen dinámicamente, en el lado del cliente.

Pero GWT utiliza javascript generado, no escrito a mano. Hacer esto a mano es doloroso.

Answer 3

ExtJS, YUI, dojo ... marcos que básicamente ofrecen una mano en aplicaciones de implementación como el que usted está describiendo

Nosotros (mi lugar de trabajo) que se utiliza como método con éxito para muchas grandes & aplicaciones a pequeña escala ... En general basando la mayoría de nuestra aplicación en ExtJS + jQuery, en algunos casos en dojo (Zend Framework (si te importa el mundo PHP) proporciona una práctica integración con elementos dojo)

Si no se abusa y se usa solo por el hecho de usarlo o superar el factor de frescura, es una herramienta increíble.

Con un diseño adecuado, ni pesado ni lento como un enfoque per se.

Answer 4

Lo he hecho a mano. Fue un poco doloroso, pero hay algo bueno. Esto solo es apropiado para aplicaciones ricas de Internet en las que una alternativa tiene poco sentido. Creo que veremos más y más aplicaciones que requieren JavaScript, especialmente después de que lleguen marcos como Cappuccino Atlas.

Answer 5

Creo que es horrible. Difícil de desarrollar Difícil de depurar Es difícil obtener la funcionalidad que desea. Prefiero mantener las aplicaciones web lo más simples posible, y optar por aplicaciones de GUI comunes cuando se necesita algo más complejo.

Answer 6

Su afirmación de que los desarrolladores web ahora pueden "asumir que su código Javascript funciona" es difícil de aceptar. En mi experiencia, el Javascript casi siempre es un agujero negro que chupa todo el tiempo y la energía que puede proporcionarlo. Los frameworks como Prototype y Script.aculo.us han mejorado MUCHO las cosas, pero aún no están tan fortalecidos como su pregunta asume.

Los dos problemas principales son uno, compatibilidad con el navegador y dos es el tiempo de desarrollo. Confía en una aplicación que no puede controlar para manejar la mayor parte de la carga de trabajo de su aplicación. El hecho de que esto pueda romperse incluso con la actualización más pequeña del navegador me preocuparía. Generar HTML en el lado del servidor mitiga este riesgo en gran medida. El desarrollo de una interfaz avanzada de Javascript consume mucho tiempo, es difícil de depurar e igualmente difícil de probar en una amplia gama de navegadores disponibles.

Si bien estas preocupaciones son reales, no se puede ignorar el hecho de que puede lograr fantásticas experiencias de usuario a través del Javascript del lado del cliente. Los marcos que mencioné anteriormente exponen una funcionalidad que ni siquiera se soñó hace uno o dos años y, como resultado, hacen que el precio inicial de desarrollo en gran medida valga la pena (y en ocasiones se acorta significativamente cuando los marcos se implementan efectivamente).

Creo que hay aplicaciones para una IU con Javascript, siempre que la decisión de tomar esa ruta esté bien pensada. No estaríamos discutiendo esto en SO, si no fuera por el hecho de que el potencial de UI que usa esta estrategia es asombroso. Las aplicaciones basadas en la web que utilizan datos basados ​​en la web son candidatos perfectos (RSS, servicios REST). Las aplicaciones que llegan a una base de datos de relaciones o servicios web complejos deben, por necesidad, mantener un acoplamiento más estricto con el lado del servidor.

Mis 2 centavos.

Answer 7

Si entiendo correctamente tu pregunta, creo que te estás refiriendo al tipo de desarrollo que uno hace con algo como ExtJS. Con Ext ya no se escribe HTML, sino que se diseña la aplicación completa en su mayoría en JavaScript, usando técnicas similares a las aplicaciones de desarrollo de GUI en el escritorio.

En su mayor parte, los kits de herramientas modernos casi han eliminado la mayoría de las peculiaridades del navegador. Aunque, de vez en cuando, puede encontrarse con problemas de procesamiento entre navegadores, no es un problema tan grave como lo sería si intentara escribir todo el JS usted mismo. La velocidad debería ser aceptable incluso en IE6, aunque en general obtendrás un mejor rendimiento en una versión reciente de Safari, Chrome o Firefox. (No sé lo suficiente sobre IE7 u 8 para comentar).

Ha aparecido un punto válido, sin embargo, sobre las URL y su capacidad para compartir. Incluso fuera del caso de uso de compartir datos, esto es importante para marcar las ubicaciones dentro de la aplicación. Existen técnicas disponibles para almacenar el estado de la aplicación y poder reconstruirlo, pero hasta donde sé, todavía no es fácil de hacer. Por esta razón, tiene sentido evitar aplicaciones web enriquecidas en situaciones en las que no son necesarias. Las aplicaciones web más simples pueden ser más simples de depurar, probar y mantener.

Dicho esto, hay situaciones en las que las aplicaciones web enriquecidas tienen mucho sentido. Por ejemplo, muchas aplicaciones de escritorio empresariales internas se pueden reescribir para ser aplicaciones web ricas. Pueden proporcionar una apariencia similar, widgets y patrones de interacción como aplicaciones de escritorio que facilitan la transición a una aplicación web. Las aplicaciones externas que implican la manipulación de datos (como el correo electrónico/lectores de noticias, aplicaciones de contabilidad, etc.) también pueden ser una buena opción.

Answer 8

Para aplicaciones de línea de consumo interno en las que puede controlar el escritorio, JavaScript tiene sentido.

Para aplicaciones externas/públicas donde no tiene idea qué navegador usan sus consumidores, manténgalo simple y use lo menos posible.

Cuando dice que Javascript simplemente funciona ahora debido a los marcos, eso no es exactamente así. IE 6 todavía está en uso generalizado, al igual que el Safari antiguo. Incluso FF 2.x, y 1.x en cierta medida, tiene una participación decente en el mercado de consumo.

Junto con eso, no todo el mundo tiene Internet de alta velocidad, que es prácticamente un requisito para muchos de estos marcos. Además, aunque la mayoría de las bibliotecas funcionan con IE 7, es un perro para la mayoría de las operaciones.

En cuanto al tamaño de la biblioteca, tenemos una serie de controles .net a los que les gusta inyectar hasta 1MB de javascript al cliente. Intentando enviar eso a la abuela.

Por último, los teléfonos están recogiendo a los usuarios como un dispositivo principal de acceso a Internet. Desafortunadamente, su tamaño de caché es pequeño y, en su mayor parte, las cosas geniales de JavaScript no funcionan demasiado bien.

Answer 9

El Teatro YUI tiene un video que creo que es altamente relevante a su pregunta - recomiendo encarecidamente observando que

High-performance JavaScript: Why Everything You've Been Taught Is Wrong

El título es un poco engañoso, pero que en realidad habla de los mismos temas que está enfrentando.

Answer 10

Me gusta implementar un enfoque híbrido. Cuando se solicita por primera vez una página, debe llenarse con toda la información que pueda inferir de la URL/Querystring/Post. Y luego cualquier cambio de estado subsecuente puede ser consultado y actualizado usando Ajax.

Mucha gente tiende a adoptar el enfoque de simplemente cargar la página, y luego dejar que el javascript/ajax haga el trabajo de carga. Esto da como resultado que el cliente espere a que se cargue la página y luego el cliente espera a que se carguen los datos.

Mucho mejor que dejar que el servidor haga esa carga de datos inicial y llene todos los elementos de la interfaz de usuario.