Aplicación de una sola página

Los autores de HTML pueden usar identificadores de elementos para mostrar u ocultar diferentes secciones del documento HTML. Luego, mediante CSS, pueden usar el :targetselector de pseudoclase para mostrar solo la sección de la página a la que navegó el navegador.

Los frameworks y bibliotecas de JavaScript para navegadores web, como Angular , Ember.js , ExtJS , Knockout.js , Meteor.js , React , Vue.js y Svelte , han adoptado los principios de las aplicaciones de una sola página (SPA). A excepción de ExtJS, todos ellos son gratuitos.

• AngularJS es un framework completamente del lado del cliente que ya no se utiliza. Su sistema de plantillas se basa en el enlace de datos bidireccional de la interfaz de usuario . Este enlace permite actualizar automáticamente la vista cuando cambia el modelo, y viceversa. La plantilla HTML se compila en el navegador. Este proceso crea HTML puro, que el navegador vuelve a renderizar en la vista en vivo. Este paso se repite para las siguientes páginas. En la programación HTML tradicional del lado del servidor, conceptos como controlador y modelo interactúan dentro de un proceso del servidor para generar nuevas vistas HTML. En AngularJS, los estados del controlador y del modelo se mantienen en el navegador del cliente. Por lo tanto, es posible generar nuevas páginas sin interacción con el servidor.
• Angular 2+ es un framework SPA desarrollado por Google después de AngularJS. Cuenta con una sólida comunidad de desarrolladores que lo utilizan. El framework se actualiza dos veces al año, añadiendo con frecuencia nuevas funcionalidades y correcciones.
• Ember.js es un framework de JavaScript para aplicaciones web del lado del cliente, basado en el patrón arquitectónico de software modelo-vista-controlador (MVC). Permite a los desarrolladores crear aplicaciones escalables de una sola página, incorporando prácticas recomendadas y convenciones comunes en un framework que proporciona un modelo de objetos completo, enlace de datos bidireccional declarativo, propiedades computadas, plantillas que se actualizan automáticamente gracias a Handlebars.js y un enrutador para gestionar el estado de la aplicación.
• ExtJS es un framework del lado del cliente que permite crear aplicaciones MVC. Cuenta con su propio sistema de eventos, gestión de ventanas y diseño, gestión de estado (almacenamiento) y diversos componentes de interfaz de usuario (cuadrículas, ventanas de diálogo, elementos de formulario, etc.). Dispone de su propio sistema de clases con cargador dinámico o estático. La aplicación creada con ExtJS puede funcionar de forma independiente (con el estado en el navegador) o en el servidor (por ejemplo, mediante una API REST que se utiliza para alimentar su almacenamiento interno). ExtJS solo tiene capacidades integradas para usar localStorage, por lo que las aplicaciones de mayor tamaño necesitan un servidor para almacenar el estado.
• Knockout.js es un framework del lado del cliente que utiliza plantillas basadas en el patrón modelo-vista-modelo de vista (MVVM).
• Meteor.js es un framework JavaScript full-stack (cliente-servidor) diseñado exclusivamente para SPAs. Ofrece un enlace de datos más sencillo que Angular, Ember o ReactJS, ^{[ 5 ]} y utiliza el Protocolo de Datos Distribuidos ^{[ 6 ]} y un patrón de publicación-suscripción para propagar automáticamente los cambios de datos a los clientes en tiempo real sin que el desarrollador tenga que escribir código de sincronización. La reactividad full-stack garantiza que todas las capas, desde la base de datos hasta las plantillas, se actualicen automáticamente cuando sea necesario. Los paquetes del ecosistema, como Server-Side Rendering ^{[ 7 ] [ 8 ],} abordan el problema de la optimización para motores de búsqueda.
• React es una biblioteca de JavaScript para la creación de interfaces de usuario . Es mantenida por Facebook , Instagram y una comunidad de desarrolladores individuales y empresas. React utiliza una extensión de sintaxis para JavaScript, llamada JSX , que es una combinación de JS y HTML (un subconjunto de HTML). Varias empresas utilizan React con Redux (biblioteca de JavaScript) , que añade capacidades de gestión de estado, lo que (junto con otras bibliotecas) permite a los desarrolladores crear aplicaciones complejas. ^{[ 9 ]}
• Vue.js es un framework de JavaScript para la creación de interfaces de usuario. Los desarrolladores de Vue también proporcionan Pinia para la gestión del estado.
• Svelte es un framework para la creación de interfaces de usuario que compila el código Svelte a manipulaciones del DOM (Modelo de Objetos del Documento) de JavaScript, evitando la necesidad de incluir un framework en el cliente y permitiendo una sintaxis de desarrollo de aplicaciones más sencilla.

Los siguientes frameworks utilizan WebAssembly o permiten crear aplicaciones de una sola página (SPA) con WebAssembly como tecnología principal o mecanismo de soporte. Estos frameworks posibilitan un desarrollo del lado del cliente interactivo y de alto rendimiento, extendiendo el paradigma SPA a través de diferentes lenguajes y ecosistemas.

• Avalonia es principalmente un framework de interfaz de usuario de escritorio multiplataforma , pero su compatibilidad experimental con WebAssembly permite utilizarlo para el desarrollo de aplicaciones de una sola página (SPA). Cuenta con un diseño de interfaz de usuario basado en XAML y características de aplicación de estilo nativo.
• Blazor WebAssembly es un framework basado en .NET que permite a los desarrolladores crear aplicaciones de una sola página (SPA) utilizando C# y la sintaxis Razor . Ejecuta código .NET en el navegador a través de WebAssembly, lo que posibilita una experiencia de desarrollo .NET completa sin depender de JavaScript.
• Flutter on the Web extiende las capacidades de desarrollo multiplataforma de Flutter a las aplicaciones de una sola página (SPA) basadas en la web. Mediante Dart y su motor gráfico Skia, Flutter permite a los desarrolladores crear SPA visualmente atractivas que se ejecutan en el navegador.
• OpenSilver es otra reimplementación de código abierto de Silverlight, pero orientada a aplicaciones de una sola página (SPA) desarrolladas con C# y XAML . Utiliza WebAssembly para ejecutar el código .NET en el navegador, por lo que resulta ideal para aplicaciones del lado del cliente altamente interactivas.
• Uno Platform es un framework multiplataforma que admite el desarrollo de SPA (Single Page Applications) mediante WebAssembly. Permite a los desarrolladores usar XAML y C# para crear aplicaciones que se ejecutan en plataformas web, móviles y de escritorio, con componentes de interfaz de usuario renderizados directamente en el navegador.

A partir de 2006, la técnica más destacada utilizada fue Ajax . ^{[ 1 ]} Ajax implica el uso de solicitudes asíncronas a un servidor para datos XML o JSON , como con XMLHttpRequest de JavaScript o más moderno fetch()(desde 2017), o el obsoleto objeto ActiveX . A diferencia del enfoque declarativo de la mayoría de los frameworks SPA, con Ajax el sitio web utiliza directamente JavaScript o una biblioteca de JavaScript como jQuery para manipular el DOM y editar elementos HTML. Ajax se ha popularizado aún más gracias a bibliotecas como jQuery , que proporciona una sintaxis más simple y normaliza el comportamiento de Ajax en diferentes navegadores que históricamente presentaban un comportamiento variable.

WebSockets es una tecnología de comunicación bidireccional en tiempo real entre cliente y servidor que forma parte de la especificación HTML. Para la comunicación en tiempo real, su uso es superior a Ajax en términos de rendimiento ^{[ 16 ]} y simplicidad.

Los eventos enviados por el servidor (SSE) son una técnica mediante la cual los servidores pueden iniciar la transmisión de datos a los clientes del navegador. Una vez establecida la conexión inicial, el flujo de eventos permanece abierto hasta que el cliente lo cierra. Los SSE se envían a través de HTTP tradicional y cuentan con diversas características de las que carecen los WebSockets por diseño, como la reconexión automática, los identificadores de eventos y la capacidad de enviar eventos arbitrarios. ^{[ 17 ]}

Aunque este método está obsoleto, también se pueden realizar llamadas asíncronas al servidor utilizando tecnologías de complementos del navegador como Silverlight , Flash o applets de Java .

Las solicitudes al servidor suelen devolver datos sin procesar (por ejemplo, XML o JSON ) o código HTML nuevo . Si el servidor devuelve HTML, JavaScript en el cliente actualiza una sección del DOM ( Modelo de Objetos del Documento ). Si se devuelven datos sin procesar, JavaScript en el cliente los convierte a HTML mediante XSL o una plantilla JSON antes de actualizar el DOM.

Debido a la falta de ejecución de JavaScript en los rastreadores de algunos motores de búsqueda web populares , ^{[ 24 ]} el SEO ( optimización para motores de búsqueda ) ha presentado históricamente un problema para los sitios web de cara al público que desean adoptar el modelo SPA. ^{[ 25 ]}

Entre 2009 y 2015, Google Webmaster Central propuso y luego recomendó un "esquema de rastreo AJAX" ^{[ 26 ] [ 27 ]} que utiliza un signo de exclamación inicial en los identificadores de fragmento para páginas AJAX#! con estado ( ). El sitio SPA debe implementar un comportamiento especial para permitir la extracción de metadatos relevantes por parte del rastreador del motor de búsqueda. Para los motores de búsqueda que no admiten este esquema de hash de URL , las URL hash de la SPA permanecen invisibles. Estas URI "hash-bang" han sido consideradas problemáticas por varios autores, incluida Jeni Tennison del W3C, porque hacen que las páginas sean inaccesibles para aquellos que no tienen JavaScript activado en su navegador. También rompen los encabezados referer HTTP, ya que los navegadores no tienen permitido enviar el identificador de fragmento en el encabezado Referer. ^{[ 28 ]} En 2015, Google desaprobó su propuesta de rastreo AJAX hash-bang. ^{[ 29 ]}

Como alternativa, las aplicaciones pueden renderizar la primera carga de página en el servidor y las actualizaciones posteriores en el cliente. Esto suele ser complicado, ya que el código de renderizado podría requerir un lenguaje o framework diferente en el servidor y en el cliente. El uso de plantillas sin lógica, la compilación cruzada entre lenguajes o el uso del mismo lenguaje en el servidor y el cliente pueden ayudar a aumentar la cantidad de código que se puede compartir.

En 2018, Google introdujo la renderización dinámica como otra opción para los sitios que deseaban ofrecer a los rastreadores una versión de una página con menos JavaScript para fines de indexación. ^{[ 30 ]} La renderización dinámica alterna entre una versión de una página que se renderiza en el lado del cliente y una versión prerrenderizada para agentes de usuario específicos. Este enfoque implica que su servidor web detecte los rastreadores (a través del agente de usuario) y los dirija a un renderizador, desde el cual se les sirve una versión más simple del contenido HTML. A partir de 2024, Google ya no recomienda la renderización dinámica, ^{[ 31 ]} sugiriendo en su lugar " renderización del lado del servidor , renderización estática o hidratación ".

Debido a que la compatibilidad con SEO no es trivial en las SPA, estas no suelen utilizarse en contextos donde la indexación por motores de búsqueda sea un requisito o deseable. Entre los casos de uso se incluyen aplicaciones que muestran datos privados protegidos por un sistema de autenticación . En el caso de que estas aplicaciones sean productos de consumo, se suele utilizar un modelo clásico de "reinicio de página" para la página de inicio y el sitio de marketing, lo que proporciona suficientes metadatos para que la aplicación aparezca como resultado en una consulta de búsqueda. Blogs, foros de soporte y otros elementos tradicionales de rediseño de página suelen rodear la SPA y pueden proporcionar a los motores de búsqueda términos relevantes.

A partir de 2021 y específicamente en Google, la compatibilidad SEO para una SPA simple es sencilla y solo requiere que se cumplan algunas condiciones simples. ^{[ 32 ]}

Una forma de aumentar la cantidad de código que se puede compartir entre servidores y clientes es usar un lenguaje de plantillas sin lógica como Mustache o Handlebars . Estas plantillas se pueden renderizar desde diferentes lenguajes de programación, como Ruby en el servidor y JavaScript en el cliente. Sin embargo, compartir plantillas suele requerir la duplicación de la lógica de negocio utilizada para elegir las plantillas correctas y rellenarlas con datos. La renderización desde plantillas puede tener efectos negativos en el rendimiento cuando solo se actualiza una pequeña parte de la página, como el valor de un campo de texto dentro de una plantilla grande. Reemplazar una plantilla completa también podría afectar la selección o la posición del cursor del usuario, mientras que actualizar solo el valor modificado podría no hacerlo. Para evitar estos problemas, las aplicaciones pueden usar enlaces de datos de la interfaz de usuario o manipulación granular del DOM para actualizar solo las partes apropiadas de la página en lugar de volver a renderizar plantillas completas. ^{[ 33 ]}

Dado que una SPA (Single Page Application) es, por definición, una "página única", este modelo altera el diseño del navegador para la navegación del historial de páginas mediante los botones "adelante" o "atrás". Esto supone un problema de usabilidad cuando un usuario pulsa el botón de retroceso, esperando ver el estado de la pantalla anterior dentro de la SPA, pero en su lugar, la página única de la aplicación se descarga y se muestra la página anterior del historial del navegador.

La solución tradicional para las aplicaciones de una sola página (SPA) ha consistido en modificar el identificador del fragmento hash de la URL del navegador según el estado actual de la pantalla. Esto se puede lograr con JavaScript y genera eventos en el historial de URL del navegador. Siempre que la SPA sea capaz de recuperar el mismo estado de pantalla a partir de la información contenida en el hash de la URL, se mantiene el comportamiento esperado del botón de retroceso.

Para abordar mejor este problema, la especificación HTML ha introducido pushState y replaceState, que proporcionan acceso programático a la URL real y al historial del navegador.

Las herramientas de análisis como Google Analytics dependen en gran medida de la carga de páginas completamente nuevas en el navegador, iniciada por una nueva carga de página. Las SPA no funcionan de esta manera.

Tras la primera carga de la página, todos los cambios posteriores de página y contenido son gestionados internamente por la aplicación, que simplemente debería llamar a una función para actualizar el paquete de análisis. Si no se llama a dicha función, el navegador nunca carga una nueva página, no se añade nada al historial de navegación y el paquete de análisis desconoce qué acciones se realizan en el sitio.

De forma similar a los problemas encontrados con los rastreadores de motores de búsqueda, las herramientas DAST pueden tener dificultades con estas aplicaciones ricas en JavaScript. Los problemas pueden incluir la falta de enlaces de hipertexto, preocupaciones sobre el uso de memoria y los recursos cargados por la SPA normalmente disponibles a través de una Interfaz de Programación de Aplicaciones o API. Las aplicaciones de una sola página siguen estando sujetas a los mismos riesgos de seguridad que las páginas web tradicionales, como el Cross-Site Scripting (XSS) , pero también a una serie de otras vulnerabilidades únicas, como la exposición de datos a través de la API y la lógica del lado del cliente y la aplicación del lado del cliente de la seguridad del lado del servidor. ^{[ 34 ]} Para escanear eficazmente una aplicación de una sola página, un escáner DAST debe poder navegar por la aplicación del lado del cliente de manera fiable y repetible para permitir el descubrimiento de todas las áreas de la aplicación y la interceptación de todas las solicitudes que la aplicación envía a servidores remotos (por ejemplo, solicitudes de API).

Es posible agregar eventos de carga de página a una SPA mediante la API de historial HTML; esto ayudará a integrar análisis. La dificultad radica en gestionar esto y asegurar que todo se registre con precisión, lo que implica verificar si faltan informes o si hay entradas duplicadas. Algunos frameworks ofrecen integraciones de análisis gratuitas que abarcan la mayoría de los principales proveedores de análisis. Los desarrolladores pueden integrarlas en la aplicación y asegurarse de que todo funcione correctamente, pero no es necesario empezar desde cero. ^{[ 33 ]}

Existen algunas maneras de acelerar la carga inicial de una SPA, como el prerrenderizado selectivo de la página de inicio/índice, el almacenamiento en caché y diversas técnicas de división de código, incluyendo la carga diferida de módulos cuando sea necesario. Sin embargo, es inevitable que se descargue el framework, al menos parte del código de la aplicación, y que se acceda a una API para obtener datos si la página es dinámica. ^{[ 33 ]} Se trata de una disyuntiva entre "pagar ahora o pagar después". La cuestión del rendimiento y los tiempos de espera sigue siendo una decisión que debe tomar el desarrollador.