Building a Better Hammer - The Story of Nuxt 4

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

Aparte de Nuxt, también estoy involucrado en la construcción de Nitro. PageSpeed.dev es un pequeño proyecto divertido para consultar las ideas de Google PageSpeed y las APIs de Core Web Vitals de una manera compartible. RegExp.dev. Magic RegExp es una biblioteca que hace que las expresiones regulares sean seguras en tipo, pero se compila en tiempo de construcción. Fontane ayuda a reducir el cambio acumulativo de diseño 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 todos estos y más en mi sitio web, Rowe.dev.

Bueno, aquí es básicamente donde estoy parado en este momento. Solo Bali, mi gato, ha sido excluido de la habitación, pero sí, normalmente me impide escribir bastante código cada vez que estoy en casa. Es extremadamente dulce, pero necesita muchos mimos cuando los quiere. Estoy hablando sobre Nuxt hoy y construyendo un mejor Nuxt y esperando con ansias el futuro de Nuxt 4. Y si no estás familiarizado con Nuxt, entonces creo que lo clave sobre 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 un componente de servidor.

Lo clave para mí es que es progresivo. Así que la idea es que comienza con las mejores prácticas integradas tanto como sea posible, y luego se adapta a ti a medida que creces. Así que a medida que quieras cambiar cosas, puedes. Si necesitas personalizarlo, puedes. Así que es una plataforma que, con suerte, mejorará la experiencia del desarrollador, hará que se sienta 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. Así que la versión 1 y 2 llegaron bastante rápido después de octubre de 2016. Comenzamos a trabajar en la versión 3 en 2020. Vue había pasado a la versión 3, lo cual es un gran cambio disruptivo. Webpack había pasado a la versión 5, otro cambio disruptivo. Y luego, a mitad de la construcción de la versión 3, salió Vite, que era un constructor completamente nuevo con una experiencia de desarrollador increíble. Y así, la versión 3 tomó bastante tiempo. Salió en noviembre de 2022. Y ahora estamos en camino a la versión 4, que esperamos que salga en junio de 2024.

Nuxt, estamos haciendo estos números, solo para decir, son en algunos aspectos métricas de vanidad. No son enormemente 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. Así que el 62% de las instalaciones de Nuxt ahora están en Nuxt 3 frente a Nuxt 2. Estas son cifras en vivo, por cierto. Así que cada vez que veo esta diapositiva, es ligeramente diferente. Y tenemos un gran número de personas que hacen que Nuxt sea lo que es. Honestamente, 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. Así que 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 construimos está muy moldeado por lo que necesitamos como un esfuerzo comunitario. Y es honestamente una de las cosas más agradables de Nuxt y de colaborar con personas de la comunidad de código abierto. Y esa es la amistad y camaradería que tenemos como parte de la comunidad. Y hay más de 680 contribuyentes.

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

A medida que adquieres una habilidad o comprensión o conocimiento de una herramienta particular en tu caja de herramientas como un artesano de la web, puede ser tentador intentar hacer todo con ella. Y eso, generalmente hablando, no es una buena idea. Somos fundamentalmente personas que construyen cosas con un propósito. Y tenemos herramientas para ese esfuerzo. Así que podemos usar diferentes herramientas. Podemos usar diferentes bibliotecas, diferentes frameworks. Y eso está totalmente bien. Por cierto, no quiero decir en absoluto que Nuxt deba ser el todo y el fin para todos. Pero sí quiero hacer que Nuxt sea más usable y más extensible para que sea un mejor martillo. Así que puedes usarlo para más cosas, que pueda usarse con clavos y tornillos y otros diferentes tipos de cosas. Y debería ser usable en muchas circunstancias diferentes.

Entonces, ¿por qué? ¿Por qué quiero que sea así? Bueno, una es que puede reducir la carga cognitiva. Así que si sabes cómo funciona algo y esa herramienta es lo suficientemente flexible como para adaptar la salida a tus necesidades, para que no tengas que cambiar la entrada, eso cambia mucho tu experiencia como desarrollador. No tienes que tomar una nueva herramienta porque tu herramienta existente es lo suficientemente flexible como para adaptarse a lo que necesitas esta vez. También puedes desbloquear el poder de la convención.

Así que en un proyecto, por ejemplo, un proyecto empresarial donde tienes nuevas personas incorporándose no tienes que capacitarlas en una forma particular de hacer este proyecto en particular. Funcionará como se espera. Y este es el poder de la convención, ya sea en Nuxt o en otros proyectos. Tailwind CSS, por ejemplo, ha disfrutado del éxito que ha tenido gracias a la convención, creo. Y significa que para un nuevo desarrollador que entra en un proyecto de Tailwind CSS, no hay necesidad de que entiendan exactamente cómo se ha configurado el CSS. Prácticamente lo saben. Saben cómo funciona. Saben cómo se construyen los estilos y cómo agregarlos al HTML, ya sea un proyecto de React o un proyecto de Vue o cualquier cosa intermedia. Pero realmente lo que no quiero, realmente la razón por la que estoy tratando de hacer Nuxt para un mejor No es para conquistar el mundo. Esto no es un juego de suma cero. Y no estamos tratando de derrotar a otros frameworks. Y creo que eso es una de las cosas que amo de las comunidades de Vue y Nuxt, es que eso no es lo que somos.

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

Así que 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 manera de decirlo. Digamos mejor que nos equivocamos en algunas cosas. Y creo que probablemente si solo echas un vistazo a este pequeño gráfico de nuestros lanzamientos principales 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 es algo en lo que nos equivocamos y reconocemos como equipo central que ese es el caso. Y me gustaría brevemente destacar algunas cosas que aprendimos de eso.

Una es que el alcance y el tiempo no son ambos entregables. No puedes entregar la visión completa de lo que quieres y hacerlo en el mismo tiempo que pronosticaste para ello. Oh, supongo que a veces puedes, pero si no puedes, tienes que fijar uno de esos. No puedes cumplir con ambos. Y puede agregar una gran cantidad de estrés si intentas hacer eso. Esa es una de las razones por las que ahora tenemos un calendario de lanzamientos basado en tiempo fijo. Cada semana, tenemos un parche, prácticamente. Cada mes, tenemos un lanzamiento menor con características. Y cada año, apuntamos a tener un lanzamiento importante. Por eso estamos llegando a NUXT 4 ahora.

Aprendimos sobre la importancia del ecosistema y de llevar junto con nosotros las bibliotecas aguas abajo que dependen de NUXT. Así que la gran actualización de Vue tomó 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 tenían que venir también. Aprendimos mucho la lección de que depender de los internos de un proyecto como NUXT hace muy difícil cambiarlo porque esos internos son las primeras cosas que cambian cuando se introduce un cambio importante. Y significa que grandes partes del ecosistema se rompen, por lo que 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 aún intentas mantenerlo en movimiento, tal vez sea una mala idea. Así que todas esas son cosas que estamos tratando de cambiar mucho sobre NUXT 4.

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

Así que aquí hay algunas cosas que estamos tratando de hacer. Y la primera es que confiamos en el ecosistema de módulos. Y hay un par de cosas que quiero destacar sobre el ecosistema de módulos que nos ayudan mientras avanzamos hacia NUXT 4. Y la primera es que es profundamente conectable. Así que puede conectarse a cada parte de NUXT y Nitro desde la construcció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 de desarrollador 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 conectable. Así que las diferentes cosas que puedes usar dentro de NUXT son todas intercambiables, si podemos hacerlo así. Ya sea el bundler, espero ver el soporte de RSPack aterrizar pronto para NUXT, o incluso los módulos ad hoc que construimos que siguen siendo los módulos principales de NUXT. Son realmente conectables y podrían ser intercambiados, o la arquitectura de capas que exponemos al final del día a los usuarios finales. El objetivo es que bastante sobre NUXT debería poder ser adaptado y movido dependiendo de tus necesidades.

Y todo eso lo hacemos posible para construir fácilmente sobre NUXT. Así que los módulos se pueden crear y distribuir, ya sea en un mono repo 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 repo en NPM. También tenemos una API para ello. Y tenemos un NUXT SDK componible. Así que la gente puede construir un módulo para NUXT 3, y cuando lancemos NUXT 4, ese módulo debería continuar funcionando siempre que siga usando cualquier utilidad componible que venga de ese kit SDK.

Esas son algunas estadísticas. Así que los módulos son una especie de módulos que han sido registrados con 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 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. Así que si inicio un proyecto, que tengo ejecutándose 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 un número de colaboradores y yo hemos estado impulsándolo bastante rápido. Así que podemos instalar el módulo de fuentes de NUXT en segundo plano, NUXT se reiniciará, el módulo ha sido 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 tenemos fuentes web personalizadas siendo usadas. Puedo habilitar, digamos, poppins. Y luego instantáneamente obtenemos herramientas de desarrollo actualizadas, tenemos alguna información sobre las fuentes que se usarán en este proyecto. También ahora están proxyadas localmente en el proyecto. Y cuando lo construyas, será parte de tu proyecto, no habrá solicitudes de terceros. Y también inyectamos algo de CSS mágico para que obtengamos cero o el menor cambio de diseño posible cuando la página se carga. 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 pueda ser creado, cualquiera que sea el proveedor con el que se integre o la característica que busque resolver, queremos que mejore la experiencia del desarrollador y reduzca esa carga cognitiva y fricción tanto como sea posible. También queremos priorizar mucho la elección del usuario.

Así que una de las cosas que notas cuando comienzas a integrar con NUXT o a construir sobre él es que tenemos muchas, muchas integraciones intercambiables. Ya sea nuestro componente de imagen de NUXT, que admite más de 20 proveedores de imágenes diferentes, ya sea la integración de KV y caché o la integración de bases de datos, que a su vez admiten muchos, muchos backends diferentes.

El objetivo es que NUXT quiera exponer primitivas únicas que funcionen de manera consistente sin importar qué proveedor uses. Así que tenemos más de 90 proveedores y el objetivo es que los usuarios puedan elegirlos según sus necesidades, pero no basados en ninguna restricción que NUXT les imponga. Esto realmente está muy en nuestro ADN. Nunca querría que la elección, la respuesta para cualquier usuario que me pregunte a qué proveedor desplegar 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 precios o DX desde su punto de vista, pero no debería ser NUXT quien los limite. Y así, siempre queremos que NUXT se enfoque en la libertad e independencia del usuario. Y creo que eso es muy hacia donde nos dirigimos y donde queremos estar como proyecto.

Así que mirando hacia NUXT 4, el peligro es que NUXT es un framework establecido. Tenemos una larga cola de usuarios que dependen de nosotros. Eso incluye empresas que no quieren que sus productos se rompan y eso incluye agencias o hackers independientes que necesitan construir rápidamente y quieren que las cosas simplemente funcionen.

Así que una de las formas en que hacemos que eso suceda es que nos enfocamos en la estabilidad. Así que tenemos ese calendario de lanzamientos confiable del que hablé y podemos probar 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 dependencias downstream para asegurarse de que el último lanzamiento no las rompa. Y así lo hacemos antes de cada lanzamiento.

Eso significa que podemos lanzar cosas con bastante felicidad que son, esperamos, innovadoras, ya sea componentes de servidor o caché de compilación, reglas de raíz en línea o federación de módulos NUXT. Podemos aspirar a construir estos, 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 test utils a nuestros usuarios finales. Ellos también pueden probarlos. Estamos colaborando con Ecosystem CI, por lo que mejoramos la experiencia para NUXT, pero también Vue usa Ecosystem CI y NUXT está incluido en eso. O VTest usa Ecosystem CI y NUXT test utils está incluido en eso. Estamos profundamente integrados entre nosotros.

Y cuando lanzamos algunas de estas características, lo hacemos en los espacios de nombres de futuro y características, para que las personas puedan optar por mejoras futuras y también volver al comportamiento anterior. Pronto estaré lanzando una acción de prueba downstream, para que las personas puedan beneficiarse del mismo tipo de experiencia Ecosystem CI, pero sin necesitar que su repositorio sea de código abierto. Y nuestro objetivo es que podamos exponer la migración de código incremental.

Por ejemplo, cuando detectamos un cambio disruptivo con una posible mejora, podemos implementar ese cambio a través de PR en todo el ecosistema de módulos. Será compatible hacia adelante y hacia atrás, ya sea que los usuarios estén usando NUXT 3 o NUXT 4. Ya hemos hecho eso para tres cambios diferentes que vienen en NUXT 4. Esperaríamos que lo mismo sea cierto para otros cambios disruptivos que planeamos lanzar. Es fácil optar a las personas. Y también planeamos enviar con modificaciones de código cuando realmente lancemos NUXT 4, para hacer la migración directa y simple. Si mantienes una biblioteca downstream, no dudes en abrir un PR para agregarla y una prueba contra ella al NUXT Ecosystem CI, y garantizaremos que no la romperemos, al menos sin decírtelo primero. Y nuestro objetivo es comprometernos con el estándar base. La plataforma web DX es un gran proyecto. Recomiendo que veas cómo se ve el estándar base en MDN, por ejemplo. Y hay algunas cosas nuevas emocionantes que planeamos construir que no mencionaré ahora. Pero todo esto se construye sobre la plataforma de nuestra estabilidad garantizada por Ecosystem CI y otros proyectos. También podemos mirar y ver cuántas personas usan algunas de las nuevas características que construimos.

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

Entonces, ¿qué pasa con NUXT 4? Creo que lo primero que hay que decir es que no se trata del bombo. Así que el objetivo es que sigamos SEMVA, lo que significa que corregimos errores y parches cada semana. Agregamos nuevas características en miners cada mes. Así que NUXT 4 no va a ser características que hemos estado reteniendo. Se envían cada mes.

NUXT 4 se trata de cambios disruptivos y reflexivos. Así que las oportunidades para que cambiemos la API cuando lo necesitemos de una manera que, con suerte, sea opcional y reversible. Está cambiando valores predeterminados, pero no rompiendo tu proyecto. Y así, en la medida de lo posible, quiero que NUXT 4 no se trate del bombo. Quiero que sea una oportunidad para que nos enfoquemos en una buena experiencia de migración y de una manera demostrando que podemos ofrecer una versión importante sin el dolor que muchos aquí habrán experimentado en, digamos, la versión 3.

Habrá algunas cosas que puedo adelantar. Así que tenemos una nueva estructura de directorios que viene, una estructura de directorios predeterminada a la que puedes optar volver a la anterior. Habrá valores predeterminados más eficientes en cosas como cargas útiles reactivas superficiales, configuración de tiempo de ejecución no reactiva, quizás, usando más la caché nativa del navegador e implementando algunas mejores prácticas. Así que análisis absoluto y construir un gancho de observación o eliminar el Booleano pendiente de nuestros composables de obtención de datos. Si estás interesado, puedes encontrar los próximos cambios con una etiqueta 4.x en el repositorio de NUXT.

Y si quieres ayudar, nos encantaría eso. Así que, con suerte, hemos lanzado una mejor experiencia de documentación recientemente. Sebastian y Anthony han estado muy involucrados en eso. Puedes venir 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 Nuxt u otro proyecto, por favor siéntete libre de contactarme. Hago un calendario disponible para charlas de 10 minutos. Y particularmente si piensas que no estás seguro si serías bienvenido o tal vez no te ves como algunos de los otros contribuyentes ya en el proyecto y sientes que podrías estar viniendo 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 viaje, ya sea en Nuxt o en otro proyecto, {{^}}me encantaría hacerlo. Así que revisa la documentación de Nuxt. Síguenos en Twitter. Únete a Discord. Y puedes esperar un 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, está emocionado por 3.12. Entonces, ¿cuál es tu expectativa de esto? Bueno, honestamente, pensé que podría haber más personas emocionadas por 3.12. Porque honestamente, ahí es donde vamos a estar lanzando el... Y para ser justos, fue injusto hacer esta pregunta antes de mi charla, porque con suerte después, ahora estás pensando que 3.12 es tal vez donde van a venir las características. Y eso es lo que estoy... Creo que estoy bastante emocionado por 3.12. Eso es lo que querría... 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 ahora mismo, la nueva versión que estabilizará todo lo que tenemos. Así que eso es realmente genial.

Y tratemos de 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? Así que principalmente, 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. Así que si tienes un archivo app.vue, básicamente puedes copiarlo. Si tienes enrutamiento basado en páginas, puedes simplemente copiarlos en tu directorio de páginas. Y Nuxt hace muchas cosas más. Pero es prácticamente todo opcional. Así que si no lo estás usando, si solo tienes tu configuración existente, debería funcionar bien.

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

Veamos si las personas que hicieron esta pregunta pueden intentarlo y hacernos saber cómo les fue. Y tenemos otra pregunta que Kishu hizo, de hecho. Dado que la mayoría de los contribuyentes en Vue y Nuxt no están patrocinados por empresas, ¿crees que aún podrían lograr el 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, cualquiera que sea tu camino para hacer que eso funcione es bueno. Así que no quiero emitir ningún tipo de juicio sobre cómo funciona eso. Todos estamos haciendo nuestro camino de muchas maneras diferentes. Así que si eso es estar patrocinado por una empresa, eso también es genial. Sucede que los frameworks son independientes, lo cual creo que es fantástico. Eso no significa que los contribuyentes individuales deban serlo. ¿Y es posible lograr el código abierto a tiempo completo? Sí, creo que lo es. Así que es posible para mí, y creo que para otros también. 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 eso no es lo que estoy tratando de lograr. Y diría que para cualquiera que haga la posibilidad de trabajar a tiempo completo en código abierto, tu objetivo podría no ser tan satisfactorio como perseguir algo que realmente disfrutes y hacer eso tanto como puedas. Creo que es más probable que logres la posibilidad de ser patrocinado de esa manera.

Genial, bueno, 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 prevenir mejorar estos problemas en los próximos cuatro años? Así que una de las cosas que hacemos en este momento es que exponemos hooks en DevTools. Creo que tenía una pequeña captura de pantalla de eso. Ahora, no da el beneficio de dónde se registran los hooks. Pero una de las cosas más sorprendentes que tenemos en JavaScript que está entrando en uso generalizado es el almacenamiento local asíncrono. Ya usamos esto en Nuxt con los registros de seguimiento que ocurren mientras se renderiza una página. Así que habrás notado si tienes registros del lado del servidor que se activan mientras se renderiza una página, los envolvemos y los registramos en la consola.

Y podemos usar la misma tecnología para rastrear dónde se añaden o registran los hooks, en qué módulo quizás 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 sería algo que me encantaría ver, probablemente en DevTime al menos.

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, te tenemos en Discord respondiendo las otras preguntas, estoy bastante seguro. Así que gracias. Estaré allí. Adiós. Gracias.