Trata bien a tus usuarios con Renderizado Segmentado

This ad is not shown to multipass and full ticket holders
JSNation US
JSNation US 2025
November 17 - 20, 2025
New York, US & Online
See JS stars in the US biggest planetarium
Learn More
In partnership with Focus Reactive
Upcoming event
JSNation US 2025
JSNation US 2025
November 17 - 20, 2025. New York, US & Online
Learn more
Bookmark
Slides
Rate this content

Si crees que el renderizado estático se limita a contenido genérico y público que es el mismo para todos los usuarios de tu sitio web, esta charla es para ti. El Renderizado Segmentado es un nuevo patrón para Jamstack que te permite personalizar contenido de forma estática, sin ningún tipo de renderizado del lado del cliente o renderizado del lado del servidor por solicitud. Obtén el mejor rendimiento posible para casos de uso como tematización, internacionalización, pruebas A/B, multiinquilinato y comienza a tratar bien a tus usuarios.

This talk has been presented at React Advanced 2022, check out the latest edition of this React Conference.

FAQ

Eric Burel es el fundador de LBKE, una pequeña empresa en Montpellier, Francia, y desarrollador web. También es el mantenedor de VulcanJS, un framework que inicialmente formaba parte del ecosistema de Meteor.js y ahora utiliza Next.js y GraphQL.

El renderizado segmentado es una técnica de personalización web que permite adaptar el contenido de una página web a las características específicas de cada usuario, como el idioma o el tema visual, mediante el uso de cookies y otros métodos para segmentar y servir contenido dinámico o estático según el usuario.

Según Eric Burel, la personalización se puede implementar utilizando cookies para almacenar información específica del usuario, como la elección de un tema. Luego, esta información es utilizada para adaptar dinámicamente la apariencia y el contenido de la aplicación web según las preferencias del usuario.

Eric Burel menciona tres formas de renderizar en Next.js: renderizado del lado del cliente, del lado del servidor y generación de semillas estáticas. Cada uno tiene sus propios usos y beneficios, siendo elegidos según las necesidades específicas de la aplicación web.

En el contexto del renderizado segmentado, un servidor proxy ligero se utiliza para reescribir URLs basadas en parámetros de cookies o headers sin que el usuario final lo perciba. Esto permite entregar diferentes versiones del contenido de manera eficiente y segura, evitando que los usuarios manipulen parámetros directamente en la URL.

El renderizado segmentado mejora la experiencia del usuario al permitir que el contenido personalizado y estático se sirva rápidamente, reduciendo así el problema de 'clientes ricos y pobres', donde los usuarios no autenticados podrían tener una mejor experiencia de navegación que los autenticados debido a tiempos de carga más rápidos.

Eric Burel
Eric Burel
21 min
24 Oct, 2022

Comments

Sign in or register to post your comment.
Video Summary and Transcription
La charla discute el concepto de renderizado segmentado para la personalización en el desarrollo web. Explora diferentes técnicas de renderizado, incluyendo el renderizado del lado del servidor, la generación estática de semillas y el renderizado dinámico. El problema de los invitados ricos y los clientes pobres se aborda a través del renderizado segmentado. La implementación del renderizado segmentado con Next.js involucra un servidor proxy ligero y la reescritura de URL. La charla también destaca los beneficios del renderizado invisible del lado del servidor y sugiere una futura API unificada para el renderizado del servidor.

1. Introducción

Short description:

Hola a todos y bienvenidos a mi charla, Trata bien a tus usuarios con el renderizado segmentado. Mi nombre es Eric Burel. Soy el fundador de LBKE, una pequeña empresa en Montpellier, Francia. Soy un desarrollador web pero también un consultor en financiamiento público para investigación empresarial. Soy el mantenedor de VulcanJS, un framework que quizás conozcas si vienes del ecosistema de Meteor.js y que ahora se ejecuta en Next.js y GraphQL.

Hola a todos y bienvenidos a mi charla, Trata bien a tus usuarios con el renderizado segmentado.

Primero, permíteme presentarme. Mi nombre es Eric Burel. Soy el fundador de LBKE, una pequeña empresa en Montpellier, Francia. Soy un desarrollador web pero también un consultor en financiamiento público para investigación empresarial. Soy el mantenedor de VulcanJS, un framework que quizás conozcas si vienes del ecosistema de Meteor.js ecosistema y que ahora se ejecuta en Next.js y GraphQL. Soy miembro del Colectivo DevoGraphics creado por Sacha Gref, quien dirige las encuestas State of GS, CSS y GraphQL. Soy responsable en particular del formulario de encuesta donde realmente completas la encuesta y enseño Next.js en Human Coders, una empresa de enseñanza en Francia. Puedes encontrarme en Twitter o en Medium donde publico algunos artículos sobre varios temas, especialmente sobre Next.js y GraphQL.

2. Personalización y Renderizado

Short description:

Voy a hablar sobre personalización y explicar qué es el segmento en el renderizado segmentado. La personalización web incluye ejemplos como la tematización, la internacionalización, el contenido pago versus gratuito y las pruebas A-B. Next.js es un framework que ofrece tres formas de renderizar aplicaciones, incluido el renderizado del lado del cliente.

Voy a hablar sobre personalización para explicar qué es el segmento en el renderizado segmentado. Entonces, ¿qué es la personalización web? Tomemos un ejemplo. Elegir un tema es el ejemplo más básico y más visible de personalización web. Digamos que en mi aplicación tengo tres temas posibles: fuego, agua y hierba, y cada tema cambiará la apariencia de la aplicación. Para implementar la tematización, la mayoría de las veces usaré una cookie. Esto es muy común en la personalización web para almacenar información específica sobre el usuario en una cookie. ¿Por qué? Porque se envían automáticamente junto con cada solicitud y si no son solo HTTP, también están disponibles para el código javascript. Por lo tanto, son muy útiles para mantener información, para saber quién es el usuario. ¿Cuál es su segmento? ¿A qué categoría pertenecen, por ejemplo? Aquí podría tener una cookie llamada `starter` con tres valores posibles: fuego, agua y hierba. Y dependiendo del valor, por supuesto, elijo un tema diferente en la aplicación. Pero no es el único caso de uso. Hay muchos casos de uso de personalización web. Tenemos este mismo caso de uso, pero también la internacionalización. Es un caso de personalización que a veces olvidamos, pero cuando cambiamos el idioma de una aplicación para adaptarlo al idioma del usuario, estamos haciendo lo que llamamos personalización. Estamos optimizando el sitio web y la experiencia del usuario según sus características. El idioma que creemos que hablan o el idioma que seleccionaron en un menú. Esto es personalización. Tener contenido pago versus gratuito también es personalización, especialmente si solo tienes el comienzo de un artículo antes de llegar a un muro de pago. Esto es personalización en el sentido de que los usuarios no pagos tienen una experiencia diferente de los usuarios pagos. Los usuarios pagos tienen su contenido y se invita a los usuarios no pagos a suscribirse. Tienen una experiencia diferente, una experiencia personalizada, y pertenecen a diferentes segmentos: usuarios invitados y usuarios pagos. Las pruebas A-B también son un caso de uso muy importante, tal vez más avanzado, pero si obtienes mucho dinero de un sitio web, probablemente ya hayas configurado pruebas A-B porque te ayuda a probar nuevas versiones de tu sitio web de forma incremental sin afectar toda tu base de datos de usuarios. La mayoría de las veces tenemos dos segmentos que en realidad se llaman buckets en el entorno de pruebas A-B, A y B, y tienes dos versiones diferentes del sitio web A y B según este segmento.

Volvamos a nuestro caso de uso de renderizado de la cosa correcta. Hablemos de Next.js porque Next.js es un framework muy interesante cuando se trata de renderizar porque incorpora tres formas de renderizar aplicaciones. La primera es el renderizado del lado del cliente. Esta es la forma más común de renderizar contenido en aplicaciones modernas de JavaScript, en software como servicio, porque es muy dinámico. Ocurre en el navegador del usuario, por lo que puedes hacer muchos cálculos allí. Solo se utiliza JavaScript del lado del cliente y para obtener datos para llenar el contenido de la página, se utilizarán las funciones incorporadas del navegador, como Fetch, o bibliotecas que se basan en estas funciones incorporadas, como SWR en el ecosistema de Vercell.

3. Técnicas de Renderizado

Short description:

El renderizado del lado del servidor es lo opuesto al renderizado del lado del cliente. La generación de semillas estáticas es un punto intermedio que permite generar múltiples versiones de una página según los parámetros. El renderizado dinámico, como el renderizado del lado del cliente, permite actualizaciones en tiempo real pero requiere más cálculos. La generación estática, aunque no es adaptable a solicitudes individuales, es más rápida y puede ser tentadora para la personalización.

El renderizado del lado del servidor es lo opuesto. Se realiza todo en el servidor para cada solicitud. Esto se asemeja, por ejemplo, a cómo funciona PHP. Cuando haces una solicitud, se accede a una página que es una plantilla. En este punto, el servidor obtendrá algunos datos de la base de datos y llenará la plantilla con los valores correctos, y obtendrás tu página renderizada que se envía tal cual al navegador como HTML puro. Y tienes la generación de semillas estáticas, que se encuentra en el medio, que básicamente es solo renderizado del lado del servidor, pero no emparejado con la solicitud, sino calculado en el momento de la construcción. Es similar de alguna manera a simplemente escribir HTML. Podrías simplemente escribir la página. Pero, por supuesto, sería bastante tonto escribir el contenido directamente. Entonces, la generación de semillas estáticas te permite hacer esto a gran escala. Tienes la misma página y el generador de semillas estáticas puede generar múltiples versiones según algunos parámetros que ingreses, como el idioma, el tema, etc. Se dividen en dos categorías. La primera sería las formas dinámicas de renderizar contenido. El renderizado del lado del cliente y el renderizado del lado del servidor emparejado con la solicitud son dinámicos porque el renderizado del lado del servidor ocurre para cada solicitud. Por lo tanto, los datos pueden actualizarse cada vez que el usuario actualiza el navegador, al menos. El renderizado del lado del cliente es aún más dinámico porque puede ser interactivo, ya que opera en el navegador del usuario. Puede realizar cálculos en cualquier momento. Incluso ni siquiera tiene que comunicarse con el servidor. Entonces, la mayoría de las veces tienes este patrón, este patrón de llamadas a APIs para obtener nuevos datos y renderizar todo en el lado del cliente. Esta es una forma muy jam-stackish de hacer las cosas. La generación de semillas estáticas es, bueno, estática. Porque las cosas se calculan en el momento de la construcción, no pueden evolucionar para cada solicitud porque aún no tienes la solicitud. Nadie ha solicitado tu servidor, simplemente lo estás construyendo e implementando en este punto. Pero es más rápido porque las cosas ya están calculadas y almacenadas en una caché, por lo que no hay nuevos cálculos. El servidor solo tiene que servir el HTML calculado. Y ¿qué usarás para la personalización? Podrías estar tentado de decir patrones dinámicos porque pueden adaptarse a la solicitud porque pueden ocurrir en el navegador del usuario, literalmente en su máquina. Es más fácil adaptarse y personalizar para un usuario preciso, por supuesto. Sin embargo, son más lentos. Necesitan más cálculos. Entonces también tienes la opción de usar la generación estática, pero ¿cómo? Es más rápido, por lo que es

4. Renderizado Segmentado para Clientes Ricos

Short description:

El uso de renderizado dinámico y más lento para contenido personalizado crea un problema de clientes ricos y pobres. Los visitantes no pagados y los usuarios invitados reciben renders estáticos más rápidos, mientras que los clientes autenticados con contenido personalizado experimentan un renderizado más lento. El renderizado segmentado aborda este problema al permitir renders estáticos para contenido personalizado.

tentador. Pero ¿cómo? Nuevamente, dado que no se mueve, ¿cómo lo haces? Y el uso sistemático de la solución dinámica y más lenta conduce a un problema que llamo el problema de clientes ricos y pobres. Utilizarás los renders estáticos más rápidos solo para contenido público, para contenido que está disponible para cualquier persona que navegue por la web. Por lo tanto, visitantes no pagados, usuarios invitados, así como usuarios conectados. Y utilizarás los renders dinámicos más lentos para contenido personalizado. Utilizarás el tiempo de CPU de los usuarios si haces renderizado del lado del cliente. Tendrás una computación más lenta en el backend si haces solicitudes emparejadas con el renderizado del lado del servidor. Básicamente, tus clientes autenticados que reciben contenido personalizado basado en sus propios datos personales tienen el patrón más pobre, el patrón más lento. Ellos son clientes pobres, mientras que los invitados que a menudo proporcionan menos valor en el sitio web porque no están conectados, no los conoces, no puedes dirigirte a ellos, no son clientes, tienen la mejor experiencia. Son clientes ricos. Este es el problema de clientes ricos y pobres. Y el renderizado segmentado es una forma de reducir este problema al permitir renders estáticos para contenido personalizado y tener clientes ricos.

5. Personalización Estática y Servidor Proxy

Short description:

Hablemos sobre la personalización estática utilizando patrones de renderizado segmentado. La implementación más sencilla es tener una URL por segmento, una URL por elección de tema para los usuarios. Pero esto conlleva algunos problemas. Los usuarios no deberían poder saber en qué segmento se encuentran. La URL puede volverse larga y fea. Para resolver este problema, introduzcamos un servidor proxy simple y ligero.

Entonces hablemos sobre la personalización estática utilizando patrones de renderizado segmentado. Hagamos un primer intento, intentemos utilizar la URL para personalizar el contenido de forma estática. Es muy fácil porque la mayoría de los generadores de semillas estáticas se basan en la URL, ya sea Next.js, Gatsby, Astro, y así sucesivamente. Les proporcionas URLs para renderizar y, dependiendo del parámetro, buscarán los datos correctos y renderizarán la página en consecuencia. Así es como funcionan. Por lo tanto, la implementación más sencilla es tener una URL por segmento, una URL por elección de tema para los usuarios. Entonces los usuarios que eligieron el tema de fuego tendrán una versión, los que eligieron el tema de agua tendrán otra versión, y los que eligieron el tema de hierba tendrán otra versión. Pero esto conlleva algunos problemas. Primero, el usuario puede cambiar la URL. Está bien para un tema, está bien para un idioma. Incluso es una característica en cierto sentido para un idioma. Puedes cambiar el idioma de la página simplemente cambiando la URL. Pero es un problema si comienzas a hacer personalización con contenido de pago. No quieres que los usuarios cambien la URL para convertirse repentinamente en usuarios de pago. Preferirías que paguen por algo. Luego, el usuario puede ver el parámetro. Nuevamente, no es un problema para un idioma, incluso es algo bueno para un idioma porque permite compartir la URL con otras personas que hablan el mismo idioma y así obtienen el contenido correcto. Pero para una prueba A-B, eso es un gran problema. Los usuarios no deberían poder saber en qué segmento se encuentran. De lo contrario, estarías sesgando drásticamente la prueba A-B. Esto conlleva muchos problemas y los datos simplemente ya no son válidos. Por lo tanto, no deberían ver el parámetro en este caso. Y finalmente, la URL puede volverse larga y fea. Si tienes muchos parámetros, terminarás con el idioma, el tema oscuro o claro, el inquilino, la empresa, la organización a la que pertenecen los usuarios. Si estás haciendo negocios a nivel empresarial, es muy común tener multiarrendamiento. Tener múltiples empresas que utilizan tu aplicación con muchos usuarios por empresa. Tendrás el segmento de prueba A-B, que no es bueno, contenido de pago, y así sucesivamente. Tendrás URLs muy largas y feas. Entonces, para resolver este problema, esta limitación, introduzcamos una nueva pieza en nuestra arquitectura. Introduzcamos un servidor proxy simple y ligero.

6. Servidor Proxy y Reescritura de URL

Short description:

El servidor proxy reescribe la URL en función del segmento, haciéndola invisible para el usuario y protegiéndola de ser modificada. La longitud y apariencia de la URL ya no son un problema, y existen patrones avanzados para comprimir parámetros si es necesario.

El papel de este servidor proxy será tomar la solicitud HTTP que llega al servidor y reescribir la URL, dependiendo del segmento. Insisto en la palabra reescribir la URL, y no redirigir la URL. Una reescritura de URL no es visible para el usuario final, y esa es la diferencia clave, porque resuelve todos nuestros problemas con la URL de una vez. El usuario ya no puede ver el parámetro. El usuario ya no puede cambiar el parámetro, porque está protegido por el servidor, se calcula en el lado del servidor. Por lo tanto, el usuario no puede manipularlo simplemente cambiando los valores del navegador. Y finalmente, el hecho de que la URL sea larga y fea ya no es un problema, porque los usuarios ya no la ven. Puedes alcanzar la limitación de 255 caracteres para la URL, pero en la práctica esto nunca sucederá realmente. Y aún así tenemos más, incluso más patrones avanzados para solucionar eso. Está vinculado en el recurso y se llama Megaparam patrones. Básicamente, puedes codificar los parámetros para comprimirlos. Así que hay una solución incluso para este ligero

7. Renderizado Segmentado y Reescritura de URL

Short description:

Para resolver nuestro problema, convertimos la cookie en un parámetro de URL compatible con los frameworks existentes. Esto se llama renderizado segmentado, donde cada variación tiene una URL única. Por ejemplo, para la internacionalización, se puede utilizar el encabezado de aceptación de idioma para reescribir la URL al idioma correcto, eliminando la necesidad de un parámetro de idioma explícito. Los usuarios pueden cambiar el idioma utilizando una cookie invisible en lugar de un parámetro de URL visible.

limitación. Entonces, para resolver nuestro problema, tenemos una solicitud HTTP con la cookie fire y convertimos eso en un parámetro de URL fire, que es compatible con la forma en que funcionan los frameworks existentes porque Gatsby, NEFGS podrán renderizar contenido estáticamente siempre que la URL para cada variación sea única. Esto es lo que llamamos renderizado segmentado. Esta es una receta con dos ingredientes teniendo una URL por segmento. Así es como funciona el renderizado estático. Si genera múltiples variaciones de su sitio web estáticamente, ya está haciendo esto, pero el truco es usar un pequeño servidor de reescritura de URL para redirigir a la URL correcta según otros parámetros de la solicitud como las cookies o los encabezados. Si tomo otro ejemplo con internacionalización, podría usar el encabezado de aceptación de idioma y reescribir la URL al idioma correcto. Esto eliminaría la necesidad de tener un parámetro de idioma explícito. Aún necesita una forma para que los usuarios cambien el idioma, pero podría hacerlo utilizando una cookie que sea invisible en lugar de usar un parámetro de URL que sea visible y en algunos escenarios podría ser feo.

8. Implementación con Next.js

Short description:

Veamos una implementación con Next.js. Nuestra aplicación utiliza el renderizado segmentado para permitir a los usuarios elegir un tema. El tema se almacena en una cookie, lo que proporciona personalización sin alterar la URL. La página se renderiza estáticamente con el tema elegido y la respuesta del servidor confirma el tema correcto. La implementación involucra la generación estática de semillas y la regeneración estática incremental para mayor flexibilidad. El middleware, un servidor proxy ligero, lee la cookie del tema y escribe la URL. Esto logra el renderizado segmentado sin necesidad de un parámetro raíz.

Ok, esto puede sonar un poco abstracto. Ahora veamos una implementación con Next.js que es muy interesante porque permite que Next.js incorpore el concepto de middlewares de borde que son exactamente eso. El servidor proxy que necesitamos para implementar el renderizado segmentado. Ellos lo proporcionan de forma nativa. Así que aquí está nuestra aplicación utilizando el renderizado segmentado. Es una aplicación de Next.js que me permite elegir un tema: fuego, agua o hierba. Ok, elijamos el tema de fuego. Verás que cambia el color como se esperaba. La parte interesante es que no altera la URL. Primero, si voy a la aplicación y reviso las cookies, veré que estoy utilizando la cookie de tema llamada 'fire' en lugar de usar un parámetro raíz. Estoy utilizando una cookie, que es la forma correcta de hacer personalización en muchos escenarios. El segundo hecho interesante es que si recargo la página, obtendré la versión temática de inmediato. Por supuesto, todo esto se renderiza estáticamente, así que por ejemplo, si voy a la red y reviso la respuesta del servidor para la solicitud html, veré mi contenido con el tema correcto. Aquí no he configurado el CSS para el renderizado en el servidor, pero puedo ver el tema de fuego en el html. Así que estoy utilizando el renderizado estático. Esto se calcula en el lado del servidor avanzado, no hay cálculos en el lado del cliente.

En cuanto a la implementación, la primera parte es simplemente una página con generación estática de semillas como encontrarías en cualquier aplicación de Next.js utilizando 'getStaticPaths' y 'getStaticProps' como de costumbre. Genero diferentes versiones de la página dependiendo del parámetro de tema. Observa que estoy utilizando la regeneración estática incremental, que es solo un patrón en Next para entender cómo manejar el caso en el que tengo muchos temas. Por ejemplo, aquí no estoy pre-renderizando el tema verde porque tal vez es menos solicitado por las personas y no quiero tener un tiempo de compilación muy largo, por lo que solo se calculará en la primera solicitud. Tenemos mucha flexibilidad con este enfoque. Y luego, por supuesto, renderizo mi página en función de este parámetro. Esto es muy común si usas Next.js o cualquier otro framework de renderizado estático, estarás acostumbrado a este enfoque. Pero la parte más importante es el middleware. Este es mi servidor proxy. Y cuando digo pequeño y ligero, no estoy bromeando. Son 25 líneas con muchos comandos. Lo que hace es leer las cookies. Si es un tema válido, escribirá la URL. Así de simple. Así es como obtengo el renderizado segmentado, renderizado estático con personalización sin

9. Renderizado en el servidor invisible y el futuro

Short description:

Esta parte discute la seguridad y los beneficios del renderizado en el servidor invisible para temas personalizados. También menciona el ejemplo de implementación y el uso del renderizado segmentado en el borde. La conclusión destaca la importancia del almacenamiento en caché en el renderizado en el servidor y sugiere una API unificada futura para el renderizado en el servidor.

El uso de un parámetro raíz. Esto es invisible para el usuario y es seguro porque ocurre en el lado del servidor. No puedo permitir que el usuario elija un tema que no existe, por ejemplo. Solo pueden seleccionar fuego, agua, hierba o ninguno. De lo contrario, lanzo un error. Esto es seguro. Es excelente para contenido de pago, por ejemplo, pruebas A-B. Finalmente, solo un detalle, pero eso es opcional, he agregado cierta lógica para cambiar el tema basado en una cookie utilizando una raíz de API. Entonces, estoy utilizando el encabezado HTTP de configuración de cookie, pero podrías hacer lo mismo en el lado del cliente, por supuesto. Volvamos a mis diapositivas. Ahora tienes un ejemplo de implementación, y en Vercel, es posible que haya una terminología diferente. No lo llamarán renderizado segmentado. Lo llamarán personalización en el borde. Y en realidad, es la traducción de Vercel de este patrón. Es lo mismo, excepto que Vercel te permite tener renderizado segmentado en el borde utilizando su red de borde. Pero es básicamente la misma idea. Breve conclusión. ¿Cuál es el futuro del renderizado en el servidor? Creo que el futuro del renderizado en el servidor es comprender que todo se trata del almacenamiento en caché. Lo estático es el renderizado en el servidor almacenado en caché en el momento de la compilación. El renderizado en el servidor por solicitud es simplemente una falta de caché en el mismo patrón. La clave de caché no es solo la URL, sino la solicitud completa. Esta es la idea detrás del renderizado segmentado, utilizar la solicitud y no solo la URL. Y el valor es, por supuesto, el HTML renderizado o los datos. Depende del patrón. El renderizado estático diferido de Gatsby, por ejemplo, desvincula ambos y Next.js siempre los considera como un todo. Están muy relacionados en Next, pero de cualquier manera, ese es el valor de caché. Entonces, mi opinión es que en el futuro, tendremos una API unificada para el renderizado en el servidor que abarque el renderizado estático, por solicitud y todo lo que haya en el medio. Y hasta entonces, tenemos el renderizado segmentado. Gracias por su atención y nos vemos más tarde.

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

Una Guía del Comportamiento de Renderizado de React
React Advanced 2022React Advanced 2022
25 min
Una Guía del Comportamiento de Renderizado de React
Top Content
This transcription provides a brief guide to React rendering behavior. It explains the process of rendering, comparing new and old elements, and the importance of pure rendering without side effects. It also covers topics such as batching and double rendering, optimizing rendering and using context and Redux in React. Overall, it offers valuable insights for developers looking to understand and optimize React rendering.
Escalando con Remix y Micro Frontends
Remix Conf Europe 2022Remix Conf Europe 2022
23 min
Escalando con Remix y Micro Frontends
Top Content
This talk discusses the usage of Microfrontends in Remix and introduces the Tiny Frontend library. Kazoo, a used car buying platform, follows a domain-driven design approach and encountered issues with granular slicing. Tiny Frontend aims to solve the slicing problem and promotes type safety and compatibility of shared dependencies. The speaker demonstrates how Tiny Frontend works with server-side rendering and how Remix can consume and update components without redeploying the app. The talk also explores the usage of micro frontends and the future support for Webpack Module Federation in Remix.
Construyendo Mejores Sitios Web con Remix
React Summit Remote Edition 2021React Summit Remote Edition 2021
33 min
Construyendo Mejores Sitios Web con Remix
Top Content
Remix is a web framework built on React Router that focuses on web fundamentals, accessibility, performance, and flexibility. It delivers real HTML and SEO benefits, and allows for automatic updating of meta tags and styles. It provides features like login functionality, session management, and error handling. Remix is a server-rendered framework that can enhance sites with JavaScript but doesn't require it for basic functionality. It aims to create quality HTML-driven documents and is flexible for use with different web technologies and stacks.
Compilador React Forget - Entendiendo React Idiomático
React Advanced 2023React Advanced 2023
33 min
Compilador React Forget - Entendiendo React Idiomático
Top Content
Joe Savona
Mofei Zhang
2 authors
The Talk discusses React Forget, a compiler built at Meta that aims to optimize client-side React development. It explores the use of memoization to improve performance and the vision of Forget to automatically determine dependencies at build time. Forget is named with an F-word pun and has the potential to optimize server builds and enable dead code elimination. The team plans to make Forget open-source and is focused on ensuring its quality before release.
Uso efectivo de useEffect
React Advanced 2022React Advanced 2022
30 min
Uso efectivo de useEffect
Top Content
Today's Talk explores the use of the useEffect hook in React development, covering topics such as fetching data, handling race conditions and cleanup, and optimizing performance. It also discusses the correct use of useEffect in React 18, the distinction between Activity Effects and Action Effects, and the potential misuse of useEffect. The Talk highlights the benefits of using useQuery or SWR for data fetching, the problems with using useEffect for initializing global singletons, and the use of state machines for handling effects. The speaker also recommends exploring the beta React docs and using tools like the stately.ai editor for visualizing state machines.
Acelerando tu aplicación React con menos JavaScript
React Summit 2023React Summit 2023
32 min
Acelerando tu aplicación React con menos JavaScript
Top Content
Mishko, the creator of Angular and AngularJS, discusses the challenges of website performance and JavaScript hydration. He explains the differences between client-side and server-side rendering and introduces Quik as a solution for efficient component hydration. Mishko demonstrates examples of state management and intercommunication using Quik. He highlights the performance benefits of using Quik with React and emphasizes the importance of reducing JavaScript size for better performance. Finally, he mentions the use of QUIC in both MPA and SPA applications for improved startup performance.

Workshops on related topic

Masterclass de Depuración de Rendimiento de React
React Summit 2023React Summit 2023
170 min
Masterclass de Depuración de Rendimiento de React
Top Content
Featured Workshop
Ivan Akulov
Ivan Akulov
Los primeros intentos de Ivan en la depuración de rendimiento fueron caóticos. Vería una interacción lenta, intentaría una optimización aleatoria, vería que no ayudaba, y seguiría intentando otras optimizaciones hasta que encontraba la correcta (o se rendía).
En aquel entonces, Ivan no sabía cómo usar bien las herramientas de rendimiento. Haría una grabación en Chrome DevTools o React Profiler, la examinaría, intentaría hacer clic en cosas aleatorias, y luego la cerraría frustrado unos minutos después. Ahora, Ivan sabe exactamente dónde y qué buscar. Y en esta masterclass, Ivan te enseñará eso también.
Así es como va a funcionar. Tomaremos una aplicación lenta → la depuraremos (usando herramientas como Chrome DevTools, React Profiler, y why-did-you-render) → identificaremos el cuello de botella → y luego repetiremos, varias veces más. No hablaremos de las soluciones (en el 90% de los casos, es simplemente el viejo y regular useMemo() o memo()). Pero hablaremos de todo lo que viene antes - y aprenderemos a analizar cualquier problema de rendimiento de React, paso a paso.
(Nota: Esta masterclass es más adecuada para ingenieros que ya están familiarizados con cómo funcionan useMemo() y memo() - pero quieren mejorar en el uso de las herramientas de rendimiento alrededor de React. Además, estaremos cubriendo el rendimiento de la interacción, no la velocidad de carga, por lo que no escucharás una palabra sobre Lighthouse 🤐)
Next.js para Desarrolladores de React.js
React Day Berlin 2023React Day Berlin 2023
157 min
Next.js para Desarrolladores de React.js
Top Content
Featured WorkshopFree
Adrian Hajdin
Adrian Hajdin
En esta avanzada masterclass de Next.js, profundizaremos en conceptos clave y técnicas que permiten a los desarrolladores de React.js aprovechar al máximo Next.js. Exploraremos temas avanzados y prácticas prácticas, equipándote con las habilidades necesarias para construir aplicaciones web de alto rendimiento y tomar decisiones arquitectónicas informadas.
Al final de esta masterclass, serás capaz de:1. Comprender los beneficios de los Componentes del Servidor React y su papel en la construcción de aplicaciones React interactivas, renderizadas por el servidor.2. Diferenciar entre el tiempo de ejecución de Edge y Node.js en Next.js y saber cuándo usar cada uno en función de los requisitos de tu proyecto.3. Explorar técnicas avanzadas de Renderizado del Lado del Servidor (SSR), incluyendo streaming, fetching paralelo vs. secuencial, y sincronización de datos.4. Implementar estrategias de caché para mejorar el rendimiento y reducir la carga del servidor en las aplicaciones Next.js.5. Utilizar Acciones React para manejar la mutación compleja del servidor.6. Optimizar tus aplicaciones Next.js para SEO, compartir en redes sociales, y rendimiento general para mejorar la descubrabilidad y la participación del usuario.
Aventuras de Renderizado Concurrente en React 18
React Advanced 2021React Advanced 2021
132 min
Aventuras de Renderizado Concurrente en React 18
Top Content
Featured Workshop
Maurice de Beijer
Maurice de Beijer
Con el lanzamiento de React 18 finalmente obtenemos el tan esperado renderizado concurrente. Pero, ¿cómo va a afectar eso a tu aplicación? ¿Cuáles son los beneficios del renderizado concurrente en React? ¿Qué necesitas hacer para cambiar al renderizado concurrente cuando actualices a React 18? ¿Y qué pasa si no quieres o no puedes usar el renderizado concurrente todavía?

¡Hay algunos cambios de comportamiento de los que debes estar al tanto! En esta masterclass cubriremos todos esos temas y más.

Acompáñame con tu portátil en esta masterclass interactiva. Verás lo fácil que es cambiar al renderizado concurrente en tu aplicación React. Aprenderás todo sobre el renderizado concurrente, SuspenseList, la API startTransition y más.
Consejos sobre React Hooks que solo los profesionales conocen
React Summit Remote Edition 2021React Summit Remote Edition 2021
177 min
Consejos sobre React Hooks que solo los profesionales conocen
Top Content
Featured Workshop
Maurice de Beijer
Maurice de Beijer
La adición de la API de hooks a React fue un cambio bastante importante. Antes de los hooks, la mayoría de los componentos tenían que ser basados en clases. Ahora, con los hooks, estos son a menudo componentes funcionales mucho más simples. Los hooks pueden ser realmente simples de usar. Casi engañosamente simples. Porque todavía hay muchas formas en las que puedes equivocarte con los hooks. Y a menudo resulta que hay muchas formas en las que puedes mejorar tus componentes con una mejor comprensión de cómo se puede usar cada hook de React.Aprenderás todo sobre los pros y los contras de los diversos hooks. Aprenderás cuándo usar useState() versus useReducer(). Veremos cómo usar useContext() de manera eficiente. Verás cuándo usar useLayoutEffect() y cuándo useEffect() es mejor.
Presentando FlashList: Construyamos juntos una lista performante en React Native
React Advanced 2022React Advanced 2022
81 min
Presentando FlashList: Construyamos juntos una lista performante en React Native
Top Content
Featured Workshop
David Cortés Fulla
Marek Fořt
Talha Naqvi
3 authors
En esta masterclass aprenderás por qué creamos FlashList en Shopify y cómo puedes usarlo en tu código hoy. Te mostraremos cómo tomar una lista que no es performante en FlatList y hacerla performante usando FlashList con mínimo esfuerzo. Usaremos herramientas como Flipper, nuestro propio código de benchmarking, y te enseñaremos cómo la API de FlashList puede cubrir casos de uso más complejos y aún así mantener un rendimiento de primera categoría.Sabrás:- Breve presentación sobre qué es FlashList, por qué lo construimos, etc.- Migrando de FlatList a FlashList- Enseñando cómo escribir una lista performante- Utilizando las herramientas proporcionadas por la biblioteca FlashList (principalmente el hook useBenchmark)- Usando los plugins de Flipper (gráfico de llamas, nuestro perfilador de listas, perfilador de UI & JS FPS, etc.)- Optimizando el rendimiento de FlashList utilizando props más avanzados como `getType`- 5-6 tareas de muestra donde descubriremos y solucionaremos problemas juntos- Preguntas y respuestas con el equipo de Shopify
React, TypeScript y TDD
React Advanced 2021React Advanced 2021
174 min
React, TypeScript y TDD
Top Content
Featured Workshop
Paul Everitt
Paul Everitt
ReactJS es extremadamente popular y, por lo tanto, ampliamente soportado. TypeScript está ganando popularidad y, por lo tanto, cada vez más soportado.

¿Los dos juntos? No tanto. Dado que ambos cambian rápidamente, es difícil encontrar materiales de aprendizaje precisos.

¿React+TypeScript, con los IDEs de JetBrains? Esa combinación de tres partes es el tema de esta serie. Mostraremos un poco sobre mucho. Es decir, los pasos clave para ser productivo, en el IDE, para proyectos de React utilizando TypeScript. En el camino, mostraremos el desarrollo guiado por pruebas y enfatizaremos consejos y trucos en el IDE.