#CSR, #SSR y #SSG: qué son y cuándo usarlos

Summary

El video discute las diferencias entre Client Side Rendering (CSR), Server Side Rendering (SSR) y Static Site Generation (SSG). Explicó los problemas de CSR como la lenta carga de páginas en blanco y las dificultades con SEO. Presentó SSR como una solución para mejorar la experiencia de usuario y SEO, aunque requiere una conexión al servidor y puede tener problemas con ciertas librerías. Finalmente, SSG se describe como ideal para contenido estático, permitiendo una carga rápida y efectiva sin un servidor en ejecución.

Takeaways

• 🌟 El Client Side Rendering (CSR) envía una página en blanco al navegador, que luego descarga y ejecuta un bundle de JavaScript para renderizar la aplicación.
• 🚀 Los SPAs (Single Page Applications) utilizan un router para manipular el DOM y mostrar diferentes componentes sin recargar la página completa.
• 💡 Las APIs del navegador, como local storage y document, no están disponibles fuera del contexto del navegador, por lo que pueden causar errores en un entorno de server-side rendering.
• 🔍 El CSR puede tener problemas con el SEO ya que los crawlers pueden no indexar correctamente una página que renderiza dinámicamente su contenido.
• 🎯 Server Side Rendering (SSR) prerenderiza la página en el servidor y envía el HTML al cliente, mejorando la experiencia de usuario y la indexación por parte de los motores de búsqueda.
• 📦 Static Site Generation (SSG) ocurre en tiempo de construcción, prerenderizando toda la aplicación en HTML estatico y mejorando la velocidad de carga y el SEO.
• 🔄 La hidratación (hydration) en SSR permite reutilizar los nodos HTML ya presentes en la página para agregar interactividad sin tener que volver a renderizarlos completamente.
• 🔧 La resumabilidad (resumability) es un enfoque que combina SSR y CSR, enviando una cantidad mínima de JavaScript para hacer la página interactiva y luego descargando el resto en paralelo.
• 🛠️ La selección de la estrategia de rendering (CSR, SSR o SSG) depende del contexto del proyecto, como la necesidad de SEO, la interacción del usuario y la frecuencia de cambios en el contenido.
• 🔑 Es importante entender en qué plataforma se están ejecutando las APIs y hacer workarounds adecuados para evitar errores al utilizar APIs propias del cliente en un entorno de servidor.
• 🌐 Frameworks como Astro permiten combinar SSR y SSG, ofreciendo flexibilidad para renderizar parte de la aplicación en el servidor y parte en el cliente según sea necesario.

Q & A

¿Qué es el Server Side Rendering (SSR) y por qué es importante?

El Server Side Rendering es una técnica en la que los componentes y nodos HTML son generados en el servidor en lugar del cliente. Es importante porque mejora la experiencia del usuario al evitar la renderización inicial en blanco y también beneficia el SEO al proporcionar contenido estático que los crawlers pueden indexar fácilmente.

¿Qué es el Client Side Rendering (CSR) y cómo funciona?

El Client Side Rendering es un método de renderización donde el navegador recibe una página en blanco y luego descarga un bundle de JavaScript que se encarga de crear el árbol y nodos del DOM necesarios para renderizar la aplicación. Funciona en aplicaciones como SPAs (Single Page Applications) donde la navegación entre páginas no implica una recarga completa de la página.

¿Qué es la Static Site Generation (SSG) y cómo se diferencia del SSR y CSR?

La Static Site Generation es una técnica donde la aplicación web se construye completamente en tiempo de construcción, generando archivos estáticos que no requieren un servidor en ejecución para ser servidos. Se diferencia del SSR en que no hay un servidor procesando solicitudes en tiempo real, y del CSR en que no hay renderización en el lado del cliente, ya que todo está pre-renderizado y estático.

¿Qué problemas pueden surgir con el uso de SSR y cómo pueden solucionarse?

El uso de SSR puede traer problemas como la duplicación de renderización y la incompatibilidad con algunas librerías o APIs del cliente. Estos problemas pueden solucionarse utilizando técnicas como la hidratación selectiva, que permite reutilizar nodos HTML ya presentes en el cliente, y workarounds para las librerías que dependen de objetos del navegador.

¿Qué es la hidratación selectiva y cómo funciona?

La hidratación selectiva es una técnica que permite reutilizar nodos HTML ya presentes en el cliente al momento de la renderización. Funciona identificando nodos con la misma estructura en el servidor y en el cliente, permitiendo que el JavaScript se centre en reemplazar o mejorar sólo los nodos necesarios, mejorando así la eficiencia y la experiencia del usuario.

¿Qué ventajas aporta el uso de la Static Site Generation?

Las ventajas de la Static Site Generation incluyen una mayor rapidez ya que solo se descargan archivos estáticos como HTML y CSS, mejor SEO debido a la presencia de metadatos estáticos, y la reducción de peticiones adicionales al servidor ya que los datos son incluidos en la página desde la construcción.

¿Cuáles son las desventajas del Client Side Rendering?

Las desventajas del Client Side Rendering incluyen la posible lenta inicial debido al tiempo necesario para descargar el bundle de JavaScript, problemas de SEO ya que los crawlers pueden tener dificultades indexando contenido generado dinámicamente, y la dependencia de las APIs del navegador que no están disponibles en un entorno de servidor.

¿Qué es la 'Island' en el contexto de Astro y cómo funciona?

En Astro, una 'Island' se refiere a cualquier componente de interfaz de usuario interactivo en la página. Funcionan renderizando páginas HTML en el servidor e inyectando placeholders o slots alrededor de regiones altamente dinámicas que luego pueden ser hidratadas en el cliente como pequeños widgets o contenidos reutilizables, aprovechando su HTML inicial renderizado en el servidor.

¿Cuáles son los casos de uso ideales para cada técnica de renderización?

El Client Side Rendering es ideal para sistemas internos y aplicaciones que no requieren posicionamiento en buscadores. El Server Side Rendering es adecuado para aplicaciones públicas donde el SEO es importante y se benefician de la renderización inicial de contenido estático. La Static Site Generation es perfecta para sitios de contenido estático como blogs o portfolios, donde no se requiere interacción dinámica y se desea una construcción rápida y eficiente.

¿Cómo se puede implementar la hidratación selectiva en React?

En React, la hidratación selectiva se puede implementar utilizando el concepto de Suspense. Esto permite hidratar ciertas partes de la página para que la web cargue estáticos por un lado y componentes interactivos por otro, sin tener que esperar a que se hidrate todo el árbol del DOM.

¿Qué es la 'resumabilidad' en el contexto de la renderización web?

La 'resumabilidad' se refiere a la capacidad de una aplicación web de ser interactiva de una manera rápida y eficiente después de su carga inicial. Implica la eliminación de la duplicación en el proceso de renderización y la descarga en paralelo de partes de JavaScript que no incluyen renderización de nodos, permitiendo que la web sea interactiva mucho antes y de una manera más performante.

Outlines

00:00

🤔 Introducción a Server Side Rendering (SSR)

El video comienza con una introducción al tema de Server Side Rendering, explicando la razón por la que se ha elegido este día para hablar sobre SSR, Static Site Generation y Client Side Rendering. El habla se desplaza hacia la explicación de un error común relacionado con la función 'local storage' que no está definida, lo que lleva al analista a profundizar en el uso de diferentes estrategias de rendering.

05:01

🌐 Client Side Rendering: Conceptos y Desventajas

Se describe el proceso de Client Side Rendering, donde el navegador recibe una página en blanco y luego descarga un 'bundle' de JavaScript para renderizar la aplicación. Se discuten las ventajas de esta técnica, como la rapidez en el servidor y la capacidad de desarrollo de SPAs, así como sus desventajas, incluyendo la mala experiencia de usuario con una página en blanco y problemas SEO relacionados con la indexación de contenidos dinámicos.

10:02

💡 Ventajas y Desventajas de Server Side Rendering (SSR)

Se abordan las ventajas de SSR, como la mejora en SEO y la carga inicial más rápida de contenido, así como la reducción de peticiones al servidor gracias a la pre-renderización de datos. También se mencionan las desventajas, como el posible aumento de tamaño en la aplicación y la incompatibility con ciertas librerías o APIs del navegador que no están disponibles en el servidor.

15:04

🚀 Static Site Generation: Conceptos y Aplicaciones

Se define Static Site Generation y se compara con SSR. Se explica que en SSG, la generación de contenido estático ocurre durante la construcción del sitio, eliminando el JavaScript innecesario y mejorando la velocidad y SEO. Se mencionan ejemplos de aplicaciones estáticas como blogs y portfolios que son ideales para SSG, y se discuten las limitaciones en términos de interacción y actualización de contenido.

20:04

🔄 Hydración y Resumabilidad: Futuro del Rendering

Se introducen los conceptos de Hydración (reutilización de nodos HTML ya presentes en la página) y Resumabilidad (renderizado de páginas con una cantidad mínima de JavaScript para interacción inicial). Se mencionan frameworks como Quick y Astro que implementan estas técnicas, mejorando la eficiencia y la experiencia de carga de la página, permitiendo una actualización progresiva de contenidos.

25:05

📝 Casos de Uso: Client Side Rendering vs Server Side Rendering vs Static Site Generation

Se presentan diferentes escenarios donde se pueden aplicar Client Side Rendering, Server Side Rendering o Static Site Generation. Se recomienda Client Side Rendering para sistemas internos, SSR para aplicaciones web públicas que requieren SEO y SSG para sitios estáticos como blogs o portfolios. Se enfatiza la importancia de entender el contexto y las necesidades del proyecto para elegir la estrategia de rendering adecuada.

Keywords

💡Server Side Rendering (SSR)

El Server Side Rendering (SSR) es una técnica en la que el contenido web se renderiza en el servidor antes de enviarse al cliente, lo que mejora la experiencia del usuario al mostrar contenido inmediato y es beneficioso para el SEO. En el video, el SSR se menciona como una estrategia para solucionar problemas de renderizado y mejorar la accesibilidad de contenidos para los crawlers de motores de búsqueda.

💡Client Side Rendering (CSR)

El Client Side Rendering (CSR) es un método de desarrollo web donde el contenido se renderiza en el navegador después de que se haya descargado el código JavaScript necesario. Esto puede resultar en una página en blanco inicial y dependiendo del tamaño del bundle y la conexión del usuario, puede causar retrasos en la visualización del contenido. El CSR es común en aplicaciones single-page (SPAs) como React, Angular y Vue.

💡Static Site Generation (SSG)

La Static Site Generation (SSG) es un enfoque donde el sitio web se genera completamente en tiempo de construcción, creando archivos estáticos que son servidos al cliente sin la necesidad de un servidor en tiempo de ejecución. Esto resulta en sitios web muy rápidos y eficientes, pero que carecen de interacción dinámica. Es ideal para contenidos estáticos como blogs o sitios de portfolio.

💡LocalStorage

LocalStorage es una característica de los navegadores web que permite el almacenamiento de datos en el lado del cliente. Los datos almacenados en LocalStorage son accesibles desde JavaScript y persisten en el dispositivo del usuario a pesar de cerrar el navegador. Sin embargo, su uso en SSR puede resultar en errores ya que LocalStorage no está disponible en el servidor.

💡SEO

SEO (Search Engine Optimization) es la práctica de mejorar la visibilidad de un sitio web en los resultados de búsqueda de motores como Google. Un buen SEO implica la optimización de contenido, metadatos y otros elementos para que los crawlers de búsqueda puedan indexar y clasificar adecuadamente el sitio web. SSR y SSG son estrategias que pueden mejorar el SEO al proporcionar contenido estático y metadata bien definidos.

💡Single Page Applications (SPAs)

Las Single Page Applications (SPAs) son aplicaciones web que carzan una sola página que se actualiza dinámicamente con JavaScript sin necesidad de recargar la página completa. Estas aplicaciones suelen utilizar CSR para gestionar la lógica y el estado de la aplicación en el navegador.

💡Bundle

Un bundle es un archivo compactado que contiene todo el código necesario para una aplicación web, incluyendo JavaScript, CSS y otros recursos. En el contexto de CSR, el bundle se descarga al principio de la carga de la página, lo que puede causar un tiempo de espera antes de que el contenido sea renderizado en la pantalla.

💡Hydration

La hidratación (hydration) es un proceso en el que se reutilizan los nodos HTML ya renderizados en el servidor (SSR) al cargar la aplicación en el cliente (CSR). Esto mejora la eficiencia al evitar la duplicación de nodos y mejorar el rendimiento al no tener que re-renderizar elementos que ya están presentes en la página.

💡Islands

Las islas (islands) son una técnica en la que se combinan elementos estáticos generados en el servidor con componentes interactivos que se cargan y se hidratan en el cliente. Esta técnica permite una renderización más eficiente al enviar solo los componentes necesarios y reutilizando el HTML estático generado previamente.

💡Framework

Un framework es un conjunto de herramientas y bibliotecas pre-construidas que facilitan el desarrollo de aplicaciones software. Los frameworks como React, Angular y Vue proporcionan estructuras y的功能 para crear aplicaciones web de manera más eficiente y escalable.

Highlights

El video discute sobre las diferencias y particularidades entre Client Side Rendering (CSR), Server Side Rendering (SSR) y Static Site Generation (SSG).

CSR envía una página en blanco al navegador y luego utiliza un bundle de JavaScript para renderizar la aplicación.

Con CSR, las APIs del navegador como local storage o document.js solo están disponibles después de que el JavaScript se haya cargado.

Las Single Page Applications (SPAs) utilizan un router para manipular el DOM y cambiar los nodos en función de la ruta.

CSR tiene la desventaja de no ser amigable con SEO debido a que los crawlers no pueden indexar contenido generado dinámicamente.

SSR prerenderiza la página en el servidor y luego envía el HTML al cliente, mejorando la experiencia de usuario y el SEO.

SSR puede tener desventajas como la duplicación del proceso de renderización y la incompatibilidad con ciertas librerías del cliente.

SSG genera la página en tiempo de construcción, lo que la hace ideal para sitios de contenido estático como blogs o portfolios.

Con SSG, los cambios en el sitio requieren una nueva construcción y despliegue, a diferencia de SSR que puede actualizarse en tiempo real.

Hydration es un concepto que busca reutilizar los nodos HTML ya presentes en la página para mejorar la eficiencia de la interacción con el DOM.

Resumability es una característica que permite a las páginas ser interactivas desde el principio con una carga mínima de JavaScript.

Frameworks como Astro permiten la implementación de islas, una arquitectura que combina componentes estáticos y dinámicos en una sola página.

Astro permite la selección de componentes para SSR, CSR o SSG, ofreciendo versatilidad en el rendizado de la página.

CSR es adecuado para sistemas internos de empresas o aplicaciones que no requieren posicionamiento en buscadores.

SSR es ideal para aplicaciones que requieren un buen posicionamiento en buscadores y contenido estático.

SSG es la opción perfecta para sitios que no cambian frecuentemente y no dependen de variables del usuario como blogs personales.

Es importante entender el contexto en el que se utiliza cada estrategia de renderizado para aprovechar al máximo sus ventajas.

El video destaca la importancia de elegir la estrategia de renderizado adecuada según las necesidades específicas del proyecto.

Transcripts

a ver mi gente

bonita vamos a ver por qué esta clase

por qué quería hablarles el día de hoy

sobre server Side rendering

[Música]

e Por qué quería hablar sobre server

Side rendering sobre static Side

generation y sobre client Side rendering

Sí en los últimos vídeos que tengo en el

canal de YouTube sobre angular mucha

gente bueno mucha gente no un par de

personas Sí y por Instagram también me

escribieron luego me preguntaron eh

sobre un error que les aparecía el error

específicamente era que local storage no

estaba definido s a lo que mi pregunta

directamente fue revisa si tienes

cerveza de render en activo y me dijeron

que sí Me confirmaron que si lo tenía en

activo entonces a partir de esa

confusión se me ocurrió bueno obviamente

pues aquí falta explicar algún par de

cosas sí en este caso del uso del

servers rendering y pues otras

estrategias de PR rendering que tenemos

vale Y el Por qué O sea para llegar a la

Fuente del por qué ocurren ese tipo de

errores si que al final es O sea la idea

de esto es aclarar el Por qué pasa eso

sí entonces por eso el día de hoy vamos

a ver estas tres cosas

Vale entonces vamos a comenzar por aquí

con el client s rendering sí client s

rendering es Pues básicamente el método

de renderización que tenemos que es

usual de las aplicaciones que que

hacemos que desarrollamos sea con

angular sea con react sea con View sea

con spelt y pare de contar bien

qué es lo que pasa cuando estamos

renderizando del lado del cliente que

justamente Esas son las siglas client s

rendering bien lo que pasa es que al

cliente se le envía o el navegador en

este caso Cuando digo cliente me refiero

al navegador vale lo que recibe el

navegador es una página en blanco sí y

se descarga un bundle de javascript ese

bundle es justamente el build que

nosotros hicimos cuando desplegamos la

aplicación no el build de toda la

aplicación Sí el que después copiamos la

carpeta dis y después desplegamos un

servidor Pues ese es el bundle Ah tras

descargarlo es la aplicación de

javascript que tenemos repito sea hecha

con react angular View lo que sea pero

es la parte javascript la que se encarga

de crear el árbol y de crear los nodos

Mejor dicho del dom html y renderizar lo

que sea que nosotros hayamos eh

desarrollado sí es decir los componentes

el menú eh la web la aplicación lo que

sea Sí por eso es que cuando nosotros

iniciamos una aplicación de este tipo lo

que lo primero que vemos es una página

en blanco y después Boom se renderiza

todo Sí después de que se descargue el

javascript Entonces qué pasa eh con este

tipo de aplicaciones que se las conoce

como spas o single page applications

porque nosotros cuando navegamos bien eh

Generalmente en estas aplicaciones no es

que estemos pasando de un html a otro

vale por eso es que utilizamos un router

por ejemplo react router dom por ejemplo

el router de angular etcétera lo que

está pasando aquí es que es el mismo

bondel es la misma aplicación de

javascript quien está manipulando el

routing y cambiando los nodos del Don

para que se visualice pues uno u otro

componente Sí Mientras mantiene por

ejemplo el nav y el footer estáticos Sí

pero todo está ahí en la misma ruta

porque de hecho si se fijan en el código

lo que tenemos es un html con un

elemento Root y ese elemento Root llama

al elemento de la aplicación llama al

componente digamos principal o al módulo

principal vale para car después

absolutamente todo entonces como ven

todo se renderiza del lado del cliente

todo se renderiza en el navegador Sí por

qué Porque lo crea o sea los nodos del

de html del dom

eh que estamos viendo en la aplicación

lo crea javascript o se crean a través

de javascript vale justamente cuando ya

están disponibles en el navegador y por

esta razón tenemos eh Cuando

desarrollamos cualquier cosa con react

con angular con View etcétera tenemos a

disposición las apis del navegador

Recuerden que cuando nosotros accedemos

a por ejemplo local storage session

storage

eh el objeto window el el objeto perdón

document eh la Api de geolocalización y

pare de contar esas apis no son del

lenguaje no son de javascript esas apis

están disponibles sí a través de qué a

través de el navegador el navegador es

quien nos provee de esas apis y la

podemos utilizar Obviamente con

javascript vale Pero si estamos fuera

del navegador esas apis no existen Sí o

sea nosotros no podemos eh hablando en

el mismo contexto de de de lenguaje

nosotros no podemos acceder a un objeto

window o un objeto document o un local

storage en nojs estamos trabajando con

javascript igual pero estamos en otro

entorno sí estamos e en otro cómo se

llama esto en otro

engine y por lo tanto pues no tenemos

esas mismas apis disponibles Sí ya vamos

a ver el Por qué les digo

esto cosillas que tenemos ventajas y

desventajas del clies rendering sí

repito Esta es la la estrategia más

usual que tenemos cada vez que

desarrollamos una aplicación es lo que

siempre estamos haciendo no sea con las

herramientas ya mencionadas etcétera sí

obviamente tenemos rapidez en el

servidor Por qué Porque el servidor pues

Generalmente solamente se encargaría de

H recibir peticiones http o Pues

desplegar los los cómo se llama Los

bundles enviarlos al navegador y pues ya

está una vez el navegador los tiene

lo que hace eh nuestro bundle es a

generar los los componentes y pues

cambiarlos según las rutas que que

estemos visitando Sí luego el modelo

pues obviamente soporta el desarrollo de

spas sí que es lo que desarrollamos

básicamente no hay necesidad de

configuración consideraciones

adicionales al desarrollar e o

interactuar con las apis del navegador

que es justamente a lo que estamos

acostumbrados si yo quiero manejar local

storage o session storage pues lo puedo

hacer aquí sin ningún problema no me va

a salir un local storage si son defin

por ejemplo sí como desventajas porque

obviamente tiene que tener desventajas

porque si no para qué vamos a cambiar

esto o vamos a crear alternativas como

lo serían server rendering o static

generation vale en este caso eh No hay

un render inicial Más allá de la página

en blanco sí y qué pasa con que no hay

un render inicial Más allá de la página

en Blanco Número Uno El usuario lo que

recibe es esa página en blanco Entonces

si el bondel es muy grande si lo si lo

que tiene que descargar el navegador es

es pesa mucho vamos y el usuario tiene

una mala conexión a internet pues lo que

va a ver es una página en blanco durante

algunos segundos Sí en el peor de los

casos un caso muy cataclísmico Pues en

un minuto o algo así de una página en

blanco y ya está Entonces eso no es para

nada ideal número uno número dos como

todos los nodos se generan de forma

dinámica en el cliente los crawlers de

los navegadores bien no tienen forma de

saber qué información va a desple va va

a renderizar Perdón nuestra web sí o

nuestra aplicación web o nuestra spa y

es por esto que justamente siempre

lidiamos con eh las fallas de El

posicionamiento en buscadores o sea seo

Sí cuando utilizamos react angular View

etcétera como eh o utilizando client

Side rendering Vale cuando desplegamos

la aplicación Pues nos damos cuenta de

que no hay metadata de que pues no hay

información sobre la web y por lo tanto

no se indexa como cualquier otra web por

ejemplo de eh yo que sé una web estática

sí entiendas estática como que tenemos

ahí los archivos html con toda la

metadata eh todos los metatags y todo lo

demás bien Por qué Porque toda esta

metadata se genera de forma dinámica y

los crawlers no van a ser una petición

para que esto se descargue van a esperar

que se descargue que se render Y pues lo

van a leer sino que van a ir y lo que

van a encontrarse es un html con un

elemento Root ya está dentro no va a

haber absolutamente nada entonces el cl

rendering con este tipo de eh pues

obviamente siempre ha tenido un fleco en

la parte del

seo

vale vamos ahora con una alternativa que

es el server Side rendering si que pues

obviamente ha tomado bastante auge sobre

todo con la salida Pues de next como

meta framework pues obviamente También

tenemos angular universal tenemos nox

como meta framework de View Tenemos

también el tema de las islas de ast que

llevamos allá vale pero cuando hablamos

de ser rendering qué es lo que pasa aquí

con respecto o en en contraposición al

client s Side rendering sí en este caso

los componentes los nodos html son

generados en el servidor no en el

cliente vale se hace un prerendering sí

se renderiza en el servidor y luego se

envía al cliente cuando el navegador

recuerden cuando hablamos de cliente

hablamos del navegador eh solicita la

web o alguna de sus páginas Sí ya se

imaginarán que tenemos que tener ahí un

servidor escuchando cuando el cliente

pues le manda una petición Mira Pásame

la página esta el servidor PR renderiza

esa página se la envía al cliente el

cliente construye el dom sí le muestra

al usuario el html y vamos a ver lo que

pasa

después a partir de lo que el cliente

recibe el crea el dom a partir de ese

html sí y el servidor envía ese html de

forma inicial pero luego pero luego

porque ya se imaginarán Ajá bueno me

envía el html y cuando cuando el usuario

de clic qué va a pasar Pues no va a

pasar nada Por qué Porque si me estás

enviando nada más html pues la web no es

interactiva todavía sí lo que va a pasar

Es que luego el servidor te va a mandar

el js Sí el javascript para darle

interacción a esa

web aquí hay un fleco importante Sí ya

vamos a ver qué pasa aquí el fleco aquí

es que obviamente la renderización

ocurre dos veces se duplica el

procedimiento Por qué Porque tenemos que

PR renderizar en el servidor luego

mandamos el html al cliente luego

mandamos el javascript al cliente y el

cliente tiene que

renderizar según lo que haya llegado a

nivel de javascript Sí entonces aquí hay

algo que como que no cuadra ya vamos a

ver qué es lo que lo soluciona O qué es

lo que trata de solucionarlo

vale ventajas y desventajas del server s

rendering sí obviamente lo más llamativo

de esto es que ya nos quitamos el

problema del seo Por qué Porque estamos

prer renderizando la parte html Así que

el usuario tiene el contenido casi que

instantáneamente sí Aunque no pueda

interactuar con él le mostramos algo que

esto es superimportante para los

crawlers de los buscadores que tengamos

Data inmediata y le mostremos algo al

usuario aunque sea a nivel html sí nos

ahorramos también peticiones desde el

cliente Por qué Porque si estamos pre

renderizando en el servidor nosotros

podríamos por ejemplo hacer alguna

consulta una base de de datos

directamente vale o sea una Api que se

conecte a la base de datos sí traernos

Data PR renderizar esa Data y enviársela

directamente al cliente en forma plana

de html y ya está tenemos ahí datos y

todo lo demás no tenemos que esperar a

que el cliente nos haga otra petición a

nosotros o al backen para enviarle la

Data y para que el cliente pues vuelva

otra vez a ejecutar javascript y pare de

contar rerender y pues muestre la Data

sí nos ahorramos ese

pasillo ahora con respecto a las

desventajas sí tenemos pues obviamente

el tamaño de la aplicación eso siempre

va a ser algo que pues dependiendo del

contexto donde estemos Pues nos va a

pesar más o menos sí sean al lado del

servidor sean al lado del cliente Pero

además Pero además aquí viene el meollo

de la cuestión aquí viene el porqué de

esta de esta charla o este vídeo sí la

incompatibilidad con algunas librerías y

apis propias del cliente propias del

navegador cuando nosotros nosotros

creamos una aplicación que es el caso

justamente que detona este vídeo en

específico cuando nosotros creamos una

aplicación por ejemplo angular 17

angular 17 ya directamente nos pregunta

en el cli Si queremos habilitar servers

rendering si le decimos que sí cuando

nosotros levantemos esa aplicación esa

aplicación se está PR renderizando un

servidor de node con Express Sí

ergo si yo trato de acceder a un objeto

de local storage o un objeto window o un

objeto document me va a dar error Sí por

qué porque no estoy en el navegador

estoy en un servidor de nodejs con

Express vale Y esto no solamente puede

darnos error en este tipo de objetos

sino también algunas librerías que

utilizan estos objetos vale por ejemplo

librerías de gráficos librerías que

almacenen pues estado en local storage

en ses storage o lo que sea ven o que

render a través de pues captura de nodo

en el navegador

Pues nos puede dar error si estamos en

ser de rendering estamos tratando de

utilizar en ese contexto me explico

entonces ojo ojo con esto cuando ustedes

estén haciendo algo de server Side

rendering vale estén implementando esta

estrategia para PR renderizar su web Sí

tienen que tener en cuenta este tipo de

cosas por qué porque van a tener que

implementar pues algún workaround van a

tener que validar En qué plataforma

están por ejemplo angular De hecho tiene

un par de cosillas puede inyectar si mal

no recuerdo es plat for ID vale Y ahora

en la versión 17 tienen otra cosa que es

after next render bien donde pues

Ejecutan digamos ese Hook y todo lo que

esté dentro del after next render se

entiende que se ejecuta de lado del

cliente por lo tanto pueden acceder ahí

a las apis propias de pues Windows

document local storage y pare de contar

entiende y otra cosa es que obviamente

puede verse afectada la experiencia de

usuario por velocidades lentas de

conexión dado que cada ruta debe pasar

por un request al servidor como tenemos

un servidor ahí escuchando y el cliente

va a pedirle Mira dame esta página Dame

esta página prendería esta otra página

envíame el html después envíame el

javascript Pues si la conexión del

usuario es lenta pues obviamente Aquí

también tenemos un pequeño fleco de pues

vas a tardar un poquillo más en Ver

cosas vale esto pues

mm es un poco relativo no a la conexión

ya del usuario eh No podemos controlarlo

todo Lamentablemente se entiende se

entiende el el el porqué del error de lo

queal storage con serv rendering y la

diferencia con respecto a clide

rendering vale por último tenemos otra

estrategia llamada static site

generation Sí y static site generation a

menudo pues se puede confundir o o

podemos relacionarla mucho con serve

rendering hay una diferencia si se fijan

cuando nosotros utilizamos ser rendering

tenemos un servidor ahí ejecutándose por

lo tanto el la parte de PR renderización

el pre rendering ocurre en tiempo de

request en tiempo de eh de ejecución

porque el servidor se está ejecutando y

es el cliente quien le pide una página

Mira prerender esto y Envíamelo me

explico cuando hablamos de static Side

generation como es una generación de

estáticos de un sitio ocurre en tiempo

de construcción cuando nosotros hacemos

el build es el mismo framework esto lo

hace por ejemplo Astro sí eh Cuando

hacemos el build es el mismo framework

quién pues pre renderiza todo y nos

lanza estáticos y elimina todo el

javascript que sea e innecesario Sí por

qué es innecesario Pues porque a veces

eh lleva duplicación ya vamos a ver el

tema de la duplicación Ah o pues ya

básicamente Pues no sé tiene que por qué

cargar en el cliente porque ya se pre

renderizo ya se hicieron pues peticiones

http o se hizo todo lo que se necesitaba

ser a nivel de pues Mostrar datos bien

me generó los estáticos a nivel de html

y css Y eso es lo que yo despliegue

vale Y ya está si yo hago un cambio en

esta web con static Side generation

tengo que generar otro build bien Y

desplegar ese nuevo build Para yo poder

ver el cambio no es como en servers

rendering que tengo un servidor ahí

ejecutándose y pues si yo quiero un

cambio Pues nada lo Solicito y ya está

el servidor pues lo procesa lo PR

renderiza y me lo envía explico

entonces este tipo de estrategia el

static generation es ideal para por

ejemplo

portfolios inclusive eh temas de yo que

sé cualquier otra web de contenido

estático de hecho la web de programación

en español está hecha con este esta

estrategia porque de hecho está hecha

con Astro vale Aunque Astro aquí mezcla

algunas cosillas que ya vamos a

ver Qué ventajas tiene el static Side

generation sí obviamente la rapidez es

una de las principales Por qué Porque ya

que estamos generando todos los

estáticos en tiempo de eh construcción

vale el cliente va a ver el contenido

inmediatamente porque son estáticos lo

que tiene que Descargar es html y css

ahí javascript no está pintando nada en

el dom no estamos manipulando eh ningún

nodo no estamos haciendo absolutamente

más nada sino enviarle al cliente pues

html y css Y eso es lo que ve vale Así

que es muy muy ligero aquí pues también

mantenemos la ventaja del seo porque al

final son estáticos así que vamos a

tener metadata por allí los crawlers van

a ser felices y nosotros también

obviamente y además e no tenemos en

ciertos casos que hacer peticiones

adicionales desde el cliente Por qué

Porque si estamos PR renderizando todo

en tiempo de construcción podemos eh PR

renderizar datos vale que estemos

sacando Pues yo que sé de una pie

terceros o una base de datos o incluso

de archivos estáticos vale generamos los

estáticos a partir de aquí y lo

mostramos así que pues ya no hay este

este Tom Dame entre cliente y servidor

me

explico ahora como desventajas pues lo

general la construcción del sitio puede

verse lenta dependiendo del tamaño de la

aplicación obviamente

eh volvemos aquí al tema del la

incompatibilidad con algunas librerías y

iis propias de Pues el cliente Por qué

Porque estamos generando estáticos si

estamos eliminando el javascript no

esperemos entonces que cuando nosotros

interactuemos con la web pues la web

reaccione de alguna manera porque es

estática si es html y css porque de

hecho estamos aquí quitando tratando de

quitar el javascript y por lo tanto

estamos evitando que se ejecute algo de

lado del cliente Sí ya vamos a ver

eh algo Cómo se llama un Matiz sobre

esto vale Ah y además Pues otra cosa que

se podría considerar desventaja es el

tema de Pues los builds sí como ya les

había comentado Si queremos hacer un

cambio en la web sí tenemos que generar

otro build porque estamos generándolo en

tiempo de construcción estamos generando

la web completa en tiempo de

construcción así que pues hay que volver

a ser un npm r build por ejemplo volver

a copiar el dis llevarlo al servidor

llevarlo a la ruta que específica del

despliegue eh Cómo se llama esto

reemplazar los archivos y pare de contar

vale esto lo podemos hacer A través de

un Chrome Job a través de la

automatización perdón de despliegues que

tienen tutoriales en YouTube

Ah en mi canal de YouTube

específicamente este Pero bueno se puede

automatizar el procedimiento vale

tampoco es que sea algo

traumático ahora

ahora hay algunas cosas ya las había

mencionado antes eh temas de matices que

vamos a tocar y tal Y qué sé yo hay

algunas cosas que entran aquí en la

ecuación fíjense que tanto service

rendering como static generation son

estrategias de pre rendering sí

básicamente renderización del contenido

previo a lo que es

e enviárselo al cliente bien previo a

que el navegador lo tenga vale para que

el navegador lo que reciba sea ya todo

el nodo del html pues construya su

cuestión y ya lo muestre y ya está s

Ahora hay estrategias para eh manejar un

poquillo lo que es la interacción con

con el dom sí o sea con interacción me

refiero a pues reaccionar a un click

reaccionar a un event listener utilizar

local storage utilizar el objeto window

utilizar document y pare de contar con

ser rendering y statis generation

vale vamos a ver aquí cómo funciona cada

estrategia vamos a compararlas ya en un

gráfico que tengo yo aquí aparte que ya

se los hice Vale y vamos a ver de qué va

la hidratación o

vale que también lo pueden encontrar por

ahí como Reconciliación o reconciliation

Vale y hacia dónde apunta más o menos el

futuro esto lo está implementando creo

que quick y hay un par de frameworks hay

uno de Google que ya lo implementado No

recuerdo el nombre pero creo que Google

photos de hecho y otra aplicación de

Google están hecho con esto vale que

implementan o están tratando de

implementar resum ability vale vamos a

ver de qué va Eso

sí a ver les he hecho aquí un pequeño

diagrama vamos a verlo me voy a poner Yo

por aquí

arriba para que se vea la cosa mejor sí

ahí está les he hecho este pequeño estos

pequeños diagramas vamos a comparar lo

que hemos visto hasta el momento y vamos

a ver el tema de hydration y el tema de

resum ability s fíjense alg nosotros

desarrollamos aquí volvemos al cli Side

rendering cuando estamos desarrollando

una spa Lo que sucede es lo siguiente el

navegador primero muestra una página en

blanco sí después ejecuta después de que

descarga el bundle de javascript que es

nuestra aplicación lo ejecuta y ese

bundle hace el render de nuestros

componentes visuales y ahí es cuando

nuestra aplicación ya se vuelve

interactiva Sí después que nosotros

cargamos la aplicación de react de

angular de View en el navegador el Bond

del js se encarga de crear todo el árbol

del dom sí de renderizar toda la web y

ahí es cuando nosotros podemos comenzar

a interactuar podemos darle a botones

podemos enviar formularios podemos hacer

y deshacer lo que nos dé la gana

Sí cuando utilizamos una estrateg

prerendering la cosa cambia fíjense lo

que sucede aquí el servidor nos envía

directamente al cliente html inicial

solamente html inicial

bien luego luego descargamos la parte de

javascript Sí pero qué sucede cuando

descargamos la parte de javascript que

este html inicial sí tiene que ser

reemplazado bien Por qué Porque la parte

de javascript pues obviamente tiene pues

event listeners tiene pues eventos

clicks pues tiene una cantidad de cosas

que pues obviamente se unen a los

elementos del html Así que esto este

árbol que hemos renderizado aquí ya no

nos sirve sino que tiene que ser

reemplazado con todo lo que implica la

interacción con javascript Sí entonces

aquí e primero que nada recibimos un

html plano luego recibimos el javascript

lo ejecutamos y aquí se vuelve a

renderizar todo se renderiza entonces

aquí existe una duplicación me explico

por qué Porque estamos aquí realmente eh

teniendo ciertos nodos html vale Y luego

los estamos renderizando con el

javascript que nos llega Entonces lo

estamos renderizando en el servidor y

después lo renderizando de nuevo en el

cliente para reemplazar el html plano

que nos llevó al principio

Esto no

es muy eficiente que se diga vale aquí

es cuando entra el concepto de hydration

sí o

reconciliation de qué va eh la

hidratación o el hydration de reutilizar

los nodos que ya están aquí vale

entonces yo tengo nodos comunes lo que

me interesa es reemplazar aquellos nodos

que no lo sean o de incrustar bien los s

handlers o lo que sea que tengamos a

nivel de interacción en los nodos que

que ya existen en el cliente porque ya

los recibimos bien no tenemos por qué

reemplazar todo eso es

hydration

sí reutilizar justamente los nodos del

dom Y a partir de allí ya nuestra web es

interactiva

Vale entonces aquí con eh hydration

Tratamos de pues

HM Cómo se llama aminorar la duplicación

para

eh primar lo que es la reutilización de

estos nodos que ya recibimos porque

repito ya tenemos html ahí o sea vamos a

reutilizar los nodos y ya está me

explico Ahora hay aparte de esto otro

concepto que es resum ability en este

caso resum ability trata de que

e nos llega en desde un principio html

del servidor con una porción mínima de

javascript Sí para qué Para que la web

sea interactiva de una vez vale Y qué va

a pasar en paralelo que va a seguir

descargando

eh partes pequeñitas de javascript pero

aquí se elimina la duplicación y cuando

nos referimos a eliminar la duplicación

nos referimos a que del pondel de

javascript se elimina todo aquello sí

que render cosas o nodos que ya tenemos

realmente aquí en principio vale Así que

este Bond del javascript va a ser mucho

más pequeñito entonces descargarlo en

paralelo no nos va a costar tanto y por

lo tanto la web va a ser interactiva

mucho más rápido y el usuario ni

siquiera lo va a notar Vale entonces a

esto apuntan frameworks como por ejemplo

repetimos eh quick vale Y hay un par de

frameworks eh Ya de de Google hay un

framework de Google otro no recuerdo de

quién era Ah que lo están implementando

que lo están apuntando hacia Esto sí de

momento Pues en las otras en los otros

frameworks y librerías que tenemos hoy

en día pues frameworks como next como

nox como angular etcétera pues tenemos

el tema de El hydration

Vale ahora fíjense que podemos de hecho

consultar esto directamente en la

documentación por ejemplo de angular sí

Y por qué consultar la documentación es

importante s super importante fíjense lo

que pasa aquí como se imaginarán si

estamos aquí tratando de reutilizar con

hydration los nodos que ya tenemos a

nivel de html para poder justamente

hacer esa Reconciliación y poder agregar

interactividad sin tener que renderizar

que destruir todos los nodos y volverlos

a renderizar con javascript

vale entre los nodos que hay

aquí s y los nodos que hay

aquí tiene que haber una concordancia

para poder reutilizarlos Por qué Porque

si lo que está aquí es diferente a lo

que está aquí entonces necesariamente

tengo que destruir y volver a renderizar

vale Y eso lo ven aquí en entación de

hecho vale

eh Por ejemplo Aquí está en constraints

vale

Pam nos dice directamente tu aplicación

debe tener el mismo la misma estructura

del dom generada tanto en el servidor

como en el cliente Sí por qué Porque el

proceso de iteration espera el mismo

árbol del dom eh a nivel estructural

desde ambas partes para qué Para poder

reutilizar esos mismos nodos si no la

tiene tiene que renderizar vale Y aquí

pues obviamente no lo va a hacer de

forma automática sino que muy

probablemente te da algún error sí Y

esto mismo ocurre por ejemplo en react

etcétera Cómo se trata de palear un poco

esta esta parte pues con algo que se

llama hidratación selectiva O selective

hydration

sí vamos ahí aparte de la documentación

de angular para que tengamos varias

fuentes hay un hlo aquí en el

repositorio de react 18 sí

Ah que está brutal o sea te explica la

parte de serv rendering Sí en

específicamente perdón el hilo es del

suspense vale que se incorpora en en

react 18 Sí y lo que nos permite el

suspense es justamente esta hidratación

selectiva

vale de forma tal de que no tenemos que

esperar a que se hidrate todo el el el

árbol del dom vale sino que podemos

hidratar ciertas partes para que la web

cargue estáticos por un lado y cargue eh

componentes o hidrate componentes

interactivos por otro lado Sí y a los

que han trabajado con Astro esto les

debe sonar porque es el mismo concepto

de Islas Ya lo vamos a ver pero fíjense

la cosa Este hilo Me encantó o sea est

esta discusión aquí en el repositorio Me

encantó se las voy a pasar por aquí por

el chat y si están viendo esto en

YouTube se los dejo también en la

descripción del vídeo porque es brutal o

sea échenle un ojo vamos

fíjense aquí

eh La idea es Es que la web llegue a

este punto lo más rápido posible Sí

cuando tenemos este recuadro verde es

porque toda la web es interactiva y ya

está lista Vale entonces cuando hacemos

client Side rendering lo primero que

vemos ya les había dicho es la web en

blanco en este caso cuando utilizamos

serv rendering pues lo que vemos es

contenido estático todavía no

interactivo y cuando ya terminamos de

hidratar pues tenemos ahora el contenido

interactivo

sí por aquí abajo por aquí abajo ya nos

comienzan a hablar de selective

hydration o hidratación selectiva Por

qué Porque si se fijan el problema está

en que hay un esquema de waterfall es

decir una cosa no puede pasar sin que

pase la anterior Sí cuando nosotros

hacemos serv rendering hacemos el fetch

de Data del hacia el server renderizando

el html del servidor cargamos el código

en el cliente e hidratamos hacia el

cliente no podemos hidratar si el código

no ha cargado no podemos eh cargar el

código si no se renderiza el html y no

podemos renderizar el html sin que se

haya hecho el fetch de Data en el

servidor me explico o sea es una cadena

que va Pues paso por paso para que la

cosa sea mucho más ágil si podamos

renderizar cosas estáticas y cosas luego

dinámicas de forma progresiva o de forma

selectiva tenemos justamente el

selective hydration vale esto en este

caso react lo hace con el tema de por

aquí lo dice vamos el tema de ya se me

olvidó el suspens vale

Sí y lo que marca el suspense es

justamente un componente que podemos

hidratar de forma selectiva todo lo

demás se va fíjense renderizando de

forma estática mientras que este

componente Pues aquí puede cargar Por

qué porque tiene interacción necesita

interacción necesita pues cargar alguna

cosilla

Vale entonces este hilo está s super

interesante y te explica Pues el tema

del suspense para aquellos que trabajan

con react y para aquellos que pues

quieran también profundizar el concepto

de lo que es selective hydration pues ya

grandes ras os Lo acabamos de explicar

Pero bueno si quieren leerse el hilo de

verdad está muy interesante y está super

recomendado vale fíjense aquí podemos

tener incluso componentes eh Ya

interactivos mientras que esto se está

hidratando todavía vale suena que le

estemos echando agua pero bueno de hecho

la la traducción es así o sea estamos

hidratando un eh Cómo se llama un don

seco no O se un don plano vale por eso

el nombre también

Ah entonces entonces cuál podría ser un

ejemplo de un componente con hidratación

por ejemplo en este hilo ponen este

componente como un listado de

comentarios vale como tú puedes

responder al comentario puedes editar el

comentario puedes eliminar el comentario

pues obviamente Debes tener interacción

Vale entonces si por ejemplo tu naf eh

tu sidebar y yo que sé tu title aquí no

son eh No necesitas interacción para

ellos pues obviamente no vas a bloquear

la carga de estos estáticos por el tema

de hidratar este componente nada más

entonces lo que haces es cargar estos

estáticos e hidratas de forma más

selectiva este componente Vale entonces

ya el usuario ve esto que es bastante

mientras ve el loader de los comentarios

hasta que esto se hidrata bien llega el

html primero y después pum se hidrata y

ya tienes interacción

Vale y hablando de islas de Astro ya les

había mencionado el tema de pues

hidratación selectiva justamente eso es

lo que implementa Astro vale vamos a ver

cómo implementa eh esta parte astro eh

Para también ver otro caso de estudio No

fíjense aquí de hecho Astro mismo nos

dice dónde

está Okay Astro plantea Bueno sí una de

las cosas que esto el concepto como tal

de Islas no viene propiamente de Astro

vale Ah De hecho viene el creador de

prct pero Astro en este caso se hizo muy

conocido por el tema de incluir el con

concepto de Islas vale la idea general

de esta arquitectura de Islas es

renderizar páginas html en el servidor e

inyectar placeholders o slots alrededor

de regiones altamente dinámicas que

luego pueden ser hidratadas en el

cliente como pequeños widget

autocontenidos reutilizando su html

inicial renderizado en el servidor vale

lo que acabamos de ver el concepto de

hydration el tema está en que la

pregunta del millón cuando cuando vemos

por primera vez Astro es cómo hace esto

sí para tener Pues un componente de

react y pues una estructura de web

totalmente estática cargar el componente

de react y que la cosa lo haga Así bien

es justamente a través de hidratación

selectiva

vale fíjense en contraste la mayoría de

los frameworks web web Perdón basados en

javascript hidrata y raliza un sitio web

completo como una gran aplicación de

javascript vale que es lo que estamos

viendo esto Pues es lo que hacen las

spas

sin embargo sin

embargo Pam Astro se hizo popular como

el primer framework web de javascript

con hidratación selectiva incorporada Y

esto es lo que le permite hacer este

tipo de Islas o implementar este tipo de

Islas Vale entonces Qué es una isla en

Astro que esto lo pueden ver también en

la clase de Astro que tenemos aquí en el

canal de YouTube una isla se refiere a

cualquier componente de interfaz de

usuario interactivo en la página Vale

entonces por ejemplo Tenemos aquí el

encabezado de una página que puede ser

una isla interactiva un Carrusel de

imágenes que también lo puede ser

mientras que la barra lateral el

contenido estático y el pie de página

Son totalmente estáticos sí Y cómo sabe

Astro Qué es lo que tiene que cargarle

lado del cliente y qué es lo que tiene

que cargar del servidor porque claro

Astro ya no O sea Astro puedes hacer

servers de rendering con Astro cuidado

Vale pero Astro nace como un static Side

generator vale o como un framework con

static s generation Mejor dicho sí

Ah entonces cómo le decimos nosotros a

asro Mira mantenme este javascript para

que se cargue el cliente Mientras que el

resto Mira te puedes volar el javascript

del resto y me lo generas los estáticos

y ya está Vale justamente con las

directivas de Astro Como por ejemplo

Esta client sí Si nosotros le ponemos

aquí a un componente de react que se

cargue en el cliente a través de esta

directiva Astro deja el javascript ahí

cuando el javascript se carga al lado

del cliente pues ahí el componente hace

lo que tiene que hacer es decir

renderiza el dom a partir del javascript

que tiene el componente vale esto lo

podemos hacer así repito con static Side

generation o también podemos implementar

por aquí eh tenemos la documentación de

el server rendering pero ya con Astro

vale e incluso Astro nos permite eh

combinar cosillas Aquí sí entonces

seleccionar componentes para client Side

rendering y seleccionar componentes para

seride rendering Y pues obviamente todo

lo demás para static generation es decir

es bastante versátil con respecto a

formas de renderizado bien bien tenemos

por aquí pues nada beneficios de las

Islas etcétera lo interesante de Astro

es entender esto para saber el Cómo

podemos justamente jugar un poco con

dónde cargamos qué Y cuándo cargamos Qué

bien y sobre todo sobre todo repito esta

esta pequeña explicación esta pequeña

charla que les he preparado para el día

de hoy viene para que entendamos En qué

contexto estamos usando Qué cosa s

Porque si estamos repito utilizando algo

con una estrategia de server Side

rendering no podemos pretender tener a

la mano o a disposición apis que no

están en el servidor sino que está en el

cliente entonces eh si vamos a utilizar

local Host si vamos a utilizar Pues el

objeto window el objeto document o lo

que sea tenemos que estar conscientes de

que tenemos que validar primero que

estamos en la plataforma correcta es

decir que estamos en el navegador Sí

cada framework o pues incluso podemos

hacer workarounds allí con javascript

vale para identificar Bueno mira estoy

en el navegador Pues bien Ahora yo puedo

utilizar aquí local storage no estoy en

el navegador pues puedo incluso crear mi

propio grapper mi propia implementación

de local storage bien para que no de

error y si estamos en el navegador pues

simple y llanamente igual o esa ese

objeto que yo mismo estoy creando que yo

mismo estoy implementando al objeto real

que es storage vale del navegador y ya

pues ya me probé mis mis métodos y no ha

pasado nada me explico es decir tenemos

que entender bien qué es lo que estamos

haciendo Y en qué contexto lo estamos

haciendo para poder jugar bien eh con lo

que tenemos a disposición

vale

Okay continuamos por aquí

Eh Eh Eh Dónde está el rollo este

de la pregunta del millón la pregunta el

millón Cuándo usamos

qué pero claro ahora mismo hay mucha

gente Eh y el IP siempre nos come sobre

todo en el mundo de desarrollo de

software el I Es algo es como el salseo

alimenta nuestras almas Entonces cuando

utilizamos cli rendering Perdón aquí

esto me culpa

Vale cuando utilizamos client Side

rendering sí cuándo utilizamos serv

rendering Y cuándo deberíamos utilizar

static Side generation esto no está

escrito en piedra son recomendaciones

generales vale ustedes pueden ya según

su contexto decidir una u otra cosa Vale

cli Side rendering es ideal para

sistemas sobre todo internos Sí es muy

común utilizar pues aplicaciones

eh directamente renderizadas en el

cliente en el navegador vale con angular

con react con View con spelt con lo que

sea sí en sistemas que son por ejemplo

sistemas internos de empresas sistemas

que no necesitan de un posicionamiento

en buscadores porque realmente eh Cómo

se llama esto no no no interesa que

estén indexados no O por lo menos no es

prioritario esos sistemas que están

detrás de alguna plataforma o algún

sistema de login bien de permisología

eh sistemas de gestión de cuentas de

usuario sistemas de e-commerce los

sistemas internos el e-commerce por

ejemplo vale o sea en él le interesa que

que que tu panel de control de tu

e-commerce aparezca en Google como la

primera cosa no O sea mal asunto

entonces todo este tipo de cosas son

candidatas a Pues desarrollarse con c eh

rendering sí cuándo le podemos sacar

provecho al server rendering cuando ya

la cosa cambia cuando necesitas ya seo s

cuando necesitas pues tener esos

estáticos porque necesitas que tu página

o tu aplicación web se indexe bien

entonces el contenido de la web aparte

cambia menudo es decir esto podríamos

verlo en relación con esto anterior vale

igual podemos utilizar pues o podemos

tener un un e-commerce vale o podemos

tener yo que sé la página de un banco la

página de un seguro o cualquier otra

cosa con login de usuarios con

permisología con lo demás pero la parte

pública sí que nos interesa que se

indexe por lo tanto tiene que tener

estáticos tiene que tener metadata tiene

que tener todo este tipo de cosas pues

esa parte pública la podríamos hacer con

serv rendering por ejemplo sí Y además

tenemos allí el tema de que como estamos

directamente en el servidor y el

servidor se está ejecutando pues tenemos

ahí una conexión a Pues un Api de

terceros o directamente a la base de

datos Y tal Y podemos hacer consultas

previas antes de enviarle al cliente

pues lo que necesita sí a nivel de

dom con respecto al static Side

generation Pues en este caso pues lo

podemos utilizar cuando el contenido de

lo que sea que estemos desarrollando

pues no cambie demasiado vale

Ah ni depende del usuario que lo está

consultando es decir no depende de un

login no depende de una sesión no

depende de

eh variables varias que estemos

controlando el lado del cli cliente

entiendase local stor stor y pare de

contar vale por ejemplo un blog personal

De hecho el blog de promoción español lo

voy a ser con Astro Vale y va a ser con

static High

generation la página de programación en

español está hecha en Astro bien con

static High generation eso no es un

servidor ejecutándose ni mucho menos

Ah el portfolio si quieren hacer un

portfolio pues lo pueden hacer estático

o sea no necesitan un servidor ahí

ejecutándose para que le prerender algo

o sea simple llanamente pues generan su

estático y ahí está vale A menos que

pues ya quieran no sé tener permisos o o

alguna cosilla allí que necesiten

ejecutar al cliente pues ya saben que

Astro les ha da la opción de tener

ciertos componentes que se pueden

ejecutar al cliente y pare de contar

Vale entonces estos serían algunos de

los casos de uso en los que pueden

aplicar tanto client Side rendering como

server Side rendering o static site

generation

sí pregunto mi gente bonita qué les

preció qué tal lo ven qué tal lo ven

fíjense que cambió un poquito el formato

para hacer un poco más no sé

estructurado o entretenido no sé si les

gustó la presentación si me dicen Mira

Pedro Olvídate las presentaciones y dale

como explicas como siempre pues no pasa

nada vamos este pero déjenmelo saber por

aquí en el chat y si estás viendo esto

en YouTube Pues en los comentarios

también eh