#CSR, #SSR y #SSG: qué son y cuándo usarlos
Summary
TLDREl 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
🤔 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.
🌐 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.
💡 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.
🚀 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.
🔄 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.
📝 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.
Mindmap
Keywords
💡Server Side Rendering (SSR)
💡Client Side Rendering (CSR)
💡Static Site Generation (SSG)
💡LocalStorage
💡SEO
💡Single Page Applications (SPAs)
💡Bundle
💡Hydration
💡Islands
💡Framework
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
Voir Plus de Vidéos Connexes
5.0 / 5 (0 votes)