React at the Edge: Construyendo un Framework desde Cero (En Vivo)

Es un placer estar aquí y el único pensamiento en mi mente en este momento es qué idiota eligió esa charla. Mi nombre es Daniel. Soy un mantenedor de código abierto a tiempo completo, lo cual es sinceramente el mejor trabajo del mundo porque puedo colaborar con personas de todo el mundo y construir cosas geniales en abierto. Dirijo el equipo central que construye Nuxt, pero también estoy en otros proyectos de código abierto. Estoy en el equipo de Nitro, Elk, Elk es un cliente de código abierto de Mastodon. He construido algunas bibliotecas como MagicRegex, Plotfontaine, y siéntete libre de revisarlas si quieres. Y visita mi sitio web, row.dev, donde puedes encontrar cómo enviarme un mensaje directo si lo deseas.

Si no hay oportunidad de hablar sobre algo en la sesión de preguntas y respuestas después de la charla, estaré encantado si quieres dejarme un mensaje. Si hay algo en lo que pueda ayudar, realmente, me encantaría hacerlo. Soy un experto desarrollador de Google, un MVP de Microsoft, una estrella de GitHub, y recientemente comencé como ingeniero de software en Vercel, donde continúo trabajando a tiempo completo en Nuxt. Vivo en Edimburgo, una ciudad hermosa, que en realidad es un poco más cálida que Nueva York y Nueva Jersey hoy. Así que ahí lo tienes. Es un lugar hermoso, tiene días muy cortos en invierno, y puede ser totalmente miserable cuando comienzan la lluvia y el viento.

Y alguien estuvo en mi charla ayer, y sabe que es posible enviar emojis en vivo a mis diapositivas a través de una URL secreta, que definitivamente no voy a decirle a nadie. No estoy aquí para hablar sobre Nuxt, pero debería decir qué es, si no lo has encontrado antes. Es un framework de pila completa para construir aplicaciones web. Está construido sobre Vue, Nitro, Vite, y el objetivo es tener algo que sea progresivamente mejorable. Así que la gente debería poder usarlo sin saber cómo funciona, y luego deberían poder configurarlo a medida que avanzan. Se inició un día después de que Next.js fuera iniciado, y me disculpo por el nombre. Es un poco confuso. Reescribimos Nuxt totalmente desde cero durante un período de unos años de 2020 a 2022. Y no estoy seguro de que haya una línea de código en Nuxt que sea la misma en Nuxt 3 que en Nuxt 2. Fue una reescritura total. Háblame de eso más tarde. Fue profundamente traumático para muchas personas, incluidos muchos usuarios, que encontraron que la ruta de migración de 2 a 3 no era tanto un camino como un precipicio. Pero tengo muchas opiniones.

De todos modos, tuvimos que hacer eso, y parte de las razones por las que elegimos reescribir Nuxt desde cero fue que había muchos cambios que estaban ocurriendo en el ecosistema. Así que inmediatamente para nosotros, estaba el hecho de que Vue había tenido un lanzamiento importante. Había esta nueva versión de Vue, Vue 3, que cambió cómo funcionaba la Reactividad para Nuxt en sí mismo. También hubo un gran cambio. Nos movimos de webpack 4 a 5, y luego durante todo el proceso de construcción de Nuxt, Evan Yu, quien originalmente creó Vue, también creó algo llamado Vite, que era maravilloso pero también extremadamente frustrante porque significaba que teníamos que re-arquitectar completamente Nuxt para trabajar con él. Quiero decir, no teníamos que hacerlo, pero la experiencia del desarrollador era tan increíble.

Y fue una oportunidad para que reestructuráramos Nuxt para ser agnóstico al empaquetador, así que lo construimos para que pudiera trabajar tanto con webpack como con Vite, y desde entonces hemos añadido RSPack, y podríamos añadir más. O podrías, es enchufable, cualquiera puede proporcionar el suyo propio. Pero había otras cosas que estaban sucediendo también, alrededor de ese tiempo en el ecosistema. Así que hubo un movimiento de ese tipo de servidor de larga duración que se inicia una vez y toma solicitudes y simplemente dura hasta que necesitas, no sé, iniciar otro contenedor o eliminarlo y reemplazarlo con un nuevo despliegue, a cosas como los trabajadores de Cloudflow, que tenían límites de tamaño muy estrictos, o lambdas, que tenían cosas como restricciones de tamaño, cuanto más grande es tu archivo zip, más tiempo lleva descomprimirlo, y donde cosas como los inicios en frío eran increíblemente importantes en términos de devolver una buena respuesta al usuario final.

Y otras cosas como Deno, Bun, un movimiento hacia ESM, y más. Y así, a partir de eso, construimos un motor de servidor para Nuxt, que es totalmente diferente de lo que teníamos antes, y lo llamamos originalmente Nuxt Sigma, luego lo llamamos Nuxt Nitro, y finalmente decidimos eliminar el Nuxt y hacerlo un servidor genérico que cualquiera podría usar para construir servidores de alto rendimiento. Y queríamos diseñarlo de tal manera que la gente pudiera construir su propio meta-framework sobre él, y eso ha sucedido, así que personas como Brandon Roberts han construido un increíble meta-framework y él usa Nitro bajo el capó. Igualmente, frameworks como SolidStart o TanStackStart también trabajan con Nitro para que sea el servidor para ellos también. Y esa es la mejor parte del código abierto, ¿verdad?

Todo eso está impulsado por UNJS, que es una organización de GitHub que comenzamos al mismo tiempo, diseñada para crear cosas que necesitábamos en Nuxt pero con las que realmente pudiéramos colaborar con personas que estaban en mundos totalmente diferentes, como React, por ejemplo. Sí, me siento muy bienvenido en una cumbre de React. Y ha sido realmente emocionante de ver. Así que cosas como Tailwind CSS usan UNJS, cosas como Angular usan UNJS, y mucho más.

Pero prometí que codificaría en vivo un framework en Nitro, y con toda honestidad les diré que no tengo idea de cómo va a salir esto porque esta mañana, estaba tirándome de los pelos después de darme cuenta en la ducha de que necesitaba cambiar totalmente lo que iba a construir. Así que eso es genial, ¿verdad? Así que aquí tengo un proyecto totalmente vacío. Y vamos a empezar. Voy a añadir NitroPack y h3. Y de inmediato, puedes simplemente iniciar NitroPack directamente.

Así que podrías decir Nitro dev. Y podemos, veamos, podemos abrir eso en el servidor de desarrollo. De hecho, antes de hacer eso, déjame crear una raíz, algo para realmente devolver una respuesta. Así que crearé una raíz de índice aquí. Y simplemente devolveré una respuesta, hola. Y si inicio el servidor de desarrollo nuevamente, tenemos una respuesta. De hecho, si solicitáramos eso en la terminal, verás que incluso tenemos un tipo de contenido HTML.

De hecho, si solicitáramos eso en la terminal, verás que incluso tenemos un tipo de contenido HTML. Pero puedes hacer mucho más. Podrías hacer cosas como devolver un objeto. Simplemente devuelves lo que necesites devolver. Así que en este caso, obtendríamos un objeto. Va a ser una respuesta JSON.

Ahora hay algunas líneas rojas onduladas aquí. Y eso es porque Nitro, por defecto, tiene una serie de patrones de comportamiento que necesitamos que TypeScript ayude al usuario final. Así que tanto el IDE como cualquier paso de verificación de tipos. Así que proporcionamos una configuración TS generada, que le dice exactamente al IDE cómo funcionan las cosas.

Así que en este caso, sabemos que DefineEventHandler se importa automáticamente. Puedes desactivarlo si quieres. Pero también significa que podemos hacer cosas muy interesantes, como imaginar por un momento que quisiéramos crear una raíz aquí llamada foo. Y vamos a devolver esto es foo. Sí, lo es. De hecho, podemos hacer fetch desde eso con seguridad de tipos. Así que podríamos hacer algo como fetch. Y de hecho, ves que obtenemos sugerencias de tipo en las raíces disponibles en esta aplicación en particular.

Y cuando hacemos fetch desde foo, en realidad obtenemos datos que regresan, los cuales están muy fuertemente tipados. También podemos hacer cosas como especificar otros elementos de la API fetch aquí, como un método. Así que podríamos decir que va a haber una solicitud get. E imagina que foo iba a ser, de hecho, una raíz solo de post. Bueno, en realidad, si hacemos eso, ahora vamos a tener un error de tipo porque tenemos que pasar post. Así que hay muchas cosas geniales que podemos hacer con Nitro.

Y algunas de estas cosas incluso... Así que en este caso, estamos realizando una llamada fetch. Podríamos usar simplemente un fetch normal y tener que pasar la respuesta. Eso funcionaría igual de bien. Pero una de las cosas que debería destacar es que no estamos pasando una URL base, porque cuando ejecutas esto en el servidor, Nitro lo sabe y en realidad no realiza una solicitud de red. Realiza una llamada de función interna que emula una solicitud de red.

Significa que no tenemos que tocar la capa de red, y todo es mucho, mucho más rápido. Pero de todos modos, podría perderme en esto. Quiero mostrarte cómo podrías construir un framework full-stack. Así que vamos a agregar un archivo de configuración de Nitro porque probablemente lo necesitemos. En nuestro archivo de configuración de Nitro, vamos a crear un manejador, que va a manejar cada otra raíz, básicamente. Así que podemos crear nuestras raíces basadas en archivos, pero queremos poder renderizar algo de React. Y así vamos a tener una raíz, que va a ser todo, básicamente. Vamos a tener un manejador, y lo vamos a llamar app-server.tsx. También necesitamos pasar alguna configuración de esbuild para decir que jsx es automático, por favor. Y deberíamos crear ese archivo. Así que aquí vamos, app-server.tsx. Y podemos simplemente devolver... Oh, eso es increíble. Bien, simplemente devolvamos... A veces, cuando un compilador es realmente útil, ¿no es así? Este es definitivamente uno de esos momentos. Whoa, eso es increíble. Estoy en un proyecto llamado React Summit.

De todos modos, esto es muy genial. Probablemente deberíamos instalar las dependencias, sin embargo. Así que instalemos React, React-DOM, y los tipos para ellos. Y comencemos nuestro servidor de desarrollo una vez más. Ahora, si accedo, creo que si todavía accedo a mi raíz foo, debería obtener algo... No. Oh, supongo que tengo que hacer un post a él. Debería obtener algunos datos JSON, pero si no, voy a obtener algo de HTML. ¡Yay! Estamos renderizando React. Y probablemente queramos hacer un poco más que eso. Queremos tener una plantilla o algo, algún tipo de documento HTML. Así que diremos, hola, React Summit 2025. Y vamos a necesitar algún cuerpo, eso servirá. Y esa es nuestra plantilla. Eso es lo que vamos a devolver. Ahora, una de las cosas que Nitro tiene es un concepto de almacenamiento de clave-valor, que es agnóstico, como mucho de Nitro. Puede ser desplegado en cualquier lugar. Eso es un valor clave muy importante. Creo que la elección del usuario es uno de los, si no el, valores más fundamentales de la web. Así que tenemos la capacidad de usar una primitiva de almacenamiento, que en este caso vamos a usar algo llamado el prefijo raíz, que son solo los archivos en nuestra aplicación. Y vamos a obtener una plantilla. Almacenamiento. Obtener ítem. Y eso va a ser una cadena. Es index.html. Copilot no puede estar en lo correcto todo el tiempo. Y vamos a renderizar nuestro HTML desde nuestra aplicación. Y luego lo devolveremos como, por favor haz esto por mí. ¿Es correcto? Lo copié. Parece correcto.

Nunca puedes confiar en ello con certeza. Está bien. Esto se ve bien. Así que ahora lo que deberíamos poder hacer es simplemente devolver, simplemente obtener nuestra aplicación. Y ahí vamos. Estamos renderizando HTML en el servidor con un meta framework de pila completa. Genial. Está funcionando.

Añadamos algo de estilo. Añadiremos Pico CSS. Y añadamos nuestra integración del lado del cliente. Así que necesitamos Vite para esto. Esto nos va a dar nuestra rehidratación en el lado del cliente. Así que no es solo HTML y MPA. Queremos tener algo que sea interactivo, ¿verdad? Es una experiencia mucho mejor para nuestros usuarios finales.

Así que hemos añadido Vite. Y ahora solo vamos a ajustar nuestra configuración aquí. Así que vamos a querer un manejador de desarrollo. Esto se ejecuta solo en modo de desarrollo. Y vamos a necesitar algunas importaciones aquí desde H3. Vamos a usar define lazy event handler, define event handler. ¿Qué más necesitamos? Desde node middleware. Creo que eso es probablemente suficiente.

Así que nuestra raíz aquí va a tener un... Usaremos el prefijo Vite. Vamos a necesitar tener un manejador, que en este caso va a ser simplemente un manejador de eventos más perezoso. Y mucho sobre Nitro, sucede cuando es necesario. Así que cuando realmente construyes una aplicación y la usas en producción, cada raíz individual se divide. Así que es una importación perezosa. Esto significa que es capaz de comenzar más rápido.

Y cuando nos movimos de Nuxt 2 con un servidor de larga ejecución, tomó 300 milisegundos iniciar una instancia de Nuxt, una totalmente mínima en producción. Con Nitro, fue menos de un milisegundo. Así que todo el patrón aquí hace una gran diferencia para optimizar los inicios en frío. Y lo que queremos hacer aquí es iniciar el servidor... El servidor de desarrollo es... ¿Qué es? Crear servidor desde Vite, creo. Y vamos a querer pasarle una base. Creo que es una base. Vamos a querer decir que el tipo de aplicación es personalizado. Creo que medio... No, no SSR. Servidor, tal vez? Medio remoto. Ahí vamos. Y vamos a devolver un manejador de eventos en este caso, por lo que es perezoso. Así que no lo creas en primer lugar hasta que sea necesario.

Así que vamos a devolver desde el middleware de nodo Vite, middlewares del servidor de desarrollo. Genial. Vamos a comprobar si eso va a funcionar. Creo que sí. Realmente lo compruebas golpeando Vite y descargando el runtime de Vite. No, eso no funciona. ¿Por qué no? Deberíamos tener Vite. Bien, servidor de desarrollo.

Este es un mal momento para que no esté funcionando, ¿verdad? Base. Tal vez. ¿Quiero root ahora? Base. Tipo de app. Probablemente quiera pasar JSX también, pero ese no es el problema aquí. Tal vez dejemos caer el... Intentemos eso. Sí. Genial. Así que tenemos eso entrando, lo que significa que ahora podemos agregar algo a nuestro HTML y decir que vamos a agregar un script, y va a ser Vite client. Intentemos eso.

Sí. Tenemos Vite funcionando. Pero no está funcionando del todo, por supuesto, porque no hay... Tenemos un evento HMR todo conectado, pero aún no hay una app de React real en el programa. Así que vamos a crear una. Así que si tienes una app de React, exportaremos una función app. Esto es lo que todos hacen, ¿verdad? Parece bien. Y simplemente importaremos eso aquí. Creo que podemos dejar eso. Y simplemente renderizaremos la app aquí. Esperemos que funcione.

Genial. Sigue funcionando. Ahora necesitamos algo del lado del cliente para eso. Lo que vamos a hacer es, creo, vamos a usar React DOM client, y en su lugar tenemos... ¿Qué es? Hydrate root. Así que vamos a hydrate root. Sí. Sí.

¿Quién necesita escribir código ya? ¿Verdad? Excepto que también queremos tener soporte HMR. Así que vamos a persistir esto en la ventana. Así que vamos a exportar app, lo que lo expone como un módulo, lo que significa que podemos hacer cosas con import meta hot. Así que podemos hacer... Oh, creo que probablemente necesito traer nuestro... Sí, referencia. Sí, eso. Vamos a hacer import meta hot except. Y vamos a traer nuestro módulo. Y si hay un módulo app, entonces rehidratamos. Creo que debería ser algo como... Esto. Así que queremos hacer... Veamos, window.root. ¿Es window.root o lo rehidratamos? Creo que haremos window.root render mod app. No tengo idea de lo que estoy escribiendo, pero espero mucho que eso funcione. Intentemos colocar un app client aquí. Y... Bien, tenemos algunas herramientas de desarrollo de React apareciendo. Eso es una buena señal, ¿verdad? Y déjame ver si puedo colocar esto a un lado de la página. Ocultar eso. Y veamos si obtenemos HMR.

No. No lo hicimos. ¿Qué es? Las funciones no son válidas como un hijo de React. Oh, ¿necesitamos hacer esto? ¿Es tan simple como esto? Intentemos eso una vez más. ¡Sí! ¡Ja-ja! Buenas noticias. Agreguemos un poco más aquí. Vamos a incluir algo de estilo. Traeremos Pico CSS.

Y vamos a insertar en SVG. Ahí vamos. Eso debería ser... No, no eso. Otro SVG. Vamos a insertar este. Genial. Y crearé un pequeño botón para demostrar que realmente está funcionando en el lado del cliente. Así que lo que necesitamos es const account setCount es useState. Y luego simplemente renderizaremos un botón aquí. Excelente. Bien, ¿está funcionando? ¡Sí! Increíble.

Así que tenemos una aplicación React renderizada del lado del cliente. Y todo está siendo construido por Vite y Nitro. Ahora, tengo un poco de preocupación aquí. Porque estoy bastante seguro de que nos estamos acercando al final de esta charla. Y probablemente hay mucho más que aún podríamos hacer. Hay tanto que puedes hacer para crear un meta framework. En este caso, tenemos algunos utils realmente, realmente útiles que puedes usar.

Así que solo te mostraré los comienzos. Y no iremos mucho más allá. Pero tenemos una utilidad en Andreas llamada Kitty. Y otra llamada C12. Y puedes construir tu propio CLI muy, muy fácilmente con esto. Puedes traer run main de Kitty. Puedes traer load config de C12. Y puedes pasar cualquier archivo de configuración arbitrario. Y puedes crear muy fácilmente tu propio CLI con solo llamar a run main. Pasando algunos subcomandos. Podríamos traer dev y build.

Y podríamos crearlo. Voy a subir todo esto, por cierto, a GitHub. Así que puedes echar un vistazo. Simplemente llamaremos a esto init. Y lo publicaremos. Pero soy consciente de que se nos ha acabado el tiempo.

Así que no voy a hacer mucho más ahora mismo. Pero siéntete libre de echar un vistazo. Porque voy a subir algunas otras cosas. Así que realmente te mostramos cómo podría ser un CLI. Cómo puedes construir y desplegar ese mismo meta framework que comenzamos.

Habiendo dicho eso, sin embargo. Todo lo que te acabo de mostrar está desactualizado. E irrelevante. Porque esto es lo que hicimos para NUX 3. Y así es como construimos NUX 3. Usamos Nitro bajo el capó. Hacemos muchas, muchas cosas diferentes. Lo configuramos. Lo hacemos funcionar bien con VEET.

Iniciamos un servidor de desarrollo VEET. Pero esto no será necesario en absoluto con Nitro versión 3. Ya estamos en alfa. Y esperamos lanzarlo en beta muy pronto. Viene como un plugin de VEET. Así que no necesitas un meta framework. Simplemente usas VEET y lo colocas en tu configuración de VEET como un plugin.

Utiliza la nueva API de entorno. Tiene soporte incorporado para React. Así que en realidad no tienes que hacer ninguna configuración de eso tampoco. Utiliza estándares web. No profundicé mucho en cómo funciona Nitro bajo el capó. Pero en Nitro versión 2, era su propio formato de evento.

Pero nos hemos movido completamente a eventos de solicitud y respuesta. Así que incluso puedes integrar si quieres Hono o Elysia en tu aplicación Nitro. Y todo funciona bien y se integra perfectamente. Creemos en la fusión con este tipo de movimiento creciente de frameworks para usar este nuevo patrón. Es mucho más rápido que Nitro versión 2.

La versión 2 de Nitro es increíblemente rápida. Pero {{^}}la versión 3 de Nitro es de un orden de magnitud diferente. Porque mucho de lo que hacemos en tiempo de ejecución en Nitro 2, lo hemos movido para ser realmente optimización en tiempo de compilación. Así que cosas como el enrutador. Ni siquiera tenemos una sintaxis de coincidencia. Emitimos declaraciones if-else. Es mucho más rápido. Y usamos un enfoque basado en árboles. Así que no es solo un caso de coincidir con cada ruta posible.

Hay mucho más que decir al respecto. Pero si estás interesado, por favor revisa la documentación de NUX. Y también la documentación de Nitro en nitro.build. No dudes en seguirnos en BlueSky. Ese código QR te llevará a un grupo de personas construyendo cosas en el ecosistema NUX. Puedes buscarme en cualquier red social que desees, excepto Twitter, por razones obvias. Y debo decir que tengo una página en mi sitio web, row.dev.chat. No dudes en ir allí. Puedes reservar una videollamada conmigo en cualquier momento. Estoy más que feliz de charlar sobre cualquier cosa en cualquier forma que pueda ayudar.

Si puedo. Muchas gracias. Particularmente si quieres involucrarte en código abierto, ya sea en NUX o Nitro o en uno de los otros proyectos en los que estoy involucrado, puedo decirte, con seguridad, que serías realmente bienvenido a hacerlo en cualquier proyecto en el que esté involucrado. Pero incluso si es algo totalmente diferente, envíame un mensaje, reserva una invitación en el calendario. Y debo decir que eso es particularmente cierto si no estás seguro de que serías bienvenido. O si no estás seguro de que eres exactamente como los mantenedores del proyecto, me encantaría hacer lo que pueda para ayudar y decirte que ciertamente serías bienvenido en cualquier proyecto que esté manteniendo. Hay mucho más que decir, y lamento haber cubierto solo un poco de la construcción de un framework de pila completa con Nitro, pero ha sido un privilegio estar aquí contigo. Muchas gracias.

Gracias. ¿Quién va a ir a casa y escribir un mejor framework? ¿Sí? ¿Algunas manos en la audiencia? Sí. Así que definitivamente has inspirado a algunas personas a usar las cosas geniales que has construido.

Todavía no tenemos preguntas. ¿Hay algo que no hayas dicho y que tal vez quieras contarle a la audiencia? Bueno, gracias, CJ. Como sucede, había una o dos características que podría haber construido, sí. Bien, genial.

¿Puedes hablar un poco sobre NJS? No sé si la gente está tan familiarizada con él, pero te hemos visto hablar de ello algunas veces. Hay muchas cosas realmente geniales allí, y similar a cómo incluso cosas que no son Vue están usando Vite, muchas cosas que no son como Nuxt o Vue están usando NJS. ¿Puedes hablar un poco sobre el ecosistema NJS? Absolutamente. Así que nuevamente, el concepto central es que debería ser algo que sea universal.

Así que mucho de lo que estamos haciendo allí es crear utilidades que funcionen igual en todas partes, así que en diferentes entornos de ejecución. Así que hay un proyecto llamado unenv, que fue adoptado por Cloudflare, e hicieron un trabajo increíble en él, por cierto. Quiero decir, fue un proyecto colaborativo, pero realmente se sumergieron particularmente al final, y potenció gran parte de la capa de compatibilidad para personas que usan, creo, Wrangler. Hay cosas como crossWS, que está construyendo servidores WebSocket que funcionan sin problemas en todas partes, ya sea Node, Deno, Bun, o lo que sea.

Cosas como OFetch potenciaron la cosa de dollarsignfetch que viste allí. Es una API compatible con Fetch, pero con hooks, desempaquetado automático de respuestas y cosas así. No sé. Hay tanto. Revisa unjs.io. Hay muchas cosas relacionadas con fuentes, en las que estoy particularmente involucrado. No sé. Hay tanto. Sí, hay muchas cosas geniales. Definitivamente sal y explóralo. Eso es todo el tiempo que tenemos, pero muchas gracias. Es un placer. Gracias. Prueba. Prueba.