miniaturadeimagen|A la izquierda, un sitio single-page. A la derecha, un sitio multi-page. Una single-page application (SPA), o aplicación de página única, es una aplicación web ó un sitio web que cabe en una sola página con el propósito de dar una experiencia más fluida a los usuarios, como si fuera una aplicación de escritorio. En un SPA todos los códigos de HTML, JavaScript, y CSS se cargan una sola vez,Flanagan, David, "JavaScript - The Definitive Guide", 5th ed., O'Reilly, Sebastopol, CA, 2006, p.497 los recursos necesarios se cargan dinámicamente cuando lo requiera la página, normalmente como respuesta a las acciones del usuario. La página no tiene que cargarse de nuevo en ningún punto del proceso y tampoco es necesario transferir a otra página las peticiones, aunque las tecnologías modernas (como el pushState() API del HTML5) permiten la navegabilidad en páginas lógicas dentro de la aplicación. La interacción con las aplicaciones de página única pueden involucrar comunicaciones dinámicas con el servidor web que está detrás.
Historia El término single-page application fue utilizado por Steve Yen en 2005, aunque el concepto ya había sido discutido en el año 2003. Stuart Morris escribió una página web de página única slashdotslash.com que tenía las mismas metas y funciones en el año 2002 En el mismo año Lucas Birdeau, Kevin Hakman, Michael Peachey y Evan Yeh describieron las implementaciones de aplicaciones de página única en la patente estadounidense 8,136,109.
Los navegadores modernos que pueden parsear HTML5 permiten a los desarrolladores cambiar la Interfaz del usuario y las aplicaciones lógicas de los servidores hacia los clientes. Bibliotecas de código abierto soportan la creación de un SPA sin forzar al desarrollador entrar a lo profundo de JavaScript y pelearse con los problemas de la tecnología.
Técnicas Existen varias técnicas que están disponibles y que pueden hacer que el navegador retenga en una sola página una aplicación que requiere comunicación con el servidor.
Frameworks de JavaScript Frameworks de JavaScript para los navegadores web como AngularJS, Ember.js, Meteor.js, ExtJS y React han adoptado los principios de SPA. AngularJS es una biblioteca del lado de cliente. AngularJS tiene templates que se basan en la tecnología de bidirectional UI data binding. Data binding es una forma automática de actualizar a la vista cuando el modelo cambia, así como actualizaciones al modelo cuando la vista cambia. El template de HTML está compilado en el navegador. Los pasos de la compilación crean un HTML puro, el cual el navegador lo interpreta y muestra. Los pasos se repiten para las vistas de las páginas subsecuentes. En la programación tradicional, donde se hace todo en el lado del servidor, los conceptos como controlador e interacción de modelo producen nuevas vistas de HTML desde el servidor. Dentro del framework AngularJS, el controlador y el modelo se mantienen dentro del navegador del cliente. Así haciendo que nuevas páginas puedan ser generadas sin interacción alguna con el servidor. Ember.js es un framework de JavaScript ejecutado del lado de cliente y se basa en la arquitectura Modelo-vista-controlador. Permite a los desarrolladores crear SPA´s escalables incorporando las mejores prácticas que proveen Objetos de modelo, data-binding bidirecional y propiedades calculadas, templates de actualización automática que están impulsados por Handlebars.js, y un manejador del estado de la aplicación. Vue.js Vue (pronunciado /vjuː/ en inglés, como view) es un framework progresivo para construir interfaces de usuario. A diferencia de otros frameworks monolíticos, Vue está diseñado desde el inicio para ser adoptado incrementalmente.
Meteor.js es un framework de JavaScript que se ejecuta de ambos lados(Full-Stack) especialmente para SPA's. Tiene funcionalidades más simples de data binding que Angular, Ember o ReactJS, y usa el protocolo de datos distribuidosIntroducing DDP, March 21, 2012 y un patrón de publicación-suscripción para propagar los cambios de datos a los clientes en tiempo real, sin tener que obligar a los desarrolladores a escribir ningún código de sincronización. La reactividad Full-Stack asegura que todas las capas de la base de datos, se actualicen automáticamente cuando sea necesario. Paquetes de ecosistema como Server Side Rendering resuelven el problema de Optimización de motor de Búsqueda. React's dominance in Single Page Applicationshttps://msmcoretech.com/blogs/single-page-applications (SPAs) stems from its component-based architecture, efficient virtual DOM rendering, and strong developer ecosystem. SPAs built with React deliver fast, app-like user experiences by dynamically updating content without full page reloads. This approach improves performance, simplifies state management, and enables scalable development across platforms. React’s flexibility also allows integration with routing libraries and build tools, making it a preferred choice for modern web applications
AJAX La técnica más prominente que se está utilizando es asynchronous JavaScript and XML (Ajax). Predomina el uso del objeto XMLHttpRequest de JavaScript, otras aplicaciones de AJAX incluyen el uso de IFRAME o elementos de script HTML. Bibliotecas populares como jQuery, normalizan el comportamiento de AJAX entre diferentes navegadores y productores, haciendo que Ajax se haga más popular.
Websockets WebSockets son tecnologías de comunicación en tiempo real entre el cliente y el servidor y forma parte de la especificación de HTML5. Es superior a AJAX en términos de rendimiento y simplicidad.
Plugins de navegadores Aunque este método es antiguo, las llamadas asíncronas al servidor también pueden ser logrados utilizando tecnologías de los plug-ins de los navegadores com Silverlight, Flash, o Java applets.
Transporte de datos (XML, JSON y AJAX) Las peticiones a los servidores normalmente resultan en datos crudos (XML o JSON), o son HTMLs nuevos que están siendo regresados. En los casos donde el HTML regresa como resultado, JavaScript en el cliente actualiza el área parcial de DOM (Document Object Model). Cuando el dato crudo es regresado, el JavaScript de lado del cliente procesa el XML o el JSON para hacer la traducción de los datos crudos a un HTML la cual es usada para actualizar la información del área parcial del DOM.
Arquitectura de servidor
Arquitectura de servidor ligero Un SPA se mueve lógicamente del servidor al cliente. Esto resulta en el rol del servidor web evolucionando en un servicio Web o un API de datos. Este cambio arquitectónico ha sido llamado como "Arquitectura de Servidor Delgado" para remarcar que la complejidad ha sido trasladado del servidor a los clientes, con el argumento de que esto reduce la complejidad del sistema.
Arquitectura de servidor pesado en estados El servidor sigue la memoria del estado de los clientes en la página. De esta forma, cuando llega una petición al servidor, los servidores mandan el HTML adecuado y con los cambios concretos hacia los clientes para que puedan transicionar al estado correspondiente (normalmente agregando/borrando/actualizando parte del DOM del cliente). Al mismo tiempo, el servidor de estados se actualiza. La mayor parte de la lógica se ejecuta en el servidor y el HTML también es procesado en el servidor. En algunos casos, el servidor simula el navegador web, recibiendo eventos y realizando cambios delta en el estado del servidor la cual se propaga automáticamente hacia el cliente.
Este enfoque necesita más memoria del servidor y procesamiento del servidor, pero la ventaja es que el modelo de desarrollo es simple porque a) la aplicación está completamente codificado en el servidor, y b) los datos y el estado en el servidor están almacenados en el mismo espacio de la memoria sin que sean necesarios los puentes de comunicación entre el servidor y el cliente.
Arquitectura de servidor pesado sin estados Es el variante del servidor de estados. En este caso, el cliente envía los datos que representa el estado al servidor, usualmente a través de peticiones de AJAX. Usando estos datos, el servidor puede reconstruir el estado del cliente y determinar la parte de la página que necesita ser modificado, lo genera con los datos necesarios la cual es enviado de vuelta al cliente para que pueda transicionar a otro estado, modificando el árbol de DOM según el acción del cliente que activó la petición.
Este enfoque requiere que se envíe más información al servidor y puede requerir más recursos computacionales por petición para poder reconstruir parcial o completamente la página del cliente en el servidor. Al mismo tiempo, este enfoque es más escalable porque no hay páginas de cliente que se almacenen en el servidor, por lo tanto las peticiones AJAX pueden transferirse a otro nodo del servidor sin la necesidad de compartir los datos de la sesión.
Ejecución local Algunos SPA's pueden ejecutarse utilizando los archivos locales a través del esquema URI. Esto permite a los usuarios descargar un SPA del servidor y ejecutar el archivo desde un almacenamiento local, sin tener que depender de la conectividad al servidor. Si algún SPA requiere guardar y actualizar los datos, debe utilizar almacenamiento web, el cual está basado en los navegadores; Estas aplicaciones se beneficiaron con los avances de HTML5 respecto a este.
Retos en el modelo SPA Como el SPA es una evolución lejos del modelo "stateless page-redraw" en la cual se basaron para diseñar a los navegadores, algunos cambios han surgido. Cada uno de estos problemas tiene una solución efectiva con:
Bibliotecas JavaScript de clientes Frameworks de lado del servidor que se especializan en el modelo SPA La evolución de los navegadores y el especificaciones de HTML5 que señalan el modelo de SPAHTML5
Optimización de motor de búsqueda
Por la falta de ejecución de JavaScript en los crawlers de los motores de Búsqueda populares SEO (Search engine optimization) ha tenido problemas para páginas públicas que adoptaron el modelo SPA.
Google hace el crawling de los URLs que contienen fragmentos de hash empezando por#!. Esto permite el uso de fragmentos de hash dentro de un solo URL de un SPA. Los comportamientos especiales deben ser implementados por el sitio de SPA para permitir la extracción de metadatos relevantes para el crawler del motor de la búsqueda. Para algunos motores de búsqueda que no soportan la esquema de hash en URL, los URL en hash del SPA permanecen invisibles.
Alternativamente, las aplicaciones pueden procesar la primera página durante el cargado en el servidor y las actualizaciones subsecuentes en el cliente. Esto es tradicionalmente difícil, porque el código de rendering podría tener que ser escrito en otro lenguaje o framework en el servidor y en el cliente. Usando plantillas sin lógica o usando la compilación cruzada de un lenguaje a otro, o usando el mismo lenguaje en el servidor y en el cliente podría ayudar a incrementar la cantidad de código que puede ser compartido.
Como la compatibilidad de SEO no es trivial en los SPAs, no es conveniente utilizar SPAs en los contextos en donde la indexación para los motores de búsqueda son un requisito. Los casos de uso incluyen aplicaciones que manejan datos privados y escondidos atrás de un sistema de autentificación. En los casos en donde estas aplicaciones son productos de consumidores, se utilizan modelos como "redibujado de página" como en las páginas de publicidad donde suficiente metadato de la aplicación aparece en el motor de búsqueda. Blogs, foros de soporte, y otros artefactos de redibujado también se juntan alrededor del SPA donde los motores puedan hacer búsquedas con los términos relevantes.