Una Saga de Problemas de Renderizado Web

Rate this content
Bookmark

Esta charla analizará la evolución de los modos de renderizado web y de qué se trata el movimiento Jamstack. Construiremos un proyecto de demostración para mostrar cómo se pueden combinar un generador de sitios estáticos y un CMS sin cabeza para crear historias dinámicas y atractivas, manteniendo al mismo tiempo los beneficios de rendimiento y escalabilidad de un sitio estático.

Aprenderás sobre las ventajas y limitaciones de cada modo de renderizado y obtendrás una comprensión más profunda de cómo utilizar Jamstack para construir experiencias de narración poderosas y dinámicas.

28 min
12 May, 2023

Video Summary and Transcription

Esta charla analiza los problemas que se enfrentan al construir y renderizar aplicaciones web, los diferentes métodos y estrategias de renderizado, y los beneficios de la arquitectura Yamstack. Cubre el renderizado en el lado del servidor, la generación de sitios estáticos, la regeneración estática incremental y el renderizado en el borde. El orador demuestra cómo construir un sitio estático utilizando un CMS Hello y la arquitectura JAMstack. Otros temas incluyen la conexión de Storyboard con una aplicación Nuxt, datos simulados, renderizado híbrido y manejo de I18N con un generador de sitios estáticos.

Available in English

1. Introducción a los Métodos y Estrategias de Renderizado

Short description:

En esta charla, discutiré los problemas que enfrentamos al construir y renderizar aplicaciones web, los diferentes métodos y estrategias de renderizado utilizados, y los beneficios de la arquitectura Yamstack. También demostraré cómo construir un sitio estático con un Hello CMS en solo dos minutos. La historia de los métodos de renderizado comienza con la hospedaje de archivos estáticos y gradualmente incorporando servidores y tecnologías de backend. Los frameworks como Vue, React, Asphalt y Angular introdujeron el renderizado del lado del cliente, donde el sitio web se renderiza en el navegador del usuario utilizando JavaScript. Este enfoque ofrece ahorro de costos, una mejor experiencia de usuario y un mejor soporte sin conexión. Sin embargo, tiene desventajas como una mala experiencia en la primera carga, problemas de accesibilidad y desafíos con la optimización para motores de búsqueda. A pesar de estos desafíos, los rastreadores de búsqueda ahora pueden renderizar sitios basados en JavaScript.

Entonces, hola a todos. Estoy muy contento de estar aquí y espero que disfruten la charla que daré hoy. Mi objetivo principal hoy es contarles todos los problemas que enfrentamos al construir sitios, al renderizar nuestras aplicaciones web, que terminamos teniendo una variedad de métodos de renderizado web para usar en la actualidad, y les mostraré la historia detrás de ellos. Entonces, lo principal que quiero que se lleven de esta charla es una visión general de los métodos y estrategias de renderizado que usamos en la actualidad para renderizar aplicaciones JavaScript, comprender en qué consiste la arquitectura Yamstack y los beneficios que conlleva. Y aprender cómo construir un sitio estático con un Hello CMS en solo dos minutos. Así que esta historia puede comenzar con otro personaje principal que no sea el sitio web. Hemos estado construyendo sitios web durante mucho tiempo, casi tanto como yo, y comenzamos simplemente hospedando algunos archivos estáticos en la nube, y después de un tiempo, comenzamos a crear servidores con PHP u otras tecnologías de backend, y comenzamos a combinarlos para tener una mejor aplicación con más datos en ella y no solo un archivo estático. Pero los desarrolladores del ecosistema JavaScript comenzaron a decidir que tal vez queremos tener aplicaciones más interactivas que ayuden al usuario final a interactuar con algo, como un formulario o algo más sofisticado. Así es cuando los frameworks como Vue, React, Asphalt o Angular comenzaron a crear nuevos métodos. Y este fue el renderizado del lado del cliente. Básicamente, el sitio web ahora se renderiza en el navegador, básicamente en el dispositivo del usuario final, lo que llamamos el cliente, utilizando JavaScript. Entonces, cuando un usuario ingresa a su sitio, descargará un esqueleto HTML que proporciona una URL a un script, una carga útil que descargarán y ejecutarán para renderizar su aplicación. Básicamente, ahora tiene un proceso que renderizará la aplicación dentro de la computadora portátil de su usuario. Los beneficios de usar este método son bastante obvios, es más económico porque no tenemos ningún servidor, todo se hace en el cliente a través de JavaScript. Tenemos una mejor experiencia de usuario en la aplicación, porque ahora cuando navegan ya tienen todo desde la primera carga. Y cuando navegan entre páginas, solo verán algunas cargas y recuperaremos algunos datos de las APIs. Así es como trabajamos. Y luego tendremos un mejor soporte sin conexión, si capturamos todo en el navegador del usuario, porque no tenemos ninguna llamada a la API, imagina que solo tienes una aplicación con algunas cosas, luego tendrán todo sin conexión a Internet. Pero, ¿qué sucedió? Por supuesto, cada método de renderizado que veremos tendrá algunas desventajas. El primero fue la mala experiencia en la primera carga. Entonces, cuando descargas el sitio web por primera vez, si no tienes la división de código y tienes todo en una carga grande, tomará mucho tiempo cargar solo una página. No era óptimo para un uso a largo plazo. El otro punto al que nos enfrentamos fue la accesibilidad. Si algunas personas tenían JavaScript deshabilitado en el navegador porque algunas personas lo hacen, suena extraño en la actualidad, pero hay muchas personas que intentan navegar sin JavaScript. Entonces, este no era un método de renderizado si nuestros usuarios no tenían JavaScript habilitado. Pero el verdadero problema en esta historia fue el villano, la optimización para motores de búsqueda, el SEO. Básicamente, los rastreadores de búsqueda cuando los clientes están renderizando aquí arriba, no tienen el tiempo adecuado para esperar a que el JavaScript renderice su sitio. Entonces, en la primera interacción, no ven ningún contenido allí. Eso fue un problema. Y, por supuesto, hoy en día ellos

2. Renderizado del lado del servidor y Generación de sitios estáticos

Short description:

El renderizado del lado del servidor permite enviar HTML prellenado al usuario, mejorando el rendimiento, el SEO y la seguridad. Sin embargo, las conexiones lentas y la carga del servidor pueden ser desafíos. La generación de sitios estáticos resuelve estos problemas al generar páginas durante el tiempo de compilación y almacenarlas en una CDN.

lo cambió y ahora pueden renderizar nuestro sitio en los rastreadores de búsqueda. Pero, ¿qué sucedió? No esperarán para siempre. Entonces, si tu rendimiento no está bien, no esperarán a que se renderice tu página y no se indexará en los motores de búsqueda. Entonces, ¿cuál fue la solución a esto? Nuestro próximo héroe, el renderizado del lado del servidor. El renderizado del lado del servidor comenzó con NAX, NAX, y todos estos meta-frameworks que están por encima de los frameworks que usamos. Y básicamente se trata de renderizar el HTML de nuestra página web en el servidor antes de enviarlo al usuario final. Entonces, ahora cuando descargamos una página al ingresar una URL, descargaremos el HTML prellenado al principio. Y lo que hacen estos frameworks es simplemente crear una aplicación universal que, en segundo plano, también descargará el JavaScript y lo ejecutará para volver a renderizar tu página mientras navegas. Entonces, obtienes los beneficios del renderizado del lado del cliente, pero la carga inicial será realmente eficiente. Y ese es uno de los beneficios. Mejoramos el rendimiento en la carga inicial porque básicamente tenemos el HTML prellenado. Tenemos un mejor SEO porque ahora los motores de búsqueda no necesitan esperar mucho tiempo para que se cargue la página porque es solo la primera página. Y luego, mejoramos la seguridad porque todo lo que necesitamos llamar a las APIs, los tokens de API estarán en el servidor, por lo que no necesitas tener los tokens de API en tu cliente. Eso es realmente genial. Pero, ¿qué sucede con esto? Por supuesto, si estábamos usando el renderizado del lado del servidor en tiempos antiguos, no teníamos la interactividad que tenemos hoy en día con la aplicación universal que proporciona Next y Next. Pero hoy en día, eso ya no es un problema. El problema es que tenemos conexiones malas y lentas. Entonces, básicamente, si estás en Nigeria y tu servidor de datos está en América, tendrás, realmente, una mala métrica para el tiempo de primer byte, el Core Web Vital. Entonces, básicamente, tomará mucho tiempo cargar para algunas personas, así que eso no es bueno. Pero el verdadero villano aquí fue el aumento de la carga del servidor. Ahora, exige más rendimiento a los servidores para generar el HTML porque ellos son los encargados de eso. Y el número de servidores era mucho mayor porque ahora cada vez que un usuario ingresa a tu sitio por primera vez, llamarán al servidor, y eso significa dinero para el negocio. Entonces, si no tienes un sitio web que tenga datos reales o tal vez algo que esté cambiando con el tiempo, tal vez no quieras esta solución porque no está hecha para tu sitio. Imagina un editor o un periódico. Tal vez solo tengan contenido estático. Ahí es donde entra en juego el próximo héroe. Entonces, básicamente, ahora tenemos una generación de sitios estáticos. Un generador de sitios estáticos genera páginas durante el tiempo de compilación. Entonces, cuando desarrollamos nuestro código y lo enviamos a nuestra nube, básicamente, ejecutamos un proceso que generará la página y esa página se almacenará en caché y se guardará en la CDN. La CDN es una red de entrega de contenido que está cerca del usuario final. Tiene múltiples nodos en todo el mundo.

3. Métodos de Renderizado y Tiempo de Construcción

Short description:

Este método de renderizado ofrece un rendimiento rápido, ahorro de costos, mejor SEO y mayor seguridad. Sin embargo, carece de interactividad y no es adecuado para la autorización de usuarios o el procesamiento de datos. La principal desventaja es el tiempo de construcción requerido para los generadores de sitios estáticos. Gatsby introdujo el primer método de generación de sitios, que genera páginas importantes y renderiza dinámicamente otras para un rendimiento óptimo.

La CDN es una red de entrega de contenido que está cerca del usuario final. Y así es como obtendrás la página. Simplemente llamando a la CDN y recuperando esa página prellenada. Y los beneficios de usar este método de renderizado son un rendimiento rápido. Porque tienes, por supuesto, una red de entrega de contenido. Es económico porque al final solo estás guardando archivos estáticos. Es mejor para el SEO porque la primera vez que llamas a una página web, recuperará la página prellenada. Y mejora la seguridad porque todo se realiza en el tiempo de construcción. Por lo tanto, no habrá servidores que puedan filtrar información o llamadas a API en el cliente. Por lo tanto, es realmente seguro. Y es escalable y fácil de mantener porque los proveedores de alojamiento solo están abriendo el ancho de banda si más usuarios intentan acceder a tu sitio. Pero con esta metodología, por supuesto, no tenemos la interactividad que queremos. Hoy en día, tal vez podamos usar funciones sin servidor o sí, agregar algo de código con JavaScript y tener una aplicación del lado del cliente dentro del sitio estático, pero ese no es el objetivo principal de este método de renderizado. Y otro punto que enfrentamos fue la autorización de usuarios o el procesamiento de datos porque si queremos tener algún tipo de administrador con un sitio estático, esto no estaba pensado para eso. Pero el verdadero villano fue el tiempo de construcción. Entonces, básicamente, la verdadera desventaja de los generadores de sitios estáticos es el tiempo total que lleva construir completamente tu sitio. Porque cuando construyes tu sitio, no construyes la página que acabas de crear o el artículo que acabas de publicar. Construyes todo el sitio nuevamente. Cada vez que cambias algo, construirás nuevamente todo el sitio completo. ¿Qué sucedió? Por ejemplo, en mi blog, solo tengo 20 artículos, ¿de acuerdo? Tomará un minuto. Pero si tienes 5,000, tomará media hora esperar para implementar un artículo al día. Entonces, eso fue el problema que enfrentamos, que creamos un nuevo método de renderizado. Y el siguiente fue creado solo por Gatsby, en realidad. Y se llama generación de sitios estáticos de primera. Básicamente, genera solo las páginas más importantes de tu sitio y las demás que no son tan importantes para el SEO o para los motores de búsqueda. Entonces, básicamente, cuando un usuario va a tu sitio web, buscará en la nube y dirá, de acuerdo, tengo esta página en caché. Serviré esa. Si no, irá al trabajador en la nube. Ejecutará el proceso de renderizar tu aplicación. Enviar en tiempo real esa página y guardarla en la caché para más tarde. Entonces, el próximo usuario tendrá esa versión en caché y

4. Incremental Static Regeneration

Short description:

Ahora tenemos menos tiempo de construcción porque solo construimos páginas importantes. Mantenemos los beneficios de la generación de sitios estáticos para SEO y rendimiento. Next introdujo la regeneración estática incremental, que muestra solo las partes cambiadas de un sitio web. Esta técnica nos permite admitir datos dinámicos en sitios estáticos y proporciona tiempos de respuesta más rápidos. Sin embargo, al principio tenía un soporte limitado y no era consistente para actualizaciones en tiempo real.

será realmente eficiente. Y los beneficios son bastante obvios. Ahora, tenemos menos tiempo de construcción porque solo construimos algunas páginas que consideramos importantes. Y mantenemos los beneficios de la generación de sitios estáticos porque tenemos SEO y rendimiento. Esto es realmente genial. Pero, ¿qué sucedió? Solo Gatsby lo admitía al principio. No todos estaban usando Gatsby. Y, por supuesto, en la nueva comunidad, nadie. Y aumentamos la complejidad. Porque necesitamos comunicarnos con el equipo de marketing, con el equipo de negocios, para decidir qué páginas son importantes y cuáles no. Y ellos comienzan a decidir cuál será la primera o no. Pero el verdadero problema eran los cambios pequeños. ¿Qué sucede si cambio un título? Que simplemente intentaré ejecutar nuevamente el proceso de construcción, eliminar todas las páginas en caché que creé con el trabajador en la nube y comenzar nuevamente el proceso. Entonces, ¿cuál es el punto principal de capturar todo si al final lo eliminaré todo y comenzaré de nuevo? Por eso Next decidió crear la regeneración estática incremental. Es una técnica que utiliza la generación de sitios estáticos para mostrar solo las partes de un sitio web que han cambiado, en lugar de regenerar el sitio completo cada vez. Básicamente, ahora tenemos una página que ya está poblada desde el servidor. Y tenemos una caché de la versión 1. Cuando el usuario ingresa, se iniciará un proceso de revalidación que generará una nueva página y se guardará en caché para más tarde. Pero el primer usuario verá la versión obsoleta, que es la v1, y el siguiente usuario que ingrese después de los segundos que especificamos en su proceso de validación, verá los nuevos datos. Entonces ahora Vercel también hizo esto disponible para Next, por lo que podemos usarlo en el ecosistema de VUE y esto es simplemente asombroso. Si tienes la oportunidad, debes usar este método de renderizado porque es increíble. Pero básicamente, los beneficios de usar esto es que ahora admitimos datos dinámicos en sitios estáticos. Eso suena muy extraño porque dirás, bueno, usaré el Pero si tienes este tipo de contenido, es mejor usar la regeneración estática incremental. Y tenemos disponibilidad porque cada vez que un usuario ingresa, siempre verá la versión más reciente. Por supuesto, no verá la primera vez, los primeros datos que tienes en tu base de datos, pero verá la página que creaste al principio. Y tendrás tiempos de respuesta más rápidos porque solo se construirán las páginas importantes al principio y las demás se generarán en los servidores. Algo similar a la primera generación del sitio. Pero el problema aquí fue que tenía un soporte limitado al principio, solo Next lo proporcionaba. Por supuesto, ahora Next, así que está bien. Pero, ¿qué sucedió? ¿Qué sucedió con este método?

5. Incremental Static Regeneration and On-Demand ISR

Short description:

El primer visitante activó el método de revalidación, lo que resultó en diferentes versiones de la página que fueron vistas por diferentes usuarios. Para abordar problemas como productos no disponibles en una plataforma de comercio electrónico, se creó el ISR bajo demanda. Esto te permite activar el proceso de revalidación para páginas específicas, mejorando la eficiencia. Mientras tanto, los desarrolladores estaban trabajando en una nueva solución.

El problema con esto es que es inconsistente para actualizaciones en tiempo real, al menos al principio. Entonces, básicamente, el primer visitante a una página activó ese método de revalidación que te expliqué, pero primero, es una página de respaldo completa, básicamente la V1. Y otro usuario estaba viendo la V2 de esa página. Por lo tanto, estaban viendo cosas diferentes. Y si tienes una plataforma de comercio electrónico y tienes un carrito, tal vez alguien estaba tratando de comprar algo que ya no estaba disponible. Eso fue un problema y para resolverlo, crearon el ISR bajo demanda, la versión 2.0 de la regeneración estática incremental. Porque ahora puedes llamar al proceso de revalidación desde tu API actual o desde el CMS de Helm. Así que imagina que estás editando una página y simplemente la publicas, puedes ejecutar el proceso de revalidación solo para la página que deseas cambiar en lugar de esperar a que el usuario ingrese a tu sitio y comience ese proceso. Esa es la solución actual.

6. Edge Rendering and its Benefits

Short description:

El renderizado en el borde es una técnica en la que el contenido web se sirve directamente desde servidores en el borde. Permite modificar el HTML renderizado en el borde antes de entregarlo al usuario final. Este método funciona bien con contenido dinámico, reduce la latencia de red, mejora la escalabilidad y proporciona almacenamiento en caché en tiempo real.

Pero mientras tanto, todos los desarrolladores estaban creando uno nuevo. Y este siguiente era el renderizado en el borde. Es una técnica en la que el contenido web se captura y se sirve directamente desde el servidor en el borde. Es similar a lo que conocemos como CDM, pero esta vez, los nodos son servidores y pueden ejecutar algo y tener potencia de cálculo. Básicamente, ahora podemos modificar el HTML renderizado que ya hemos construido en el borde antes de entregarlo al usuario final. Y los beneficios son increíbles. Funciona mejor con contenido dinámico. Puedes tener datos en tiempo real, reducir la latencia de red porque siempre tendrás un servidor cerca de tu usuario final, mejorar la escalabilidad porque tienes una red para cambiar entre servidores si no hay ninguno disponible. Y luego tienes almacenamiento en caché en tiempo real. Básicamente,

7. Irenrendering and Route Rendering

Short description:

Tenemos el irenrendering 2.0, que nos permite elegir diferentes métodos de renderizado para cada ruta de nuestro sitio web. Mediante el uso de propiedades en Nuxt, podemos definir si una ruta debe renderizarse como una página estática, generación estática incremental o renderizado del lado del cliente. Esta flexibilidad nos brinda control sobre cómo se renderizan las diferentes secciones de nuestro sitio web.

lo que estás viendo parece un sitio estático, pero en realidad es un servidor en el fondo. Pero el problema aquí es, bueno, ¿qué pasa si tenemos un proyecto o un sitio web que tiene tantas secciones diferentes que queremos construir con el mismo marco de trabajo? Bueno, para eso, tenemos el irenrendering. Básicamente, al principio, lo estábamos usando para combinar el renderizado del lado del servidor y del lado del cliente con la aplicación universal. Pero ahora tenemos el irenrendering 2.0, lo que en Nuxt se llama estrategia de almacenamiento en caché por rutas. Pero básicamente, ahora las rutas pueden ser una página estática generada bajo demanda, una ISR o simplemente una aplicación de una sola página o renderizado del lado del cliente o renderizado del lado del servidor. Podemos elegir para cada ruta de nuestra página, una barra diagonal admin, si queremos que sea un renderizado del lado del cliente, una barra diagonal blog para que sea un sitio estático y podemos decidir qué parte de nuestro sitio web se renderizará de qué manera. La forma de hacerlo en Nuxt es usando estas propiedades. Básicamente, solo defines la ruta que deseas tener como una página estática o generación estática incremental. Entonces, en la parte superior, puedes ver la versión de generación estática incremental que es SWR-to-true. Y si deseas tener solo un sitio estático completo, puedes poner static-to-true y SSR-to-false será renderizado del lado del cliente. Por defecto, porque al principio, Nuxt era del lado del servidor. Pero luego terminamos teniendo todo a la vez.

8. Introducción a la Arquitectura Jamstack

Short description:

Hay varios métodos de renderizado para cubrir, incluida la arquitectura de isla. Puedes construir un sitio estático con aplicaciones del lado del cliente, mejora progresiva y elegir una generación de sitio estático para implementación. La arquitectura Jamstack acopla el frontend y el backend, proporcionando escalabilidad, flexibilidad, rendimiento y mantenibilidad. YAM, que significa JavaScript, API y Markup, es la base de este mundo. Ahora, demostraré cómo construir un sitio estático utilizando un Hello CMS y la arquitectura Jamstack.

Y ¿qué sucedió ahora? Bueno, hay muchos métodos de renderizado que puedo cubrir en esta charla. Pero en episodios futuros, veremos qué es la arquitectura de isla. Pero básicamente, puedes construir un sitio estático con algunos componentes que serán aplicaciones del lado del cliente dentro de tu propia aplicación, mejora progresiva, comenzar a eliminar JavaScript cuando no lo necesites muchas cosas que necesitamos aprender. Pero, por supuesto, al final, pensarás, bueno, quiero implementar mi sitio. Necesito elegir algo, ¿verdad? De lo contrario, seguiré aprendiendo, pero nunca implementaré un sitio. Y por eso eliges una generación de sitio estático. Y cuando estaba construyendo mi sitio web, pensé, okay, quiero crear mi frontend con Nuxt. Lo tengo claro. Pero para el backend, no sé qué quiero hacer. En realidad, no sé si quiero crear un backend. Y por eso mencioné Jamstack. Jamstack es básicamente una arquitectura que acopla la Capa de Experiencia Web, lo que podemos llamar el frontend, con los datos y la lógica empresarial, lo que podemos llamar el backend. Entonces, básicamente, ahora todo está acoplado. Y tenemos escalabilidad porque, por supuesto, solo estamos creando un sitio estático que se alojará en algún cloud. Y el cloud pondrá el ancho de banda disponible para todos los usuarios. Tenemos flexibilidad. Podemos elegir la tecnología que queramos en el frontend y en el backend. Y ese es mi objetivo principal. Y rendimiento, porque tendremos un sitio estático al final. Y mantenibilidad, porque, por supuesto, todo lo acoplado es más fácil de mantener. Pero la idea es que este mundo proviene de YAM. Y YAM es simplemente la J es JavaScript, el generador de sitios estáticos que usarías para construir tu sitio. La A es API. Entonces, básicamente, donde estás guardando los datos. En este caso, tengo un CMS, porque trabajo allí. Y luego tenemos el marcado que es básicamente, cuando construyes el proceso de regeneración de tus páginas, el HTML final con los datos poblados que estás guardando en el proveedor de alojamiento. En este caso, Nullify con el nuevo logotipo que no entiendo. Pero sí, Nullify es ese ahora. Y ahora, lo que quiero mostrarte es de una manera muy rápida, solo dos minutos, cómo construir un sitio estático utilizando un Hello CMS y

9. Creating a Repository and Previewing the Site

Short description:

Básicamente, creo mi propio repositorio para guardar el contenido de mi sitio web. Selecciono mi plan, copio el comando, selecciono NUXT stream, NPM y Europa. Llamo a mi repositorio View London y se servirá en la nube. Instalo los paquetes, creo SSL, ejecuto la versión SSL de localhost, voy al contenido y previsualizo mi sitio en localhost.

la arquitectura JAMstack. Así que déjame mostrarte ahora. Básicamente, esto es un bloque de historia donde creo mi propio repositorio para guardar el contenido de mi sitio web. Creo un nuevo espacio, así que solo diría, View London. Y una vez que pueda encontrar, espera, porque sí, mejor. Entonces, si creo la página, seleccionaría mi plan gratuito, creo. No sé qué pasó con esto cuando estoy compartiendo la pantalla. Pero, está bien. Entonces, ahora podemos ir a comenzar, y tiene un comando que hará todo el esqueleto del proyecto por nosotros. Entonces, básicamente, puedo copiarlo, ignorar el token de API, no lo estás viendo. Y luego seleccionaremos NUXT stream. Y seleccionar NPM, por ejemplo, pero puedes elegir lo que quieras. Y Europa, porque estamos en Europa. Y está bien. Entonces, diré, View London, para llamar a mi repositorio. Y diré que se servirá en la nube, no localmente. Y una vez que esté listo, diré... Lo que haremos es simplemente instalar los paquetes. Y ejecutar el proyecto... De acuerdo. No. Entonces, ahora necesito ir a View London e instalar los paquetes. Y una vez que los tenga instalados, para conectarme con shareblock, necesito SSL. Crearé un maxsert. Pero esto es solo para SSL. Ignóralo. Y luego podemos ejecutar la versión SSL de nuestro localhost. Y una vez que lo tenga, lo que haré es simplemente ir al contenido. Y el contenido es donde vive todo mi contenido, básicamente. Y aquí podemos ver que hay una URL para la previsualización de nuestro sitio. Solo quiero ver mi localhost. Así que simplemente pondré aquí rápidamente localhost

10. Connecting Storyboard with Nuxt Application

Short description:

Ahora que he conectado Storyboard con mi aplicación Nuxt, puedo generar mi página estáticamente. Al ejecutar el comando 'yarn generate', el HTML se prepopula con los datos necesarios, eliminando la necesidad de llamadas a la API. Esto garantiza un proceso de renderizado rápido y eficiente.

3000 y guardarlo. Entonces, ahora que lo tengo, si vuelvo, veré un error 404 porque solo tengo la página de índice en Nuxt. Y para tener la página de índice, necesito agregar este último, esta ruta real. Y ahora habré conectado Storyboard con mi aplicación Nuxt y puedo cambiar todo, y ahora, si lo publico, quiero generar mi página estáticamente. Para hacer eso, simplemente iré a Nuxt y diré, está bien, genera mi página en un modo estático, y ahora quiero que sirvas la salida. Y si lo sirvo, puedo ver ahora en HTML localhost. Puedo ver en mi parte superior de la red, aquí, que no tengo ninguna llamada a la API porque todo ya está prepopulado en el HTML generado después de ejecutar el comando

QnA

Contact, Mock Data, and Edge Rendering

Short description:

Y tengo esta diapositiva si quieres contactarme o darme cualquier comentario sobre la charla o todo lo que hemos hablado aquí, puedes contactarme en dantraus en cualquier red social. Uno de los de Lutz preguntó si recomiendas simular datos cuando necesitas probar un componente que llama a una API. Bueno, solía hacer eso mucho, diría yo. Hoy en día, con Storyblock, ya tienes el archivo JSON que te proporciona todas las propiedades. Cuando estás construyendo sitios web, digamos que estás construyendo un sitio web que va a ser utilizado por miles de personas. Necesitas enfocarte realmente en el rendimiento. ¿Qué método de renderizado usarías? ¿Qué tipo de cosas usarías para informar? Sí, en realidad hoy en día creo que el renderizado en el borde es realmente efectivo. Cada plataforma en la nube está impulsando este tipo de forma de renderizar nuestro sitio web.

y yarn generate. Básicamente eso fue todo. Y tengo esta diapositiva si quieres contactarme o darme cualquier comentario sobre la charla o todo lo que hemos hablado aquí, puedes contactarme en dantraus en cualquier red social. Y muchas gracias. Gracias, gracias, gracias. Eso fue increíble. Vamos, toma asiento, siéntete cómodo. Ya tenemos bastantes preguntas llegando. Vamos a responder algunas. Una de las preguntas de Lutz fue si recomiendas simular data cuando necesitas probar un componente que llama a una API. Bueno, solía hacer eso mucho, diría yo. Hoy en día, con Storyblock ya tienes el archivo JSON que te proporciona todas las propiedades. Es más fácil porque tienes como una plantilla del data que tendrás en el componente cuando lo estás creando. Porque básicamente el componente que creas en Hello, CMS generalmente está vinculado a las propiedades que recibirás en ese componente. Pero por supuesto, al principio cuando comencé a crear mi sitio web, por ejemplo, creé datos simulados para crear mis componentes y luego comencé a usar Hello, CMS después. Entonces, ¿por qué no? Me gusta simular data. Es genial. Voy a actualizar rápidamente el mío porque tengo algunas preguntas antiguas. Muy bien. Pasemos a la siguiente pregunta, que es... Me olvidé. Dame un momento. Voy a hacer mi pregunta. Mientras espero a que mi teléfono se recargue, cuando estás construyendo sitios web, sé que hablaste de tus sitios, pero digamos que estás construyendo un sitio web que va a ser utilizado por miles de personas. Necesitas enfocarte realmente en el rendimiento. ¿Qué método de renderizado usarías? ¿Qué tipo de cosas usarías para informar? Sé que cubriste esto en tu charla, pero solo quiero que profundices un poco más.

Sí, en realidad hoy en día creo que el renderizado en el borde es realmente efectivo. Cada plataforma en la nube está impulsando este tipo de forma de renderizar nuestro sitio web. Y si pienso a largo plazo, si quiero tener un sitio ahora mismo que solo tenga artículos, está bien construirlo con un sitio estático. Pero si piensas a largo plazo, tal vez tendrás una sección que será un comercio electrónico. Así que siempre es mejor usar el renderizado en el borde o algo que tenga un servidor para ejecutarse, porque al principio, por supuesto, no piensas en una plataforma de comercio electrónico, pero al final la tendrás si todo va bien, ya sabes. Así que sí, renderizado en el borde.

Hybrid Rendering and Slide Design

Short description:

Cada sitio está a un paso de convertirse en una plataforma de comercio electrónico. El renderizado híbrido nos permite elegir métodos de renderizado por ruta. Hay muchos métodos de renderizado para explorar y el futuro ofrece aún más posibilidades. Las diapositivas fueron creadas utilizando Figma e inspiradas en un programa de televisión. El orador también recibió elogios por sus elecciones de diseño y se le preguntó sobre sus joyas NUTS.

Así que cada sitio está a un paso de convertirse en una plataforma de comercio electrónico, eso es lo que me llevo. De acuerdo, tenemos otra pregunta. ¿Será el renderizado híbrido el futuro del renderizado de contenido web? Por ejemplo, renderizado autoseleccionado. Nunca había oído hablar de renderizado autoseleccionado. ¿Renderizado seleccionado? Renderizado autoseleccionado. Pero tal vez se refiere al renderizado híbrido, como seleccionar de manera muy precisa. Tiene sentido. Sí, creo que es genial que los frameworks puedan hacer eso por nosotros, porque no necesitamos crear un nuevo proyecto desde cero, solo para construir nuestro proyecto de esa manera. Podemos elegir por ruta lo que queremos. Así que sí, creo que el renderizado híbrido también es genial. Pero por supuesto, el renderizado en el borde no forma parte de eso, así que debes estar seguro de que solo quieres los que el renderizado híbrido te proporciona. Del lado del cliente, del lado del servidor, estático o incremental. Sí, hay muchos. Sí, hay muchos... Es realmente interesante, porque pensé que conocía la mayoría de los métodos de renderizado, pero hoy aprendí sobre muchos y vi el futuro de lo que está por venir. Sí, los futuros son como... Todavía hay mucho que necesito aprender. También, un gran agradecimiento a Anonymous. Pero 11 personas votaron a favor. Realmente nos gustaron tus diapositivas. Me gusta tu design de diapositivas. Oh, gracias. ¿Qué consideras al elegir tus design de diapositivas? Bueno, en realidad, las hice yo misma con Figma. Estaba viendo una serie de eventos desafortunados el programa de televisión en el que se basa, y estaba dibujando sus caras. Y luego me di cuenta, okay, tal vez pueda hacer algo con esto. Y así creé las diapositivas. Eso es increíble. Eso es genial. Alguien más preguntó, ¿dónde compraste las joyas NUTS? ¿NUTS es entonces el negocio de moda? Porque, quiero decir, es bastante genial. Pero te refieres a esta, ¿verdad? ¿Como los pendientes? Sí, creo que sí.

Earrings, Nuxt, Rendering Tools, and I18N

Short description:

Hice mis propios pendientes de tecnología utilizando una impresora 3D. Aunque no puedes comprarlos, puedes pedirlos después del evento. Al comenzar con Vue, tiene sentido usar Nuxt por su experiencia en aplicaciones del lado del servidor. Para elegir el mejor método de renderizado, verifica el rendimiento de tu sitio y considera la velocidad de conexión del público objetivo. Manejar I18N con un generador de sitios estáticos puede ser desafiante debido a los complementos beta, que requieren páginas separadas para cada idioma.

Sí, lo hice yo misma porque compré una impresora 3D hace algún tiempo. Así que decidí crear mis propios pendientes de tecnología. Definitivamente. Pero no los estoy vendiendo. Si quieres, puedes obtenerlos, pero no los estoy vendiendo.

Después del evento, después de que haya usado la charla, definitivamente sube y pídele algunos pendientes para ti también. Alguien más hizo la pregunta, ¿tiene sentido no usar Nuxt al comenzar a trabajar con Vue en estos días? Esa es una buena pregunta. Sí, por supuesto, puedes construir tu propio SSR utilizando el complemento de Vue y cosas así. Pero creo que Nuxt te respalda. Si algo sucede o si necesitas actualizar, ellos lo harán por ti. Siempre prefiero usar algo que ellos están construyendo porque creo que tienen más experiencia que yo en la creación de aplicaciones del lado del servidor. Así que elegiría Nuxt. Bien, apóyate en los hombros de los gigantes, chico. Y también, en tu charla, hablaste sobre todas las diferentes formas de informar tu elección sobre qué método de renderizado elegir, pero hay mucho que tener en cuenta. Y la siguiente pregunta es, ¿hay alguna herramienta que puedas recomendar que ayude a las personas a tomar esas decisiones sobre el mejor tipo de renderizado para cada ruta? Tal vez necesitemos crear una. Bueno, lo que puedes hacer es... Una startup. Sí. No, pero lo que puedes hacer, por supuesto, es verificar el rendimiento de tu sitio. Básicamente, si tienes un sitio estático, la única forma de medir si va bien es el tiempo de compilación, lo notarás rápidamente porque tu sitio no se implementará hasta una hora después. Pero si tienes problemas, por ejemplo, con el renderizado del lado del servidor, así es como puedes medirlo con herramientas de rendimiento. Básicamente, puedes verificar la mala conexión lenta para las personas que están muy lejos de los servidores y cosas así. Y para eso, el renderizado solucionará la mayoría de los problemas que tenemos hoy en día. Bueno, bueno. La siguiente tiene un acrónimo que por alguna razón no reconozco en este momento. Pero ¿cómo manejas I18N con un generador de sitios estáticos? ¿Quiero decir, traducciones? Bueno, sí. En realidad, eso es interesante. Porque el complemento que tenemos actualmente en los modelos del sistema Naxaco no funciona correctamente con sitios estáticos.

I18N Deployment and Rebuilding App

Short description:

Si despliegas un sitio con I18N, tendrás que generar todas las páginas por idioma. La generación estática incremental ayuda con esto. No hay problemas potenciales con no reconstruir completamente tu aplicación cada vez que la despliegas, especialmente para los editores con artículos desactualizados. Los usuarios pueden generar contenido específico sobre la marcha. Puedes encontrar más información y ver videos de baile hip-hop en Instagram y Adventrals.

sitios porque está en beta. Pero espero que al final funcione. Pero básicamente, si despliegas un sitio con I18N, tendrás que generar todas las páginas por idioma. Sí. Así que eso es mucho. La generación estática incremental ayudará con eso. Genial, genial. Tenemos una respuesta para todo. Me encanta esto. Experto, experto. Y el último uno. ¿Hay algún problema potencial con no reconstruir completamente tu aplicación cada vez que la despliegas? En realidad no, porque si pensamos en los editores grandes que tienen muchos artículos, la mayoría de ellos están desactualizados o tal vez del pasado. Esos ya no son importantes. Tal vez para un usuario que quiere ver un contenido específico, lo generarían sobre la marcha. Así que la generación estática incremental o la primera generación se creó por eso. Porque, por supuesto, quieres tener 1,000 artículos que creaste recientemente en los motores de búsqueda, pero los demás están desactualizados. Así que está bien no Genial. Y última pregunta, solo por diversión, ¿dónde pueden las personas obtener más información sobre ti y ver algunos de tus increíbles videos de baile hip-hop? Bueno, el hip-hop está en Instagram solamente, pero las otras cosas en Adventrals, en Twitter, estoy más allí. Genial. Muy bien, demos un gran aplauso. 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 2022React Advanced Conference 2022
25 min
A Guide to React Rendering Behavior
Top Content
React is a library for "rendering" UI from components, but many users find themselves confused about how React rendering actually works. What do terms like "rendering", "reconciliation", "Fibers", and "committing" actually mean? When do renders happen? How does Context affect rendering, and how do libraries like Redux cause updates? In this talk, we'll clear up the confusion and provide a solid foundation for understanding when, why, and how React renders. We'll look at: - What "rendering" actually is - How React queues renders and the standard rendering behavior - How keys and component types are used in rendering - Techniques for optimizing render performance - How context usage affects rendering behavior| - How external libraries tie into React rendering
React Summit 2023React Summit 2023
32 min
Speeding Up Your React App With Less JavaScript
Too much JavaScript is getting you down? New frameworks promising no JavaScript look interesting, but you have an existing React application to maintain. What if Qwik React is your answer for faster applications startup and better user experience? Qwik React allows you to easily turn your React application into a collection of islands, which can be SSRed and delayed hydrated, and in some instances, hydration skipped altogether. And all of this in an incremental way without a rewrite.
React Summit 2023React Summit 2023
23 min
React Concurrency, Explained
React 18! Concurrent features! You might’ve already tried the new APIs like useTransition, or you might’ve just heard of them. But do you know how React 18 achieves the performance wins it brings with itself? In this talk, let’s peek under the hood of React 18’s performance features: - How React 18 lowers the time your page stays frozen (aka TBT) - What exactly happens in the main thread when you run useTransition() - What’s the catch with the improvements (there’s no free cake!), and why Vue.js and Preact straight refused to ship anything similar
JSNation 2022JSNation 2022
21 min
The Future of Performance Tooling
Top Content
Our understanding of performance & user-experience has heavily evolved over the years. Web Developer Tooling needs to similarly evolve to make sure it is user-centric, actionable and contextual where modern experiences are concerned. In this talk, Addy will walk you through Chrome and others have been thinking about this problem and what updates they've been making to performance tools to lower the friction for building great experiences on the web.
React Summit Remote Edition 2021React Summit Remote Edition 2021
43 min
RedwoodJS: The Full-Stack React App Framework of Your Dreams
Top Content
Tired of rebuilding your React-based web framework from scratch for every new project? You're in luck! RedwoodJS is a full-stack web application framework (think Rails but for JS/TS devs) based on React, Apollo GraphQL, and Prisma 2. We do the heavy integration work so you don't have to. We also beautifully integrate Jest and Storybook, and offer built-in solutions for declarative data fetching, authentication, pre-rendering, logging, a11y, and tons more. Deploy to Netlify, Vercel, or go oldschool on AWS or bare metal. In this talk you'll learn about the RedwoodJS architecture, see core features in action, and walk away with a sense of wonder and awe in your heart.

Workshops on related topic

React Summit 2023React Summit 2023
170 min
React Performance Debugging Masterclass
Featured WorkshopFree
Ivan’s first attempts at performance debugging were chaotic. He would see a slow interaction, try a random optimization, see that it didn't help, and keep trying other optimizations until he found the right one (or gave up).
Back then, Ivan didn’t know how to use performance devtools well. He would do a recording in Chrome DevTools or React Profiler, poke around it, try clicking random things, and then close it in frustration a few minutes later. Now, Ivan knows exactly where and what to look for. And in this workshop, Ivan will teach you that too.
Here’s how this is going to work. We’ll take a slow app → debug it (using tools like Chrome DevTools, React Profiler, and why-did-you-render) → pinpoint the bottleneck → and then repeat, several times more. We won’t talk about the solutions (in 90% of the cases, it’s just the ol’ regular useMemo() or memo()). But we’ll talk about everything that comes before – and learn how to analyze any React performance problem, step by step.
(Note: This workshop is best suited for engineers who are already familiar with how useMemo() and memo() work – but want to get better at using the performance tools around React. Also, we’ll be covering interaction performance, not load speed, so you won’t hear a word about Lighthouse 🤐)
React Summit 2023React Summit 2023
145 min
React at Scale with Nx
Featured WorkshopFree
We're going to be using Nx and some its plugins to accelerate the development of this app.
Some of the things you'll learn:- Generating a pristine Nx workspace- Generating frontend React apps and backend APIs inside your workspace, with pre-configured proxies- Creating shared libs for re-using code- Generating new routed components with all the routes pre-configured by Nx and ready to go- How to organize code in a monorepo- Easily move libs around your folder structure- Creating Storybook stories and e2e Cypress tests for your components
Table of contents: - Lab 1 - Generate an empty workspace- Lab 2 - Generate a React app- Lab 3 - Executors- Lab 3.1 - Migrations- Lab 4 - Generate a component lib- Lab 5 - Generate a utility lib- Lab 6 - Generate a route lib- Lab 7 - Add an Express API- Lab 8 - Displaying a full game in the routed game-detail component- Lab 9 - Generate a type lib that the API and frontend can share- Lab 10 - Generate Storybook stories for the shared ui component- Lab 11 - E2E test the shared component
JSNation 2023JSNation 2023
170 min
Building WebApps That Light Up the Internet with QwikCity
Featured WorkshopFree
Building instant-on web applications at scale have been elusive. Real-world sites need tracking, analytics, and complex user interfaces and interactions. We always start with the best intentions but end up with a less-than-ideal site.
QwikCity is a new meta-framework that allows you to build large-scale applications with constant startup-up performance. We will look at how to build a QwikCity application and what makes it unique. The workshop will show you how to set up a QwikCitp project. How routing works with layout. The demo application will fetch data and present it to the user in an editable form. And finally, how one can use authentication. All of the basic parts for any large-scale applications.
Along the way, we will also look at what makes Qwik unique, and how resumability enables constant startup performance no matter the application complexity.
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
148 min
React Performance Debugging
Workshop
Ivan’s first attempts at performance debugging were chaotic. He would see a slow interaction, try a random optimization, see that it didn't help, and keep trying other optimizations until he found the right one (or gave up).
Back then, Ivan didn’t know how to use performance devtools well. He would do a recording in Chrome DevTools or React Profiler, poke around it, try clicking random things, and then close it in frustration a few minutes later. Now, Ivan knows exactly where and what to look for. And in this workshop, Ivan will teach you that too.
Here’s how this is going to work. We’ll take a slow app → debug it (using tools like Chrome DevTools, React Profiler, and why-did-you-render) → pinpoint the bottleneck → and then repeat, several times more. We won’t talk about the solutions (in 90% of the cases, it’s just the ol’ regular useMemo() or memo()). But we’ll talk about everything that comes before – and learn how to analyze any React performance problem, step by step.
(Note: This workshop is best suited for engineers who are already familiar with how useMemo() and memo() work – but want to get better at using the performance tools around React. Also, we’ll be covering interaction performance, not load speed, so you won’t hear a word about Lighthouse 🤐)
GraphQL Galaxy 2021GraphQL Galaxy 2021
164 min
Hard GraphQL Problems at Shopify
WorkshopFree
At Shopify scale, we solve some pretty hard problems. In this workshop, five different speakers will outline some of the challenges we’ve faced, and how we’ve overcome them.

Table of contents:
1 - The infamous "N+1" problem: Jonathan Baker - Let's talk about what it is, why it is a problem, and how Shopify handles it at scale across several GraphQL APIs.
2 - Contextualizing GraphQL APIs: Alex Ackerman - How and why we decided to use directives. I’ll share what directives are, which directives are available out of the box, and how to create custom directives.
3 - Faster GraphQL queries for mobile clients: Theo Ben Hassen - As your mobile app grows, so will your GraphQL queries. In this talk, I will go over diverse strategies to make your queries faster and more effective.
4 - Building tomorrow’s product today: Greg MacWilliam - How Shopify adopts future features in today’s code.
5 - Managing large APIs effectively: Rebecca Friedman - We have thousands of developers at Shopify. Let’s take a look at how we’re ensuring the quality and consistency of our GraphQL APIs with so many contributors.