Querido cliente, te estoy dejando

Rate this content
Bookmark

Con los componentes del servidor de React y las nuevas capacidades de suspense SSR de React, tenemos un cambio de paradigma en el mundo de la representación del lado cliente/servidor. El péndulo que comenzó en páginas HTML simples, rápidamente se inclinó hacia la representación completamente del lado cliente, ahora está volviendo al lado del servidor. Los marcos emergentes como Next.js y Remix dan inicio a una nueva era de desarrollo web, en la que la representación del lado servidor es un ciudadano de primera clase. En esta charla profundizaremos en esas características de React, hablaremos sobre las prácticas más avanzadas en cuanto a la representación del servidor y tal vez vislumbremos el emocionante futuro de las relaciones de pila completa entre el front-end y el back-end.

21 min
21 Jun, 2022

Video Summary and Transcription

Liad Yosef analiza la importancia y evolución de la representación del lado servidor, destacando sus beneficios como el rendimiento mejorado y el SEO. Explora diferentes estrategias de representación y los desafíos de la hidratación en React. Presenta SuspenseSSL en React 18 como una solución para obtener datos de forma anticipada e hidratar selectivamente componentes. También menciona React Server Component como un cambio revolucionario para reducir el tamaño del paquete en la representación con React.

Available in English

1. Introducción a la Renderización del Lado del Servidor

Short description:

En esta parte, Liad Yosef se presenta a sí mismo y al tema de la charla, que es la renderización del lado del servidor. Menciona la importancia de discutir este tema y hace referencia a una cita de Abraham Lincoln. También menciona que la charla se centrará en la renderización del lado del servidor en React.

Hola. Hola a todos. Gracias por asistir a mi charla. Soy Liad Yosef. Mi charla se llama Querido Cliente, Te Dejo. Vamos a hablar un poco sobre la renderización del lado del servidor, la renderización del lado del servidor, y todo lo que hay en medio. Así que soy Liad Yosef. Soy el arquitecto principal de front-end en Douda. Soy un entusiasta de la web y en mi tiempo libre también soy un astronauta analógico. Tengo el privilegio de participar en misiones analógicas en todo el mundo, me gusta mucho el espacio. Así que con esto en mente, convertiremos nuestra charla en algo así como una charla en modo oscuro, y será temática espacial. Entonces podrías preguntarte, ¿por qué necesitamos hablar sobre la renderización del lado del servidor? Abraham Lincoln dijo una vez que si tuviera ocho horas para cortar un árbol, pasaría seis afilando mi hacha, y Rick Sanchez agregó que el universo es mucho más complicado de lo que piensas. Así que prepárate para una aventura de 20 minutos en la madriguera del conejo de la renderización del lado del servidor, ¿y cómo lo abordamos en React? Así que es hora de maratón, y todos sabemos que preferimos ver Netflix en lugar de ver

2. Understanding Server-Side Rendering

Short description:

En esta parte, Liad Yosef discute el concepto de renderización del lado del servidor y su evolución a lo largo del tiempo. Explica la diferencia entre la renderización clásica del servidor, la renderización cliente-servidor y la nueva renderización del lado del servidor. Liad destaca las razones para utilizar la renderización del lado del servidor, como el mejor rendimiento, una mejor optimización para motores de búsqueda y la solución de problemas con la renderización del lado del cliente. También menciona la importancia de considerar criterios de rendimiento como el cambio de diseño acumulativo y la carga de contenido significativo. Además, hace referencia a una charla de Rich Harris sobre el impacto de las aplicaciones de una sola página en la web.

charlas técnicas. No es como si estuviéramos viendo a Dan Abramov en Netflix. Así que enmarcaré mi charla un poco como Netflix. Hay muchos temas para discutir. Puedes elegir rendimiento o hooks o La Casa de Papel, una web tres o un juego de cuadrícula, pero me enfocaré en las paredes del servidor. Paredes del servidor, eso es algo que necesitamos aprender. Necesitamos entender para realmente comprender la relación cliente-servidor. Y comenzaremos con una pequeña historia básica sobre las paredes cliente-servidor. Entonces, cuando hablamos de la renderización clásica del servidor, ¿de qué estamos hablando? En la renderización clásica del servidor, el enfoque común hace unos 15 o 20 años, el servidor genera una estructura de marcado y el cliente ejecuta la lógica de interacción. Puedes pensar en PHP o JSP o cualquier otra cosa con la que estés familiarizado. Entonces, en la renderización clásica del servidor, el navegador solicita al servidor que ensamble la página. El servidor ensambla la página en el lado del servidor, enviando el marcado plano al cliente y el cliente obtiene el marcado. Esa es la renderización clásica del servidor. Y si quieren hacer que su marcado sea interactivo, simplemente le piden al servidor que envíe el hito, el JavaScript, para hacerlo útil. Esa es la renderización clásica del servidor. En la renderización cliente-servidor, ese es un paradigma con el que comenzamos a trabajar hace unos 10 años, el cliente se encarga de generar la estructura de marcado y la lógica de interacción, como en React. Entonces, el cliente solicita ensamblar la página y el servidor simplemente envía un contenedor vacío y luego es responsabilidad del cliente solicitar a React o al código JavaScript para renderizarlo ellos mismos. React renderiza el marcado y si hay algo más que el cliente desee, pueden solicitar al servidor otro código JavaScript para renderizar la parte faltante. Esa es la renderización del lado del cliente. En la nueva renderización del lado del servidor, que es el paradigma con el que comenzamos a trabajar hace unos dos o tres o cuatro años el servidor se encarga de generar la estructura de marcado y el cliente se encarga de ejecutar la lógica de interacción. Espera, ¿qué? Quiero decir, hemos vuelto al punto de partida desde el PHP de hace 20 años hasta la renderización del lado del servidor de hoy. Bueno, debes recordar que React es un lenguaje de plantillas. Por lo tanto, también puedes usarlo en el servidor para hacer plantillas. Puedes preguntarte por qué. ¿Cuál es la razón de hacer renderización del lado del servidor? Bueno, en el pasado, cuando teníamos velocidades de red lentas y dispositivos lentos, teníamos que hacer todo en el servidor, ¿verdad? Porque el cliente no era lo suficientemente fuerte o potente como para renderizar. A medida que los dispositivos se volvieron más potentes y los clientes querían aplicaciones más complejas, trasladamos la renderización al cliente. Pero ahora, a medida que las redes se vuelven realmente rápidas y se envía mucho código complejo al cliente y nuestros estándares de carga se han vuelto más altos, queremos que las cosas se carguen mucho más rápido, tenemos que volver a trasladar la renderización al servidor. Si hablamos de rendimiento, esos son dos criterios que Google verifica en sus Core Web Vitals. Luego, el cambio de diseño acumulativo verifica qué sucede cuando el cliente renderiza el marcado, pero algo aparece de repente porque el cliente lo está renderizando incrementalmente, y luego haces clic en algo que no querías hacer clic. O la carga de contenido significativo, ¿cuánto tiempo tarda el cliente en obtener los datos para renderizar algo, lo cual es un problema en el mundo de la renderización insuficiente del cliente. El SEO también es un problema, porque cuando Google intenta indexar nuestra página, accede al servidor, solicita la página y si el servidor devuelve solo un contenedor vacío, Google no sabe cómo indexar nuestra página. Hay una charla muy buena de Rich Harris llamada `Las aplicaciones de una sola página arruinaron la web` y en general hay una muy buena charla en la esfera de Twitter o en la web sobre aplicaciones de una sola página versus aplicaciones de varias páginas, donde algunas personas dicen que las aplicaciones de varias páginas no cumplen con las expectativas que queremos y otras personas dicen que las aplicaciones de una sola página, debido a su carga lenta, no ofrecen

3. Understanding Rendering Strategies and Spectrum

Short description:

Hay un debate sobre aplicaciones de una sola página versus aplicaciones de varias páginas. La renderización implica quién construye el marcado, cómo se vuelve interactivo, cuándo se construye y desde dónde se sirve. La renderización estática proporciona la misma página para todos, se puede almacenar en caché fácilmente pero no es personalizada. La renderización del lado del cliente permite la personalización pero no se puede almacenar en caché y tiene una carga inicial lenta. La regeneración estática incremental genera algunas páginas bajo demanda. La renderización en tiempo real del lado del servidor se utiliza para contenido personalizado. Los componentes de nivel React son adecuados para aplicaciones web con partes estáticas y dinámicas. La renderización estática clásica se basa en la caché para servir las páginas. La renderización estática incremental genera variaciones en la caché. El servidor sigue siendo necesario y la caché puede ser activada por la propia caché.

Hay una charla muy buena de Rich Harris llamada, Las aplicaciones de una sola página arruinaron la web, y en general hay una muy buena charla en la esfera de Twitter o en la web sobre aplicaciones de una sola página versus aplicaciones de varias páginas, donde algunas personas dicen que las aplicaciones de varias páginas no cumplen con las expectativas que queremos y otras personas dicen que las aplicaciones de una sola página, debido a su carga lenta, no ofrecen el rendimiento que queremos. Ese es un debate en curso.

Pero para entender un poco de qué estamos hablando, necesitamos entender qué estamos hablando cuando hablamos de renderización. Así que, renderización 101, hablamos de quién construye el marcado. Puede ser el cliente, el servidor o el borde en el medio. ¿Cómo se vuelve interactivo? ¿Es el cliente el que lo hace interactivo? ¿O es el código JavaScript el que lo hace interactivo? ¿Son las funciones nativas del navegador? ¿O es React el que lo hace interactivo? ¿Cuándo se construye? ¿Se construye en tiempo de compilación o en tiempo de ejecución? Y, por supuesto, ¿desde dónde se sirve? ¿Se sirve desde algún tipo de red de borde, una caché o el propio servidor?

Entonces, si pensamos en un blog simple, por ejemplo, que es muy estático, entonces sabemos que se construye en tiempo de compilación, es interactivo. Estamos usando código JavaScript. El servidor lo está construyendo y se sirve desde la caché, ¿verdad? Porque no necesitas reconstruirlo en tiempo de ejecución. Pero si tienes una aplicación web compleja, eso es algo que el cliente está construyendo, probablemente usando React u otros frameworks, y requiere un servidor. Requiere un servidor en tiempo de ejecución para funcionar.

Entonces, si pensamos en esas dos partes, esos dos bordes, tienes la renderización del lado del servidor para páginas muy estáticas y simples, por un lado, y tienes la renderización del lado del cliente para aplicaciones web muy complejas, por otro lado, puedes colocarlos en un espectro, porque esas no son las únicas dos opciones que tenemos. Entonces, en la renderización estática, que es la renderización del lado del servidor en tiempo de compilación, obtienes la misma página para todos y se puede almacenar en caché fácilmente, pero no se puede personalizar. Y no puedes tener variantes, porque necesitas construir todo en tiempo de compilación y requiere una compilación para cada actualización, mientras que en la aplicación del lado del cliente, que es la más dinámica, se puede personalizar fácilmente porque se hace bajo demanda en la solicitud, pero no se puede almacenar en caché y tiene una carga inicial lenta y una obtención de datos lenta, porque tienes que ir al servidor para todo, pero tiene una capacidad de respuesta rápida en la aplicación. Pero debemos recordar, esto es un espectro, así que si quiero construir una página de listado y quiero que cada página en el listado sea diferente, porque tengo 10,000 propiedades que quiero listar, entonces puedo usar algo que se llama regeneración estática incremental, que no solo genera todo en tiempo de compilación, sino que genera algunos de ellos en tiempo de compilación y otros bajo demanda. Si quiero construir algo más personal, como mis reservas o mi cuenta, o cosas que necesitan mis datos, necesitan mis cookies para presentarse, entonces tendría que ir con la renderización en tiempo real del lado del servidor, porque no puedo almacenar en caché nada, y, por otro lado, si quiero construir una aplicación web, pero la mayoría de las partes de la aplicación web son estáticas y solo algunas partes son dinámicas, iría con componentes de nivel React. Hablaremos de todas estas estrategias. Entonces, cuando hablamos de estrategias SSL o el multiverso de la locura, debemos recordar que cuando hablamos de renderización estática, ya no hablamos solo del cliente y el servidor. Necesitamos poner algo en el medio, que es la red de borde o la caché, y luego podemos discutir sobre las relaciones entre el cliente, el borde y el servidor. En la renderización estática clásica, que es como vimos, las páginas de blog, el servidor genera la página en tiempo de compilación y envía la página a la caché, a la red de borde, y luego sale de la imagen. Ya no necesitamos el servidor. Simplemente generó la página y ya está. El cliente solicita la página a la caché o al borde y obtiene la página, obtiene la publicación del blog, y es importante entender. Es importante tener en cuenta que todos los clientes obtendrán la misma página porque todos la solicitan desde la caché. Como dijimos, las páginas se pueden almacenar en caché fácilmente y no requieren un servidor, y tienen un gran rendimiento, pero necesitan reconstruirse para cada actualización, y hay un problema con la obtención de datos. En la regeneración estática incremental, el servidor construye la página, la envía a la caché para que se almacene en caché, pero también construye muchas variaciones, muchas otras variaciones en la caché, y cuando el cliente solicita la página a la caché, obtienen la página, y otro cliente puede solicitar otra página y obtendrá otra página, pero si un tercer cliente solicita una página que no existe en la caché o en la red de borde, entonces va directamente al servidor. El servidor lo genera en tiempo real y lo envía a la caché, lo almacena en caché, y luego el cliente se comunica con la caché y obtiene esta página. Es como lo mejor de ambos mundos, pero aún necesitas un servidor. También puede ser activado por la caché. Puedes establecer un tiempo de invalidación. Por ejemplo, si tienes una página que necesita ser validada o actualizada cada par de minutos, cuando el cliente solicita la página a la caché, la caché puede decir que esta es la página que quieres, y el siguiente cliente, la caché puede decir, oye, la página está obsoleta, pidiendo al servidor que la regenere, mientras al mismo tiempo sirve la página obsoleta al cliente, y luego el servidor regenera una nueva página, la reemplaza en la caché, y luego el siguiente cliente obtendrá la página actualizada.

4. Estrategias de Renderizado e Hidratación

Short description:

El renderizado estático incremental permite el almacenamiento en caché y reduce los tiempos de compilación para múltiples páginas, pero no puede reflejar datos específicos del usuario. La renderización completa en el servidor proporciona contenido altamente personalizado y páginas únicas sin un proceso de compilación, pero tiene un tiempo de respuesta largo. La renderización en el borde combina los beneficios del renderizado y la red de borde, lo que permite un HTML rápido y transmitido. La hidratación, el proceso de hacer que el marcado sea interactivo, es un desafío ya que requiere enviar todo el código al cliente y no se puede hidratar parcialmente. React está trabajando en soluciones como suspense y otros componentes.

La renderización estática incremental permite el almacenamiento en caché y reduce los tiempos de compilación para múltiples páginas, pero no puede reflejar datos específicos del usuario. Entonces, si tienes miles de publicaciones de blog, no tienes que construir todas ellas de antemano, pero requiere un servidor y no puede reflejar datos específicos del usuario porque no vas realmente al servidor y generas una página única, y los viajes al servidor son largos.

La renderización completa en el servidor, eso es lo que llamamos renderizado en el lado del servidor, tenemos que recordar que la caché ya no está en la ecuación, el cliente se comunica directamente con el servidor, por lo que el cliente puede solicitar una página altamente personalizada, por ejemplo, detalles de la cuenta, mis listados o mi cuenta, y el servidor la construirá y la enviará al cliente algo muy único para ese cliente. Y si otro cliente solicita la página al servidor, el servidor construirá algo completamente diferente, porque es un cliente diferente, un cliente diferente, y se lo enviará.

Entonces, en la renderización completa en el servidor, obtenemos un contenido altamente personalizado y páginas únicas, y no necesitamos un proceso de compilación, lo cual es importante, pero requiere un servidor y aún tenemos el largo tiempo de respuesta desde el servidor. ¿Por qué el largo tiempo de respuesta? Porque si miramos el código del servidor, por ejemplo, podemos ver que la línea relevante aquí es una renderización a cadena, y esta línea es síncrona, por lo que necesitamos renderizar todo antes de poder enviar la página, y eso es un problema. Y discutiremos algunas formas de resolverlo pronto.

Y hay voces que dicen que si tu renderizado en el lado del servidor tarda más de 200 milisegundos, tal vez sea mejor hacer el renderizado en el lado del cliente en su lugar.

Y ahora lo nuevo de lo que todos están hablando es el renderizado en el borde o el uso de la red de borde para renderizar, y eso es como tener lo mejor de ambos mundos, porque si tenemos la red de borde que se está extendiendo por todo el mundo, podemos usarla para renderizar las páginas. No tenemos que hacer viajes al servidor. Entonces, si simplemente unimos el renderizado y la red de borde, podemos tener algo como esto. Podemos tener la red de borde alrededor del mundo, el cliente solicita una página similar a una persona desde la red de borde. La red de borde la construye y la devuelve en tiempo real. Pero como la red de borde es como una CDN, se extiende por todo el mundo, obtienes el punto de borde que está más cerca del cliente, lo que lo hace rápido. Entonces, el renderizado en el borde permitirá la transmisión, porque ahora que tienes tiempos rápidos y cortos entre el borde y el cliente, puedes transmitir HTML al cliente para que el cliente pueda ver partes del HTML mientras se están renderizando. Requiere una red de borde y Next lo admite, Remix lo admitirá, Netlify tiene Netlify Edge Functions, que es bastante impresionante. Eso es algo que debes tener en cuenta.

Y ahora hablemos de nuestro némesis, nuestro enemigo, la hidratación. Entonces, la hidratación es en realidad el proceso que ocurre en el cliente después de recibir el marcado. Y eso es un problema, porque si lo piensas, ¿quién le da vida al marcado? Puede ser el navegador que utiliza interacciones nativas del navegador como envío de formularios y menús desplegables y cosas que el navegador sabe cómo manejar. Remix se basa mucho en esto. O puede ser JavaScript, ¿verdad? Entonces, el navegador puede pedir al servidor que envíe algún código JavaScript para hacer que el marcado cobre vida o sea interactivo. O puede ser React. Pero React hace la hidratación, lo que significa que construye todo el marcado en el servidor y luego el servidor lo envía al cliente y luego el cliente tiene que pedir a React nuevamente para reconstruir el marcado, lo cual es bastante ineficiente, reconstruir el marcado. Y solo entonces agrega la lógica de interacción, ¿verdad? Esta es una hidratación basada en React y en React, necesitamos enviar al cliente tanto el código de renderizado como el código de interacción, lo que hace preguntarse si el único código que necesitamos es este es el código de interacción. ¿Por qué necesitamos enviar todo esto al cliente? Entonces, la hidratación se está convirtiendo en un problema porque tienes que enviar todo el código al cliente y porque no puedes hidratar parcialmente. Tienes que esperar a que todo el código llegue al cliente hasta que puedas hidratar. Puedes leer a Steve Sower, tiene una publicación de blog muy buena al respecto. Y React está tratando de resolverlo con suspense como inicio y otros componentes de React.

5. Usando SuspenseSSL para el Renderizado en el Lado del Servidor

Short description:

Entonces, una breve introducción sobre suspense. Nuestro problema con SSR es que necesitamos obtener todos los datos de antemano en el servidor, cargar todo el JavaScript antes de la hidratación y luego hidratar todo antes de poder interactuar con él. Si queremos construir un sitio web de mentoría para los Avengers, tenemos que obtener todo de antemano, lo cual es difícil. Pero SuspenseSSL viene a nuestro rescate en React 18. React introdujo el streaming de HTML y la hidratación selectiva, lo que nos permite transmitir HTML al cliente e hidratar selectivamente. En lugar de usar renderToString en el servidor y hidratar en el cliente, podemos usar renderToPipe del stream y hidratar la raíz en el cliente. El mismo código de suspense se renderizará en el servidor y se enviará al cliente. React hidratará todo lo que pueda en el cliente y cuando las reseñas estén listas, el servidor enviará un script para reemplazarlas en el marcado.

Entonces, una breve introducción sobre suspense. Si queremos renderizar algo de forma perezosa, como aquí, queremos renderizar el ratón solo si Elon Musk está presente. Lo envolvemos en suspense y luego obtenemos un bonito spinner si queremos. Y solo cuando Elon Musk llega, podemos renderizar el ratón. Así es la idea de suspense.

Nuestro problema con SSR, como dijimos, es que necesitamos obtener todos los datos de antemano en el servidor, cargar todo el JavaScript antes de la hidratación y luego hidratar todo antes de poder interactuar con él. Es como una cascada. El servidor obtiene todos los datos, luego el servidor renderiza todo el HTML y lo envía al cliente. Luego, el cliente carga todo el código JavaScript y luego necesita hidratar toda la aplicación. Eso es un problema.

Entonces, si queremos construir un sitio web de mentoría para los Avengers y lo llamamos mentor, por ejemplo, todos pueden seleccionar un mentor de su elección, y tienes la página del mentor, que tiene la imagen y las reseñas del mentor y el nombre del mentor, ¿verdad? Lo construimos en React. Es bastante simple. Tenemos el nombre, la imagen, la descripción y las reseñas. Y digamos que quieres, si el servidor lo renderiza, es muy simple. El servidor simplemente lo renderiza en el marcado, lo envía al cliente y luego React hace su magia en el cliente y se vuelve interactivo y eso es increíble. Pero digamos que quieres que la imagen del mentor y las reseñas del mentor se carguen de forma perezosa. Tal vez lleva mucho tiempo obtener las reseñas de la fuente de datos de terceros. Entonces quieres envolverlo, digamos, en suspense, ¿verdad? Lo envolverías en suspense con un fallback. Pero luego tienes un problema con el SSL, porque React lo renderizará en el servidor, pero no sabe qué hacer con la parte de suspense. No lo sabe, porque no está ahí, así que lo enviará al cliente, pero React en el cliente realmente no sabe qué hacer. Eso es un problema, porque tienes que obtener todo de antemano. Y esta es la parte donde SSL se vuelve difícil. Por eso no utilizamos realmente SSL a gran escala hasta hace unos años, porque es difícil. Pero SuspenseSSL viene a nuestro rescate en React 18. React introdujo el streaming de HTML, la capacidad de transmitir HTML al cliente, y SelectiveHydration, la capacidad de hidratar selectivamente partes de los clientes. Entonces, en lugar de usar renderToString en el servidor y hidratar en el cliente, simplemente podemos hacer renderToPipe del stream y hidratar la raíz en el cliente. Y luego el mismo código de suspense se renderizará en el servidor con la carga y el spinner y se enviará al cliente. Luego, React hidratará todo lo que pueda en el cliente. Y solo cuando las reseñas estén listas, el servidor enviará al cliente algún tipo de script que diga, `oye, las reseñas están listas. Solo reemplázalas en el marcado`, lo cual es bastante sorprendente.

6. React Server Component y Reducción de Paquetes

Short description:

React Server Component es un cambio de juego para el renderizado con React. Te permite definir partes de una página como componentes del servidor, que pueden acceder a la base de datos y agrupar dependencias sin ser enviadas al cliente. Al definir solo la parte interactiva como un componente del cliente, se puede reducir el tamaño del paquete en un 90%. Echa un vistazo a la charla de Dana Bramov y al RFC de componentes del servidor para obtener más información.

Y también sabe cómo hacer SelectiveHydration. Si varias partes de la página se están hidratando y el usuario hace clic en una de ellas, entonces React prioriza automáticamente esta parte para ser hidratada y sabe cómo reproducir los clics en esta parte, lo cual es genial. React Server Component también es un cambio de juego. Básicamente significa que si tienes una página en la que la mayor parte está renderizada estáticamente, no necesitas mucho código de interacción, no necesitas React, pero quieres renderizarlo con React. Por ejemplo, solo la calificación del mentor es algo que quieres que sea interactivo. Entonces puedes definir algunas partes de la página como componentes del servidor, y esas partes pueden acceder a la base de datos y agrupar muchas dependencias, pero ninguna de ellas se enviará al cliente. Entonces, si solo defines partes como componentes del servidor y solo tu parte interactiva la defines como componente del cliente, solo este componente del cliente se agrupará y se enviará al navegador, lo que puede reducir el paquete en un 90%, lo cual es asombroso. Hay una buena charla de Dana Bramov al respecto, te recomiendo leer el RFC de componentes del servidor, es muy informativo. No podemos hablar de SSR sin mencionar a Next.js. Next.js se está convirtiendo en la solución de facto para el renderizado SSR de React. Permite tanto la generación de sitios estáticos, por lo que puedes utilizar getStaticProps y luego definir que esta página se renderizará en el momento de la construcción, como el renderizado en el lado del servidor con getServerSideProps y luego el servidor lo renderizará, lo cual es asombroso. Acaba de recibir una actualización para diseños o rutas anidadas, lo que te permite transmitir partes de la página al cliente. Eso va a ser realmente importante. No se puede hablar de Next sin mencionar a Remix, que es el nuevo niño en la ciudad. También es bastante impresionante. Va en una dirección diferente al no enviar mucho JavaScript al cliente, sino confiar en los navegadores nativos para trabajar con la página. También tienen rutas anidadas. De hecho, ya tenían enrutamiento anidado antes. No utilizan los componentes del servidor de React, en realidad tenían una demostración que muestra que son más rápidos que los componentes del servidor de React, lo cual es asombroso. Remix y Next se están convirtiendo en la próxima guerra o debate. Puedes leer muchos tweets al respecto. Algunos dicen que Next es mejor, otros dicen que Remix es mejor, porque se siente como PHP para React. No sé si es un cumplido o no, pero lo es. Es importante recordar que eventualmente necesitas elegir las herramientas correctas para el trabajo y eventualmente convergerá en algo. Lo más importante es recordar que el renderizado en el lado del cliente sigue siendo bastante bueno. No tienes que usar el renderizado en el lado del servidor todo el tiempo, aún puedes hacer renderizado en el lado del cliente. Cliente y servidor no tienen que ser enemigos, podemos trabajar juntos. Si todo esto es demasiado y abrumador y estás diciendo, hey, no puedo entender todo esto, simplemente puedes volver a tu Netflix y elegir un episodio familiar y reconfortante de Hooks, y leer un poco más sobre Hooks. Recuerda, el futuro es increíble, y tú eres increíble, muchas gracias.

Check out more articles and videos

We constantly think of articles and videos that might spark Git people interest / skill us up or help building a stellar career

React Advanced Conference 2023React Advanced Conference 2023
27 min
Simplifying Server Components
Server Components are arguably the biggest change to React since its initial release but many of us in the community have struggled to get a handle on them. In this talk we'll try to break down the different moving parts so that you have a good understanding of what's going on under the hood, and explore the line between React and the frameworks that are built upon it.
React Day Berlin 2023React Day Berlin 2023
21 min
Exploring React Server Component Fundamentals
I've been developing a minimalistic framework for React Server Components (RSC). This talk will share my journey to deeply understand RSC from a technical perspective. I'll demonstrate how RSC features operate at a low level and provide insights into what RSC offers at its core. By the end, you should have a stronger mental model of React Server Components fundamentals.
React Summit 2023React Summit 2023
26 min
Server Components: The Epic Tale of Rendering UX
Server components, introduced in React v18 end these shortcomings, enabling rendering React components fully on the server, into an intermediate abstraction format without needing to add to the JavaScript bundle. This talk aims to cover the following points:1. A fun story of how we needed CSR and how SSR started to take its place2. What are server components and what benefits did they bring like 0 javascript bundle size3. Demo of a simple app using client-side rendering, SSR, and server components and analyzing the performance gains and understanding when to use what4. My take on how rendering UI will change with this approach
React Advanced Conference 2023React Advanced Conference 2023
28 min
A Practical Guide for Migrating to Server Components
Server Components are the hot new thing, but so far much of the discourse around them has been abstract. Let's change that. This talk will focus on the practical side of things, providing a roadmap to navigate the migration journey. Starting from an app using the older Next.js pages router and React Query, we’ll break this journey down into a set of actionable, incremental steps, stopping only when we have something shippable that’s clearly superior to what we began with. We’ll also discuss next steps and strategies for gradually embracing more aspects of this transformative paradigm.

Workshops on related topic

JSNation 2023JSNation 2023
174 min
Developing Dynamic Blogs with SvelteKit & Storyblok: A Hands-on Workshop
Featured WorkshopFree
This SvelteKit workshop explores the integration of 3rd party services, such as Storyblok, in a SvelteKit project. Participants will learn how to create a SvelteKit project, leverage Svelte components, and connect to external APIs. The workshop covers important concepts including SSR, CSR, static site generation, and deploying the application using adapters. By the end of the workshop, attendees will have a solid understanding of building SvelteKit applications with API integrations and be prepared for deployment.
React Day Berlin 2022React Day Berlin 2022
53 min
Next.js 13: Data Fetching Strategies
Top Content
WorkshopFree
- Introduction- Prerequisites for the workshop- Fetching strategies: fundamentals- Fetching strategies – hands-on: fetch API, cache (static VS dynamic), revalidate, suspense (parallel data fetching)- Test your build and serve it on Vercel- Future: Server components VS Client components- Workshop easter egg (unrelated to the topic, calling out accessibility)- Wrapping up
React Advanced Conference 2023React Advanced Conference 2023
153 min
React Server Components Unleashed: A Deep Dive into Next-Gen Web Development
Workshop
Get ready to supercharge your web development skills with React Server Components! In this immersive, 3-hour workshop, we'll unlock the full potential of this revolutionary technology and explore how it's transforming the way developers build lightning-fast, efficient web applications.
Join us as we delve into the exciting world of React Server Components, which seamlessly blend server-side rendering with client-side interactivity for unparalleled performance and user experience. You'll gain hands-on experience through practical exercises, real-world examples, and expert guidance on how to harness the power of Server Components in your own projects.
Throughout the workshop, we'll cover essential topics, including:
- Understanding the differences between Server and Client Components- Implementing Server Components to optimize data fetching and reduce JavaScript bundle size- Integrating Server and Client Components for a seamless user experience- Strategies for effectively passing data between components and managing state- Tips and best practices for maximizing the performance benefits of React Server Components
Workshop level: 
No matter your current level of React expertise, this workshop will equip you with the knowledge and tools to take your web development game to new heights. Don't miss this opportunity to stay ahead of the curve and master the cutting-edge technology that's changing the face of web development. Sign up now and unleash the full power of React Server Components!
React Advanced Conference 2021React Advanced Conference 2021
170 min
Build a Custom Storefront on Shopify with Hydrogen
Workshop
Hydrogen is an opinionated React framework and SDK for building fast, custom storefronts powered Shopify. Hydrogen embraces React Server Components and makes use of Vite and Tailwind CSS. In this workshop participants will get a first look at Hydrogen, learn how and when to use it, all while building a fully functional custom storefront with the Hydrogen team themselves.
React Advanced Conference 2022React Advanced Conference 2022
81 min
Build a Product Page with Shopify’s Hydrogen Framework
WorkshopFree
Get hands on with Hydrogen, a React-based framework for building headless storefronts. Hydrogen is built for Shopify commerce with all the features you need for a production-ready storefront. It provides a quick start, build-fast environment so you can focus on the fun stuff - building unique commerce experiences. In this workshop we’ll scaffold a new storefront and rapidly build a product page. We’ll cover how to get started, file-based routing, fetching data from the Storefront API, Hydrogen’s built-in components and how to apply styling with Tailwind.You will know:- Get started with the hello-world template on StackBlitz- File-based routing to create a /products/example route- Dynamic routing /products/:handle- Hit the Storefront API with GraphQL- Move the query into the Hydrogen app- Update the query to fetch a product by handle- Display title, price, image & description.- Tailwind styling- Variant picker and buy now button- Bonus if there’s time: Collections page
Prerequisites: - A Chromium-based browser (StackBlitz)- Ideally experience with React. A general web development background would be fine.