Una aplicación de una sola página ( SPA ) es una aplicación web o un sitio web que interactúa con el usuario reescribiendo dinámicamente la página web actual con nuevos datos del servidor web , en lugar del método predeterminado de un navegador web que carga páginas completamente nuevas. El objetivo son transiciones más rápidas que hagan que el sitio web se sienta más como una aplicación nativa .
En un SPA, nunca se actualiza una página; en su lugar, todo el código HTML , JavaScript y CSS necesario es recuperado por el navegador con una sola carga de página, [1] o los recursos apropiados se cargan dinámicamente y se agregan a la página según sea necesario, generalmente en respuesta a las acciones del usuario. La página no se recarga en ningún momento del proceso, ni transfiere el control a otra página, aunque el hash de ubicación o la API de historial HTML5 se pueden utilizar para proporcionar la percepción y navegabilidad de páginas lógicas separadas en la aplicación. [2]
Historia
Los orígenes del término aplicación de una sola página no están claros, aunque el concepto se discutió al menos ya en 2003. [3] Stuart Morris, un estudiante de programación en la Universidad de Cardiff, Gales, escribió el sitio web autónomo en slashdotslash.com con los mismos objetivos y funciones en abril de 2002, [4] y más tarde el mismo año Lucas Birdeau, Kevin Hakman, Michael Peachey y Clifford Yeh describieron una implementación de solicitud de una sola página en la patente estadounidense 8.136.109. [5]
JavaScript se puede utilizar en un navegador web para mostrar la interfaz de usuario (UI), ejecutar la lógica de la aplicación y comunicarse con un servidor web. Hay disponibles bibliotecas maduras de código abierto que admiten la creación de un SPA, lo que reduce la cantidad de código JavaScript que los desarrolladores tienen que escribir.
Enfoques técnicos
Hay varias técnicas disponibles que permiten al navegador retener una sola página incluso cuando la aplicación requiere comunicación con el servidor.
Hashes de documentos
Los autores de HTML pueden aprovechar los ID de elementos para mostrar u ocultar diferentes secciones del documento HTML. Luego, usando CSS, los autores pueden usar el selector `# target` para mostrar solo la sección de la página a la que navegó el navegador.
Marcos de JavaScript
Los marcos y bibliotecas de JavaScript del navegador web, como AngularJS , Ember.js , ExtJS , Knockout.js , Meteor.js , React , Vue.js y Svelte han adoptado los principios de SPA. Aparte de ExtJS, todos estos son de código abierto .
- AngularJS es un marco totalmente del lado del cliente. Las plantillas de AngularJS se basan en el enlace de datos de la interfaz de usuario bidireccional . El enlace de datos es una forma automática de actualizar la vista cada vez que cambia el modelo, así como de actualizar el modelo cada vez que cambia la vista. La plantilla HTML se compila en el navegador. El paso de compilación crea HTML puro, que el navegador vuelve a renderizar en la vista en vivo. El paso se repite para las visitas de página posteriores. En la programación HTML tradicional del lado del servidor, conceptos como controlador y modelo interactúan dentro de un proceso de servidor para producir nuevas vistas HTML. En el marco AngularJS, los estados del controlador y del modelo se mantienen dentro del navegador del cliente. Por lo tanto, se pueden generar nuevas páginas sin ninguna interacción con un servidor.
- Ember.js es un marco de aplicación web JavaScript 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 modismos comunes y mejores prácticas en un marco que proporciona un modelo de objetos enriquecido, enlace de datos bidireccional declarativo, propiedades calculadas, plantillas de actualización automática impulsadas por Handlebars.js y un enrutador para gestionar el estado de la aplicación.
- ExtJS también es un marco del lado del cliente que permite crear aplicaciones MVC. Tiene su propio sistema de eventos, administración de ventanas y diseño, administración de estado (tiendas) y varios componentes de interfaz de usuario (cuadrículas, ventanas de diálogo, elementos de formulario, etc.). Tiene su propio sistema de clases con cargador dinámico o estático. La aplicación construida con ExtJS puede existir por sí sola (con el estado en el navegador) o con el servidor (por ejemplo, con la API REST que se usa para llenar sus tiendas internas). ExtJS solo tiene capacidades integradas para usar localStorage, por lo que las aplicaciones más grandes necesitan un servidor para almacenar el estado.
- Knockout.js es un marco del lado del cliente que usa plantillas basadas en el patrón Model-View-ViewModel .
- Meteor.js es un marco de JavaScript de pila completa (cliente-servidor) diseñado exclusivamente para SPA. Cuenta con un enlace de datos más simple que Angular, Ember o ReactJS, [6] y utiliza el Protocolo de datos distribuidos [7] y un patrón de publicación-suscripción para propagar automáticamente los cambios de datos a los clientes en tiempo real sin necesidad de que el desarrollador escriba ningún código de sincronización. . La reactividad de la pila completa garantiza que todas las capas, desde la base de datos hasta las plantillas, se actualicen automáticamente cuando sea necesario. Los paquetes de ecosistemas como Server Side Rendering [8] abordan el problema de la optimización de motores de búsqueda.
- React es una biblioteca de JavaScript para crear interfaces de usuario . Es mantenido por Facebook , Instagram y una comunidad de desarrolladores y corporaciones individuales. React usa un nuevo lenguaje que es una mezcla de JS y HTML (un subconjunto de HTML). Varias empresas usan React with Redux (biblioteca de JavaScript) que agrega capacidades de administración de estado, lo que (con varias otras bibliotecas) permite a los desarrolladores crear aplicaciones complejas. [9]
- Vue.js es un marco de JavaScript para crear interfaces de usuario. Los desarrolladores de Vue también proporcionan Vuex para la gestión del estado.
- Svelte es un marco para construir interfaces de usuario que compila código Svelte para manipulaciones DOM de JavaScript, evitando la necesidad de empaquetar un marco para el cliente y permitiendo una sintaxis de desarrollo de aplicaciones más simple.
Ajax
A partir de 2006, la técnica más destacada utilizada fue Ajax . [1] Ajax implica el uso de solicitudes asincrónicas a un servidor para datos XML o JSON , como con XMLHttpRequest de JavaScript o fetch () más moderno (desde 2017), o el objeto ActiveX obsoleto . A diferencia del enfoque declarativo de la mayoría de los marcos de 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 ha sido popularizado aún más por bibliotecas como jQuery , que proporciona una sintaxis más simple y normaliza el comportamiento de Ajax en diferentes navegadores que históricamente han tenido un comportamiento variable.
WebSockets
Los WebSockets son una tecnología de comunicación cliente-servidor bidireccional en tiempo real que forman parte de la especificación HTML5. Para la comunicación en tiempo real, su uso es superior al de Ajax en términos de rendimiento [10] y simplicidad.
Eventos enviados por el servidor
Los eventos enviados por el servidor (SSE) es una técnica mediante la cual los servidores pueden iniciar la transmisión de datos a los clientes del navegador. Una vez que se ha establecido una conexión inicial, un flujo de eventos permanece abierto hasta que el cliente lo cierra. Los SSE se envían a través de HTTP tradicional y tienen una variedad de características de las que los WebSockets carecen por diseño, como reconexión automática, ID de eventos y la capacidad de enviar eventos arbitrarios. [11]
Complementos del navegador
Aunque este método está desactualizado, las llamadas asincrónicas al servidor también se pueden lograr utilizando tecnologías de complementos del navegador como Silverlight , Flash o subprogramas de Java .
Transporte de datos (XML, JSON y Ajax)
Las solicitudes al servidor generalmente dan como resultado datos sin procesar (por ejemplo, XML o JSON ) o HTML nuevo que se devuelve. En el caso de que el servidor devuelva HTML, JavaScript en el cliente actualiza un área parcial del DOM ( Modelo de objetos de documento ). [12] Cuando se devuelven datos sin procesar, a menudo se usa un proceso JavaScript XML / ( XSL ) del lado del cliente (y en el caso de JSON una plantilla ) para traducir los datos sin procesar a HTML, que luego se usa para actualizar un área parcial del DOM.
Arquitectura del servidor
Arquitectura de servidor delgado
Un SPA mueve la lógica del servidor al cliente, con la función del servidor web evolucionando hacia una API de datos puros o un servicio web. Este cambio de arquitectura, en algunos círculos, ha sido denominado "Arquitectura de servidor delgado" para resaltar que la complejidad se ha trasladado del servidor al cliente, con el argumento de que esto reduce en última instancia la complejidad general del sistema.
Arquitectura de servidor con estado grueso
El servidor mantiene en memoria el estado necesario del estado del cliente de la página. De esta manera, cuando cualquier solicitud llega al servidor (generalmente acciones del usuario), el servidor envía el HTML y / o JavaScript apropiado con los cambios concretos para llevar al cliente al nuevo estado deseado (generalmente agregando / eliminando / actualizando una parte del cliente DOM). Al mismo tiempo, se actualiza el estado en el servidor. La mayor parte de la lógica se ejecuta en el servidor y, por lo general, HTML también se representa en el servidor. De alguna manera, el servidor simula un navegador web, recibiendo eventos y realizando cambios delta en el estado del servidor que se propagan automáticamente al cliente.
Este enfoque necesita más memoria de servidor y procesamiento de servidor, pero la ventaja es un modelo de desarrollo simplificado porque a) la aplicación generalmente está completamente codificada en el servidor, yb) los datos y el estado de la interfaz de usuario en el servidor se comparten en el mismo espacio de memoria sin necesidad de puentes de comunicación cliente / servidor personalizados.
Arquitectura de servidor sin estado grueso
Esta es una variante del enfoque de servidor con estado. La página del cliente envía datos que representan su estado actual al servidor, generalmente a través de solicitudes Ajax. Con estos datos, el servidor puede reconstruir el estado del cliente de la parte de la página que necesita ser modificada y puede generar los datos o el código necesarios (por ejemplo, como JSON o JavaScript), que se devuelve al cliente para traer a un nuevo estado, generalmente modificando el árbol DOM de la página de acuerdo con la acción del cliente que motivó la solicitud.
Este enfoque requiere que se envíen más datos al servidor y puede requerir más recursos computacionales por solicitud para reconstruir parcial o totalmente el estado de la página del cliente en el servidor. Al mismo tiempo, este enfoque es más fácilmente escalable porque no hay datos de página por cliente guardados en el servidor y, por lo tanto, las solicitudes Ajax se pueden enviar a diferentes nodos del servidor sin necesidad de compartir datos de sesión o afinidad con el servidor.
Ejecutando localmente
Algunas SPA pueden ejecutarse desde un archivo local utilizando el esquema de URI de archivo . Esto brinda a los usuarios la capacidad de descargar el SPA desde un servidor y ejecutar el archivo desde un dispositivo de almacenamiento local, sin depender de la conectividad del servidor. Si tal SPA desea almacenar y actualizar datos, debe usar almacenamiento web basado en navegador . Estas aplicaciones se benefician de los avances disponibles con HTML5 . [13]
Desafíos con el modelo SPA
Debido a que el SPA es una evolución que se aleja del modelo de redibujado de páginas sin estado para el que se diseñaron originalmente los navegadores, han surgido algunos desafíos nuevos. Las posibles soluciones (de diversa complejidad, exhaustividad y control de autor) incluyen: [14]
- Bibliotecas de JavaScript del lado del cliente.
- Marcos web del lado del servidor que se especializan en el modelo SPA. [15] [16] [17]
- La evolución de los navegadores y la especificación HTML5, [18] diseñada para el modelo SPA.
Optimización de motores de búsqueda
Debido a la falta de ejecución de JavaScript en los rastreadores de algunos motores de búsqueda populares , [19] SEO ( optimización de motores de búsqueda ) ha presentado históricamente un problema para los sitios web públicos que desean adoptar el modelo SPA. [20]
Entre 2009 y 2015, Google Webmaster Central propuso y luego recomendó un "esquema de rastreo AJAX" [21] [22] utilizando un signo de exclamación inicial en los identificadores de fragmentos para las 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 con hash del SPA permanecen invisibles. Estos URI "hash-bang" han sido considerados problemáticos por varios escritores, incluida Jeni Tennison en el W3C, porque hacen que las páginas sean inaccesibles para aquellos que no tienen JavaScript activado en su navegador. También rompen los encabezados de referencia de HTTP, ya que los navegadores no pueden enviar el identificador de fragmento en el encabezado de referencia. [23] En 2015, Google desaprobó su propuesta de rastreo de hash-bang AJAX. [24]
Alternativamente, las aplicaciones pueden representar la carga de la primera página en el servidor y las actualizaciones de página subsiguientes en el cliente. Esto es tradicionalmente difícil, porque es posible que el código de renderizado deba escribirse en un lenguaje o marco diferente en el servidor y en el cliente. El uso de plantillas sin lógica, la compilación cruzada de un idioma a otro o el uso del mismo idioma en el servidor y el cliente pueden ayudar a aumentar la cantidad de código que se puede compartir.
En 2018, Google introdujo el renderizado dinámico como otra opción para los sitios que deseen ofrecer a los rastreadores una versión pesada de una página sin JavaScript para fines de indexación. [25] El renderizado dinámico cambia entre una versión de una página que se renderiza en el lado del cliente y una versión previamente renderizada 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 enrute a un renderizador, desde el cual luego se les entrega una versión más simple de contenido HTML.
Debido a que la compatibilidad de SEO no es trivial en las SPA, vale la pena señalar que las SPA comúnmente no se usan en un contexto donde la indexación de motores de búsqueda es un requisito o deseable. Los casos de uso incluyen aplicaciones que muestran datos privados ocultos detrás de un sistema de autenticación . En los casos en que estas aplicaciones son productos de consumo, a menudo se utiliza un modelo clásico de "redibujo de página" para la página de destino de las aplicaciones y el sitio de marketing, que proporciona suficientes metadatos para que la aplicación aparezca como un éxito en una consulta de motor de búsqueda. Los blogs, foros de soporte y otros artefactos tradicionales de redibujo de páginas a menudo se encuentran alrededor del SPA que pueden sembrar motores de búsqueda con términos relevantes.
Otro enfoque utilizado por los marcos web centrados en el servidor como ItsNat basado en Java es representar cualquier hipertexto en el servidor utilizando el mismo lenguaje y tecnología de plantillas. En este enfoque, el servidor conoce con precisión el estado del DOM en el cliente, cualquier actualización de página grande o pequeña requerida se genera en el servidor y es transportada por Ajax, el código JavaScript exacto para llevar la página del cliente al nuevo estado ejecutando métodos DOM. . Los desarrolladores pueden decidir qué estados de la página deben ser rastreados por las arañas web para SEO y poder generar el estado requerido en el momento de la carga generando HTML sin formato en lugar de JavaScript. En el caso del marco ItsNat, esto es automático porque ItsNat mantiene el árbol DOM del cliente en el servidor como un árbol DOM Java W3C; La representación de este árbol DOM en el servidor genera HTML sin formato en el momento de la carga y acciones DOM de JavaScript para las solicitudes Ajax. Esta dualidad es muy importante para SEO porque los desarrolladores pueden construir con el mismo código Java y plantillas basadas en HTML puro el estado DOM deseado en el servidor; En el momento de la carga de la página, ItsNat genera HTML convencional, lo que hace que este estado DOM sea compatible con SEO.
A partir de la versión 1.3, [26] ItsNat proporciona un nuevo modo sin estado, y el DOM del cliente no se mantiene en el servidor porque, con el cliente en modo sin estado, el estado del DOM se reconstruye parcial o totalmente en el servidor al procesar cualquier solicitud Ajax basada en datos requeridos enviados por el cliente que informan al servidor del estado actual del DOM; el modo sin estado también puede ser compatible con SEO porque la compatibilidad con SEO ocurre en el momento de la carga de la página inicial y no se ve afectada por los modos con estado o sin estado. Otra posible opción son los marcos como PreRender, Puppeteer, Rendertron que se pueden integrar fácilmente en cualquier sitio web como un middleware con la configuración del servidor web que permite que las solicitudes de bot (bot de Google y otros) sean atendidas por el middleware mientras que las solicitudes que no son de bot se atienden como de costumbre . Estos marcos almacenan en caché las páginas relevantes del sitio web periódicamente para permitir que las últimas versiones estén disponibles para los motores de búsqueda. Estos marcos han sido aprobados oficialmente por Google. [27]
Hay un par de soluciones para que parezca que el sitio web se puede rastrear. Ambos implican la creación de páginas HTML independientes que reflejan el contenido del SPA. El servidor podría crear una versión del sitio basada en HTML y entregarla a los rastreadores, o es posible usar un navegador sin cabeza como PhantomJS para ejecutar la aplicación JavaScript y generar el HTML resultante.
Ambos requieren bastante esfuerzo y pueden terminar dando un dolor de cabeza de mantenimiento para los sitios grandes y complejos. También existen posibles problemas de SEO. Si se considera que el HTML generado por el servidor es demasiado diferente del contenido de SPA, el sitio será penalizado. La ejecución de PhantomJS para generar el HTML puede ralentizar la velocidad de respuesta de las páginas, que es algo por lo que los motores de búsqueda, Google en particular, degradan la clasificación. [28]
Partición de código cliente / servidor
Una forma de aumentar la cantidad de código que se puede compartir entre servidores y clientes es utilizar un lenguaje de plantilla sin lógica como Moustache o Handlebars . Estas plantillas se pueden renderizar desde diferentes lenguajes de host, como Ruby en el servidor y JavaScript en el cliente. Sin embargo, el simple hecho de compartir plantillas normalmente requiere la duplicación de la lógica empresarial utilizada para elegir las plantillas correctas y completarlas con datos. La representación a partir de plantillas puede tener efectos negativos en el rendimiento cuando solo se actualiza una pequeña parte de la página, como el valor de una entrada de texto dentro de una plantilla grande. Reemplazar una plantilla completa también puede perturbar la selección de un usuario o la posición del cursor, mientras que actualizar solo el valor cambiado podría no hacerlo. Para evitar estos problemas, las aplicaciones pueden usar enlaces de datos de IU o manipulación DOM granular para actualizar solo las partes apropiadas de la página en lugar de volver a renderizar plantillas completas.
Historial del navegador
Siendo un SPA, por definición, "una sola página", el modelo rompe el diseño del navegador para la navegación del historial de la página usando los botones "adelante" o "atrás". Esto presenta un impedimento de usabilidad cuando un usuario presiona el botón Atrás, esperando el estado de la pantalla anterior dentro del SPA, pero en cambio, la aplicación se descarga de una sola página y se presenta la página anterior en el historial del navegador.
La solución tradicional para las SPA ha sido cambiar el identificador del fragmento hash de la URL del navegador de acuerdo con el estado actual de la pantalla. Esto se puede lograr con JavaScript y hace que los eventos del historial de URL se generen dentro del navegador. Siempre que el SPA sea capaz de resucitar el mismo estado de pantalla a partir de la información contenida en el hash de la URL, se conserva el comportamiento esperado del botón de retroceso.
Para abordar aún más este problema, la especificación HTML5 ha introducido pushState y replaceState proporcionando acceso programático a la URL real y al historial del navegador.
Analítica
Las herramientas de análisis como Google Analytics dependen en gran medida de la carga de páginas completamente nuevas en el navegador, iniciadas por la carga de una nueva página. Los SPA no funcionan de esta manera.
Después de la carga de la primera página, la aplicación maneja internamente todos los cambios de contenido y de página subsiguientes, que simplemente debe llamar a una función para actualizar el paquete de análisis. Si no se llama a dicha función, el navegador nunca activa la carga de una nueva página, no se agrega nada al historial del navegador y el paquete de análisis no tiene idea de quién está haciendo qué en el sitio.
Escaneo de seguridad
De manera similar a los problemas encontrados con los rastreadores de motores de búsqueda, las herramientas DAST pueden tener problemas con estas aplicaciones ricas en JavaScript. Los problemas pueden incluir la falta de enlaces de hipertexto, el uso de la memoria y los recursos cargados por el SPA que normalmente están disponibles mediante una interfaz de programación de aplicaciones o API. Las aplicaciones de una sola página todavía están sujetas a los mismos riesgos de seguridad que las páginas web tradicionales como Cross-Site Scripting (XSS) , pero también una serie de otras vulnerabilidades únicas como la exposición de datos a través de API y la lógica del lado del cliente y la aplicación del servidor del lado del cliente. -Seguridad lateral. [29] Para escanear de manera efectiva una aplicación de una sola página, un escáner DAST debe poder navegar por la aplicación del lado del cliente de una manera confiable y repetible para permitir el descubrimiento de todas las áreas de la aplicación y la interceptación de todas las solicitudes que envía la aplicación. a servidores remotos (por ejemplo, solicitudes de API). Hay pocas herramientas comerciales capaces de realizar tales acciones, pero definitivamente existen.
Agregar cargas de página a un SPA
Es posible agregar eventos de carga de página a un SPA usando la API de historial HTML5; esto ayudará a integrar la analítica. La dificultad radica en gestionar esto y asegurarse de que todo se rastrea con precisión; esto implica verificar si faltan informes y entradas dobles. Algunos marcos proporcionan integraciones de análisis de código abierto que se dirigen a la mayoría de los principales proveedores de análisis. Los desarrolladores pueden integrarlos en la aplicación y asegurarse de que todo funcione correctamente, pero no es necesario hacerlo todo desde cero. [28]
Acelerando la carga de la página
Hay algunas formas de acelerar la carga inicial de un SPA, como un enfoque pesado para el almacenamiento en caché y los módulos de carga diferida cuando sea necesario. Pero no es posible evitar el hecho de que necesita descargar el marco, al menos parte del código de la aplicación, y lo más probable es que acceda a una API para obtener datos antes de mostrar algo en el navegador. [28] Este es un escenario de compensación "págame ahora o págame después". La cuestión del rendimiento y los tiempos de espera sigue siendo una decisión que debe tomar el desarrollador.
Ciclo de vida de la página
Un SPA se carga completamente en la carga de la página inicial y luego las regiones de la página se reemplazan o actualizan con nuevos fragmentos de página cargados desde el servidor a pedido. Para evitar la descarga excesiva de funciones no utilizadas, un SPA a menudo descargará progresivamente más funciones a medida que sean necesarias, ya sea pequeños fragmentos de la página o módulos de pantalla completos.
De esta manera existe una analogía entre "estados" en un SPA y "páginas" en un sitio web tradicional. Debido a que la "navegación de estado" en la misma página es análoga a la navegación de página, en teoría, cualquier sitio web basado en páginas podría convertirse en una sola página reemplazando en la misma página solo las partes modificadas.
El enfoque de SPA en la web es similar a la técnica de presentación de interfaz de documento único (SDI) popular en las aplicaciones de escritorio nativas .
Ver también
- Aplicación web progresiva (PWA)
Referencias
- ↑ a b Flanagan, David, " JavaScript - The Definitive Guide ", 5.a ed., O'Reilly, Sebastopol, CA, 2006 , p.497
- ^ "Arreglar el botón Atrás: comportamiento del SPA mediante el hash de ubicación" . Blog de software de Falafel . Consultado el 18 de enero de 2016 .
- ^ "Navegación interna: ampliar la navegación web el paradigma de la navegación" . Consultado el 3 de febrero de 2011 .
- ^ "Slashdotslash.com: un sitio web autónomo que utiliza DHTML" . Consultado el 6 de julio de 2012 .
- ^ "Patente de Estados Unidos 8.136.109" . Consultado el 12 de abril de 2002 .
- ^ "Meteoro resplandor" .
Meteor Blaze es una poderosa biblioteca para crear interfaces de usuario que se actualizan en vivo. Blaze cumple el mismo propósito que Angular, Backbone, Ember, React, Polymer o Knockout, pero es mucho más fácil de usar. Lo creamos porque pensamos que otras bibliotecas hacían que la programación de la interfaz de usuario fuera innecesariamente difícil y confusa.
- ^ Presentación de DDP , 21 de marzo de 2012
- ^ "Representación del lado del servidor para Meteor" . Archivado desde el original el 20 de marzo de 2015 . Consultado el 31 de enero de 2015 .
- ^ "Aplicaciones de una sola página frente a aplicaciones de varias páginas: pros, contras, trampas - BLAKIT - Soluciones de TI" . blak-it.com . BLAKIT - Soluciones de TI. 17 de octubre de 2017 . Consultado el 19 de octubre de 2017 .
- ^ "Monitoreo en tiempo real usando AJAX y WebSockets" . www.computer.org . Consultado el 1 de junio de 2016 .
- ^ "Eventos enviados por el servidor" . W3C. 17 de julio de 2013.
- ^ "Usando InnerHTML" . www.webrocketx.com . Consultado el 21 de enero de 2016 .
- ^ "Aplicaciones web no alojadas" .
- ^ "El manifiesto de interfaz de una sola página" . Consultado el 25 de abril de 2014 .
- ^ "Derby" . Consultado el 11 de diciembre de 2011 .
- ^ "Sails.js" . Consultado el 20 de febrero de 2013 .
- ^ "Tutorial: sitio web de interfaz de página única con ItsNat" . Consultado el 13 de enero de 2011 .
- ^ HTML5
- ^ "Lo que ve el usuario, lo que ve el rastreador" . Consultado el 6 de enero de 2014 .
el navegador puede ejecutar JavaScript y producir contenido sobre la marcha; el rastreador no puede
- ^ "Hacer que las aplicaciones Ajax sean rastreables" . Consultado el 6 de enero de 2014 .
Históricamente, las aplicaciones Ajax han sido difíciles de procesar para los motores de búsqueda porque se produce contenido Ajax
- ^ "Propuesta para hacer rastreable AJAX" . Google. 7 de octubre de 2009 . Consultado el 13 de julio de 2011 .
- ^ "(Especificaciones) Hacer que las aplicaciones AJAX sean rastreables" . Google . Consultado el 4 de marzo de 2013 .
- ^ "Hash URI" . Blog del W3C . 12 de mayo de 2011 . Consultado el 13 de julio de 2011 .
- ^ "Desaprovechando nuestro esquema de rastreo AJAX" . Blog oficial del Centro para webmasters de Google . Consultado el 23 de febrero de 2017 .
- ^ "Implementar renderizado dinámico" . Central de búsqueda de Google . 13 de octubre de 2018 . Consultado el 7 de enero de 2021 .
- ^ "Notas de la versión de ItsNat v1.3" . Consultado el 9 de junio de 2013 .
- ^ https://developers.google.com/search/docs/guides/dynamic-rendering
- ↑ a b c Holmes, Simone (2015). Obtener MEAN con Mongo, Express, Angular y Node . Publicaciones Manning. ISBN 978-1-6172-9203-3
- ^ "Aplicaciones de una sola página (SPA)" . Appcheck Ltd .
enlaces externos
- Migración de aplicaciones web de varias páginas a interfaces Ajax de una sola página (Universidad Tecnológica de Delft)
- El manifiesto de interfaz de una sola página
- Representación dinámica