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

19

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)?

Vilx-
fuente
So on the server side we would still have a basic layout simliar to our current ASPX markup, but that then would get sent to the client only once, and the Javascript part would take care of all the subsequent UI updates.Está describiendo exactamente qué es ASP.NET, lo que me dice que probablemente no lo esté utilizando correctamente. :) En sus aplicaciones ASP.NET, si coloca componentes dentro de los paneles de actualización, la biblioteca javascript ASP.NET realizará devoluciones de datos asíncronas en el lado del servidor y solo volverá a representar los componentes que especifique.
maple_shaft
@maple_shaft - Lo sé, pero de alguna manera esto funciona lento como el infierno. Además, las cuadrículas ya hacen devoluciones de llamada. Para todo lo demás, si hay una devolución de datos, en la gran mayoría de los casos debe actualizar la mayor parte de la página de todos modos, porque los controles cambian la visibilidad / capacidad de escritura / etc. Y eso es lento.
Vilx-
3
Cada vez que veo una aplicación ASP.NET donde alguien coloca todo en la página dentro de un panel de Actualización, tengo ganas de tirar mi monitor a la pared>. <! Esto derrota prácticamente todo el propósito de ASP.NET. Para mantener el ciclo de vida del lado del servidor y los eventos de la aplicación, es necesario que se comunique de un lado a otro con todo el ViewState de la página. Si tiene 200 controles y una cuadrícula de datos, Joel Spolsky no necesitaría predecir que tendrá problemas de rendimiento masivos. Ed Woodcock y AmmoQ resumieron todo a la perfección, así que no necesito darte una respuesta adicional.
maple_shaft
1
@maple_shaft - Lo siento, pero en realidad hice un perfil de estas cosas. También fue / es lento en las computadoras de desarrolladores locales, y Fiddler mostró claramente que la conexión HTTP se abrió por menos de un segundo, mientras que la página solo apareció varios segundos más tarde, y todo el tiempo mientras el navegador estaba usando tanta CPU como podía obtener y fue básicamente congelado. Eso no es Viewstate hinchado, eso es HTML / Javascript hinchado.
Vilx-
1
@ Vilx: no hay nada de malo en C # /. NET (aparte de solo Windows / costo). Hay grandes problemas con la hinchazón que los frameworks ASP.NET WebForms ponen encima. Como se mencionó, prueba Nancy si te gusta .NET. Pero esto está completamente fuera de tema, fue solo un comentario que le iría mejor si dejara de usar formularios web
Raynos

Respuestas:

10

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!

Ed James
fuente
No, como ya comenté sobre la respuesta de Darknights, esta es una aplicación interna, sin una porción (bueno, pequeña) orientada al público, por lo que la dependencia de JavaScript está bien. Y he hecho perfiles. El lado del servidor es bueno. Es el lado del cliente el que se atasca bajo el HTML generado (como dije, el marcado generado por ASP.NET es pésimo) y el Javascript Devexpress.
Vilx-
1
@EdWoodcock Los sitios web ASP.NET son, por su propia naturaleza, controlados por Javascript. Es cómo maneja la comunicación asincrónica de ViewState y la representación de elementos de página.
maple_shaft
@ Vilx: esto puede sorprender, pero los controles como Data Grids son enormemente complejos. ¿Quizás tienes demasiados elementos en una sola página?
maple_shaft
@ Vilx: tal vez es hora de ver el uso de su control, si están generando un marcado loco (los controles predeterminados de asp.net no lo hacen en la mayoría de los casos si está usando cosas como repetidores en lugar de DataGrids, etc.), entonces tal vez debe rodar sus propios controles (o pasar a HTML escrito a mano en UserControls).
Ed James
1
@maple_shaft - O, más específicamente, Flex, que (según tengo entendido) está construido sobre Flash para exactamente esos fines. Es otra idea con la que he estado jugando durante algún tiempo. Pero ... por mucho que intenté mencionar esto a otros, solo recibí una respuesta negativa, así que no puedo imaginar sacar esto adelante. También requeriría que todos aprendamos algo completamente nuevo.
Vilx-
8

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.

usuario281377
fuente
1
Me siento muy cómodo con Javascript. Sin embargo, sé que otras personas no lo son.
Vilx-
2
Lo hice durante varios años en un trabajo anterior. ExtJS es muy agradable y puedes hacer una gran cantidad con él.
Zachary K
@ZacharyK - ¿Cómo funciona en formas realmente complejas? ¿Los que escribí allí, con varias vistas de cuadrícula, paneles, etc.
Vilx-
2
Muy bien. necesita pensar en sus modelos de datos, por supuesto. Para ser honesto, trato de evitar formas enormes y compongo varios elementos más pequeños. Pero eso tiene menos que ver con los límites de ExtJS que con el buen diseño, etc.
Zachary K
@ZacharyK - Demasiado perezoso para repetirme. Lea mi comentario sobre la respuesta de Ed Woodcock. No puedo hacerlo más simple. :(
Vilx-
8

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.

Joeri Sebrechts
fuente
¡Ojalá pudiera hacer más que solo +1 debido a tu experiencia real!
Vilx-
4

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.

tdammers
fuente
1

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".

Noche oscura
fuente
Las aplicaciones ya tienen mucho javascript y no funcionan sin él. Nuestros clientes están de acuerdo con eso y nunca se han quejado. Y, para ser honesto, todavía no he encontrado un usuario que tenga Javascript deshabilitado hoy en día. Tenga en cuenta también que estas aplicaciones NO necesitan ningún tipo de SEO (sería un desastre si un motor de búsqueda pudiera acceder a toda esa información confidencial), y NO están destinadas para su uso desde dispositivos móviles. También estamos pensando en hacer algo similar para dispositivos móviles, pero eso es solo en etapas conceptuales por ahora, y ni siquiera sabemos si habría una demanda.
Vilx-
2
"Y, para ser honesto, todavía no he encontrado un usuario que tenga Javascript deshabilitado hoy en día". Pues hola entonces. Tengo noscript instalado, por lo que el valor predeterminado para mí es tener JavaScript deshabilitado al aterrizar en un nuevo sitio web. Y si nada funciona, generalmente cierro la pestaña del sitio web.
Arkh
3
@Arkh, estás pensando como un programador, no como un usuario, representamos una pequeña minoría en el gran esquema de las cosas. ¿No vamos a convertir esto en un "a js o no a js?" porque se hizo hasta la muerte en estas partes :)
Darknight
1
Las personas que desactivan JS generalmente son conscientes de que al hacerlo pueden encontrar sitios que dependen de él y, por lo tanto, no funcionarán. Eligen si desean habilitarlo para un sitio en particular, pero si deshabilitan deliberadamente una tecnología estándar, no me importa si no pueden navegar por un sitio. Por otro lado, no sé sobre el soporte de JS para lectores de pantalla. Eso puede ser un problema mayor. Y, por supuesto, está el problema de la indexación. Pero cuando uno quiere hacer una aplicación que no necesita indexación y que de todos modos no podrá ser utilizada por personas ciegas, tiene sentido confiar en JS.
Andrea
1
maple_shaft Me gustas, así que lo diré amablemente, no corramos por ese camino :) ¡gracias!
Darknight
1

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.

por favor
fuente