revista-apd-372-1

revista-apd-372-2

Entrevista José Carlos Jiménez, Socio de Innusual

Accesibilidad EAA (European Accessibility ACT)

En esta ocasión, me gustaría profundizar en la elección entre SPA, SSR y SSG, tres enfoques fundamentales en el desarrollo web moderno. Estos métodos no solo impactan el rendimiento de nuestras aplicaciones web, sino que también influyen en la experiencia del usuario y en cómo los motores de búsqueda perciben nuestro sitio.

Al hablar de estos enfoques, me gusta considerar no solo las necesidades técnicas del proyecto, sino también la experiencia de nuestros usuarios. Antes de arrancar un proyecto debemos plantearnos algunas incógnitas… ¿Cómo garantizamos que nuestros usuarios disfruten de una experiencia rápida y fluida, mientras atendemos las exigencias de SEO? ¿Cómo evitamos la frustración que puede surgir de tiempos de carga lentos o de una navegación poco intuitiva? Para responder a estas preguntas, es esencial conocer los puntos fuertes y las limitaciones de cada técnica de renderizado.

## SPA (Single Page Application)
Las SPA ofrecen una experiencia similar a la de una aplicación de escritorio. Todo el contenido de la aplicación se carga en una única página y las subsecuentes interacciones se manejan en el navegador sin recargar la página. Esto hace que la navegación sea rápida y fluida, lo que es excelente para aplicaciones muy interactivas como paneles de administración o plataformas donde el usuario interactúa constantemente con la interfaz, como herramientas de gestión de proyectos o aplicaciones de edición.

La principal ventaja de las SPA es su rapidez al manejar cambios en el DOM de manera dinámica. Esto es posible gracias a frameworks como React, Angular o Vue, que ofrecen un modelo de renderizado basado en componentes. Sin embargo, las SPA dependen mucho de JavaScript, y eso presenta desafíos de SEO. Tradicionalmente, los motores de búsqueda han tenido dificultades para indexar contenido que depende exclusivamente de JavaScript, aunque esto ha mejorado con el tiempo. Sin embargo, si nuestro proyecto tiene una gran dependencia del SEO, las SPA no siempre serán la mejor opción.

En mi experiencia, las SPA funcionan mejor cuando la prioridad es la interacción continua del usuario y la carga inicial es rápida. Si el contenido estático no es una prioridad y el SEO puede pasar a un segundo plano, una SPA puede ser ideal.

## SSR (Server-Side Rendering)
Si buscamos optimizar el SEO y la velocidad de carga inicial, el SSR se convierte en una opción muy atractiva. Con SSR, el servidor procesa y entrega una página ya renderizada al navegador, lo que ayuda a que el contenido sea visible casi instantáneamente y facilita la indexación por motores de búsqueda. Este enfoque es excelente para sitios que necesitan contenido actualizado y relevante en tiempo real, como sitios de noticias, e-commerce o aplicaciones con contenido en constante cambio.

SSR soluciona algunos de los problemas de las SPA al equilibrar la rapidez en la carga inicial con una buena indexación SEO. En ocasiones me ha tocado elegir entre frameworks como Next.js, Nuxt.js, Remix y Astro permiten implementar SSR con relativa facilidad. Estos frameworks gestionan el renderizado en el servidor y ofrecen funcionalidades que facilitan la actualización y el mantenimiento del contenido. Eso sí, SSR implica una carga mayor en el servidor, ya que cada vez que un usuario solicita una página, el servidor tiene que procesar esa petición y enviar el contenido renderizado. Esto puede incrementar el costo y la complejidad del despliegue.

## SSG (Static Site Generation)
En el otro extremo, tenemos el enfoque de SSG, donde las páginas se generan una sola vez en el momento de la compilación y se sirven de forma estática. Las páginas resultantes se pueden distribuir a través de una CDN, lo que garantiza tiempos de carga extremadamente rápidos, ya que no se requiere procesamiento adicional en el servidor para servir el contenido. Esto hace que SSG sea una opción excelente para sitios con contenido que cambia poco, como blogs, portfolios y otros sitios con contenido mayormente estático.

Frameworks como Next.js, Astro y Gatsby facilitan la implementación de SSG, permitiendo que el sitio sea rápido, seguro y eficiente en el consumo de recursos. Una de las ventajas clave de este enfoque es su capacidad de escalar fácilmente. En lugar de depender de servidores robustos para procesar cada solicitud, los sitios SSG distribuyen el contenido ya generado, reduciendo la carga en el servidor y los costos de infraestructura.

Sin embargo, SSG no es la mejor elección para proyectos que requieren actualizaciones de contenido constantes, ya que cada cambio en el contenido implica una regeneración del sitio. Esto puede ser un proceso lento en sitios grandes y no es ideal para aplicaciones que necesitan datos en tiempo real o contenido que se actualiza frecuentemente, como un sitio de noticias.

## Ventajas y Desventajas
Es importante tener en cuenta las ventajas y desventajas de cada enfoque en función de los requisitos del proyecto:

- **SPA**: Ofrece una navegación rápida y una experiencia de usuario muy interactiva. Sin embargo, la carga inicial puede ser más pesada y el SEO puede verse comprometido si no se implementan soluciones adicionales, como el uso de prerendering o SSR en determinadas páginas.

- **SSR**: Optimiza la carga inicial y el SEO, proporcionando contenido pre-renderizado. No obstante, puede requerir más recursos del servidor, y la implementación y el despliegue pueden ser más complejos.

- **SSG**: Garantiza tiempos de carga rápidos y una menor carga en el servidor, lo que lo hace perfecto para contenido estable y mayormente estático. Sin embargo, es menos flexible para sitios con contenido que cambia constantemente y necesita regeneración para reflejar nuevos cambios.

## ¿Cuándo usar SPA, SSR o SSG?
Al seleccionar entre SPA, SSR o SSG, es importante valorar las características y necesidades específicas de tu proyecto:

- **SPA**: Ideal para aplicaciones que requieren mucha interactividad y donde el SEO no es una prioridad. Ejemplos: aplicaciones de tipo panel de usuario o herramientas de gestión.

- **SSR**: Excelente para proyectos que necesitan un equilibrio entre SEO, rendimiento inicial y contenido en tiempo real. Ejemplos: e-commerce, sitios de noticias y redes sociales.

- **SSG**: Perfecto para sitios donde la velocidad y el SEO son prioritarios y el contenido cambia poco. Ejemplos: blogs, portfolios y sitios de documentación.

## Conclusión
Elegir la técnica de renderizado adecuada entre SPA, SSR y SSG es una decisión estratégica que impactará en el rendimiento, la usabilidad y el posicionamiento en buscadores de nuestra aplicación. No existe una única opción correcta; cada proyecto tiene sus propias necesidades y prioridades. En mi experiencia, conocer bien los beneficios y limitaciones de cada enfoque me permite tomar una decisión fundamentada, logrando aplicaciones que no solo funcionen bien técnicamente, sino que también ofrezcan una experiencia excepcional al usuario.

Optimiza el rendimiento y SEO de tu web

La reactividad en JavaScript ha evolucionado constantemente desde sus inicios. Inicialmente, las actualizaciones del DOM se realizaban manualmente, lo que resultaba en un código complejo y propenso a errores. Con la llegada de AJAX en los 2000, fue posible realizar solicitudes asincrónicas sin recargar la página, mejorando la interactividad. Más tarde, las Promises facilitaron el manejo de operaciones asincrónicas, simplificando el control de flujo en casos complejos. También, el uso de objetos Proxy ha permitido crear mecanismos reactivos que detectan y responden a cambios en los objetos, brindando una manera eficiente de gestionar el estado de la aplicación.

## Reactividad en Angular
Actualmente, nos encontramos en la era de los frameworks. Éstos han buscado formas de facilitar el trabajo de los desarrolladores en lo que respecta a la reactividad. Angular aportó nuevos enfoques:

- __Enlace de datos bidireccional:__ Esto comenzó con AngularJS y permitía que los cambios en el modelo de datos se reflejaran en el DOM (una dirección) y que los eventos del DOM provocaran acciones en el modelo de datos (la otra dirección). Lo primero fue posible gracias a la detección de cambios y a Zone.JS, que Angular introdujo como un sistema optimizado para detectar cambios en nuestros modelos de datos, utilizando Zone.JS para interceptar y rastrear todo tipo de tareas asíncronas (eventos, promesas, llamadas HTTP, etc.).
- __RxJS:__ Angular adoptó esta librería y la integró completamente en el framework; éste no se puede entender sin RxJS. Gracias a los Observables y sus diferentes operadores, los desarrolladores tienen una forma robusta y eficiente de trabajar con datos asíncronos y complejos, logrando un código mucho más predecible y reactivo.

Sin embargo, estos enfoques presentan algunos problemas. La detección de cambios puede generar problemas de rendimiento en aplicaciones grandes, por lo que Angular siempre ha tenido la fama de ser un framework lento. Aunque contaba con la detección de cambios OnPush, que restringía las condiciones para iniciar un ciclo de detección y no actualizaba todos los componentes a la vez si no era necesario, todos sabemos que la mayoría de los proyectos ignoran esta posibilidad y utilizan la detección de cambios por defecto.

Con RxJS sucede algo similar; aunque en los últimos años se ha notado que cada vez más personas utilizan Observables y Subjects en su código, muchas veces sigue siendo de forma no deseada. Se realizan muchas suscripciones manuales con posibles fugas de memoria y se ve un uso nulo de operadores más allá de filter, map y switchMap. No podemos olvidar a aquellos que ignoran por completo RxJS y lo utilizan únicamente cuando el framework lo exige. La razón es obvia: RxJS tiene una curva de aprendizaje difícil de gestionar para muchos desarrolladores, especialmente en un mundo de consultoría frenético, con fechas de entrega siempre próximas.

## Introducción de Signals
Las primeras discusiones sobre Signals en Angular aparecieron en 2022 con el RFC del equipo en GitHub. Estas se introdujeron por primera vez en Angular 16 de manera experimental. Aunque esta nueva forma de enfocar la reactividad no es realmente algo nuevo, sino que es muy parecida a las runas de Svelte, lanzadas en 2016, o a la reactividad en Vue.JS.
Una Signal es una variable cuyo valor puede cambiar en el tiempo y su cambio provoca la actualización de otras Signals dependientes. Los beneficios son claros:
- __Simplicidad__: No necesitamos lidiar con suscripciones ni operadores de RxJS, y tampoco con la asincronía.
- __Eficiencia__: Las Signals no requieren detección de cambios y pueden actualizar valores de forma más granular.
- __Depuración__: La depuración de observables siempre ha sido un dolor de cabeza, ya que conocer el valor actual es complicado si no se sigue el flujo desde el comienzo. Esto no sucede con las Signals porque estas siempre tienen un valor definido fácil de inspeccionar.

Si quieres conocer más sobre las Signals, te recomiendo consultar [la documentación oficial](https://angular.dev/guide/signals)

## Gestión del estado con Signals
Aunque solemos pensar en la gestión del estado global de nuestras aplicaciones, el estado de un único componente o servicio también debe gestionarse; a esto lo llamaremos gestión de estado localizado.

### Gestión de estado localizado
Gracias a las Signals, en los componentes ya no necesitaremos implementar OnChanges ni convertir nuestros @Input en setters para detectar cambios. Tampoco será necesario utilizar observables tan a menudo (por desgracia, las Signals aún no están integradas en módulos de Angular como el redireccionamiento o los formularios reactivos). En caso de necesitarlo, gracias a @angular/core/rxjs-interop, podremos convertir Observables a Signals fácilmente. En cuanto a servicios, lo mismo ocurre; nuestras propiedades no reactivas y Subjects pueden ser convertidos a Signals sin dificultad. 

Sin embargo, no debemos emocionarnos convirtiendo todo a Signals; los operadores de RxJS pueden ser muy útiles para ciertos casos de uso, y las llamadas externas a través de HttpClient no siempre pueden ser convertidas. La idea es que tanto Signals como RxJS convivan en un mismo proyecto, siendo utilizados cada uno según sus características: RxJS para flujos asíncronos y complejos que se benefician del uso de operadores, y Signals para propiedades reactivas síncronas con lógica accesible sin operadores; mientras que utilizamos el paquete de interoperabilidad para la conversión entre ambos tipos de datos.

### Gestión del estado global
Las librerías de gestión de estado global más utilizadas en Angular son NGRX y NGXS. Ambas intentan implementar el patrón FLUX con sus respectivas aproximaciones.

__NGXS Store__

Esta librería nos ofrece el paquete @ngxs/store y tras la salida de Signals, han sido rápidos para adaptar su solución a este nuevo paradigma. Se ha incluido un nuevo método “selectSignal” para que los selectores del estado sean de tipo Signal en lugar de Observables.

__NGRX__

En este caso, la librería nos ofrece varios paquetes para dos tipos de gestión. La gestión de estado por patrón FLUX con @ngrx/store y @ngrx/effects, y otra gestión más reducida y simple para sustituir los servicios con Subjects, que sería @ngrx/component-store. En ambos casos se ha incluido un nuevo método para que los selectores devuelvan una Signal en lugar de Observables, llamado “selectSignal”. 

Además de estas adaptaciones, el equipo de NGRX ha creado un nuevo paquete, @ngrx/signals, donde el estado es un Signal en sí y no hay dependencia alguna con RxJS. Y al igual que antes, en este caso contamos con la SignalStore para estados complejos y SignalState para aquellas gestión más simple y ligera.

## Conclusión
Está claro que las Signals son uno de los cambios más significativos en Angular de los últimos años. Este nuevo enfoque de reactividad afecta tanto al framework como a las librerías que utilizamos con él. Poco a poco, todos los módulos de Angular irán incorporando el uso de Signals, al igual que las librerías más populares. Esto apunta a un futuro sin Zone.JS ni detección de cambios, aportando ventajas como la mejora del rendimiento, la reducción de la carga inicial al eliminar las dependencias de Zone.JS y posiblemente de RxJS, así como la simplificación del proceso de depuración en caso de errores.

¿Y tú? ¿Has probado ya las Signals?


Entrevista José Carlos Jiménez, Socio de Innusual

>>> Podría interesarte

Accesibilidad EAA (European Accessibility ACT)

Optimiza el rendimiento y SEO de tu web

Gestión del estado con Signals en Angular

.css-adcnbg{font-family:var(--chakra-fonts-body);font-weight:300;color:inherit;}>>> Podría interesarte

Accesibilidad EAA (European Accessibility ACT)

Optimiza el rendimiento y SEO de tu web

Gestión del estado con Signals en Angular

>>> Podría interesarte