1. Introducción a los Métodos y Estrategias de Renderizado
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
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
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
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
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
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
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
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
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
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
Contact, Mock Data, and Edge Rendering
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
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
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
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.
