¿Cuándo debo usar la Aplicación de página única (SPA) y cuándo debo usar la Aplicación de página múltiple (MPA)?

Otra consideración es que los SPA son más efectivos (UX más rápido, más fluido), a expensas de un tiempo de carga inicial más lento. Si está desarrollando un sitio web que tiene como objetivo atraer tráfico de contenido específico de los motores de búsqueda y enlaces directos y no se espera que los usuarios naveguen por el sitio web después de haber accedido al contenido específico que solicitaron, entonces la penalización del tiempo de carga de los SPA es desventajosa. Por lo tanto, los SPA probablemente no sean adecuados para foros, blogs, sitios de noticias, servicios de agregación / curación de contenido público.

Los SPA también son arquitectónicamente más complejos y los errores a veces son más difíciles de solucionar. Si está ejecutando un cronograma de desarrollo de tiempo crítico, puede ser más rápido trabajar sin un marco (a menos, por supuesto, que tenga experiencia).

Finalmente, todavía existe un peligro real de que algunos clientes no admitan o tengan JavaScript deshabilitado. Las aplicaciones de una sola página no permiten un retroceso semi-funcional, mientras que eso sería posible con una aplicación de múltiples páginas. Por supuesto, restringiría UX, pero al menos el sitio web sería accesible.

Dicho esto, no creo en desarrollar para el mínimo común denominador. Creo que los desarrolladores deberían esforzarse por utilizar las tecnologías de su elección en un intento de promover su adopción. Aún así, puede ser crítico para su aplicación que sea accesible para el segmento de mercado más grande posible.

En algunos casos, sin duda es mejor hacer una aplicación de varias páginas.

Muchas personas en el mundo lo han hecho, lo están haciendo y lo harán en el futuro aplicaciones de varias páginas en Ruby on Rails, Phoenix, Express, Django, Flask, ASP.NET, etc. Este es un enfoque bastante estable para medios y serios aplicaciones con lógica empresarial avanzada.

Pero los desarrolladores constantemente tienen dolor de cabeza cuando intentan organizar una gran aplicación para cliente ligero. Las colisiones entre los scripts y el infierno de devolución de llamada hacen que las personas busquen refugio en los nuevos “marcos” publicitados, pero requieren una organización más compleja del código de la aplicación y generan un nuevo grupo de problemas inherentes al cliente pesado.

Por el momento, hay un excelente marco JavaScript Normas.js para crear un cliente ligero sin dolor de cabeza, que se utiliza con éxito en la producción: https://github.com/evrone/normas

No abandone la representación del servidor en 202x, es un gran enfoque para la creación de un MVP o una versión completa.

SPA, puede hacer casi todo lo que hace MPA Y también se carga mucho más rápido. Todos los archivos se obtienen una vez, y luego todo el contenido se proporciona a pedido mediante enrutamiento y solicitudes http / s a ​​las API.

Si desea aprender SPA, que es la tendencia sexy actual en el desarrollo web … Le recomiendo que vaya a Code School y consulte su tutorial angular gratuito. A partir de ahí, puede ver / leer tutoriales y la documentación oficial. Se vuelve complicado ya que su aplicación requiere más funcionalidad y administración de la interfaz de usuario, por lo que no será fácil ya que la depuración también es difícil en JS.

Sin embargo, recomiendo comenzar ahora y tómese su tiempo. Github también tiene muchos proyectos de muestra bien documentados. Buena suerte.

Es una tarea muy difícil y difícil hacer la optimización SEO de la aplicación de página única con contenido cargado por ajax. Si la esencia principal de su aplicación es la funcionalidad, entonces podría usar libremente la aplicación de una sola página, pero si desea publicar contenido, es mejor desarrollarlo en varias páginas.

No te preocupes Tu gerente de producto te lo dirá.

Pero en serio, MPA se está volviendo cojo. Proporciona muy mala experiencia de usuario. Y no es difícil crear un SPA con marcos modernos como Angularjs