¿React sin JavaScript?

Hola. Mi nombre es Fred Schott, y esta es mi charla, Astro, React sin JavaScript. Esta es una charla sobre lenguaje. Y no me refiero a JavaScript versus PHP versus C++ versus Fortran. Lo que quiero decir es el lenguaje de la mente. Y realmente, el lenguaje de cómo hablamos sobre el desarrollo web, y cómo pensamos sobre el desarrollo web, y cómo eso influye en lo que podemos construir como desarrolladores web. Sabes, lo que se considera fácil versus lo que se considera difícil. Lo que es sencillo versus lo que es muy difícil. Lo que es posible y lo que es imposible. Todo proviene del lenguaje que hablamos sobre el desarrollo web. Y para darte un ejemplo, de lo que estoy hablando, quiero mostrar una charla en una conferencia que realmente me encanta. Esta es probablemente mi charla favorita de los últimos 20 años. Además, obviamente la infame charla de qué, si no la has visto, es una delicia. Definitivamente te recomiendo que la busques rápidamente en Google cuando termine la conferencia. Pero de lo que quiero hablar es de esta charla. Este es Pete Hunt, uno de los creadores de React, hablando sobre React. Y realmente lanzando React.

Ahora, lo que necesitas saber sobre esta charla es que tuvo lugar en 2013. Y esta es básicamente la primera vez que todos ven React. Y por lo tanto, las ideas que se presentan aquí, ya sabes, en 2020, son ideas de componentes y ciclos de renderizado y cómo pensamos sobre el desarrollo Front End. Todo suena exactamente a lo que hemos llegado a entender como buenas mejores prácticas. Pero, para esta audiencia, estos conceptos son muy extraños. Esta no es una audiencia que piensa en componentes y JSX. Esta es una audiencia que tradicionalmente solo ha pensado en términos de MVC. Eso es Modelo Vista Controlador. Si tuviste la suerte de haber evitado esta parte del desarrollo web, te ahorraré los detalles. No te perdiste mucho de nada. Pero MVC era esta idea de separar tu código y separar tus preocupaciones de tal manera que aportara claridad y limpieza a tu base de código. Separar tus preocupaciones era el objetivo aquí. Y así, cuando Facebook lanzó Componentes, era básicamente esta idea de, ya sabes,

Y es posible que estés pensando, ¿de qué estás hablando? El equipo de React ha estado trabajando en componentes de React renderizados en el servidor durante años. Es increíblemente difícil. Suspense, modo concurrente, todas estas cosas se están uniendo, pero es un gran desafío. ¿De qué estás hablando que has descubierto esto? Y esto es exactamente de lo que estoy hablando sobre el lenguaje. En ciertas formas de pensar, es muy difícil. Con Astro, es muy fácil.

Antes de entrar en la demostración, quiero mostrarte un pequeño fragmento rápido. Astro se trata de construir tu sitio con archivos Astro. Esencialmente, es un superconjunto de HTML. Esto también es válido en Astro. Es similar a cómo JSX es paraJavaScript. Astro es para HTML. Pero esta es la base de cada sitio. Así que puedes ver este tipo de páginas index.Astro, que es esencialmente la página de inicio de tu sitio web que estás construyendo. Es HTML básico como base. Y si conoces HTML o incluso si conoces JSX, entonces ya conoces Astro. Y para construir la página de inicio de Astro, Astro.build, esencialmente junté algunas páginas estáticas, HTML, agregué un SVG y lo medí. Y obtuve un sitio tan rápido, tan rápido que no se podía medir en Lighthouse. Así que todos estos frameworks con sus puntuaciones perfectas de 100 y todo en verde, ya no es genial. Lo que descubrí que es realmente genial, son los ceros. Sé tan rápido que no se pueda medir. Ese es el nuevo objetivo. El desafío está planteado. Pero eso es lo que quiero transmitir aquí un poco. Es esta idea de HTML.

Y realmente la idea de cómo Astro se compara con otros frameworks que existen hoy en día. Y la forma en que lo enmarcaría es aplicaciones JavaScript vs. sitios web HTML. Las aplicaciones JavaScript son lo que estás construyendo con la mayoría de los frameworks que existen hoy en día. Eso es Next.js, Gatsby, Blitz, Redwood. Todos ellos se tratan de construir tu sitio como una aplicación JavaScript. Y hay muchas buenas razones para hacer esto.

Las aplicaciones JavaScript son potentes. Son muy expresivas. Puedes cargar datos, obtener datos, hacer enrutamiento. Y todas estas diferentes formas de construir un sitio en un lenguaje realmente agradable para el poder y el control. Pero son complejas. Next.js y todos estos frameworks existen básicamente para darte diferentes ganchos para hacer que tu sitio sea más rápido que el modelo tradicional de enviar una aplicación completa al usuario, que es el modelo tradicional de SBA. Entonces, puedes construir una aplicación JavaScript y enviarla al usuario. Podrías usar algo como Next que la renderizará en un servidor. Se trata de optimizar esa historia porque el rendimiento puede ser un desafío. Cuando construyes una gran aplicación y ahora quieres enviarla al usuario en tal vez un dispositivo de menor potencia o una conexión a Internet más débil, eso puede ser realmente desafiante de hacer correctamente, por eso las optimizaciones como SSR, SSG, son realmente importantes en el mundo de las aplicaciones JavaScript. Y podrías decir, sabes, si piensas que la distinción no tiene mucho sentido, eso es casi a lo que me refiero aquí, es que hoy en día somos tan sinónimos de aplicaciones JavaScript y sitios web como la misma cosa. Y hay buenas razones para eso. Si piensas en lo que es un sitio web HTML, probablemente sea algo de menor potencia. Eleventy o Hugo, se centran realmente en el contenido, markdown, generación estática de HTML, es una idea bastante de menor potencia o al menos tradicionalmente lo ha sido. Lo que terminan teniendo que hacer es decir, sí, JavaScript es esta otra cosa a la que no tocamos. Somos HTML. Si quieres agregar React, hazlo tú mismo. Así que el sitio web de Snowpax, uno de los proyectos en los que trabajo, lo construimos con Eleventy. Es genial. Es rápido, pero en el momento en que necesitas interactividad, tienes que configurar tu propia cosa.

Pero queremos ir más allá, queremos seguir incorporando más conceptos de componentes modernos en cómo renderizas esta página. Así que pensemos en componentes, agreguemos algunos componentes a este HTML. Comencemos con dos. Uno es algo que llamaremos cabeza común. Y tengo que escribir eso correctamente, components.commonhead.astronaut, commonhead.astronaut. Y el otro es una imagen de héroe. Agreguemos una bonita imagen de héroe en la página. Empecemos con eso, simplemente añadámoslo aquí.

Y la cabeza común en realidad será un componente que se encargará de todas estas propiedades meta. Así que si tienes muchas páginas en tu sitio, no quieres repetirte una y otra vez, podemos usar un componente como este para agrupar algunas propiedades y etiquetas comunes de cabeza para que las uses en varias páginas. Ahora, la cabeza común es interesante porque en realidad toma props. Es un archivo Astro, es un fragmento de HTML que vamos a inyectar en el sitio, pero va a tomar la prop del título como veremos en un segundo. Puedes ver que lo hace utilizando nuevamente un concepto de Svelte de definir tus props como valores exportados. Así que aquí hemos exportado el título para mostrar que es una prop. Y luego podemos usarlo en el fragmento de HTML que vamos a inyectar en tu sitio. De nuevo, conceptos muy similares a los de React y Svelte, estamos tomando prestadas muchas ideas realmente buenas que hemos visto en la comunidad antes que nosotros. También puedes notar,

Ahora, para el resto de esto, mostraré algunos fragmentos más interesantes. El primero es un Pokédex. ¿Qué buena demostración técnica no incluye Pokémon? Ahora hay algunas cosas interesantes que quiero mostrar en el fragmento. La primera es que cuando decimos que tenemos esta sintaxis similar a JSX, realmente lo decimos. Puedes ver aquí una expresión completa de JavaScript que mezcla la sintaxis de astro y JavaScript juntas. Así que al igual que el JSX al que estamos acostumbrados en React, vamos a usar esta expresión para renderizar múltiples componentes en la página. Aquí, vamos a mostrar realmente un sprite de Pokémon para los primeros tres Pokémon en el Pokédex. Oh, y tenemos que usarlo primero. Búsqueda de Pokémon. Y agreguemos un poco de display flex solo para colocarlos todos en la página. Mira eso. Así que si no conoces Pokémon, toda la idea de un Pokédex, nada de eso es importante. Lo que estamos haciendo aquí es divertirnos con Pokémon y generar tres pequeños sprites aquí, tres pequeñas imágenes. Lo interesante de este componente es que estamos introduciendo la idea de obtención de datos. Así que no enviamos todos los Pokémon conocidos por el hombre. Aquí tenemos la obtención de datos, obteniendo en tiempo de compilación y realizando una llamada a la API. No solo tenemos ese soporte a través de fetch, sino que también tenemos top level await. Así que la idea de esto afectando al usuario, es completamente en tiempo de compilación. Puedes usar top level await como parte de tu renderizado en el servidor y el usuario nunca lo ve. Así que no hay realmente una gran preocupación de performance para el usuario aquí porque todo esto se renderiza como HTML estático al final del día. Podemos ver eso en el panel de red aquí. Actualizaré y no hay JavaScript en la página, todo es HTML estático. Así que esa es una idea realmente interesante de cómo puedes expresarte con el lenguaje basado en HTML en el servidor llamado Astro de formas en las que estarías mucho más limitado si estuvieras utilizando un framework de front-end como React o Svelte donde no puedes simplemente agregar un top level await porque el usuario lo vería. En este mundo, estamos completamente renderizados en el servidor.

Entonces, en realidad no tenemos esas preocupaciones. Somos un poco más libres para expresarnos de esta manera sin el boilerplate.

Voy a mostrar otro pequeño fragmento de demostración aquí. Y eso es esta idea de regalar la parte divertida, un selector de emojis. Esto no es solo cualquier selector de emojis. Agreguemos nuestra importación aquí arriba. Puede que lo hayas visto en el directorio de componentes si lo estabas buscando. Este no es un archivo de Astro. Es un archivo JSX. Es un componente de React.

Dije al principio en la charla, ¿verdad? Hemos hecho componentes renderizados en el servidor. ¿Qué significa eso? Significa que te permitimos usar React en tu aplicación de Astro. Aquí tenemos un componente de React. Está utilizando otro paquete de npm. Está utilizando algo de CSS. Y todo esto genera marcado en el lado del servidor. Vamos a renderizar este componente en el lado del servidor. Aquí tenemos tres de ellos. Actualicemos la página. Y mira eso. Acabamos de combinar. De hecho, lo haré. Así puedes verlo tú mismo. Hemos combinado Astro como un lenguaje HTML y React como un framework JavaScript. Pero los hemos renderizado todos en el lado del servidor. Todo generando HTML al final del día. Así que puedes hacer esto con cualquier framework. Es el React Summit. Usaremos React. Pero Preact es

Entonces, lo que tenemos aquí es la idea de tomar un componente escrito en un framework como React o pre-actores. Y agregarle un modificador aquí para promoverlo al cliente. Digamos que haremos idle aquí. Lo que hace esto es generar no solo el marcador de posición, sino también, verás aquí, código para hidratar este componente en la página. Entonces, ahora tenemos un componente completamente interactivo. Todo funciona en el cliente. Y verás aquí en el panel de red, un seguimiento de red real, que muestra cómo se carga esto. En realidad se está ejecutando en el navegador. Esto es desarrollo. Por lo tanto, estamos siendo un poco más agresivos en el JavaScript que enviamos en producción. Esto se empaquetaría, minimizaría y se eliminaría del árbol.

Otra cosa genial aquí es la idea de visible. Si lo escribes correctamente, visible. Y esto, lo haré aquí. A medida que te desplazas hacia abajo, solo será cuando llegues al componente real que toma ese costo y realmente hidrata esos componentes. Entonces, si algo está debajo del pliegue, en realidad nunca pagarías el precio de cargarlo hasta que realmente interactúes con él y lo veas en tu pantalla. Hay muchas más cosas geniales como esta en Astro que simplemente no tengo tiempo para mostrarte. Ni siquiera hemos llegado a cómo funciona el estilo de ámbito en el marcado por defecto. Todo esto se trata de ayudarte a construir un sitio que tenga la menor cantidad de JavaScript y el menor peso posible que deba enviarse al usuario. El superpoder de Astro es algo llamado hidratación parcial. Esta es esa capacidad que viste de mezclar HTML estático y JavaScript del lado del cliente en base a cada componente. Por defecto,