Construyendo un Mejor Martillo - La Historia de Nuxt 4

Es un placer estar aquí hoy y hablar sobre la construcción de un mejor martillo, la historia de Nuxt 4. Mi nombre es Daniel Rowe. Actualmente lidero el equipo principal de Nuxt. También estoy involucrado en otros proyectos de código abierto. Tengo el privilegio de ser un mantenedor de código abierto a tiempo completo.

Además de Nuxt, también estoy involucrado en la construcción de Nitro. PageSpeed.dev es un divertido proyecto para consultar las estadísticas de velocidad de página de Google y las API de Core Web Vitals de una manera compartible. RegExp.dev. Magic RegExp es una biblioteca que hace que las expresiones regulares sean seguras en cuanto a tipos, pero se compila en tiempo de compilación. Fontane ayuda a reducir el cambio de diseño acumulativo en las fuentes web y mejora tus Core Web Vitals. ElkZone es un cliente para Mastodon. FirstCommit.is encontrará el primer commit de alguien en GitHub, y puedes encontrar todo esto y más en mi sitio web, Rowe.dev.

Bueno, aquí es donde estoy parado en este momento. Solo Bali, mi gato, ha sido excluido de la habitación, pero sí, normalmente me impide escribir mucho código cuando estoy en casa. Es extremadamente dulce, pero necesita muchos mimos cuando los quiere. Hoy estoy hablando de Nuxt y de construir un mejor Nuxt y mirando hacia el futuro a Nuxt 4. Y si no estás familiarizado con Nuxt, creo que lo más importante de Nuxt, desde mi punto de vista, es un framework para construir aplicaciones web de pila completa, y está construido sobre Vue y sobre Nitro como componente del servidor.

Lo más importante para mí es que es progresivo. La idea es que comienza con las mejores prácticas incorporadas tanto como sea posible, y luego se adapta a medida que creces. Entonces, a medida que desees cambiar las cosas, puedes hacerlo. Si necesitas personalizarlo, puedes hacerlo. Es una plataforma que esperamos mejore la experiencia del desarrollador, haciéndola intuitiva, pero sin limitarte cuando necesites hacer cambios.

Y Nuxt fue creado por primera vez en octubre de 2016 por Sebastian Chopin. Y puedes ver una pequeña línea de tiempo del proyecto. Las versiones 1 y 2 llegaron bastante rápido después de octubre de 2016. Comenzamos a trabajar en la versión 3 en 2020. Vue se había actualizado a la versión 3, que es un gran cambio rompedor. Webpack se había actualizado a la versión 5, otro cambio rompedor. Y luego, a mitad de la construcción de la versión 3, salió Vite, que era un constructor completamente nuevo con una increíble DX. Así que la versión 3 tardó bastante tiempo. Se lanzó en noviembre de 2022. Y ahora estamos en camino a la versión 4, que esperamos que salga en junio de 2024.

Nuxt, estamos mostrando estas cifras, solo para decir, son en cierto modo métricas de vanidad. No son muy precisas porque esta es solo la estadística de NPM o GitHub, pero tenemos 51,500 estrellas, 29 millones de descargas y estamos viendo un aumento en la adopción. Entonces, el 62% de las instalaciones de Nuxt ahora están en Nuxt 3 en comparación con Nuxt 2. Estas son cifras en tiempo real, por cierto. Así que cada vez que veo esta diapositiva, es un poco diferente. Y tenemos una gran cantidad de personas que hacen que Nuxt sea lo que es. En realidad, esta es una cifra mucho más importante que las descargas de NPM porque Nuxt es en gran medida un producto de la comunidad y el ecosistema. Entonces, no estamos patrocinados por una gran corporación. Todo el equipo que construye Nuxt son mantenedores de código abierto, al igual que nuestra comunidad. Y nuestra dirección y lo que creamos y cómo lo construimos está muy influenciado por lo que necesitamos como un esfuerzo de la comunidad. Y honestamente, es una de las cosas más agradables de Nuxt y de colaborar con personas de la comunidad de código abierto. Y eso es la amistad y camaradería que tenemos como parte de la comunidad. Y hay más de 680 colaboradores.

Quiero hablar sobre la construcción de un mejor martillo, la historia de Nuxt 4. Y cuando digo construir un mejor martillo, probablemente pensarás, y eso es lo que pretendo, en la expresión de que para alguien con un martillo, todo parece un clavo. Y eso es inevitable, creo.

A medida que adquieres habilidades o comprensión o conocimiento de una herramienta en particular en tu caja de herramientas como un artesano de la web, puede resultar tentador intentar hacer todo con ella. Y eso, en términos generales, no es una buena idea. Somos personas que construimos cosas con un propósito. Y tenemos herramientas para eso. Así que podemos usar diferentes herramientas. Podemos usar diferentes bibliotecas, diferentesframeworks. Y eso está totalmente bien. Por cierto, no quiero decir que Nuxt deba ser el todo y el fin de todo para todos. Pero quiero hacer que Nuxt sea más usable y extensible para que sea un mejor martillo. Para que puedas usarlo para más cosas, que se pueda usar con clavos, tornillos y otros tipos de cosas diferentes. Y debería ser usable en muchas circunstancias diferentes.

Entonces, ¿por qué? ¿Por qué quiero que sea así? Bueno, uno de los motivos es que puede reducir la carga cognitiva. Si sabes cómo funciona algo y esa herramienta es lo suficientemente flexible como para adaptar la salida a tus necesidades, de modo que no tengas que cambiar la entrada, eso cambia mucho tu experiencia como desarrollador. No tienes que aprender a usar una nueva herramienta porque la que ya tienes es lo suficientemente flexible como para adaptarse a lo que necesitas en ese momento. También puedes aprovechar el poder de la convención.

Por ejemplo, en un proyecto enterprise donde se incorporan nuevas personas al equipo, no es necesario enseñarles una forma particular de hacer ese proyecto en particular. Funcionará como se espera. Y esto es el poder de la convención, ya sea en Nuxt o en otros proyectos. Por ejemplo, Tailwind CSS ha tenido éxito gracias a la convención, creo. Y esto significa que un nuevo desarrollador que se una a un proyecto de Tailwind CSS no necesita entender exactamente cómo se ha configurado el CSS. Básicamente, ya lo saben. Saben cómo funciona. Saben cómo se construyen los estilos y cómo agregarlos al HTML, ya sea en un proyecto de React o de Vue o cualquier otro. Pero lo que no quiero, y la razón por la que intento mejorar Nuxt, no es conquistar el mundo. Esto no es un juego de suma cero. Y no estamos tratando de derrotar a otrosframeworks. Y creo que eso es algo que me encanta de las comunidades de Vue y Nuxt, es que no somos así.

No queremos hacer eso. Lo que estamos tratando de hacer es crear algo genial e increíble y mejorar la vida de las personas en el proceso. No se trata de derribar a otras personas o desplazarlas. Espero sinceramente que no nos identifiquemos con la herramienta que usamos, pero sí quiero hacer de Nuxt una mejor herramienta para todo tipo de propósitos.

En el camino hacia Nuxt 4, en realidad en el camino hacia Nuxt 3, diré que se cometieron errores. En realidad, esa no es una buena forma de decirlo. Digamos en cambio que nos equivocamos en algunas cosas. Y creo que probablemente si echas un vistazo a este pequeño gráfico de nuestros principales lanzamientos hasta ahora, probablemente puedas ver en qué nos equivocamos. Lo más obvio es que tardamos demasiado en llegar a la versión 3. Y de alguna manera, eso no fue culpa de nadie en particular. Hubo muchas razones, buenas razones por las que nos llevó tanto tiempo, pero creo que aún así es algo en lo que nos equivocamos y reconocemos como equipo central que ese es el caso. Y me gustaría mencionar brevemente algunas cosas que aprendimos de eso.

Una de ellas es que el alcance y el tiempo no son entregables al mismo tiempo. No puedes entregar la visión completa de lo que quieres y hacerlo en el mismo tiempo que pronosticaste. Oh, supongo que a veces puedes, pero si no puedes, debes elegir uno de ellos. No puedes cumplir con ambos. Y puede generar una gran cantidad de estrés si intentas hacerlo. Esa es una de las razones por las que ahora tenemos un calendario de lanzamiento fijo basado en el tiempo. Cada semana, tenemos una corrección, prácticamente. Cada mes, tenemos un lanzamiento menor con características. Y cada año, nuestro objetivo es tener un lanzamiento mayor. Por eso ahora estamos llegando a NUXT 4.

Aprendimos sobre la importancia del ecosistema y de llevar consigo las bibliotecas dependientes de NUXT. Por ejemplo, la actualización importante de Vue llevó mucho tiempo debido a todos los paquetes dependientes de ella, entre los cuales estaba NUXT. Y luego NUXT en sí tenía muchos paquetes y módulos dependientes de él. Y todos ellos también tuvieron que venir. Aprendimos mucho de que depender de los internos de un proyecto como NUXT hace que sea muy difícil cambiarlo porque esos internos son lo primero que cambia cuando se introduce un cambio rompedor. Y significa que se rompen grandes partes del ecosistema, por eso introdujimos NUXT Kit, pero más sobre eso en un momento. Y aprendimos que reparar un coche en movimiento, es decir, cambiar el motor mientras intentas mantenerlo en movimiento, tal vez no sea una buena idea. Así que todas esas son cosas que estamos tratando de cambiar en NUXT 4.

Y espero que estas sean cosas relevantes para cualquier persona en un proyecto que busque realizar cambios importantes. Estas son cosas que hemos aprendido de la manera difícil.

Entonces, aquí hay algunas cosas que estamos tratando de hacer. Y la primera es que nos basamos en el ecosistema de módulos. Y hay un par de cosas que quiero destacar sobre el ecosistema de módulos que nos ayudan a medida que avanzamos hacia NUXT 4. Y la primera es que es profundamente enganchable. Por lo tanto, puede engancharse en cada parte de NUXT y Nitro, desde la compilación hasta el código en tiempo de ejecución. Y todo esto está impulsado por hookable, que es realmente una API increíble desarrollada por Puya Parsa. Échale un vistazo. Admite muchas cosas diferentes para Go DX, incluida la integración de herramientas para desarrolladores y la integración con la tarea de creación de consola, lo que ayuda mucho a que los navegadores muestren los registros correctamente.

Y NUXT también es enganchable. Por lo tanto, las diferentes cosas que puedes usar dentro de NUXT son intercambiables, si podemos hacerlo así. Ya sea el bundler, espero ver pronto el soporte de RSPack para NUXT, o incluso los módulos ad hoc que construimos y que aún son los módulos principales de NUXT. En realidad, son enganchables y se pueden reemplazar, o la capa arquitectura que exponemos al final del día a los usuarios finales. El objetivo es que gran parte de NUXT pueda adaptarse y moverse dependiendo de tus necesidades.

Y todo eso lo hacemos posible de construir fácilmente en NUXT. Por lo tanto, los módulos pueden ser creados y distribuidos, ya sea en un mono repositorio local o en un registro interno o publicados en NPM. Proporcionamos herramientas para hacer posible construirlos. Son consultables desde el conjunto de datos de módulos de NUXT, que es solo un repositorio en NPM. También tenemos una API para ello. Y tenemos un SDK componible de NUXT. Por lo tanto, las personas pueden construir un módulo para NUXT 3, y cuando lancemos NUXT 4, ese módulo debería seguir funcionando siempre y cuando siga utilizando las utilidades componibles que provienen de ese kit SDK.

Esas son algunas estadísticas. Por lo tanto, los módulos son módulos que se han registrado en el registro. Tenemos más de 205 de ellos. Tenemos 170 mantenedores, más de 1,000 colaboradores, 130,000 estrellas y 12 millones de descargas hasta el día de hoy, supongo. Y puedes ver las estadísticas tú mismo de esa manera. Solo una demostración rápida de cómo se ve eso para la experiencia del desarrollador. Entonces, si inicio un proyecto, que tengo en ejecución aquí en segundo plano, y abro las herramientas de desarrollo, puedo ver muchas cosas sobre mi proyecto. Y no entraré en todos estos detalles, pero puedo abrir el panel de módulos y decir buscar para instalar uno nuevo. Puedo instalar el módulo de fuentes, que es relativamente nuevo. Lo construí probablemente hace un mes, un par de meses, y varios colaboradores y yo hemos estado impulsándolo rápidamente. Por lo tanto, podemos instalar el módulo de fuentes de NUXT en segundo plano, NUXT se reiniciará, el módulo se ha agregado a mi configuración y ahora puedo hacer algo. También verás que tengo un pequeño panel de herramientas de desarrollo aquí, que muestra que no hay fuentes web personalizadas en uso. Puedo habilitar, por ejemplo, poppins. Y al instante obtendremos las herramientas de desarrollo actualizadas, tendremos información sobre las fuentes que se utilizarán en este proyecto. También ahora están siendo proxy localmente en el proyecto. Y cuando lo construyas, formará parte de tu proyecto, no habrá solicitudes de terceros. Y también inyectamos un poco de CSS mágico para que haya cero o la menor cantidad posible de cambio de diseño cuando se carga la página. Y toda esa experiencia, nuestro objetivo es hacerla lo más simple y fluida posible para las personas que usan NUXT.

Y así, cualquier módulo que se pueda crear, sin importar el proveedor con el que se integre o la función que tenga como objetivo resolver, queremos que mejore la experiencia del desarrollador y reduzca esa carga cognitiva y fricción tanto como sea posible. También queremos priorizar la elección del usuario.

Entonces, una de las cosas que notarás cuando comiences a integrarte con NUXT o a construir sobre él es que tenemos muchas integraciones intercambiables. Ya sea nuestro componente de imagen de NUXT, que admite más de 20 proveedores de imágenes, ya sea la integración de KV y caché o la integración de la base de datos, que en sí mismas admiten muchos y diferentes backends.

El objetivo es que NUXT exponga primitivas únicas que funcionen de manera consistente sin importar qué proveedor uses. Tenemos más de 90 proveedores y el objetivo es que los usuarios puedan elegirlos según sus necesidades, pero no en función de ninguna restricción que NUXT les imponga. Esto realmente está en nuestro ADN. Nunca querría que la elección, la respuesta para cualquier usuario que me pregunte a qué proveedor implementar o qué base de datos usar, dependa de NUXT. Siempre debería depender de las necesidades del usuario y lo que quieran hacer, ya sea el precio o la experiencia del desarrollador desde su punto de vista, pero no debería ser NUXT quien los limite. Siempre queremos que NUXT se enfoque en la libertad e independencia del usuario. Y creo que eso es exactamente hacia donde apuntamos y donde queremos estar como proyecto.

Así que, mirando hacia NUXT 4, el peligro es que NUXT es un marco de trabajo establecido. Tenemos una larga lista de usuarios que dependen de nosotros. Esto incluye empresas que no quieren que sus productos se rompan, así como agencias o desarrolladores independientes que necesitan construir rápidamente y quieren que las cosas simplemente funcionen.

Una de las formas en que logramos esto es enfocándonos en la estabilidad. Tenemos un calendario de lanzamiento confiable del que hablé y podemos realizar pruebas antes de cada lanzamiento contra Ecosystem CI, que se toma del proyecto VEET. Dominic fue pionero en Ecosystem CI, que es una forma de probar las dependencias aguas abajo para asegurarse de que la última versión no las rompa. Y lo hacemos antes de cada lanzamiento.

Eso significa que podemos lanzar cosas que, esperamos, sean innovadoras, ya sea que se trate de componentes del servidor, almacenamiento en caché de compilación, reglas de raíz en línea o federación de módulos NUXT. Podemos construirlos, probarlos y asegurarnos de que los proyectos de los usuarios no se vean afectados, pero que las personas puedan optar por ellos. También tenemos la capacidad de exponer muchas de las características de prueba que usamos en NUXT a través de utilidades de prueba para nuestros usuarios finales. Ellos también pueden probarlas. Estamos colaborando con Ecosystem CI para mejorar la experiencia de NUXT, pero también Vue utiliza Ecosystem CI y NUXT está incluido en eso. VTest también utiliza Ecosystem CI y NUXT test utils está incluido en eso. Estamos profundamente integrados entre nosotros.

Cuando lanzamos algunas de estas características, lo hacemos en espacios de nombres futuros, para que las personas puedan optar por mejoras futuras y también volver a la funcionalidad anterior. Pronto lanzaré una acción de prueba aguas abajo, para que las personas puedan beneficiarse de la misma experiencia de Ecosystem CI, pero sin necesidad de que su repositorio sea de código abierto. Nuestro objetivo es poder exponer la migración incremental de código.

Por ejemplo, cuando detectamos un cambio que rompe la compatibilidad con una posible mejora, podemos implementar ese cambio a través de una solicitud de extracción en todo el ecosistema de módulos. Será compatible hacia adelante y hacia atrás, ya sea que los usuarios estén utilizando NUXT 3 o NUXT 4. Ya hemos hecho eso para tres cambios diferentes que vendrán en NUXT 4. Esperamos que lo mismo sea cierto para otros cambios que planeamos lanzar. Es fácil incluir a las personas. También tenemos la intención de incluir modificaciones de código cuando realmente lancemos NUXT 4, para que la migración sea sencilla y simple. Si mantienes una biblioteca aguas abajo, no dudes en abrir una solicitud de extracción para agregarla y realizar una prueba en Ecosystem CI de NUXT, y garantizaremos que no la romperemos, al menos sin avisarte primero. Y nos comprometemos con el estándar de referencia. El proyecto DX de la plataforma web es excelente. Te recomiendo que veas cómo se ve la referencia en MDN, por ejemplo. Y hay cosas nuevas y emocionantes que planeamos construir, pero no entraré en detalles ahora. Pero todo esto se basa en la estabilidad garantizada por Ecosystem CI y otros proyectos. También podemos ver cuántas personas utilizan algunas de las nuevas características que construimos.

Y eso nos ayuda a tomar decisiones sobre lo que priorizamos. Todo esto es completamente opcional, por cierto. Tendrás que dar tu consentimiento si quieres que lo sepamos. Pero te recomendaría encarecidamente que lo hagas, porque es realmente útil como equipo. Valoramos eso.

Entonces, ¿qué hay de NUXT 4? Creo que lo primero que hay que decir es que no se trata de la publicidad. Por lo tanto, el objetivo es seguir SEMVA, lo que significa que solucionamos errores y parches todas las semanas. Agregamos nuevas características en versiones menores cada mes. Entonces, NUXT 4 no serán características que hemos estado reteniendo. Se lanzan cada mes.

NUXT 4 se trata de cambios reflexivos y significativos. Por lo tanto, las oportunidades para cambiar la API cuando sea necesario de una manera que, con suerte, sea opcional. Cambia los valores predeterminados, pero no rompe tu proyecto. Y, en la medida de lo posible, quiero que NUXT 4 no se trate de la publicidad. Quiero que sea una oportunidad para que nos centremos en una buena experiencia de migración y, de alguna manera, demostrar que podemos ofrecer una versión importante sin el dolor que muchos aquí habrán experimentado, por ejemplo, en la versión 3.

Habrá algunas cosas que puedo adelantar. Así que tenemos una nueva estructura de directorios en camino, una estructura de directorios predeterminada a la que puedes optar volver a la anterior. Habrá valores predeterminados más eficientes en cosas como cargas reactivas superficiales, configuración en tiempo de ejecución no reactiva, tal vez, utilizando la caché nativa del navegador y aplicando algunas mejores prácticas. Por lo tanto, analizar y construir un gancho de observación o eliminar el booleano pendiente de nuestros componibles de búsqueda de datos. Si estás interesado, puedes encontrar los cambios próximos con una etiqueta 4.x en el repositorio de NUXT. Y si quieres ayudar, nos encantaría eso. Esperemos que hayamos lanzado una mejor experiencia de documentación recientemente. Sebastian y Anthony han estado muy involucrados en eso. Puedes unirte a Discord. Hay un canal de contribución donde puedes enviarme un mensaje directamente. Y si estás involucrado y quieres estarlo, hay un nuxters.nuxt.com que te dará un rol especial en Discord y una pequeña tarjeta que puedes compartir. Y si estás interesado o quieres involucrarte en código abierto, ya sea en Nuxt u otro proyecto, no dudes en contactarme. Tengo disponible un calendario para charlas de 10 minutos. Y especialmente si crees que no estás seguro de si serías bienvenido o tal vez no te pareces a algunos de los otros colaboradores que ya están en el proyecto y sientes que podrías estar llegando desde afuera, por favor, por favor, no te sientas así. Y por favor, reserva una llamada.

Me encantaría decirte en persona que nos encantaría tenerte y que serías muy bienvenido. Y si hay algo que pueda hacer para ayudarte en tu camino, ya sea en Nuxt o en otro proyecto, me encantaría hacerlo. Así que echa un vistazo a la documentación de Nuxt. Síguenos en Twitter. Únete a Discord. Puedes esperar el lanzamiento de Nuxt 4 muy pronto, apuntando a junio de 2024. Muchas gracias. Ha sido un verdadero placer estar aquí hoy.

Primero, intentemos discutir los resultados de la encuesta. Podemos ver que el 88% está emocionado por Nuxt antes. Pero el 12%, creo que estoy en ese grupo, está emocionado por la versión 3.12. ¿Cuál es tu expectativa al respecto? Bueno, honestamente, pensé que habría más personas emocionadas por la versión 3.12. Porque honestamente, ahí es donde vamos a lanzar... Y para ser justos, fue injusto hacer esta pregunta antes de mi charla, porque espero que después, ahora estés pensando que la versión 3.12 es tal vez donde vendrán las características. Y eso es lo que... Creo que estoy bastante emocionado por la versión 3.12. Eso es lo que quiero... Quiero ver a más personas emocionadas por eso. Porque... Sí.

Sí, pero en realidad, estaba pensando lo mismo. Es como Nuxt 4 para el futuro en este momento, la nueva versión que estabilizará todo lo que tenemos. Así que eso es genial.

Intentemos discutir algunas de las preguntas que tenemos de la audiencia. La más votada es sobre ¿qué tan difícil es aprender Nuxt si tengo experiencia con aplicaciones de una sola página de Vue? ¿Qué piensas, Daniel? En su mayoría, lo que tendrás que hacer si quieres migrar una aplicación de una sola página de Vue existente a Nuxt es eliminar código. Entonces, si tienes un archivo app.vue, simplemente puedes copiarlo. Si tienes enrutamiento basado en páginas, simplemente cópialos en tu directorio de páginas. Y Nuxt hace muchas cosas adicionales. Pero prácticamente todo es opcional. Entonces, si no lo estás usando, si solo tienes tu configuración existente, debería funcionar bien.

Si tienes algún problema con eso, avísame, porque estaría encantado de ayudarte. Pero creo que debería ser una migración muy, muy sencilla. Y luego puedes usar básicamente otras características de Nuxt como desees. Así que debería ser una migración muy sencilla. Agrega cosas, en lugar de deshabilitar cualquier funcionalidad que estés utilizando. Tiene sentido. Sí.

Veamos si las personas que hacen esta pregunta pueden probarlo y hacernos saber cómo les fue. Y tenemos otra pregunta que hizo Kishu, en realidad. Dado que la mayoría de los colaboradores en Vue y Nuxt no son patrocinados por empresas, ¿crees que aún podrían dedicarse al código abierto a tiempo completo sin depender de una empresa? Por supuesto. Quiero decir, una de las cosas que diría, ya sabes, si estás trabajando en código abierto, cualquier camino que elijas para que funcione está bien. Así que no quiero emitir ningún tipo de juicio sobre cómo funciona eso. Todos estamos encontrando nuestro camino de muchas formas diferentes. Entonces, si eso implica ser patrocinado por una empresa, también está bien. Sucede que los frameworks son independientes, lo cual creo que es fantástico. Eso no significa que los colaboradores individuales necesiten serlo. ¿Y es posible dedicarse al código abierto a tiempo completo? Sí, creo que sí. Así que es posible para mí, y creo que también para otros. Pero no haría de eso el objetivo principal. Quiero decir, no aspiro, mi objetivo no es trabajar a tiempo completo en código abierto. Estoy haciendo eso, estoy encantado de poder hacerlo, pero no es lo que estoy tratando de lograr. Y diría que para cualquiera que esté considerando la posibilidad de trabajar a tiempo completo en código abierto, su objetivo podría no ser tan satisfactorio como perseguir algo que realmente disfrutas y hacerlo tanto como puedas. Creo que tienes más probabilidades de lograr la posibilidad de ser patrocinado de esa manera. Genial, sigamos con la siguiente pregunta. Así que tenemos una sobre el tema de la charla básicamente, preguntan sobre los sistemas basados en hooks son conocidos por ser opacos, ya que es difícil rastrear lo que se está registrando o cómo planeas mejorar estos problemas en los próximos cuatro años. Entonces, una de las cosas que hacemos actualmente es que exponemos hooks en DevTools. Creo que tenía una pequeña captura de pantalla de eso. Ahora, no proporciona el beneficio de dónde se registran los hooks. Pero una de las cosas más increíbles que tenemos en JavaScript que se está utilizando ampliamente es el almacenamiento local asíncrono. Ya lo usamos en Nuxt con el seguimiento de registros que ocurren durante el renderizado de una página. Entonces, habrás notado si tienes registros del lado del servidor que se activan durante el renderizado de una página, los envolvemos y los registramos en la console.

Y podemos utilizar la misma tecnología para rastrear dónde se agregan o registran los hooks, en qué módulo tal vez o en qué parte de tu aplicación. Y así, si hay un hook que se comporta mal, podemos rastrearlo hasta su origen. Y eso es algo que me encantaría ver, al menos en DevTime.

Genial. Eso es realmente genial. Bueno, Backstage me está diciendo que se nos acabó el tiempo. Así que muchas gracias, Daniel, por todas tus respuestas. Y, por supuesto, sabemos que estás en Discord respondiendo las otras preguntas, estoy bastante seguro. Así que gracias. Estaré allí. Adiós. Gracias.