Repensando el Bundling: Por Qué No Necesitas Menos JavaScript

Muchas gracias. Es un placer estar aquí. Gracias por alejarse de, seamos honestos, la pantalla más increíble del mundo. ¿Alguna vez has estado en una pantalla tan asombrosa? No, quiero decir, me envolvió. Estaba rodeado por esa pantalla y cautivado.

Voy a hablar sobre repensar el empaquetado, y me disculpo por el subtítulo, porque eso es exactamente lo que estoy diciendo. Así que te he atraído aquí bajo falsos pretextos, y no es demasiado tarde si quieres volver al planetario. Porque no voy a decir solo por qué no necesitas menos JavaScript. Por supuesto, bueno, eso vendrá. Pero primero, ¿quién soy?

Mi nombre es Daniel. Soy un mantenedor de código abierto a tiempo completo, lo cual tengo que decir es el trabajo más increíble del mundo. Mantengo Nuxt. Dirijo el equipo que construye eso, que es un framework full-stack para construir aplicaciones web. También estoy en el equipo que construye Nitro, que es un framework para construir servidores. Hablaré un poco sobre eso mañana si estás en React Summit. También he construido algunos sitios web y bibliotecas de código abierto que podrías querer revisar también, incluyendo magicregex, Fontaine. Puedes verificar tu sitio web en pagespeed.dev y así sucesivamente.

Elk es un cliente para Masterdone. Soy un Google Developer Expert, Microsoft MVP, una estrella de GitHub. Y recientemente me convertí en ingeniero de software en Vercel, quienes me emplearon para continuar mi trabajo en código abierto. Vivo en Edimburgo con mis dos gatos y mi familia. Esta es básicamente una vista muy hermosa de la ciudad. Es realmente muy hermosa. También es muy fría y muy lluviosa, particularmente a medida que avanza el invierno. Y como al menos uno de ustedes ha descubierto, si escanean ese código QR o van a a row.dev slash live, pueden enviar cualquier emoji en la pantalla. Les he dado algunos emojis para enviar fácilmente, pero también pueden enviar cualquier emoji si quieren. Así que usen ese poder con responsabilidad. No violaciones del código de conducta, por favor. Genial. Creo.

Sí. Bien. Has descubierto cómo funciona eso. Por cierto, ¿no es increíble lo que podemos construir? Esto no fue complicado. Esto no es decir que podría hacer cosas increíbles. Esto es decir que podemos hacer cosas increíbles. Así que aquí estamos conectándonos a... Esto está construido sobre PartyKit y en mi sitio web, que es todo de código abierto.

Cuando envías un emoji, va a un servidor WebSocket alojado en CloudFlare, que está conectado a mis diapositivas, lo que hace que se muestre en la pantalla. Fue absurdamente simple de crear. Y podemos simplemente hacer cualquier cosa que queramos. Es genial. Cuando estaba desarrollando esa función, por cierto, me hicieron un rickroll porque cometí el error de publicar en blue sky.

Debería decir que estoy en todas las redes sociales excepto Twitter por razones obvias. Siéntete libre de conectar. Puedes encontrar mis handles en mi sitio web, que es row.dev. Siéntete libre de enviarme un mensaje directo en cualquier momento o enviar una pregunta si puedo ayudar de alguna manera. Soy un mantenedor de código abierto porque me encanta eso. Así que no te sientas mal por ello. Me encantaría saber de ti.

Nuxt, que es el framework en el que paso la mayor parte de mi tiempo trabajando, es un framework full-stack. Es progresivo. Así que la idea es que deberías poder comenzar con casi ninguna configuración o conocimiento previo requerido. Deberías poder construir. Y luego, a medida que tus circunstancias y necesidades cambien, deberías poder configurarlo como desees. Fue creado el día después de Nuxt.js. Si estás aquí porque piensas que mantengo Nuxt.js, también lamento mucho decir que no lo hago. Y también eres bienvenido a volver a la pantalla de grandeza. Pero fue creado el día después de eso.

Lo mismo que Nuxt.js originalmente, pero para Vue. Y desde entonces, los dos frameworks han evolucionado por separado y ahora tienen conjuntos de características bastante diferentes. Lo reescribimos completamente para la versión 3, lo cual tal vez fue una mala idea. Pero terminó resultando bastante bien. Y tenemos un framework completamente reescrito. E incluso reconstruimos el backend del servidor, de donde vino Nitro. Y muchas otras bibliotecas que construimos. En ese momento lo abstrajimos en una organización de GitHub llamada unjs, que ahora aloja bibliotecas usadas en todas partes, desde Tailwind CSS hasta Astro, Angular, y podría seguir. Nuxt tiene algunas estrellas en GitHub.

Creo que ese último pico es un artefacto de los números de npm. Pero en realidad, estoy mucho menos emocionado por esas métricas que por esta. Es un framework basado en la comunidad. Así que ha sido construido por más de 960 colaboradores. Y es impulsado por la comunidad, no por ninguna empresa o agenda corporativa. No está respaldado por capital de riesgo, por ejemplo. Nuxt está construido para resolver las necesidades y problemas que enfrentan los desarrolladores. Y originalmente me involucré como colaborador por exactamente la misma razón. Estaba usando Nuxt, y quería arreglar errores y añadir características. Y participé al igual que cada una de esas 960 personas. Y he venido aquí hoy con una opinión que siento que tal vez sea un poco peligrosa de decir.

En realidad, creo que JavaScript es bueno. ¿O... Sí? ¿Sí? ¿La gente está de acuerdo con eso? Bien. Hay algunas personas sentadas en la parte de atrás pensando, hmm... Y para ustedes, puedo decir al menos que tal vez podamos llegar a un compromiso en la idea de que JavaScript es útil. No sé si tuvieron la misma clase de experiencia que yo. Descubrir un sitio web que era verdaderamente interactivo del lado del cliente por primera vez. En lugar de ese largo viaje de ida y vuelta al servidor, imágenes cargándose lentamente de manera progresiva, texto apareciendo de manera brusca, CSS cargándose de un golpe al final. En realidad, interactuabas con algo que se sentía mucho más como una aplicación nativa. Y JavaScript, cuando mejora y mejora la experiencia del usuario, puede ser absolutamente increíble. Y quiero hablar particularmente sobre lo que podemos hacer y compartir algunas cosas que estamos haciendo en Nuxt, que no son exclusivas de Nuxt. Y espero que esto no se perciba como una charla sobre el único proyecto que estoy manteniendo. Sino sobre lo que podemos hacer como personas que usan frameworks y construyen frameworks que hacen la web más eficiente para todos. Aquí están algunas de las estrategias que estamos implementando.

Y creo que lo primero que tienes que hacer, con lo que tienes que empezar, es expandir la posibilidad, expandir el alcance de lo que significa cuando miras el bundling. Así que, normalmente, de lo que hablamos cuando hablamos de bundling es de esta línea en un documento HTML en un sitio web. ¿De qué estamos hablando? Del bundle de JavaScript. Y pensamos que el rendimiento se trata de mejorar JavaScript. Y en realidad, si podemos alejarnos de frameworks y bibliotecas, mucho mejor. No podría estar más en desacuerdo. Primero, necesitamos expandir nuestra visión de lo que un framework o un bundler puede hacer. Y por supuesto, no es solo esa línea. Es todo el HTML. Así que, aquí hay algunos ejemplos. Así que, estilo y alineación. Así que, cuando construyes un sitio web, si es un sitio verdaderamente increíble, simple y directo, probablemente tendrás un archivo CSS y tendrás tu texto. Ese archivo CSS está bien. Es una solicitud de red separada, pero hay formas de optimizarlo, por ejemplo, enviando una pista temprana o algo para decirle al navegador que comience a descargarlo. Pero a medida que comienzas a construir tu sitio web, y a medida que tienes componentes que se cargan de manera diferida o son fragmentos separados, podrías encontrar que en realidad tienes más y más archivos CSS separados. Y esta es una de las cosas que es problemática o no eficiente con sitios web que pueden crecer, pueden convertirse en enormes monolitos con miles de componentes y potencialmente cientos o, digamos, cientos de archivos CSS cargados.

Así que, encontramos que podíamos hacer esto en Nuxt. Podíamos incrustarlos. Así que, tomamos un componente como este, que es un componente de Vue. Si no lo has encontrado, piénsalo como un poco de HTML, un poco de CSS, un poco de JavaScript. En este caso, es solo HTML y CSS. Así que, tomamos ese CSS. Tomamos ese componente, lo rastreamos. Así que, esto es en lo que se compila con un compilador de Vue. Podemos, cada vez que ese componente se carga o renderiza algo en el servidor, rastrear qué componente se cargó o qué componente logró renderizar algo. Luego podemos tomar esa clave y rastrearla con los estilos que tenía. Así que, esto es algo que hacemos. Este es nuestro código real que ejecutamos. Y tomamos todos los estilos de ese componente y luego cada componente que se renderizó en el servidor, y los comprimimos en un solo bloque de estilo incrustado que podemos renderizar en la carga inicial. Eliminamos todo del CSS del lado del cliente que garantizamos estará en el HTML renderizado por el servidor. Y, ¡voilà!, lo que deberíamos tener son sitios web más eficientes. Hay un costo, por supuesto. Cada vez que haces eso, reduces la capacidad de almacenamiento en caché de tu CSS, por lo que no es simplemente un archivo. Pero, por otro lado, tienes sitios web muy eficientes, con bajo cambio de diseño en la carga inicial. Reduces el número de archivos que descargas. Y creemos, en general, que es un buen valor predeterminado, particularmente para componentes de Vue, que a menudo están fragmentados. Así que producen archivos separados. Y somos muy capaces de rastrearlos. De hecho, en el vuelo de camino aquí, estaba implementando esta función. La enviamos con Vite en Nuxt 3 y 4, pero estaba implementándola para Webpack y RSPack.

Así que deberíamos expandir eso en Nuxt bastante pronto. Aquí está la segunda cosa que estamos haciendo. No sé cuál es tu core web vital favorito. Asumo que todos tenemos core web vitals favoritos, ¿verdad? ¿El póster en la oficina de tu core web vital favorito? ¿No? ¿Solo yo? Así que uno de los nuevos core web vitals que surgió en los últimos años es interactionToNextPaint, I-N-P, que básicamente mide el tiempo de respuesta cuando realizas cualquier tipo de interacción en un sitio web. ¿Qué tan rápido responde a lo que has hecho? Y una de las grandes advertencias que surgieron, esto fue en realidad tuiteado por alguien del equipo de Chrome, quien notó que en realidad de bastantes frameworks, cuando este nuevo core de vitals salió, verían grandes disminuciones en sus resultados de rendimiento de sitios web para sitios web que estaban usando esos frameworks.

De hecho, descubrimos que esto era cierto en un caso muy particular donde estábamos optimizando para el rendimiento. Así que tenemos esta cosa llamada un sitio web completamente estático, o tenemos la capacidad de extraer cargas útiles donde cada vez que renderizas una página que ha sido pre-renderizada, extraemos todos los datos que esa página necesita. Así que solicitudes de red, tareas asíncronas o complejas, piensa en cosas como el resaltado de sintaxis. Podrías querer resaltar la sintaxis de algunas cosas de tu sitio web basado en una solicitud a un CMS. Pero no quieres hacer eso cada vez que alguien visita el sitio web y definitivamente no quieres hacerlo en el lado del cliente cuando visitan un sitio web, ¿verdad? Eso sería terrible. Así que lo extraemos todo por adelantado y básicamente lo hacemos para que pueda ser instantáneo.

Así que si alguien navega de una página a otra, tenemos este payload.json que existe. Usamos una herramienta genial llamada dValue que fue creada originalmente por Rich Harris y toma datos json y los convierte en un objeto ricamente reactivo que puede usar cosas como view shallow reactive o incluso podría incrustar componentes de isla dentro de la carga útil. Y así lo hacemos, y lo que encontramos fue que cuando la gente habilitaba este modo rápido, la gente navegaba de página a página y tenían alta interacción a NextPaint. ¿Alguien puede adivinar por qué? ¿No? Bueno, tal vez. No lo escuché completamente. ¿Esperando para descargar? No, esta es la cosa.

Descargamos todo por adelantado. Pero era peor que si hacías clic y luego se iba y tenía que descargar cosas. Y la razón era porque todo estaba allí, el hilo de JavaScript estaba bloqueado porque inmediatamente comenzaba a volver a renderizar. Mientras que si al menos tenías que ir y hacer una solicitud de red, tenías la oportunidad de dar retroalimentación al usuario antes de que la solicitud terminara. Así que en realidad añadimos a nivel de framework la capacidad de inyectar automáticamente un request animation frame para permitir que el navegador respondiera al usuario al, no sé, enfocar o desenfocar el botón que hicieron clic o lo que fuera que necesitaba suceder en el navegador.

Y al costo de unos ocho milisegundos, probablemente no perceptible para el usuario final en el sentido de que el resultado final de cargar la página ocurrió igual de rápido, pero el punto era que obtuvieron una interacción más pronto, mejor experiencia de usuario. Y eso fue algo que pudimos implementar a nivel de framework para mejorar el rendimiento para los usuarios. Y esto también lo enfrentan otros frameworks. Malte Ubi, CTO de Vercel, escribió un artículo muy, muy interesante sobre exactamente el mismo desafío que enfrentaron en Next.js.

Aquí hay otro core web vital. Cumulative layout shift. Si alguna vez has estado en un sitio web que hace esto, lo visitas, y luego parpadea y la fuente se carga. Es terrible. Es absolutamente horrible. Y lo odio más. Este es mi core vital menos favorito, personalmente. O mi favorito, supongo. Porque el punto es que intento recoger algo y hago clic en otra cosa, ¿verdad? Me confunde totalmente.

Y esta sería una experiencia mucho mejor, ¿verdad? Poder cargar esa fuente web pero sin un cambio de diseño. Y esto es algo que pudimos construir en Next. Detectamos que había todos estos problemas e inconvenientes cuando la gente usa fuentes web personalizadas, que son todos solucionables pero requieren un esfuerzo adicional de los usuarios. Y así, pudimos hacer esto. Pudimos tomar ese mismo tipo de componente de vista, detectar familias de fuentes, extraerlas, descargar la fuente.

Así que sin conexiones de terceros, sin problemas de privacidad. De hecho, descárgalo en su proyecto. Descarga el CSS para que no sea un recurso adicional a cargar. Verifica las métricas de la fuente. Así que ve exactamente cuán grande es en comparación con la fuente de respaldo que el usuario está usando. Inyecta usando sobrescrituras de font face, como un, es básicamente un lecho de Procusto que mueve la fuente de respaldo para que sea lo más cercana posible a la forma de la fuente web personalizada para que no haya cambio de diseño. Y pudimos enviar eso como un módulo de Next y fuentes web personalizadas sin configuración. Simplemente lo usas.

Familia de fuentes, todo está configurado para ti. Tengo una pregunta rápida. ¿Estás usando Next? Y solo quiero señalar brevemente lo inteligente que soy. No realmente. Porque te he dado dos opciones y son sí y aún no. Y diré, por cierto, que estoy realmente honrado de que tantas personas que no están usando Next hayan venido a escucharme hablar. Así que gracias. Bueno, esto es un regalo para ti si no estás usando Next y también no planeas usarlo. Porque hemos extraído todo sobre las fuentes de Next en una biblioteca agnóstica sin sobrecarga de tiempo de ejecución que hace todas esas cosas y es utilizable en cualquier Vite-based Así que, disfruta. Aprecio la mímica del aplauso. Eso fue muy porque no hay nada peor que ser la única persona aplaudiendo, ¿verdad? Es como que tienes que esperar a una masa crítica. Y así, de todos modos, es algo difícil. Aplaudes mientras también miras alrededor.

Eso es lo que hago. Aquí hay otra cosa que podemos hacer. Acabamos de enviar esto en el último menor de Next. Todavía es una característica experimental. Pero imagina que tienes un sitio web estático que hace cosas como algo que es costoso, resaltado de sintaxis. Y lo hace en este estado de datos asíncronos. En realidad, podemos a nivel de compilador identificar eso, extraerlo en un archivo virtual y solo cargarlo cuando sea necesario. En realidad, pudimos reducir el total de JavaScript usado en Next.com en casi un 40% y reducir el JavaScript no utilizado en un 66%, haciendo algo, una optimización que ningún usuario podría hacer fácilmente en su propio proyecto.

Recientemente lanzamos, en el último año, algo llamado Next Scripts, que es una integración alrededor de scripts de terceros, que son el mayor problema en términos de rendimiento web. A veces la gente mira el rendimiento de frameworks como Nuxt o Next en términos de core web vitals, y parece que tienen un rendimiento muy pobre. De hecho, esto es a menudo debido a la correlación entre las personas que usan estos frameworks para cosas como sitios de marketing y luego lanzan grandes cantidades de scripts de terceros en el sitio web. Así que no es realmente algo de lo que el framework tenga la culpa, pero es algo que podemos ayudar a solucionar. Así que lanzamos Nuxt Scripts, que proporciona mejores componentes fachada para muchos de los elementos que la gente usa, así como reemplazos para cosas como Google Tag Manager, consentimiento de cookies incorporado, soporte SSR, y mucho más. Y también podemos realmente empaquetar scripts de terceros en algunos casos para que ni siquiera tengas un origen de terceros y realmente podemos optimizar el script usando las opciones del compilador del proyecto del usuario final.

Prometo que voy tan rápido como puedo, lo siento mucho si estoy tomando un poco de tiempo. Otro desafío que estamos lanzando experimentalmente es poder tomar muchos fragmentos asíncronos incrustados en una solicitud inicial y realmente reempaquetarlos en un único fragmento de JavaScript usando algo de magia con import maps. Esto, por cierto, es extremadamente genial, tendrás que creerme. Incluso funciona con el almacenamiento en caché porque podemos en el mapa de entrada reescribir todas las solicitudes subsiguientes a esos archivos iniciales en re-exportaciones desde el archivo reempaquetado que creamos. Es muy genial, me encanta tanto. Lo siento.

Construimos otra herramienta que quiero mencionar, E18E, que es una iniciativa de limpieza del ecosistema. Es fenomenal limpiando las dependencias que se instalan en nuestros proyectos día a día y realmente podemos eliminar polyfills que ya no son necesarios en JavaScript en tiempo de compilación. Así que puedes revisar polyfills desconectados y purgados. ¿Y por qué usar JavaScript si no lo necesitas? Así que puedes construir una aplicación multipágina sin JavaScript con Nuxt con una línea de código y eso no es solo en toda la aplicación, sino que puedes hacerlo por ruta si lo deseas. Y estamos viendo hacia dónde vamos a continuación. Así que estamos a punto de lanzar, acabamos de lanzar, acabamos de hacer de código abierto la primera versión de Nuxt hence y tenemos una nueva versión de Nuxt Accessibility que voy a mostrarte muy brevemente porque no puedo resistirme.

Tenemos un nuevo panel de DevTools. Oh no, ¿qué he hecho? Creo que he matado el servidor de desarrollo. Bien, no voy a hacerte una demostración de eso. Si estás interesado, podemos hacerlo más tarde. Pero estamos viendo qué podemos hacer a nivel de framework usando la experimentación. Así que tenemos una oportunidad, una gran oportunidad como framework para aprender de expertos, descubrir las mejores prácticas, enviarlas a usuarios que pueden o no ya ser expertos en esas cosas, e iterar, experimentar e iterar, lo que con suerte hace que la web sea mejor para todos.

Y sobre el tema de la experimentación, tengo un estudio muy rápido que he estado realizando durante esta charla. Quiero saber el uso de emojis... Ahí vamos. Lo analizaré más tarde y adaptaré la charla. Si estás interesado en cualquiera de las cosas de las que hemos estado hablando en Nuxt o algunas de las otras técnicas, no dudes en ponerte en contacto. Me encantaría saber de ti. Puedes encontrar más sobre Nuxt en nuestro sitio web. Tenemos un discord si quieres hacer preguntas. Ese código QR te llevará a un paquete de inicio de BlueSky de personas en el equipo del ecosistema Nuxt, que son unas 25-30 personas que están construyendo módulos centrales de Nuxt o contribuyendo al framework en sí.

Y también debo decir que tengo una agenda abierta. Si vas a rho.dev chat puedes reservar una llamada conmigo en cualquier momento. Me encantaría hablar. Si quieres involucrarte en código abierto, ya sea en Nuxt o no, estoy más que feliz de responder cualquier pregunta. Y particularmente diré que si sientes alguna duda, si sientes que tal vez tu origen no es exactamente el mismo que el de las personas involucradas en un proyecto de código abierto en el que te gustaría participar, puedo decirte desde mi punto de vista que serías extremadamente bienvenido. Y tal vez pueda abrir algunas puertas o puentes si eso es algo que sería útil.

Por favor, siéntete libre de reservar una llamada. Ha sido un verdadero placer hablar contigo. Muchas gracias por venir a escucharme.

Este primero es de mí. ¿Cuál fue tu primer PR en el repositorio de Nuxt? Hablaste sobre cómo te involucraste en el código abierto. Así que creo que sería genial escuchar cómo sucedió. No lo sé, pero puedo decirte que mi primera participación no fue realmente en crear PRs. Así que iba con una pregunta. Entonces, estaba enfrentando un error o no sabía cómo hacer algo. Y así fui a Discord y pregunté y la gente respondió. Y luego descubrí que porque ahora estaba en el Discord, veía a alguien más haciendo la misma pregunta y ahora tenía una respuesta. Así que les respondí. Y eso fue increíble. Como el golpe de poder ayudar a alguien más. Y fue simplemente genial. Y así lo hice más y más. Y luego comencé a contribuir a un módulo. No estaba en el núcleo de Nuxt. Se llamaba el Now Builder. Los viejos tiempos cuando Vercel se llamaba Zite y tenía una plataforma llamada Now. Estaba ejecutando un SaaS y nuestra principal cosa era usar eso. Así que desplegábamos imágenes de Docker en esto. Y así comencé a construir este Now Builder y luego eventualmente comencé a mantenerlo. Así que probablemente mi primer PR fue a querer tal vez al Now Builder. Genial. Genial escucharlo.

Muy bien. Esta siguiente pregunta viene de Code Witch. ¿Construir un meta framework se siente más como ingeniería de front-end o back-end? Creo que se siente más como back-end.

Enviamos muy poco CSS. No CSS de producción. Y realmente no tenemos una opinión sobre cómo construyes tus interfaces. Así que mucho de esto, construir un meta framework es un ejercicio para descubrir lo poco que sabes. Porque estás enfrentando muchas cosas. Tienes que descubrir cómo funciona Webpack y cómo funciona Rollup. Y luego tienes que entender cómo funciona Node y cómo funciona Bun. Hay campos enteros separados donde la gente es experta, donde obviamente tú no eres un experto. Y tienes que enfrentarte a ellos, aprender, ser corregido e iterar. Y nada equipará más tu síndrome del impostor que mantener un meta framework. Te lo aseguro. Definitivamente.

Genial. Bien. La siguiente pregunta viene de Igor. ¿Es seguro agrupar scripts de terceros? Quiero decir, cambian a menudo y es la razón por la que no están en el paquete. Así que depende, absolutamente, del script de terceros. Algunos de ellos absolutamente no funcionarán, incluso. Esperan ser servidos desde un cierto origen. Algunos scripts de terceros sí, funcionan absolutamente bien. Y es una forma de evitar el problema de los encabezados de caché para esos scripts de terceros. Pero sí, tienes que tomarlo caso por caso. Sí, eso tiene mucho sentido.

Esta siguiente, creo, probablemente sea aplicable a muchas personas que intentan averiguar cómo pueden aplicar lo que hablaste en tu charla a lo que están trabajando en. Entonces, ¿cuál fue tu motivación... Espera, esa no era la pregunta. Esta. ¿Cómo puedo mejorar las aplicaciones React heredadas creadas hace siete años como las construidas con Nuxt? Entonces, ¿cómo pueden obtener algunas de las características de las que hablabas en una aplicación más heredada? Así que creo que una de las primeras cosas que probablemente puedas hacer es cambiar a Preact, lo cual sería... En modo compacto, a menudo es un reemplazo directo, particularmente si estás viendo una aplicación React heredada y simplemente quieres que sea más pequeña y más eficiente. También puedes escribir tu propio código de empaquetador. Así que probablemente estés viendo Babel. Probablemente estés usando una configuración de webpack Babel con una aplicación React heredada de hace siete años. Y comenzaría identificando el código que no necesita estar allí. Así que mira tu análisis de árbol, encuentra el código que no debería estar allí. Probablemente no se use. Y puedes escribir un plugin rápido. Por cierto, los LLMs son geniales para este tipo de cosas. Así que no tienes experiencia, digamos, escribiendo un plugin de Babel o un plugin de PostCSS o lo que sea. Es muy limitado y es muy comprobable. Así que puedes pedirle a un LLM que te ayude a hacer algo así.

Escribe algo de código para eliminar cosas que no necesitas, por ejemplo. Es tan difícil saberlo sin ver un ejemplo específico. Pero lo he hecho muchas veces en aplicaciones heredadas. Genial. He perdido estos. Así que vamos a saltar aquí. ¿Cuál fue tu motivación para reescribir Nuxt para V3? ¿Y por qué fue tal vez una mala idea? En general, reescribir algo desde cero es una mala idea.

Por defecto. Tienes que tener una razón realmente, realmente buena para hacerlo. Porque todos queremos hacerlo. A todos nos encanta el proyecto perfectamente prístino y fresco. No hay nada más increíble que empezar desde cero. Se siente genial. Pero hay muchos problemas, porque te pierdes todos los casos extremos, todas las correcciones de errores que han existido durante años. Pierdes contexto en muchas cosas. Así que, en general, realmente tienes que tener una razón muy fuerte para hacerlo.

Lo hicimos porque había tantos cambios importantes. Hubo un cambio de Webpack a Vite. Hubo un cambio de Vue 2 a Vue 3. Había una necesidad de construir sitios web que estuvieran optimizados para serverless y no para servidores de larga ejecución. Cambiamos de un inicio en frío de 300 milisegundos en una aplicación Nuxt mínima sin dependencias con Nuxt 2 a menos de un milisegundo en Nuxt 3 porque lo reescribimos desde cero. Y así había muchas buenas razones. Creo que lo que hicimos peor en todo el proceso fue que fuimos demasiado lentos. Priorizamos la completitud de nuestra hoja de ruta sobre la iteración y el cronograma. Y tampoco nos comunicamos lo suficientemente bien con la comunidad mientras lo hacíamos. Y estamos trabajando muy duro ahora con nuestras versiones principales.

Acabamos de lanzar la versión 4. Y tendremos la versión 5 próximamente, creo, probablemente en el nuevo año. Y estamos realmente trabajando duro para que la migración sea tan fluida como no lo fue la migración de 2 a 3. Genial. Esta pregunta viene de netscape. ¿Es tu integración de emoji slides de código abierto? ¿Pueden encontrar el código para eso? Lo es. Así que mi repositorio de slides no es de código abierto, aunque todas mis slides estarán en mi sitio web. Pero el código en mi sitio web live.vue, que corresponde a esa página en vivo, tiene todo lo que necesitas. Creo que si simplemente copias y pegas eso en Slide Dev, podrás tener exactamente lo mismo. Genial. Estamos casi sin tiempo. Pero última pregunta aquí. ¿Cómo son siempre tan buenas tus charlas? Definitivamente puedes volver. Es amable de tu parte decirlo. Genial. Muy bien. Muchas gracias, Daniel. Gracias.