usar - que es javascript

Aplicación de una sola página: ventajas y desventajas (11)

He leído sobre SPA y sus ventajas. Encuentro la mayoría de ellos poco convincentes. Hay 3 ventajas que despiertan mis dudas.

Pregunta: ¿Puede actuar como defensor de SPA y demostrar que estoy equivocado acerca de las tres primeras declaraciones?

=== ADVANTAGES ===

1. SPA es extremadamente bueno para sitios muy receptivos:

La representación del lado del servidor es difícil de implementar para todos los estados intermedios: los estados de vista pequeña no se asignan bien a las URL.
Las aplicaciones de una sola página se distinguen por su capacidad para volver a dibujar cualquier parte de la interfaz de usuario sin necesidad de un servidor de ida y vuelta para recuperar HTML. Esto se logra separando los datos de la presentación de datos al tener una capa de modelo que maneja datos y una capa de vista que lee de los modelos.

¿Qué hay de malo en sostener una capa de modelo para no SPA? ¿SPA es la única arquitectura compatible con MVC en el lado del cliente?

2. Con SPA no necesitamos usar consultas adicionales al servidor para descargar páginas.

Hah, ¿y cuántas páginas puede descargar el usuario al visitar su sitio? ¿Dos tres? En su lugar, aparecen otros problemas de seguridad y debe separar su página de inicio de sesión, página de administración, etc. en páginas separadas. A su vez, entra en conflicto con la arquitectura SPA.

3. ¿Puede haber otras ventajas? No escuche nada más ..

=== DISADVANTAGES ===

El cliente debe habilitar javascript.
Solo un punto de entrada al sitio.
Seguridad.

PD : He trabajado en proyectos SPA y no SPA. Y hago esas preguntas porque necesito profundizar mi comprensión. No es para dañar a los seguidores de SPA. No me pidas que lea un poco más sobre SPA. Solo quiero escuchar tus consideraciones sobre eso.

Desventajas

1. El cliente debe habilitar javascript. Sí, esta es una clara desventaja de SPA. En mi caso, sé que puedo esperar que mis usuarios tengan JavaScript habilitado. Si no puede, entonces no puede hacer un SPA, punto. Es como tratar de implementar una aplicación .NET en una máquina sin el .NET Framework instalado.

2. Solo un punto de entrada al sitio. SammyJS este problema usando SammyJS . 2-3 días de trabajo para configurar su enrutamiento correctamente, y las personas podrán crear marcadores de enlaces profundos en su aplicación que funcionen correctamente. Su servidor solo necesitará exponer un punto final - el punto final "déme el HTML + CSS + JS para esta aplicación" (piénselo como una ubicación de descarga / actualización para una aplicación precompilada) - y el JavaScript del lado del cliente que escriba manejar la entrada real en la aplicación.

3. Seguridad. Este problema no es exclusivo de las ZPE, debe tratar la seguridad exactamente de la misma manera cuando tiene una aplicación de cliente-servidor "de la vieja escuela" (el modelo HATEOAS de usar Hipertexto para vincular páginas). Es solo que el usuario está haciendo las solicitudes en lugar de su JavaScript, y que los resultados están en HTML en lugar de JSON o en algún formato de datos. En una aplicación que no sea SPA, debe asegurar las páginas individuales en el servidor, mientras que en una aplicación SPA debe asegurar los puntos finales de los datos. (Y, si no desea que su cliente tenga acceso a todo el código, entonces tiene que dividir el JavaScript descargable en áreas separadas también. Simplemente ato eso en mi sistema de enrutamiento basado en SammyJS para que el navegador solo solicite cosas a las que el cliente sabe que debería tener acceso, basadas en una carga inicial de las funciones del usuario, y luego eso se convierte en un problema).

Ventajas

Una gran ventaja arquitectónica de un SPA (que rara vez se menciona) en muchos casos es la gran reducción en el "chattiness" de su aplicación. Si lo diseña correctamente para manejar la mayor parte del procesamiento en el cliente (el punto principal, después de todo), entonces la cantidad de solicitudes al servidor (leer "posibilidades de 503 errores que arruinan su experiencia de usuario") se reduce drásticamente. De hecho, un SPA hace posible hacer un procesamiento completamente fuera de línea, que es enorme en algunas situaciones.
El rendimiento es ciertamente mejor con la representación del lado del cliente si lo haces bien, pero esta no es la razón más convincente para construir un SPA. (La velocidad de la red está mejorando, después de todo). No defienda el caso de SPA solo por este motivo.
La flexibilidad en el diseño de su IU es quizás la otra gran ventaja que he encontrado. Una vez que definí mi API (con un SDK en JavaScript), pude reescribir completamente mi interfaz sin impacto en el servidor, aparte de algunos archivos de recursos estáticos. ¡Intenta hacer eso con una aplicación MVC tradicional! :) (Esto se vuelve valioso cuando tienes que preocuparte por las implementaciones en vivo y la consistencia de la versión de tu API).

Entonces, en conclusión: si necesita un procesamiento fuera de línea (o al menos desea que sus clientes puedan sobrevivir a interrupciones ocasionales del servidor), reduciendo drásticamente sus propios costos de hardware, y puede suponer JavaScript y navegadores modernos, entonces necesita un SPA. En otros casos, es más una compensación.

En mi desarrollo, encontré dos ventajas distintas para usar un SPA. Eso no quiere decir que lo siguiente no se puede lograr en una aplicación web tradicional solo que veo un beneficio incremental sin introducir desventajas adicionales.

El potencial de una menor solicitud del servidor como la representación de nuevo contenido no siempre es, ni siquiera es, una solicitud del servidor http para una nueva página html. Pero digo potencial porque el contenido nuevo fácilmente podría requerir una llamada Ajax para obtener datos, pero esos datos podrían ser incrementalmente más ligeros que el marcado en sí mismo que proporciona un beneficio neto.
La capacidad de mantener "Estado". En sus términos más simples, establezca una variable en la entrada a la aplicación y estará disponible para otros componentes a lo largo de la experiencia del usuario sin pasarlo o configurarlo en un patrón de almacenamiento local. Sin embargo, la gestión inteligente de esta capacidad es clave para mantener despejado el alcance del nivel superior.

Además de requerir JS (lo cual no es una locura para requerir de aplicaciones web), otras desventajas señaladas son, en mi opinión, ya sea no específicas de SPA o pueden mitigarse a través de buenos hábitos y patrones de desarrollo.

Entiendo que esta es una pregunta anterior, pero me gustaría agregar otra desventaja de las Aplicaciones de una sola página:

Si construye una API que devuelve resultados en un lenguaje de datos (como XML o JSON) en lugar de un lenguaje de formateo (como HTML), está permitiendo una mayor interoperabilidad de aplicaciones, por ejemplo, en aplicaciones de empresa a empresa (B2B). Tal interoperabilidad tiene grandes beneficios, pero permite que las personas escriban software para "minar" (o robar) sus datos. Esta desventaja particular es común a todas las API que usan un lenguaje de datos, y no a SPA en general (de hecho, un SPA que pide al servidor HTML pre-renderizado evita esto, pero a expensas de una mala separación entre modelo y vista). Este riesgo expuesto por esta desventaja puede mitigarse por diversos medios, como limitación de solicitudes y bloqueo de conexiones, etc.

Intente no considerar el uso de un SPA sin definir primero cómo abordará la seguridad y la estabilidad de la API en el lado del servidor. Entonces verá algunas de las verdaderas ventajas de usar un SPA. Específicamente, si utiliza un servidor RESTful que implementa OAUTH 2.0 para la seguridad, obtendrá dos separaciones fundamentales de inquietudes que pueden reducir sus costos de desarrollo y mantenimiento.

Esto moverá la sesión (y su seguridad) al SPA y liberará a su servidor de toda esa sobrecarga.
Sus API se vuelven estables y fácilmente extensibles.

Insinuado a antes, pero no hecho explícito; Si su objetivo es implementar aplicaciones de Android y Apple, escribir un JavaScript SPA envuelto por una llamada nativa para alojar la pantalla en un navegador (Android o Apple) elimina la necesidad de mantener tanto una base de código Apple como una base de código Android.

Me gustaría defender que SPA sea el mejor para aplicaciones basadas en datos. gmail, por supuesto, se trata de datos y, por lo tanto, es un buen candidato para un SPA.

Pero si su página es principalmente para mostrar, por ejemplo, una página de términos de servicio, entonces un SPA es completamente exagerado.

Creo que el punto ideal es tener un sitio con una mezcla de páginas de estilo SPA y static / MVC, dependiendo de la página en particular.

Por ejemplo, en un sitio que estoy construyendo, el usuario aterriza en una página de índice MVC estándar. Pero luego, cuando van a la aplicación real, llama el SPA. Otra ventaja de esto es que el tiempo de carga del SPA no está en la página de inicio, sino en la página de la aplicación. El tiempo de carga en la página de inicio podría ser una distracción para los usuarios del sitio por primera vez.

Este escenario es un poco como usar Flash. Después de algunos años de experiencia, el número de sitios solo Flash cayó a casi cero debido al factor de carga. Pero como un componente de página, todavía está en uso.

Para empresas como Google, Amazon, etc., cuyos servidores se ejecutan a máxima capacidad en modo 24/7, reducir el tráfico significa dinero real, menos hardware, menos energía y menos mantenimiento. Cambiar el uso de la CPU del servidor al cliente vale la pena, y los SPAs brillan. Las ventajas desventajas con sobrepeso por el momento. Entonces, SPA o no SPA depende mucho del caso de uso.

Solo por mencionar otro caso de uso probablemente no tan obvio (para desarrolladores web) para SPA: actualmente estoy buscando una forma de implementar GUI en sistemas integrados y la arquitectura basada en navegador me parece atractiva. Tradicionalmente, no había muchas posibilidades para las IU en los sistemas integrados: Java, Qt, wx, etc. o los marcos comerciales de propiedad. Hace algunos años, Adobe intentó ingresar al mercado con flash, pero parece no tener tanto éxito.

Hoy en día, como los "sistemas integrados" son tan potentes como los mainframes hace algunos años, una interfaz de usuario basada en navegador conectada a la unidad de control a través de REST es una posible solución. La ventaja es la enorme paleta de herramientas para UI sin costo. (Por ejemplo, Qt requiere 20-30 $ por unidad vendida en derechos de regalías más 3000-4000 $ por desarrollador)

Para dicha arquitectura, SPA ofrece muchas ventajas, por ejemplo, un enfoque de desarrollo más familiar para los desarrolladores de aplicaciones de escritorio, acceso reducido al servidor (a menudo en la industria automovilística, la interfaz de usuario y los embrollos del sistema son hardware separado, donde el sistema tiene un sistema operativo RT).

Como el único cliente es el navegador integrado, las desventajas mencionadas como la disponibilidad de JS, el registro en el servidor y la seguridad ya no cuentan.

Soy un pragmático, así que trataré de ver esto en términos de costos y beneficios.

Tenga en cuenta que por cualquier desventaja que doy, reconozco que son solucionables. Es por eso que no veo nada en blanco y negro, sino costos y beneficios.

Ventajas

Seguimiento del estado más sencillo: no es necesario utilizar cookies, envío de formularios, almacenamiento local, almacenamiento de sesiones, etc. para recordar el estado entre cargas de 2 páginas.
El contenido de la placa de la caldera que está en cada página (encabezado, pie de página, logotipo, pancarta de derechos de autor, etc.) solo se carga una vez por cada sesión típica del navegador.
Sin latencia adicional al cambiar de "páginas".

Desventajas

Monitoreo de rendimiento: manos atadas: la mayoría de las soluciones de monitoreo de rendimiento a nivel de navegador que he visto se centran exclusivamente en el tiempo de carga de la página, como tiempo hasta primer byte, tiempo para compilar DOM, recorrido de red para HTML, evento de carga, etc. Actualización de la página la carga posterior a través de AJAX no se mediría. Hay soluciones que le permiten instrumentar su código para registrar medidas explícitas, como al hacer clic en un enlace, iniciar un temporizador, luego finalizar un temporizador después de mostrar los resultados de AJAX y enviar ese comentario. New Relic, por ejemplo, es compatible con esta funcionalidad. Al usar un SPA, se ha vinculado a solo unas pocas herramientas posibles.
Pruebas de seguridad / penetración: manos atadas: las exploraciones de seguridad automatizadas pueden tener dificultades para descubrir enlaces cuando toda una página está construida dinámicamente por un marco SPA. Probablemente haya soluciones para esto, pero nuevamente, usted se ha limitado.
Agrupamiento: Es fácil entrar en una situación cuando está descargando todo el código necesario para todo el sitio web en la carga de la página inicial, lo que puede funcionar terriblemente para conexiones de bajo ancho de banda. Puede agrupar sus archivos JavaScript y CSS para tratar de cargar en pedazos más naturales a medida que avanza, pero ahora necesita mantener esa asignación y ver si los archivos involuntarios se obtienen a través de dependencias no realizadas (simplemente me pasó a mí). De nuevo, solucionable, pero con un costo.
Refactorización de Big Bang: si desea realizar un cambio arquitectónico importante, como por ejemplo, cambiar de un marco a otro, para minimizar el riesgo, es conveniente realizar cambios incrementales. Es decir, comience a usar lo nuevo, migre sobre alguna base, como por página, por función, etc., luego suelte lo viejo después. Con la aplicación tradicional de varias páginas, puede cambiar una página de Angular a Reaccionar, luego cambiar otra página en el siguiente sprint. Con un SPA, es todo o nada. Si desea cambiar, debe cambiar la aplicación completa de una vez.
Complejidad de la navegación: existen herramientas para ayudar a mantener el contexto de navegación en los SPA, como history.js, Angular 2, la mayoría de los cuales dependen del marco de URL (#) o de la API de historial más reciente. Si cada página fuera una página separada, no necesita nada de eso.
Complejidad de descifrar el código: naturalmente pensamos en los sitios web como páginas. Una aplicación de varias páginas suele particionar código por página, lo que ayuda a la mantenibilidad.

De nuevo, reconozco que cada uno de estos problemas es solvente, a algún costo. Pero llega un punto en el que pasas todo el tiempo solucionando problemas que podrías haber evitado en primer lugar. Vuelve a los beneficios y lo importantes que son para usted.

Una gran desventaja de SPA - SEO. Recientemente, Google y Bing comenzaron a indexar páginas basadas en Ajax ejecutando JavaScript durante el rastreo, y aún en muchos casos las páginas se indexan incorrectamente.

Al desarrollar SPA, se verá forzado a manejar problemas de SEO, probablemente pos-renderizando todo su sitio y creando instantáneas html estáticas para el uso del rastreador. Esto requerirá una inversión sólida en una infraestructura adecuada.

Actualización 19.06.16:

Desde que escribí esta respuesta hace un tiempo, tengo mucha más experiencia con las aplicaciones de una sola página (concretamente, AngularJS 1.x), así que tengo más información para compartir.

En mi opinión, la principal desventaja de las aplicaciones de SPA es SEO, lo que las limita al tipo de aplicaciones de "tablero de instrumentos" solamente. Además, vas a tener momentos mucho más difíciles con el almacenamiento en caché, en comparación con las soluciones clásicas. Por ejemplo, en el almacenamiento en caché de ASP.NET es extremadamente fácil: solo active OutputCaching y estará listo: toda la página HTML se almacenará en caché según la URL (o cualquier otro parámetro). Sin embargo, en SPA deberá manejar el caché usted mismo (mediante el uso de algunas soluciones como el caché de segundo nivel, el caché de plantillas, etc.).

Veamos uno de los sitios de SPA más populares, GMail.

1. SPA es extremadamente bueno para sitios muy receptivos:

La representación del lado del servidor no es tan difícil como solía ser con técnicas simples como mantener un #hash en la URL, o más recientemente HTML5 pushState . Con este enfoque, el estado exacto de la aplicación web está incrustado en la URL de la página. Como en GMail cada vez que abre un correo, se agrega una etiqueta hash especial a la URL. Si se copia y se pega a otra ventana del navegador puede abrir el mismo correo (siempre que puedan autenticarse). Este enfoque se asigna directamente a una cadena de consulta más tradicional, la diferencia es meramente en la ejecución. Con HTML5 pushState () puede eliminar #hash y usar URLs completamente clásicas que pueden resolverse en el servidor en la primera solicitud y luego cargarse a través de ajax en solicitudes posteriores.

2. Con SPA no necesitamos usar consultas adicionales al servidor para descargar páginas.

¿El número de páginas de descargas de usuarios durante la visita a mi sitio web? realmente cuántos correos electrónicos se leen cuando abre su cuenta de correo. Leo> 50 de una vez. ahora la estructura de los correos es casi la misma. si va a utilizar un esquema de representación del lado del servidor, el servidor lo renderizará en cada solicitud (caso típico). - preocupación de seguridad - usted debe / no debe tener páginas separadas para los administradores / inicio de sesión que dependen completamente de la estructura de su sitio tomar paytm.com, por ejemplo, también hacer un sitio web SPA no significa que abra todos los puntos finales para todas las Me refiero a los usuarios que utilizo la autenticación de formularios en mi sitio web de spa. - en el framework de SPA probablemente más utilizado, Angular JS, el desarrollador puede cargar todo el templo html desde el sitio web, de modo que pueda hacerse según el nivel de autenticación de los usuarios. la carga previa html para todos los tipos de autenticación no es SPA.

3. ¿Puede haber otras ventajas? No escuche nada más ..

en estos días puede suponer con seguridad que el cliente tendrá navegadores habilitados para JavaScript.
solo un punto de entrada del sitio. Como mencioné anteriormente, es posible mantener el estado, puede tener cualquier número de puntos de entrada como desee, pero debe tener uno seguro.
incluso en un usuario SPA solo ve a lo que tiene los derechos adecuados. no tiene que inyectar todo a la vez. cargar plantillas diff html y javascript async también es una parte válida de SPA.

Las ventajas que puedo pensar son:

renderizar html obviamente requiere algunos recursos ahora que cada usuario que visita tu sitio está haciendo esto. Además, el renderizado de las principales lógicas ahora se realiza desde el lado del cliente en lugar del lado del servidor.
problemas de fecha y hora - Solo le doy al cliente que la hora UTC es un formato preestablecido y ni siquiera me preocupan las zonas horarias en las que dejo javascript manejarlo. esta es una gran ventaja para donde tuve que adivinar las zonas horarias en función de la ubicación derivada de la IP de los usuarios.
Para mí, el estado se mantiene mejor en un SPA porque una vez que has establecido una variable sabes que estará allí. esto da la sensación de desarrollar una aplicación en lugar de una página web. esto ayuda mucho a hacer sitios como foodpanda, flipkart, amazon. porque si no está usando el estado del lado del cliente está usando sesiones costosas.
los sitios web seguramente son extremadamente receptivos; tomaré un ejemplo extremo para este intento de hacer una calculadora en un sitio web que no sea SPA (sé que es extraño).

Actualizaciones de Comentarios

No parece que nadie haya mencionado sobre enchufes y largas encuestas. Si cierra la sesión desde otro cliente, por ejemplo, la aplicación móvil, su navegador también debe cerrar la sesión. Si no usa SPA, debe volver a crear la conexión de socket cada vez que haya una redirección. Esto también debería funcionar con cualquier actualización en datos como notificaciones, actualización de perfil, etc.
Una perspectiva alternativa: además de su sitio web, ¿su proyecto incluirá una aplicación móvil nativa? En caso afirmativo, lo más probable es que esté alimentando datos sin procesar a esa aplicación nativa desde un servidor (es decir, JSON) y haciendo el procesamiento del lado del cliente para procesarlos, ¿correcto? Entonces, con esta afirmación, YA está haciendo un modelo de representación del lado del cliente. Ahora la pregunta es: ¿por qué no debería usar el mismo modelo para la versión del sitio web de su proyecto? Una especie de obviedad. Entonces, la pregunta es si desea presentar páginas del lado del servidor solo para los beneficios de SEO y la conveniencia de las URL que se pueden compartir / marcar como favoritos.

2. Con SPA no necesitamos usar consultas adicionales al servidor para descargar páginas.

Todavía tengo que aprender mucho, pero desde que comencé a aprender sobre SPA, los amo.

Este punto en particular puede marcar una gran diferencia.

En muchas aplicaciones web que no son SPA, verá que seguirán recuperando y agregando contenido a las páginas que realizan solicitudes ajax. Así que creo que SPA va más allá al considerar: ¿qué ocurre si el contenido que se va a recuperar y mostrar con ajax es toda la página? y no solo una pequeña porción de una página?

Déjame presentar un escenario. Considera que tienes 2 páginas:

una página con una lista de productos
una página para ver los detalles de un producto específico

Considera que estás en la página de la lista. A continuación, haga clic en un producto para ver los detalles. La aplicación del lado del cliente activará 2 solicitudes ajax:

una solicitud para obtener un objeto json con los detalles del producto
una solicitud para obtener una plantilla html donde se insertarán los detalles del producto

Luego, la aplicación del lado del cliente insertará los datos en la plantilla html y lo mostrará.

Luego, vuelve a la lista (¡no se realiza ninguna solicitud para esto!) Y abre otro producto. Esta vez, solo habrá una solicitud ajax para obtener los detalles del producto. La plantilla html será la misma, por lo que no es necesario volver a descargarla.

Usted puede decir que en un SPA que no sea, cuando abre los detalles del producto, solo hace 1 solicitud y en este escenario lo hicimos 2. Sí. Pero obtienes la ganancia desde una perspectiva general, cuando navegas por muchas páginas, la cantidad de solicitudes será menor. Y los datos que se transfieren entre el lado del cliente y el servidor también serán más bajos porque las plantillas html serán reutilizadas. Además, no necesita descargar en todas las solicitudes todos los css, imágenes, archivos javascript que están presentes en todas las páginas.

Además, consideremos que el idioma del lado del servidor es Java. Si analiza las 2 solicitudes que mencioné, 1 descarga los datos (no necesita cargar ningún archivo de vista y llama al motor de representación de la vista) y las otras descargas y la plantilla html estática para que pueda tener un servidor web HTTP que pueda recuperar directamente sin tener que llamar al servidor de aplicaciones Java, ¡no se realiza ningún cálculo!

Finalmente, las grandes compañías están utilizando SPA: Facebook, GMail, Amazon. No juegan, tienen los mejores ingenieros estudiando todo esto. Entonces, si no ve las ventajas, inicialmente puede confiar en ellas y esperar descubrirlas en el futuro.

Pero es importante usar buenos patrones de diseño de SPA. Puede usar un framework como AngularJS. No intente implementar un SPA sin utilizar buenos patrones de diseño porque puede terminar teniendo un desastre.

Desventajas : Técnicamente, el diseño y el desarrollo inicial de SPA son complejos y se pueden evitar. Otras razones para no usar este SPA pueden ser:

a) Seguridad: la aplicación de una sola página es menos segura en comparación con las páginas tradicionales debido a la creación de scripts de sitios cruzados (XSS).
b) Pérdida de memoria: la pérdida de memoria en JavaScript incluso puede hacer que la potente computadora se desacelere. Como los sitios web tradicionales fomentan la navegación entre las páginas, por lo tanto, cualquier pérdida de memoria causada por la página anterior casi se limpia dejando menos residuos.
c) El cliente debe habilitar JavaScript para ejecutar SPA, pero en la aplicación de varias páginas JavaScript puede evitarse por completo.
d) SPA crece a un tamaño óptimo, causa un largo tiempo de espera. Ejemplo: trabajando en Gmail con una conexión más lenta.

Además de lo anterior, otras limitaciones arquitectónicas son la pérdida de datos de navegación, ningún registro de historial de navegación en el navegador y la dificultad en la prueba funcional automatizada con selenio.

This enlace explica las Ventajas e Inconvenientes de la Aplicación de una sola página.