¿Es una buena idea hacer UI 100% en Javascript y proporcionar datos a través de una API?

Mi trabajo principal del día es hacer aplicaciones HTML. Con eso me refiero a las aplicaciones de tipo CRUD utilizadas internamente con muchas vistas de cuadrícula editables, cuadros de texto, menús desplegables, etc. Actualmente estamos utilizando formularios web ASP.NET, que hacen el trabajo, pero el rendimiento es en su mayoría pésimo, y con frecuencia usted tienes que saltar a través de aros para obtener lo que necesitas. Aros que se cuelgan del techo y se incendian.

Así que me pregunto si tal vez sería una buena idea mover toda la interfaz de usuario al lado de JavaScript. Desarrolle un sólido conjunto de controles reutilizables que se adapten específicamente a nuestras necesidades y solo intercambie datos con el servidor. Sí, me gusta el paradigma de "control" (también conocido como "widget"), es bastante adecuado para tales aplicaciones. Entonces, en el lado del servidor, todavía tendríamos un diseño básico similar a nuestro marcado ASPX actual, pero que luego se enviaría al cliente solo una vez, y la parte de Javascript se encargaría de todas las actualizaciones posteriores de la interfaz de usuario.

El problema es que nunca he hecho esto antes, y nunca he visto a nadie hacer esto tampoco, así que no sé cuáles serían los problemas. En particular, estoy preocupado por:

• Rendimiento aún. La evaluación comparativa muestra que actualmente el retraso principal está en el lado del cliente, cuando el navegador intenta volver a representar la mayor parte de la página después de una actualización AJAX. El marcado generado por las formas web ASP.NET le da un nuevo significado a la palabra "web", y los ricos controles Devexpress agregan su propia capa de complejidad de Javascript. ¿Pero sería más rápido recalcular todos los cambios necesarios en el lado de Javascript y luego actualizar solo lo que necesita ser actualizado? Tenga en cuenta que estoy hablando de formularios que tienen varias vistas de cuadrícula editables, muchos cuadros de texto, muchos menús desplegables cada uno con medio millón de elementos filtrables, etc.
• Facilidad de desarrollo . Habría mucho más Javascript ahora, y probablemente se mezclaría con el marcado HTML de la página. Eso o algún tipo de nuevo motor de visualización tendría que ser producido. Intellisense para Javascript también es mucho peor que para el código C #, y debido a la naturaleza dinámica de Javascript no se puede esperar que mejore mucho. Las prácticas de codificación pueden mejorarlo un poco, pero no mucho. Además, la mayoría de nuestros desarrolladores son principalmente desarrolladores de C #, por lo que habrá cierta curva de aprendizaje y errores iniciales.
• Seguridad . Se deberán realizar muchas comprobaciones de seguridad dos veces (del lado del servidor y del lado de la interfaz de usuario), y el lado del servidor de procesamiento de datos tendrá que incluir muchas más. Actualmente, si configura un cuadro de texto para que sea de solo lectura en el lado del servidor, puede depender de que su valor no cambie a través del viaje de ida y vuelta del cliente. El marco ya tiene suficiente código para garantizar eso (a través del cifrado de estado de vista). Con el enfoque de solo datos, se vuelve más difícil, ya que debe verificar todo manualmente. Por otro lado, tal vez los agujeros de seguridad sean más fáciles de detectar, ya que solo tendrá que preocuparse por los datos.

Con todo, ¿esto resolverá nuestros problemas o los empeorará? ¿Alguien ha intentado esto alguna vez y cuáles fueron los resultados? ¿Hay algún marco por ahí que ayude en este tipo de esfuerzo (aparte de jQuery y sus equivalentes morales)?

Linkedin hace esto para su sitio móvil (ver http://engineering.linkedin.com/nodejs/blazing-fast-nodejs-10-performance-tips-linkedin-mobile parte 4), y aparentemente ha sido muy beneficioso para ellos desde un punto de vista de rendimiento.

Sin embargo, te sugiero que evites hacer lo mismo, por varias razones.

El primero es la capacidad de mantenimiento: C # / ASP.net es, debido a que es un marco del lado del servidor, independiente del cliente, mientras que Javascript no lo es (incluso con un marco como jQuery no obtendrá una compatibilidad 100% entre navegadores) , no a prueba de futuro). Yo diría que también es más fácil verificar la funcionalidad de una aplicación estáticamente tipada que una dinámica, que es algo que debe considerar absolutamente si está construyendo sitios a gran escala.

El segundo es que le resultará difícil encontrar a otras personas que sean capaces (y estén dispuestas) de crear una aplicación de JavaScript puro del tipo de complejidad necesaria para ejecutar todo su sitio web (en comparación con la relativa facilidad de búsqueda. Programadores NET). Esto podría no ser una preocupación suya directamente, pero ciertamente es algo en lo que pensar desde una perspectiva a largo plazo.

El tercer problema es la compatibilidad del cliente; si está creando sitios web públicos, recuerde que una parte razonable de la red todavía no tiene JS habilitado (por varias razones), por lo que deberá estar absolutamente seguro de que no va a excluir una gran parte de su base de usuarios cambiando a un sitio web basado en JS.

En cuanto a sus preocupaciones con viñetas:

• No me preocuparía demasiado por el aspecto de la seguridad, no hay ninguna razón por la que no pueda mezclar paradigmas y hacer un procesamiento del lado del servidor cuando requiera seguridad (tendrá algún código de representación de vista en algún lugar que devuelva HTML , no hay ninguna razón por la que no pueda hacer que esto simplemente active una llamada AJAX en su lugar, cuando sea necesario).

• La facilidad de desarrollo no es realmente una preocupación también, en mi opinión, hay muy buenas herramientas disponibles para el desarrollo de JS, ¡no se meta solo en VisualStudio porque está acostumbrado! (pruebe JetBrains WebStorm, por ejemplo).

• El rendimiento de los motores de vista JS es absolutamente bueno en la mayoría de los casos (de nuevo, en mi experiencia), los uso mucho en el día a día. Lo que sugeriría es evitar los marcos más pesados ​​como knockout.js, etc., y dirigirse a algo como el motor de micro plantillas de Jon Resig. De esta forma, puede conectar el código de soporte de manera segura, rápida y confiable.

Lo que haría, si fuera usted, es realmente examinar las razones detrás de este cambio; Bien podría ser que simplemente no está aprovechando .NET de manera efectiva y necesita mejorar su juego, WebForms no es un marco fuera de la caja particularmente lento, por lo que tal vez algunas de las bibliotecas de terceros que está utilizando están ralentizando tu renderizado.

Intente hacer un perfil de rendimiento de la aplicación utilizando una herramienta de prueba de carga y creación de perfiles, y vea dónde están sus cuellos de botella antes de hundir una gran cantidad de tiempo y esfuerzo en una solución más radical, probablemente se sorprenderá de lo que encuentre como el culpable de tu lentitud!

Use ExtJS si quiere ir por ese camino, no reinvente la rueda. Pero prepárate, esto significa un cambio de paradigma completo. Sus habilidades HTML son casi obsoletas. AJAX en todas partes, el servidor proporciona principalmente una API AJAX. Escribirás mucho más javascript que nunca, así que mejor asegúrate de estar realmente en forma con javascript.

El equipo en el que estoy decidió migrar a ExtJS a fines de 2008. Teníamos en ese momento una aplicación PHP de 200,000 líneas que sufría problemas de front-end. Nuestra situación era mucho peor que la suya, porque teníamos un marco de controles de formulario manual que era realmente malo, y teníamos un uso intensivo de iframes para cargar secciones de la página (la arquitectura visual se remontaba a 2005, y el equipo no estaba al tanto) de ajax que al principio). Tuvimos que refactorizar el código de todos modos, por lo que fue más fácil decidir volver a diseñar la base de código para que sea principalmente del lado del cliente.

Hoy la aplicación tiene 300,000 líneas, de las cuales 60,000 líneas son código extjs, y aproximadamente 3/4 de la funcionalidad se ha migrado a ExtJS. El código extjs es una aplicación de una sola página, pero aún incorpora algunos formularios heredados dentro de iframes. Primero trasladamos el contenedor de navegación y luego migramos las diferentes áreas de características poco a poco. Con este enfoque, logramos integrar la migración de extjs en el proceso de desarrollo de funciones regulares, sin ralentizarnos demasiado.

• Actuación

  El código ExtJS demostró ser mucho más rápido que el código heredado. El antiguo código era, por supuesto, muy malo en cuanto al rendimiento, pero aun así estamos contentos con los resultados. El código de la interfaz de usuario es todo JavaScript estático, por lo que se almacena en caché realmente bien (estamos en las etapas de planificación de lanzarlo en un CDN). El servidor no está involucrado en el renderizado front-end, lo que reduce la carga de trabajo allí. También ayuda que ExtJS proporcione mucho control sobre el ciclo de vida de la interfaz de usuario (representación diferida, descarga fácil de elementos de interfaz de usuario invisibles). Por lo general, una vez que el código se inicia (arquitectura de carga bajo demanda), la mayor parte del tiempo de carga de una pantalla se gasta en la llamada al servicio web para obtener los datos. La cuadrícula ExtJS es realmente rápida, especialmente cuando se utilizan vistas almacenadas para representar las filas visibles en el desplazamiento.

• Facilidad de desarrollo

  Para ser honesto, este es un bolso mixto. ExtJS es un DSL, no es realmente desarrollo web en el sentido tradicional. A nuestros desarrolladores les llevó mucho tiempo aprender realmente la API del marco, y no veo que esta curva sea menos pronunciada en otros marcos del lado del cliente. Todos en el equipo deben ser desarrolladores de JavaScript "senior" (como regla general, el libro de Crockford no debe guardar secretos). Sufrimos problemas de arranque con los nuevos desarrolladores, porque la experiencia del lado del cliente no está tan extendida como se podría pensar, y la experiencia de extjs es casi nula (en Bélgica, donde estamos ubicados).

  Por otro lado, una vez que esté actualizado, la experiencia de desarrollo es muy agradable. ExtJS es muy poderoso, por lo que si estás en el ritmo puedes crear pantallas increíbles muy rápidamente. IDE-wise utilizamos PHPStorm, que he encontrado que es lo suficientemente competente con el código ExtJS.

• Seguridad

  La seguridad es una de las principales razones para hacer la interfaz de usuario del lado del cliente. La razón es simple: reducción de la superficie de ataque. Las API de servicio web utilizadas por nuestro código ExtJS son una superficie de ataque mucho más pequeña que una capa de interfaz de usuario del lado del servidor. El ASVS de OWASP especifica que debe validar todas las entradas en el servidor para su corrección antes de usarlo. En una arquitectura de servicios web, es obvio y fácil cuándo y cómo hacer la validación de entrada. También me resulta más fácil razonar sobre la seguridad en una arquitectura de interfaz de usuario del lado del cliente. Todavía tenemos problemas con XSS, porque no está exento de codificación a HTML, pero en general somos mucho mejores en seguridad que en la antigua base de código. ExtJS facilita la validación del lado del servidor de los campos de formulario, por lo que no sufrimos mucho tener que escribir el código dos veces.

Si puede permitirse el lujo de no admitir usuarios sin script, y los motores de búsqueda no le conciernen, entonces sí, es un enfoque perfectamente viable. Aquí hay un breve resumen de los pros y los contras:

Pros:

• todo en un solo lugar (javascript)
• puede cargar datos desde el servidor, no marcado, lo que puede ahorrar mucho ancho de banda si se hace correctamente
• es más fácil obtener una aplicación receptiva (la latencia de la red todavía está ahí, pero la respuesta inicial a la entrada de un usuario llega más rápido)
• el servidor web no necesita renderizar HTML ni expandir ninguna plantilla (es decir, el esfuerzo de procesamiento se mueve del servidor al cliente)

Contras:

• todo debe estar en javascript (puede o no ser un problema)
• la lógica crítica debe duplicarse en el servidor
• El estado debe mantenerse en el cliente y el servidor, y sincronizarse entre ambos
• la seguridad puede ser más difícil de corregir (considerando cómo cualquier cosa en el código del lado del cliente puede ser manipulada por usuarios maliciosos)
• expone una gran parte de su base de código (el código que se ejecuta en el servidor no se puede ver desde afuera)

Personalmente, creo que si sigues esta ruta, los UpdatePanels de ASP.NET no son la forma correcta. Son excelentes para ajaxificar parcialmente las aplicaciones web existentes, pero aún envían HTML a través de AJAX, y administrar el estado de esta manera puede ser bastante complicado. Será mejor que vaya hasta el final, sirviendo solo un documento HTML estático, y luego use una biblioteca de plantillas de JavaScript para hacer la representación HTML; el servidor no sirve ningún HTML dinámico, en cambio, el cliente realiza llamadas de nivel de lógica de negocios en el servidor y recibe datos sin procesar.

Si puedes pero ...

Debe asegurarse de tener una "degradación" elegante para que las partes críticas de su aplicación sigan funcionando sin Javascript.

Así es como construyo la mayoría de las aplicaciones al estilo "HIJAX".

Mi sitio todavía está en pañales, pero 100% js ui ha estado bien para mí hasta ahora. La única lógica de servidor que existe en el front-end son las asignaciones de modelos y las URL de ajax. El servidor no tiene ningún conocimiento sobre la interfaz de usuario, lo que para mí es muy fácil de mantener. Si está interesado, puede consultar mi sitio, que está escrito en ExtJS http://coffeedig.com/coffee/ . Mi sitio realmente no tiene ningún problema de seguridad, pero el cliente ayuda al usuario normal mediante una simple validación. Sé que un usuario malintencionado realmente podría enviar cualquier ajax al servidor, por lo que toda la lógica de "seguridad" se realiza en el servidor.

Creo que el mayor problema para usted es que va a hacer una inversión completa de lo que su equipo está acostumbrado, habrá una curva de aprendizaje empinada. Creo que el mejor enfoque sería experimentar con algunos frameworks js e intentar sentirlo escribiendo algunas pantallas simples.