Una Saga de Problemas de Renderizado Web

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

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

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.

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.