Optimizando la experiencia del desarrollador con Nuxt 3

Hola, soy Daniel Rowe y hablaré sobre la optimización de la experiencia del desarrollador con Nuxt 3. La experiencia del desarrollador es un tema cercano a mi corazón y creo que eso es probablemente cierto para la mayoría de nosotros aquí hoy. ¿No es cierto? Las herramientas que usamos tienen la capacidad de hacer nuestra vida dolorosa o hacerla mágica.

En este momento estoy hablando en mi papel como miembro del equipo de framework de Nuxt en sí, lo que significa que tengo la oportunidad de mantener y trabajar en el framework junto con una gran comunidad de personas que contribuyen y hacen posible Nuxt. En mi rol anterior, sin embargo, fui CTO de una startup tecnológica. Nuestro producto principal se construyó en Nuxt, por lo que realmente he experimentado Nuxt desde ambos ángulos, tanto como usuario frustrado por los problemas y tratando de resolverlos, como también contribuyendo y solucionando problemas, que fue mi primera forma de contribuir a la comunidad de Nuxt. Pero, por supuesto, ahora también tengo la perspectiva de trabajar en el equipo de Nuxt y realmente voy a estar pensando en la experiencia del desarrollador desde ambas perspectivas hoy.

Esto es donde estoy ubicado. Estoy en el noreste del Reino Unido, ya hace frío y fresco, definitivamente es otoño y aquí es donde me siento la mayoría de los días. Miro mi escritorio y veo a mi gato, uno de mis gatos, tengo tres, pero esa es Lily en la foto, y tengo una taza de café si es por la mañana o una taza de té si es por la tarde, y aquí es donde me gusta estar. Me gusta sentarme y programar o charlar, resolver problemas e intentar mejorar las cosas. Aquí es donde me siento más en la zona. Así que tengo una pregunta para ti, ¿cuándo te has sentido más productivo, más en la zona, en ese estado de flujo del que a veces hablamos como desarrolladores? Tómate un momento, llámalo una pausa, y ve si puedes congelar ese momento en tu cabeza. Puede haber sido que te enfrentabas a un problema. Tenías una gran idea que estabas implementando. Habías estado buscando un error durante mucho tiempo y finalmente lo encontraste. Tal vez hayas publicado una biblioteca y estés viendo cómo llegan las estrellas de GitHub, o hayas visto tu primer PR fusionado. Sea cual sea la razón, parece que estás en la cima del mundo. Así que cuanto más he pensado en mis propios momentos de estar en la zona o hablar con otros que han tenido la misma experiencia, creo que hay muchas cosas que influyen en ellos y es un tema enormemente complejo. Obviamente queremos replicarlo. Es adictivo. Es un momento maravilloso en el tiempo y depende de muchas cosas. Desde tu propio bienestar personal, hasta cuánto has dormido, cuánta cafeína has ingerido, hasta cómo te tratan las personas o si te están dando el valor que te mereces, cómo te sientes contigo mismo. Pero hay algunos factores comunes, creo, cuando se trata de pensar en las herramientas que usamos, que es especialmente, por supuesto, el tema en el que estoy pensando hoy, las formas en que las herramientas que usamos pueden promover ese momento en la zona, pueden promover nuestra experiencia como desarrolladores, y creo que se trata especialmente de estos dos ejes. Por un lado, las limitaciones, las cosas que nos frenan, y por otro lado, la creatividad, las cosas que intentamos hacer, esa sensación de visión o energía o impulso que tenemos. Y ahora, cuando hablo de limitaciones, no me refiero a las limitaciones con las que trabajas cuando intentas encontrar una solución a un problema, como un problema empresarial. Estoy hablando de la limitación que es más como una burocracia que simplemente te detiene, que te impide implementar la idea que podrías tener. Obviamente, eso puede ser una simplificación excesiva, pero creo que se ve una gran experiencia del desarrollador cuando tienes esa creatividad, cuando fluyes, tienes una idea increíble y hay muy poco o nada que te impida realizarla. Así que cuanto más creamos oportunidades para la creatividad y reducimos las limitaciones, creo que vemos una mejor experiencia del desarrollador y eso es realmente donde Nuxt siempre ha buscado posicionarse. No te preocupes si no sabes qué es Nuxt, Nuxt es un framework de vistas, un framework de JavaScript. Es un framework progresivo que

significa que es adecuado para alguien sin conocimiento previo. Puedes empezar a usar NUXT, instalar un proyecto de NUXT y deberías poder comenzar a desarrollar de inmediato. No requiere configuración adicional, funciona de manera predeterminada, pero si necesitas tomar el control total, puedes hacerlo. A medida que comienzas a construir con NUXT, puedes configurar prácticamente cualquier cosa. De hecho, con el ecosistema de módulos y el contenedor de módulos completo, puedes configurar todo sobre NUXT y hacer que funcione de manera completamente diferente a cuando lo comenzaste a usar por primera vez. Es un framework progresivo, pero realmente está diseñado para eliminar mucha redundancia. Esa falta de configuración es extremadamente importante, está en el ADN de NUXT. Así que cuando comiences tu proyecto de NUXT, es posible que veas una carpeta de páginas, simplemente coloca cualquier componente de Vue allí y se convertirá en una ruta de tu aplicación, se dividirá en paquetes, se configurará con el enrutador de Vue, tendrá un nombre. Todas las cosas que antes tenías que hacer como parte de la redundancia de un proyecto de Vue se hacen automáticamente por NUXT. Recientemente, es posible que hayas querido tener un sitio web estático. NUXT permite el renderizado del lado del servidor. De hecho, fue una de las pocas soluciones que lo hizo desde el principio en los días de las aplicaciones de Vue, era algo bastante complicado de configurar y NUXT lo hizo posible y más recientemente, con la generación de sitios estáticos, NUXT también lo hace posible. Muchas otras cosas, desde integraciones con el almacén de VueX hasta el registro automático de middleware. Creo que probablemente lo más destacado es el concepto de módulos. La idea es que si necesitas implementar una aplicación web progresiva o necesitas implementar autenticación, no tienes que hacerlo tú mismo. Si tienes un CMS que deseas integrar u otro servicio simplemente importas el módulo correspondiente y NUXT te permite avanzar con tu idea sin necesidad de retroceder y descubrir la redundancia que requeriría configurar adecuadamente ese servicio o volver a implementar ese concepto. Así que no es necesario reinventar la rueda. El concepto de NUXT es realmente liberarte de las limitaciones y permitirte enfocarte en esa idea, en tu visión.

NUXT 3 sigue el mismo camino. Con NUXT 3, hay muchas cosas de las que hablar, muchas formas en las que hemos intentado mejorar la experiencia del desarrollador, pero hoy quiero centrarme en cuatro en particular. Quiero enfocarme en cómo hemos buscado mejorar la documentación, porque eso puede parecer algo menor, pero creo que es una forma profunda en la que hemos buscado cambiar la documentación, hacer que NUXT sea más fácil de usar para los desarrolladores. Quiero enfocarme en cómo estamos importando automáticamente bibliotecas, funciones auxiliares y componentes. Quiero hablar sobre nuestra experiencia del desarrollador en el servidor. Esta es realmente una forma completamente diferente de abordar la funcionalidad del lado del servidor, y quiero hablar sobre el despliegue y cómo hemos buscado que la experiencia del desarrollador de tomar una aplicación y desplegarla sea sencilla y asombrosa. Primero, profundicemos en la documentación. Y cuando hablo de documentación, permíteme usar el ejemplo del esquema de configuración de Nuxt. El esquema de configuración de Nuxt es un ejemplo de algo para lo que necesitamos una gran documentación. Si vas a la documentación actual de Nuxt2, verás que hay páginas y páginas y páginas de información sobre cómo configurar Nuxt, no es que tengas que hacer esto, pero cuando se trata de tomar el control total de tu aplicación Nuxt, hay muchas formas que proporcionamos para hacerlo. Y eso es parte de lo que significa tener un framework progresivo. Tenemos que dar opciones porque el framework hace mucho trabajo pesado para los usuarios. Pero en el momento en que tienes algo que requiere mucha configuración, significa que es

Es posible que la aplicación en sí y la documentación se desvíen. Por lo tanto, puedes proporcionar una nueva función, pero si no la documentas, no sirve de nada. O si el tipo o la opción cambian para esa nueva función y no lo documentas correctamente, también marca una gran diferencia. Así que con Nuxt 3, tenemos la oportunidad de repensar esto, y hemos creado una solución unificada única para el esquema, la documentación y los valores predeterminados. Aquí tienes un ejemplo. Este es un posible esquema para un elemento de configuración. Este es el propio esquema de configuración que se utilizará en una aplicación Nuxt. Y estos son solo dos propiedades en particular que he extraído. Si la aplicación está en modo silencioso, que es típicamente lo que quieres en producción, y si tiene trazado de rendimiento involucrado, que es típicamente algo que solo quieres en desarrollo. Así que tenemos resolutores especiales que nos permiten establecer cuál es el estado predeterminado para cada uno de ellos si no se proporciona una configuración explícita. Y depende de otra entrada en el archivo de configuración, es decir, si el modo de desarrollo está habilitado o no. Pero lo que realmente espero que te llame la atención es el hecho de que tenemos la documentación ahí. Así que esta es la documentación para nuestro sitio web actual de Nuxt, pero la hemos puesto directamente en el esquema mismo. Lo que esto significa es que cuando estamos editando código o haciendo un cambio, tendremos que cambiar este archivo, y si cambiamos este archivo, tenemos que cambiar la documentación. Eso forma parte de hacer la solicitud de extracción al núcleo. Luego, cuando realmente compilamos la biblioteca, tendremos una documentación y una configuración que son únicas y específicas para esa versión de Nuxt. Produce algo que se ve un poco así en términos de un archivo de esquema de configuración, toda la información, pero más completa, sacando todo, desde los tipos de JSDoc hasta los resolutores reales e incluso produciendo un archivo de valores predeterminados separado solo para darte algo con lo que puedas interactuar programáticamente. Y también tenemos las utilidades que te permiten consumir un archivo como este. Y todo esto se lanza bajo un proyecto llamado sin tipos, que estamos haciendo público y se puede utilizar en cualquier framework. Entonces, cuando se trata de interactuar con tus Nuxtats, cuando intentas configurarlo, significa que podemos extraer toda la documentación de tu carpeta de módulos de nodo, donde se encuentra, en tu editor. Entonces, mientras estás editando esa configuración y quieres establecer una de las opciones, puedes ver toda la documentación que tenemos. No es muy extensa en este caso particular, habría algunas opciones que tendrían mucha más información, incluyendo ejemplos de código, enlaces a otros sitios web y todo tipo de información adicional. Pero debería darte una idea de la funcionalidad y el poder de esta capacidad. El hecho de que realmente podamos tomar la documentación y ponerla justo ahí mientras escribes significa que, con suerte, tu experiencia como desarrollador mejorará drásticamente. No necesitarás buscar en la documentación en línea. No necesitarás ni siquiera descubrir cuál es la pregunta. Con suerte, el beneficio de que todo esté completamente tipado y documentado a medida que avanzas marcará una gran diferencia. Es el tipo de cosa que marcaría toda la diferencia para mí. En segundo lugar, tenemos esta funcionalidad de importaciones automáticas. Estarás familiarizado con esto si has utilizado el módulo de componentes de Nuxt, que se puede habilitar simplemente estableciendo components true en un proyecto de Nuxt 2, pero ahora esto está integrado en Nuxt 3. Así que todos los componentes que coloques en tu directorio de componentes estarán disponibles para que los importes automáticamente en

Uso de componentes. Entonces, si estás utilizando ese componente en otro archivo, en una página por ejemplo, se incluirá automáticamente en esa página. O puedes decir que es una importación perezosa y luego se generará como un fragmento separado, tal vez si lo muestras condicionalmente o algo así. Bueno, hemos llevado esto un paso más allá. Ahora no se trata solo de componentes, sino también de funciones auxiliares y bibliotecas. Realmente estamos aprovechando los beneficios de tener un framework aquí. Por lo tanto, algunas de estas cosas serían imposibles si no estuvieras pensando en un framework, algo que tiene control tanto sobre el bundler como sobre el transformador de código, pero es posible con Nuxt. Esto significa que en cualquier parte de tu código puedes usar funciones comunes como ref, watch, computed o use router, o incluso composables específicos de Nuxt como use meta. Simplemente los usas. Nuxt se dará cuenta de que los has utilizado en ese fragmento. Generará automáticamente las importaciones que se requieren y eso significa, por supuesto, que también podemos hacer una organización eficiente del código en tiempo de compilación. Entonces, cuando lo usas, tienes la importación y cuando no lo usas, no necesitas importar nada en absoluto. Esto es cómo podría verse, por ejemplo. Entonces, si estás trabajando en un componente, deberías poder escribir. Ahora, define pops, debo decir que es solo una macro del compilador, pero deberías poder usar cosas como use meta, que te permite acceder a los metadatos de una página, o ref, que es una utilidad de vista y con tipado completo. No es específico de tu memoria o algo así.

eso. Y eso obviamente también se refleja en la plantilla. En tercer lugar, te permitimos algunas mejoras importantes para los desarrolladores en el lado del servidor. Así que el nuevo framework de servidor de NUXT 3, y esto también es cierto para NUXT 2 si estás usando bridge. De hecho, varias de estas características son comunes a NUXT 2 si estás usando bridge. Hemos construido un nuevo framework HTTP llamado H3. Es ultra minimalista, por lo que es absolutamente pequeño. Es más rápido que muchos de los otros frameworks disponibles. De hecho, no conozco uno más rápido. Tiene muchas utilidades pequeñas como use cookie, o use body, use query que te permiten hacer cosas que podrías querer hacer para las solicitudes, pero que se pueden eliminar del árbol de dependencias para que no se inyecten de forma predeterminada. Es multiplataforma, por lo que se ejecuta tanto en un navegador como en un Service Worker o un entorno Node, lo que significa que tu aplicación de NUX no tiene que estar compilada para un objetivo específico. No se espera que se ejecute solo en un entorno Node y te permite hacer cosas como simplemente devolver el objeto JavaScript desde un controlador de solicitud. No tienes que convertirlo a una cadena JSON y establecer el encabezado del tipo de contenido, o simplemente puedes lanzar un error y no tienes que preocuparte por devolver correctamente una respuesta a esa solicitud en particular. Todo se maneja automáticamente. Además, tenemos algo llamado un fetch isomórfico. Un fetch isomórfico es básicamente una utilidad que te permite realizar una llamada a una función local si se está ejecutando en el servidor, pero una solicitud de red adecuada si se está ejecutando en el cliente. Entonces, tu nuevo servidor de NUX 3, que es, por cierto, generado como un solo archivo en lugar de un directorio de muchos archivos, no tiene una dependencia de tiempo de ejecución en NUXed. Es completamente independiente. Es todo lo que necesitas para ejecutar tu aplicación y ejecutar ese servidor, pero no tiene ninguna dependencia de tiempo de ejecución de ninguna de las características de NUXed que hacen esto posible.

Y esto es un poco de cómo se ve. Lo primero que cualquier solicitud encontrará es este orquestador impulsado por H3 que decidirá qué partes del código son necesarias para renderizar una respuesta a esa solicitud en particular. Entonces, si es solo uno de los puntos finales de la API, no cargaremos todo el paquete de vista, no cargaremos el renderizador de vista ni nada por el estilo. Solo cargaremos el código que se necesita. Si es una página, por ejemplo, en tu aplicación de vista que podría ser cargada, y esa página podría tener una dependencia y podría querer hacer una solicitud a una de las API con las que comparte espacio en ese servidor, donde no tiene sentido enviar esa solicitud a la capa HTTP y hacerla como una solicitud HTTP adecuada. Además, eso sería terriblemente ineficiente en algo como una función serverless. Realmente no quieres volver a golpear el punto final. El código está ahí. Solo necesita cargarse en memoria. Y este fetch, esta función $fetch, fetch isomórfico del que estamos hablando, le dice a H3 que cargue este código y nos dé la respuesta. Es una forma increíblemente eficiente de obtener una respuesta de un punto final serverless. Y

simplemente funciona. No solo funciona, también está completamente tipado. Por lo tanto, puedes crear un punto final serverless, digamos tiempo, que nos dará la marca de tiempo de una solicitud en particular. Y eso simplemente devolverá un número. No tenemos que manejar ese número de ninguna manera. Será pasado correctamente por el fetch isomórfico. Y en realidad podemos esperar a que se obtenga ese número. Pero lo increíble es que TypeScript realmente conoce el tipo de lo que ese fetch isomórfico nos va a devolver. Eso es bastante mágico, si me lo permites decir. Y obviamente podríamos tener algo un poco más complejo donde no solo devolvemos un número, sino que también necesitamos acceder a los objetos de solicitud y respuesta predeterminados en Node. Por cierto, esos están tipados de la misma manera que una solicitud y respuesta normales en Node, aunque H3 H3 no se esté ejecutando en un entorno Node, se simulará para tener la misma forma. Por lo tanto, podrías acceder a algo como la URL de la solicitud o puedes llamar a res.end si realmente quieres, aunque mucho de el poder de H3 es que no necesitas hacer eso y puedes devolver directamente tu JSON o interactuar directamente con los parámetros. Eso sería totalmente posible. Podrías lanzar un error y que se maneje automáticamente o podrías acceder a los objetos de solicitud y respuesta y eso debería funcionar perfectamente. Todo eso significa que debería ser posible mejorar drásticamente la experiencia del usuario con el servidor de Nuxt 3. Y creo que hay muchas más mejoras que podremos ofrecer en las próximas semanas y meses. Así que estén atentos y definitivamente avísenme si tienen alguna idea. Por último, el despliegue. Y esto es algo que creo que importa mucho porque ejecutar un servidor Node es una cosa. Tiene muchos requisitos particulares que pueden ser diferentes, por ejemplo, de ejecutar un script basado en PHP o algo así. Por lo tanto, para Nuxt 3, hemos buscado hacer esto lo más simple posible. Primero, como mencioné, solo hay un punto de entrada que necesitas para tu aplicación Nuxt 3. Podría ser simplemente ejecutar node.output server server.mjs. Así es como podría verse eso. Por ejemplo, simplemente construye tu aplicación. Es increíblemente rápido. Nuevo CLI. He habilitado los tiempos en este ejemplo en particular. Así que verás cuánto tiempo tarda en iniciarse. Tres milisegundos de inicio en frío. Y acabo de realizar mi solicitud en otro

window. Ahí lo tienes. Así que puedes ver cuánto tiempo tarda en cargar cada parte del controlador de solicitudes. Solo milisegundos. Porque podemos generar solo un runtime único, significa que podemos desplegar en muchos más destinos de los que podríamos hacer antes. La aplicación completa puede ser empaquetada en 100 kilobytes, en lugar de algo como 5 o 10 megabytes, como podría haber sido antes si intentabas desplegar en una función lambda. Pero además de eso, muchas de las mejoras que hemos podido traer a algo como Nux Nitro han hecho que ahora seamos multiplataforma. Ya no necesitamos un entorno de node, siempre y cuando las dependencias de tu aplicación no lo requieran. Por lo tanto, puedes desplegar directamente en un Cloudflare o en un service worker del navegador o en Deno, y habrá más. La salida de Nitro, el nuevo servidor NUXT es capaz de ser desplegado en casi cualquier lugar que puedas imaginar. Y nuevamente, se trata de eliminar restricciones. No tienes que averiguar cómo hacer que el servidor NUXT que obtienes al final del comando de construcción se ajuste a la configuración de despliegue que tienes. Debería funcionar sin problemas. A partir de la fecha de lanzamiento, NUXT3 tiene soporte de configuración cero para varias plataformas, especialmente notable en Netlify y Vercel, donde no se requiere configuración alguna. Pero eso también es cierto en cierta medida con Cloudflare, con Azure functions, Azure Static Web Apps. Es cierto con Firebase con una configuración mínima y habrá más. Nitro permite una increíble experiencia de desarrollo desde el punto de vista del despliegue. Realmente esperamos cualquier comentario que tengamos al respecto. Queremos que sea lo mejor posible. Si algo de lo que he dicho te ha impactado, por favor, házmelo saber. Nos gustaría hacer que Nuxt 3 sea lo más increíble posible y retroportar tantas de estas características como sea posible a tus aplicaciones de Nuxt 2, para que puedas beneficiarte de todo esto hoy mismo, incluso antes de migrar o construir una nueva aplicación con Nuxt 3. Consulta la documentación en nuxtest.org. Ten en cuenta que algunas de ellas son generadas automáticamente, como prometí. Síguenos en Twitter y únete a nuestro servidor de Discord si quieres compartir ideas. Y luego, por supuesto, por favor, contáctame directamente, porque realmente valoraría eso enormemente. Ha sido un verdadero placer. Y si hay algo que pueda hacer para ayudar, no dudes en hacérmelo saber. Gracias.