Aplicación de página única: ventajas y desventajas [cerrado]

203

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

Pregunta: ¿Puede actuar como defensor de SPA y demostrar que estoy equivocado acerca de las primeras tres 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 de volver a dibujar cualquier parte de la interfaz de usuario sin requerir un viaje de ida y vuelta del servidor para recuperar HTML. Esto se logra separando los datos de la presentación de datos al tener una capa de modelo que maneja los datos y una capa de vista que lee de los modelos.

¿Qué tiene de malo mantener 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 durante su visita a su sitio? ¿Dos tres? En cambio, aparecen otros problemas de seguridad y necesita 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 alguna otra ventaja? No escuche nada más ...

                            === DISADVANTAGES ===
  1. El cliente debe habilitar javascript.
  2. Solo un punto de entrada al sitio.
  3. Seguridad.

PD : He trabajado en proyectos SPA y no SPA. Y estoy haciendo esas preguntas porque necesito profundizar mi comprensión. No significa dañar a los partidarios del SPA. No me pidas que lea un poco más sobre SPA. Solo quiero escuchar tus consideraciones al respecto.

VB_
fuente
1
2. y 3. no son problemas.
Wiktor Zychla
1
Sugiero que en lugar de solo leer sobre SPA, podría pasar un tiempo jugando con un marco real como extjs. El tiempo transcurrido allí dará sus frutos y podrá responder sus propias preguntas.
Wiktor Zychla
3
@WiktorZychla Trabajo en un proyecto SPA. Yo uso JQuery + Backbone. También he escrito un sitio JSP. No puedo responder esas preguntas. ¿Puedes?
VB_
3
@VolodymyrBakhmatiuk: eso no importa, lo que el usuario puede comprometer es la interfaz gráfica de usuario, no los datos porque los datos están guardados en el lado del servidor.
Wiktor Zychla
44
¿Qué pasa si esta pregunta está basada en la opinión? A menudo me preguntaba por qué y cuándo debería escribir un SPA. Sería útil si SO permitiera también las preguntas Pros n Contras
Anurag Awasthi

Respuestas:

144

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 HTML5pushState . Con este enfoque, el estado exacto de la aplicación web se incrusta 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 pega en otra ventana del navegador, puede abrir exactamente el mismo correo (siempre que puedan autenticarse). Este enfoque se asigna directamente a una cadena de consulta más tradicional, la diferencia está simplemente en la ejecución. Con HTML5 pushState () puede eliminar #hashy usar URL completamente clásicas que pueden resolverse en el servidor en la primera solicitud y luego cargar 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 que el usuario descarga durante la visita a mi sitio web? realmente cuántos correos leen algunas lecturas cuando abre su cuenta de correo. Leí> 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 representará en cada solicitud (caso típico). - preocupación de seguridad: debe / no debe mantener páginas separadas para los administradores / inicio de sesión que dependen completamente de la estructura de su sitio, tome paytm.com, por ejemplo, también hacer un sitio web SPA no significa que abra todos los puntos finales para todos los usuarios quiero decir que uso formularios de autenticación con mi sitio web de spa. - en el marco de SPA probablemente más utilizado, Angular JS, el desarrollador puede cargar todo el templo html desde el sitio web para que se pueda hacer dependiendo del nivel de autenticación de los usuarios. precargar html para todos los tipos de autenticación no es

3. ¿Puede haber alguna otra ventaja? No escuche nada más ...

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

Las ventajas que se me ocurren son:

  1. La representación de HTML obviamente requiere algunos recursos ahora que cada usuario que visita su sitio está haciendo esto. Además, no solo la representación de las principales lógicas ahora se realiza del lado del cliente en lugar del lado del servidor.
  2. problemas de fecha y hora: solo le doy al cliente la hora UTC es un formato preestablecido y ni siquiera me importan las zonas horarias que dejo que JavaScript lo maneje. Esto es una gran ventaja en donde tuve que adivinar las zonas horarias basadas en la ubicación derivada de la IP de los usuarios.
  3. para mí, el estado se mantiene mejor en un SPA porque una vez que ha establecido una variable, sabe que estará allí. esto da la sensación de desarrollar una aplicación en lugar de una página web. Esto generalmente ayuda mucho en la creación de sitios como foodpanda, flipkart, amazon. porque si no está utilizando el estado del lado del cliente, está utilizando sesiones costosas.
  4. 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 alguien haya mencionado sobre enchufes y sondeos largos. Si cierra la sesión desde otro cliente, por ejemplo, la aplicación móvil, su navegador también debería cerrar 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 alimente datos sin procesar a esa aplicación nativa desde un servidor (es decir, JSON) y realice un procesamiento del lado del cliente para procesarlo, ¿correcto? Entonces, con esta afirmación, YA estás 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? Un poco obvio. Luego, la pregunta es si desea renderizar páginas del lado del servidor solo para los beneficios de SEO y la conveniencia de URL compartibles / marcables

Parv Sharma
fuente
44
Bien por ti para hacer de esto una respuesta Wiki de la comunidad :) También estos son grandes puntos
Jason Sperske
@Parv Sharma explica por favor más ampliamente por qué mantener el estado es más compatible con SPA
VB_
44
No puede indexar fácilmente páginas para la optimización SEO con SPA.
Ankit_Shah55
2
@ Ankit_Shah55 Puede que esto ya no sea cierto (al menos para Google, que posee la mayor parte del mercado de motores de búsqueda de todos modos). Consulte "Desaprobar nuestro esquema de rastreo AJAX" de Google. Tengo entendido que ya no tiene que hacer nada especial para que Google indexe su SPA. Sin embargo, creo que tendrá que asegurarse de admitir pushstate, porque no creo que Google indexe fragmentos hash.
Kevin Wheeler
3
No parece que alguien haya mencionado sobre enchufes y sondeos largos. Si cierra la sesión desde otro cliente, por ejemplo, la aplicación móvil, su navegador también debería cerrar 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 de datos como las notificaciones de actualización del perfil, etc.
tsuz
66

Soy pragmático, por lo 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 de estado más fácil: no es necesario usar cookies, envío de formularios, almacenamiento local, almacenamiento de sesión, etc. para recordar el estado entre 2 cargas de página.
  • El contenido de la placa de caldera que se encuentra en cada página (encabezado, pie de página, logotipo, banner de copyright, etc.) solo se carga una vez por sesión típica del navegador.
  • Sin latencia general al cambiar de "páginas".

Desventajas

  • Supervisión del rendimiento: manos a la obra: la mayoría de las soluciones de supervisión del rendimiento a nivel de navegador que he visto se centran exclusivamente en el tiempo de carga de la página, como el tiempo para el primer byte, el tiempo para crear DOM, el viaje de ida y vuelta de red para el HTML, el evento de carga, etc. Actualización de la página post-carga 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 esos comentarios. New Relic, por ejemplo, admite esta funcionalidad. Al usar un SPA, se ha limitado a unas pocas herramientas posibles.
  • Pruebas de seguridad / penetración: manos atadas: los escaneos de seguridad automatizados pueden tener dificultades para descubrir enlaces cuando toda su página se construye dinámicamente mediante un marco de SPA. Probablemente hay soluciones para esto, pero de nuevo, te has limitado.
  • Agrupación: 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 intentar cargarlos en fragmentos más naturales a medida que avanza, pero ahora necesita mantener esa asignación y observar si los archivos no deseados se introducen a través de dependencias no realizadas (me sucedió 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 de alguna manera, como por página, por función, etc., y luego elimine el anterior. Con la aplicación tradicional de varias páginas, puede cambiar una página de Angular a Reaccionar, y luego cambiar otra página en el próximo sprint. Con un SPA, es todo o nada. Si desea cambiar, debe cambiar toda la aplicación de una vez.
  • Complejidad de la navegación: las herramientas existen para ayudar a mantener el contexto de navegación en los SPA, como history.js, Angular 2, la mayoría de los cuales se basan en el marco de URL (#) o en la API de historial más reciente. Si cada página era 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 generalmente divide el código por página, lo que ayuda a la mantenibilidad.

Nuevamente, reconozco que cada uno de estos problemas es solucionable, a algún costo. Pero llega un punto en el que pasa todo su tiempo resolviendo problemas que podría haber evitado en primer lugar. Se trata de los beneficios y de lo importantes que son para usted.

Brandon
fuente
2
Creo que esta respuesta proporciona comentarios muy válidos de alguien que realmente ha construido un sistema complejo grande y experimentado las bajas a largo plazo que trae SPA (o parece)
DanielCuadra
44
Lo que obtengo de esta respuesta es que evite el SPA si está haciendo algo incluso remotamente serio.
IvanP
Creo que nos dio una visión general muy útil en lugar de responder. Realmente pragmático.
Hos Mercury
3
Estoy de acuerdo. SPA se veía genial cuando hicimos una prueba de concepto. Tres años después, hemos visto todos los problemas mencionados en esta respuesta y seguimos dedicando mucho tiempo a tratar de resolverlos. El cambio de marco ya no es una opción y estamos atrapados con un marco que básicamente detuvo el desarrollo.
Qi Fan
1
He experimentado los últimos 4 puntos de desventaja directamente. He creado una aplicación web LOC de 10K con Angular, Bootstrap y PHP como los principales jugadores con aproximadamente 5K de código Angular JS. Hay algunas características realmente interesantes de Angular, pero en este punto realmente desearía haber usado un enfoque tradicional basado en páginas y creo que habría acelerado significativamente el desarrollo del sitio.
Zack Macomber
41

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 habilitado JavaScript. Si no puede, entonces no puede hacer un SPA, punto. Eso es como tratar de implementar una aplicación .NET en una máquina sin .NET Framework instalado.

2. Solo un punto de entrada al sitio. Soluciono este problema usando SammyJS . 2-3 días de trabajo para configurar su enrutamiento correctamente, y las personas podrán crear marcadores de enlace profundo en su aplicación que funcionen correctamente. Su servidor solo necesitará exponer un punto final: el punto final "deme el HTML + CSS + JS para esta aplicación" (piense en ello 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 los SPA, tiene que lidiar con la seguridad exactamente de la misma manera cuando tiene una aplicación cliente-servidor "de la vieja escuela" (el modelo HATEOAS de usar Hipertexto para vincular entre 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 algún formato de datos. En una aplicación que no es SPA, debe proteger las páginas individuales en el servidor, mientras que en una aplicación SPA debe proteger los puntos finales de datos. (Y, si no desea que su cliente tenga acceso a todo el código, también debe dividir el JavaScript descargable en áreas separadas. Simplemente lo relaciono con 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, en función de una carga inicial de los roles del usuario,

Ventajas

  1. 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ía del procesamiento en el cliente (el punto completo, después de todo), entonces el número de solicitudes al servidor (lea "posibilidades de errores 503 que arruinan su experiencia de usuario") se reduce drásticamente. De hecho, un SPA hace posible el procesamiento completamente fuera de línea, lo cual es enorme en algunas situaciones.

  2. El rendimiento es ciertamente mejor con la representación del lado del cliente si lo hace correctamente, pero esta no es la razón más convincente para construir un SPA. (Las velocidades de red están mejorando, después de todo). No defienda el SPA solo sobre esta base.

  3. La flexibilidad en su diseño de interfaz de usuario 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 con cero impacto en el servidor, aparte de algunos archivos de recursos estáticos. ¡Intenta hacerlo con una aplicación MVC tradicional! :) (Esto se vuelve valioso cuando tiene que preocuparse por las implementaciones en vivo y la coherencia de la versión de su API).

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

Lars Kemmann
fuente
66
Otra ventaja es que un SPA se puede guardar como un marcador ("Agregar a la pantalla de inicio") en iOS y abrirlo en modo de pantalla completa (suponiendo que haya definido la metaetiqueta correcta ), haciéndolo sentir como una aplicación nativa y no como una aplicación nativa. página web.
Strille
77
3. Es tan fácil en la aplicación MVC tradicional. Si opera con los mismos datos, solo necesita hacer cambios en la parte V (vista) de su aplicación. Suelen ser plantillas, css y js.
karantan
¿Puede una versión SPA de SO tener enlaces a preguntas individuales para compartir, o qué ventajas y desventajas traería, por ejemplo, en términos de SEO (capacidad de búsqueda de preguntas anteriores desde un motor de búsqueda)?
Selçuk
55
La mayoría de las aplicaciones de SPA que he visto son más comunicativas que las aplicaciones del lado del servidor. En lugar de una sola solicitud para obtener datos, termina con más solicitudes al servidor por página.
Matthew Whited el
29

Una desventaja importante 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.

Durante el desarrollo de SPA, se verá obligado a manejar los problemas de SEO, probablemente mediante el procesamiento posterior de todo su sitio y la creación de instantáneas html estáticas para el uso del rastreador. Esto requerirá una inversión sólida en infraestructuras adecuadas.

Actualización 19.06.16:

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

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

Illidan
fuente
¿Es mejor SEO que el tráfico se reenvíe a una sola página frente a un par de páginas?
SILENCIOSO
@SILENT - no estoy seguro, pero como todas las páginas en el mismo dominio, no creo que deba haber una diferencia
Illidan
No entiendo el argumento de SEO. ¿No puede tener las mismas rutas definidas en su SPA también definidas en el lado del servidor, para que los robots de búsqueda puedan rastrear fácilmente su sitio y, al mismo tiempo, las personas obtengan URL directas a su contenido? Y entonces, puede tener dos conjuntos de plantillas para mantener, gran cosa. Puede intentar usar plantillas universales si es una preocupación.
MarsAndBack
@MarsAndBack: No estoy seguro de qué enlaces de servidor está hablando. Si te refieres al mapa del sitio, entonces es inútil en el caso de SPA: los motores de búsqueda no ejecutan JavaScript (al menos, este era el estado de cosas hace unos años), solo descargan y analizan HTML. Entonces, incluso si prepara un mapa del sitio, la página no se construirá correctamente.
Illidan
12

Me gustaría argumentar que SPA es 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 óptimo es tener un sitio con una mezcla de páginas de estilo SPA y estáticas / 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 al 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 Flash solo se redujo a casi cero debido al factor de carga. Pero como componente de la página, todavía está en uso.

Greg Gum
fuente
1
después de muchos años de desarrollo web, eso es lo que puedo confirmar. debe mezclar ambas aplicaciones, spa y mvc juntas. usted no puede tener una respuesta, tampoco. Primero tuve toda mi aplicación como spa, descubrí que mi aplicación no está en la lista de Google correctamente. así que me mudé a mpa y uso el spa solo en situaciones necesarias. WordPress tampoco es un spa y un marco popular por buenas razones.
Rudolf Schmidt
1
Este es mi enfoque también. Tengo SPA como el área principal para que mis usuarios revisen rápidamente los resultados de búsqueda, ya sea en un mapa o lista dinámica. Luego, al mirar los detalles, se abren como páginas estándar prestados por el servidor. Mis rutas funcionan tanto dentro del SPA como como rutas de servidor de primera carga. He duplicado el código de plantilla y el código de ruta, pero no podría importarme menos, es un mal necesario.
MarsAndBack
8

Para empresas como google, amazon, etc., cuyos servidores funcionan a su capacidad máxima en modo 24/7, reducir el tráfico significa dinero real: menos hardware, menos energía, menos mantenimiento. Cambiar el uso de la CPU del servidor al cliente vale la pena, y los SPA brillan. Las ventajas sobrepeso desventajas de lejos. Entonces, SPA o no SPA depende mucho del caso de uso.

Solo por mencionar otro caso de uso para SPAs, probablemente no tan obvio (para desarrolladores web): actualmente estoy buscando una manera de implementar GUI en sistemas integrados y la arquitectura basada en navegador me parece atractiva. Tradicionalmente, no había muchas posibilidades de interfaz de usuario en sistemas integrados: Java, Qt, wx, etc. o 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 gran paleta de herramientas para la interfaz de usuario sin costo alguno. (por ejemplo, Qt requiere 20-30 $ por unidad vendida en regalías, más 3000-4000 $ por desarrollador)

Para dicha arquitectura, el 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 automotriz, la interfaz de usuario y los problemas del sistema son hardware separado, donde la parte del sistema tiene un sistema operativo RT).

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

Valentin Heinitz
fuente
1
Amazon no está demasiado preocupado por el ancho de banda o el recuento de solicitudes. Cada página tiene alrededor de 10 MB y más de 200 solicitudes.
Matthew Whited el
3

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

Todavía tengo que aprender mucho, pero desde que empecé a aprender sobre SPA, me encantan.

Este punto en particular puede hacer una gran diferencia.

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

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

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

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

  1. una solicitud para obtener un objeto json con los detalles del producto
  2. 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 los mostrará.

Luego vuelve a la lista (no se hace 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.

Puede decir que en un no SPA, cuando abre los detalles del producto, realiza solo 1 solicitud y en este escenario hicimos 2. Sí. Pero obtienes la ganancia desde una perspectiva general, cuando navegas por muchas páginas, el número 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 se reutilizarán. Además, no es necesario descargar en todas las solicitudes todos esos archivos CSS, imágenes y JavaScript que están presentes en todas las páginas.

Además, consideremos que el lenguaje del lado del servidor es Java. Si analiza las 2 solicitudes que mencioné, 1 descarga datos (no necesita cargar ningún archivo de vista y llamar al motor de representación de vistas) y las otras descargas y la plantilla estática html 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 empresas están utilizando SPA: Facebook, GMail, Amazon. No juegan, tienen los mejores ingenieros que estudian todo esto. Entonces, si no ve las ventajas, inicialmente puede confiar en ellas y esperar descubrirlas en el futuro.

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

dam_js
fuente
1
Facebook no es un SPA, en realidad es una aplicación de estilo MPA, están usando ReactJS aquí y allá para comentarios, chat, etc. Instagram es un buen ejemplo para la página completa de SPA con PWA habilitado. Lo mismo aplica para Amazon, Youtube, ambas son aplicaciones MPA.
Peter Húbek
3

Desventajas : Técnicamente, el diseño y el desarrollo inicial de SPA es complejo y puede evitarse. Otras razones para no usar este SPA pueden ser:

  • a) Seguridad: la aplicación de página única es menos segura en comparación con las páginas tradicionales debido a las secuencias de comandos entre sitios (XSS).
  • b) Pérdida de memoria: la pérdida de memoria en JavaScript puede incluso hacer que la computadora potente se desacelere. Como los sitios web tradicionales alientan a navegar 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 aplicaciones de varias páginas, JavaScript se puede evitar por completo.
  • d) El SPA crece a un tamaño óptimo, lo que causa un largo tiempo de espera. Por ejemplo: trabajar 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, sin registro del historial de navegación en el navegador y la dificultad en las pruebas funcionales automatizadas con selenio.

Este enlace explica las ventajas y desventajas de la aplicación de página única.

Vish
fuente
12
Esto es incorrecto. a) XSS afecta las páginas generadas por el servidor tan fácilmente como los documentos generados en el cliente. Yo argumentaría más, dado que existen soluciones de mitigación XSS muy simples y efectivas para el cliente. Si no desea permitir XSS, no interprete el contenido enviado por el usuario como HTML. Cualquier programador decente puede manejar esto. La navegación es fácil usando cualquiera de las técnicas disponibles (pushState, enrutamiento hash, etc.). AFT para un SPA correctamente construido es exactamente igual a cualquier otra aplicación web. El resumen de su respuesta es que no sabe cómo construir para el cliente.
Jason Miller
@JasonMiller: De acuerdo. Me doy cuenta de que el resumen no es todo el contexto de todo el blog. Haré cambios en ello. Gracias.
Visite
66
Los puntos ayb son completamente inválidos. Ambos tienen más que ver con una programación deficiente que las características de un SPA, y ambos son perfectamente posibles con un sitio web tradicional; Las vulnerabilidades de XSS pueden afectar su sitio incluso si no escribe una línea de JS. Las pérdidas de memoria son tan posibles del lado del servidor como del lado del cliente. En cuanto al punto c, cualquiera que deshabilite Javascript en estos días es probable que el uso de la web en general sea un problema importante, en mi humilde opinión no es un problema.
garryp
2

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

  • Posibilidad de una menor solicitud del servidor, ya que la representación de contenido nuevo no siempre es una solicitud del servidor http para una nueva página html. Pero digo potencial porque el nuevo contenido podría requerir fácilmente una llamada de Ajax para obtener datos, pero esos datos podrían ser incrementalmente más livianos que el marcado en sí mismo, lo que proporciona un beneficio neto.

  • La capacidad de mantener el "Estado". En sus términos más simples, establezca una variable al ingresar a la aplicación y estará disponible para otros componentes a lo largo de la experiencia del usuario sin pasarla o establecerla en un patrón de almacenamiento local. Sin embargo, la administración inteligente de esta capacidad es clave para mantener el alcance de nivel superior despejado.

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

JOP
fuente
1

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 usa un servidor RESTful que implementa OAUTH 2.0 por seguridad, logrará dos separaciones fundamentales de preocupaciones que pueden reducir sus costos de desarrollo y mantenimiento.

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

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

Bill Lawrence
fuente
0

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

Si crea una API que devuelve resultados en un lenguaje de datos (como XML o JSON) en lugar de un lenguaje de formato (como HTML), está permitiendo una mayor interoperabilidad de aplicaciones, por ejemplo, en aplicaciones de empresa a empresa (B2B). Dicha interoperabilidad tiene grandes beneficios pero permite a las personas escribir software para "extraer" (o robar) sus datos. Esta desventaja particular es común a todas las API que usan un lenguaje de datos, y no a los SPA en general (de hecho, un SPA que le pide al servidor HTML preprocesado lo evita, pero a expensas de una separación de modelo / vista deficiente). Este riesgo expuesto por esta desventaja puede mitigarse por diversos medios, como la limitación de solicitudes y el bloqueo de conexiones, etc.

Magnus
fuente
2
1.) No tener una API no significa que no se puedan extraer páginas HTML. 2.) Puede evitar el mal uso de su API hasta cierto punto. 3.) Al tener una API, puede crear fácilmente no solo páginas web, sino también aplicaciones móviles, lo que en mi opinión supera en gran medida cualquier desventaja.
Honza Kalfus
1. No dije que la no API impide la minería de datos. Acabo de decir que una API puede facilitar la extracción de datos. 2. A eso se dirigió mi última oración. 3. Tener una API tiene muchas ventajas, y yo personalmente prefiero una combinación de API / SPA para la mayoría de los casos de uso que normalmente encuentro. Sin embargo, solo quería agregar una única desventaja a la lista (que en retrospectiva debería haber agregado como un comentario en lugar de una respuesta completa).
Magnus
Lo sentimos, pero si no lo he entendido mal, no lo hizo, dijo que "dicha interoperabilidad tiene grandes beneficios pero permite a las personas escribir software para" extraer "(o robar) sus datos". Si cambiara un poco su oración, también podría decir que "los sitios web permiten a las personas escribir software para" extraer "(o robar) sus datos". y ser correcto Ahora no digo que tu idea sea incorrecta, estoy de acuerdo con que la minería sea más fácil, solo digo que no es lo que has escrito;)
Honza Kalfus
Convenido. No estaba lo suficientemente claro. Los datos incrustados en HTML son explotables. Los datos incrustados en JSON / XML / etc. también se pueden extraer, solo que es más fácil
magnus