¿Qué es una aplicación de página única?

Las aplicaciones web modernas también se denominan aplicaciones de una sola página. ¿Qué significa esto?

En el pasado, cuando los navegadores eran mucho menos capaces que hoy y el rendimiento de JavaScript era deficiente, todas las páginas procedían de un servidor. Cada vez que hacía clic en algo, se realizaba una nueva solicitud al servidor y, posteriormente, el navegador cargaba la nueva página.

Solo los productos muy innovadores funcionaron de manera diferente y experimentaron con nuevos enfoques.

Hoy en día, popularizado por los marcos de JavaScript frontend modernos como React, una aplicación generalmente se construye como una aplicación de una sola página: solo carga el código de la aplicación (HTML,CSS,JavaScript) una vez, y cuando interactúas con la aplicación, lo que generalmente sucede es que JavaScript intercepta los eventos del navegador y en lugar de realizar una nueva solicitud al servidor que luego devuelve un nuevo documento, el cliente solicita algo de JSON o realiza una acción en el servidor. pero la página que ve el usuario nunca se borra por completo y se comporta más como una aplicación de escritorio.

Las aplicaciones de una sola página están creadas en JavaScript (o al menos compiladas en JavaScript) y funcionan en el navegador.

La tecnología es siempre la misma, pero la filosofía y algunos componentes clave de cómo funciona la aplicación son diferentes.

Ejemplos de aplicaciones de una sola página

Algunos ejemplos notables:

  • Gmail
  • mapas de Google
  • Facebook
  • Gorjeo
  • Google Drive

Pros y contras de los SPA

Un SPA se siente mucho más rápido para el usuario, porque en lugar de esperar a que se produzca la comunicación cliente-servidor y esperar a que el navegador vuelva a representar la página, ahora puede tener comentarios instantáneos. Esta es la responsabilidad del creador de la aplicación, pero puede tener transiciones y spinners y cualquier tipo de mejora de UX que sea ciertamente mejor que el flujo de trabajo tradicional.

Además de hacer que la experiencia sea más rápida para el usuario, el servidor consumirá menos recursos porque puede concentrarse en proporcionar una API eficiente en lugar de crear los diseños del lado del servidor.

Esto lo hace ideal si también crea una aplicación móvil sobre la API, ya que puede reutilizar completamente su código del lado del servidor existente.

Las aplicaciones de una sola página son fáciles de transformar en aplicaciones web progresivas, lo que a su vez le permite proporcionar almacenamiento en caché local y admitir experiencias fuera de línea para sus servicios (o un mejor mensaje de error si sus usuarios necesitan estar en línea).

Los SPA se utilizan mejor cuando no hay necesidad de SEO (optimización de motores de búsqueda). Por ejemplo, para aplicaciones que funcionan detrás de un inicio de sesión.

Los motores de búsqueda, aunque mejoran cada día, todavía tienen problemas para indexar sitios creados con un enfoque SPA en lugar de las páginas tradicionales representadas por el servidor. Este es el caso de los blogs. Si va a confiar en los motores de búsqueda, ni siquiera se moleste en crear una aplicación de una sola página sin tener también una parte renderizada por el servidor.

Al codificar un SPA, escribirás una gran cantidad de JavaScript. Dado que la aplicación puede durar mucho tiempo, tendrá que prestar mucha más atención a las posibles fugas de memoria; si en el pasado su página tenía una vida útil que se contaba en minutos, ahora un SPA podría permanecer abierto durante horas en un tiempo y si hay algún problema de memoria que aumentará el uso de la memoria del navegador en mucho más y causará una experiencia desagradablemente lenta si no lo resuelve.

Los SPA son excelentes cuando se trabaja en equipo. Los desarrolladores de backend solo pueden centrarse en la API, y los desarrolladores de frontend pueden centrarse en crear la mejor experiencia de usuario, haciendo uso de la API integrada en el backend.

Como contra, las aplicaciones de una sola página dependen en gran medida de JavaScript. Esto puede hacer que el uso de una aplicación que se ejecute en dispositivos de bajo consumo sea una mala experiencia en términos de velocidad. Además, es posible que algunos de sus visitantes solo tengan JavaScript desactivado, y también debe considerar la accesibilidad para cualquier cosa que cree.

Anulando la navegación

Dado que se deshace de la navegación predeterminada del navegador, las URL deben administrarse manualmente.

Esta parte de una aplicación se llama enrutador. Algunos frameworks ya se encargan de ellos (como Ember), otros requieren bibliotecas que hagan este trabajo (comoReaccionar enrutador).

¿Cuál es el problema? Al principio, esto fue una ocurrencia tardía para los desarrolladores que crean aplicaciones de página única. Esto provocó el problema común del "botón de retroceso roto": al navegar dentro de la aplicación, la URL no cambiaba (ya que la navegación predeterminada del navegador fue secuestrada) y presionar el botón de retroceso, una operación común que hacen los usuarios para ir a la pantalla anterior, podría moverse a un sitio web que visitó hace mucho tiempo.

Este problema ahora se puede resolver utilizando elAPI de historialofrecidos por los navegadores, pero la mayoría de las veces utilizará una biblioteca que utiliza internamente esa API, comoReaccionar enrutador.


Más tutoriales de js: