Panel Discussion: ¿Cuál es el siguiente gran paso para Vue/Nuxt?

Entonces, sí, vamos a tener algunas preguntas antes de que el público proponga cualquier pregunta o tema. La primera es, ¿cuál crees que es el próximo gran paso para Vue slash next? Empecemos por Daniel. ¿Cuál es el próximo paso? Bueno, muchas de las cosas en las que estamos trabajando ahora mismo son sobre rendimiento, tanto haciendo las cosas más rápidas en el tiempo de compilación como en el tiempo de desarrollo, y también pensando en cuáles son las formas en que podemos hacer que el compilador mejore las cosas para ti en producción, porque ¿por qué no, verdad? Creo que eso es algo en lo que siempre queremos estar a la vanguardia. Parece que eso no es un gran próximo paso, no es algo completamente nuevo o algo así, pero creo que es algo en lo que realmente estamos poniendo mucho esfuerzo. Tengo algunas cosas más de vanguardia también. Creo que estamos buscando ver mucho más sobre WASM en el navegador y también en el servidor, y eso va a ser cada vez más necesario a medida que el ecosistema de herramientas de construcción de JavaScript se dirige hacia bibliotecas nativas, como pensar en cosas basadas en Rust o impulsadas por Rust. Y entonces, WASM va a ser realmente importante para desplegar binarios en producción. Así que, eso es bastante genial. Y podría enumerar algunas otras cosas, pero estoy seguro de que hay otros que también podrían querer agregar algunas cosas.

Cierto. Sí, también sé que WASM es realmente muy bueno para el rendimiento. Conozco a alguien que tuvo beneficios increíbles con él, así que definitivamente es una buena elección.

¿Qué piensas, Maya? Sí, estoy de acuerdo con Daniel respecto al rendimiento en WASM. Nunca lo he intentado, personalmente nunca he intentado trabajar con eso en absoluto, pero he visto bastantes discusiones al respecto. Y especialmente la persona que trabaja en eso es de Microsoft, así que lo veo en todas partes.

Bien, perfecto. Eduardo, ¿algún comentario? Nada que agregar. Lo siento. Eduardo, seguramente vas a decir algo sobre los loaders. Siento... Intentó contenerse, intentó contenerse... Pensé que era sobre WASM. Creo que la pregunta es simplemente, ¿cuál es el próximo gran paso? Completamente me perdí la pregunta. Hay algunas cosas que tengo que hacer en segundo plano debido a la hora del día. Así que, fue medio divertido, medio otra cosa. Sí, el data loader es algo importante. Uno de mi lado sigue trabajando en ello, pero ha sido más de un año. Quiero decir, prácticamente todo está en la charla, ¿verdad? Bien. Dije, lo siento mucho. Lo siento por más detalles. Probablemente vieron la charla de Eduardo. Si no, siéntanse libres. ¿Qué hay de ti? ¿Qué hay de ti, Alex? ¿Tienes algún proyecto interesante próximamente? ¿Algún proyecto interesante próximamente? Sí, quiero decir, además del canal de YouTube y el podcast. Los arruinaste todos. Eso es todo, eso es todo. Danos más detalles sobre tus planes para, impulsarlo y cómo conectar a la comunidad o... Sí, creo que cómo conectar a la comunidad, ese es un muy buen punto. Así que, creo que mientras mi contenido en YouTube, por ejemplo, también el streaming es más sobre educación o streaming, como simplemente mostrando cómo construyo cosas que puedo compartir y tal vez la gente esté interesada en eso. Creo que el podcast es realmente una cosa de la comunidad porque el objetivo es tener a algunas personas increíbles del lado de código abierto de Vue en su propio ecosistema, pero también muchas personas que son usuarios de Vue, que construyen cosas increíbles con él y que tal vez, no sé, se convirtieron en consultores de Vue o líderes de equipo o CTOs o startups, como startups divertidas que usan Vue Knox para alcanzar sus objetivos y explicar qué funcionó bien, qué no funcionó bien, si hubieran tomado decisiones diferentes, qué desearían.

Y escuchar a personas que son entusiastas ávidos de Vue, pero que no tienen esa voz en la comunidad en este momento porque tal vez no sean tan populares o no comparten el conocimiento de otra manera. Y hay tantos proyectos increíbles por ahí. Así que, Michael, le doy un saludo, quien está de baja por paternidad en este momento, volverá muy pronto. Tenemos algunos invitados realmente geniales alineados y sí, definitivamente deberías seguir Deja Vu en ese término. Sí. No estoy seguro si podemos tener algunos enlaces en Discord o algo, pero sí, por favor. Y sí, también, quería señalar el hecho de que como estás en el equipo de Nuxt, eso es muy bueno porque puedes simplemente explicar las cosas cuando se lanzan y, sí, explicar algunos puntos dolorosos que la gente podría tener. Así que, sí, eso es muy bueno. Si nadie tiene nada que preguntar sobre eso, supongo, segunda pregunta? Creo que tengo. Bien, Maya, adelante.

Bien. Bien. Tengo una pregunta sobre el podcast, Alex. Entonces, ¿cuál es el público objetivo al que te diriges? ¿Es también para desarrolladores medios, digamos, desarrolladores senior para aprender, escuchar y mejorar? Porque encuentro que ahora la mayoría de los podcasts, quiero decir, para Vue o para front end, para la web, son muy de nivel principiante. En cierta fase, tenemos desarrolladores de rango medio o senior comenzando. Empieza a volverse demasiado, ¿cómo se dice?, demasiado básico.

Pero queremos un poco más de enfoque para construir sistemas más complejos y cómo avanzar desde allí. Entonces, quiero decir, ¿cómo se mantendría el podcast? Es un buen punto. Entonces, nuestra audiencia en general son cualquier tipo de desarrolladores de Vue, desarrolladores en general que estén interesados en el ecosistema de Vue y Nuxt. Y de alguna manera, estoy de acuerdo con, especialmente para contenido para principiantes, es bastante fácil producirlo. No necesitas una cantidad loca de experiencia. Pero especialmente para personas que ya han escuchado bastante contenido para principiantes, se estanca en algún momento. Pero lo que queremos hacer es también dar a todos los que escuchan al menos algo nuevo para aprender. Tal vez no en cada episodio, no creo que eso sea realmente posible, pero al menos tener también algunos puntos como, oh sí, mira, tal vez no leas las últimas notas de la versión. Aquí hay una característica. Y no solo aquí hay una característica, también puedes descubrirlo, pero ¿por qué? Como dar ejemplos, dar casos de uso. Y con las personas compartiendo sus historias, también dar inspiración y puntos como, oh, interesante. Esa persona, digamos, construyó una aplicación genial o un juego genial con Vue.

Y también compartir algunas historias sobre lo que funcionó bien, lo que no funcionó bien. Entonces, el problema con los podcasts es principalmente que es un tema muy complejo. Es complicado sin compartir pantalla, sin profundizar demasiado y luego perder a las personas que tal vez no estén tan interesadas. Así que, eso es lo que comúnmente hago más en videos, porque entonces tienes la pantalla también. Así que, sí, eso es complicado, pero al final, tratamos de atender a todos y también allí, agradecemos cada retroalimentación. Y si dices, está bien, más contenido de eso, cosas más profundas, tratamos de facilitar a todos.

Entendido. Sí, conozco a bastante gente. Conozco a bastante gente que estaría muy dispuesta a presentar su trabajo con ello. Y también, sí, basado en las personas que están haciendo Deja Vu, sí, eso probablemente también sea bastante avanzado si el público lo quiere. Así que, sí, muy buena elección. Recordatorio amable de que si alguien quiere hacer una pregunta sobre un tema específico, puede hacerlo en Slido. ¿Y está bien? ¿Tenemos algo más? ¿O puedo pasar a la segunda pregunta esta vez?

Quiero decir, ahora que estás preguntando, Konstantin, creo que cuál es el próximo gran paso, lo que no se mencionó, y tal vez sea algo obvio, pero habrá más, al menos desde mi punto de vista, sin juego de palabras, e ideas, habrá más conexiones con el servidor y el cliente. Porque ahora mismo, todavía, los tratamos hasta cierto punto como entidades diferentes, y tenemos conexiones API. Y por supuesto, con cosas como Nuxt server components, las cosas se acercan cada vez más. Pero también veo que eso viene cada vez más. Pero también allí, sabemos que no sucederá en el mundo de React, donde los server components serán algo desde el principio, eso no es lo que está planeado en Vue, pero tener más experimentos allí en el meta framework.

Así que, Nuxt será bastante interesante de ver. Y también, probablemente veremos más y más del equipo de Nuxt, gracias a NGS. Y el hecho de que se usa en muchos lugares, también las herramientas de desarrollo que tenemos en Vue que ahora se usan en Solid y Astro, tal vez incluso en más lugares. Así que sí, definitivamente es una buena elección. ¿Sí? ¿Maya? ¿Daniel? ¿Eduardo? ¿Algún otro comentario? ¿Todo bien?

¿Sí? ¿Maya? ¿Daniel? ¿Eduardo? ¿Algún otro comentario? ¿Todo bien? Entonces, en línea con lo que estaba diciendo sobre el rendimiento, creo que vale la pena mencionar VaporMode en Vue. Porque ese es exactamente el tipo de rendimiento habilitado por las transformaciones en tiempo de construcción de las que estoy hablando. Creo que también veremos cosas como... Entonces, la fusión de Wiz y Angular es muy interesante, porque trae al ámbito de código abierto muchas de las primitivas centrales que Google ha estado usando con Wiz para crear cosas realmente interesantes. Entonces, componentes reanudables, una especie de hidratación bajo demanda, y eso básicamente se va a filtrar. Así que eso es algo que estoy observando con gran interés en términos de Nuxt. Así que, esto es solo para desarrollar lo que fue... Estoy comenzando a darme cuenta de que fue una respuesta un poco vaga antes. Así que, creo que definitivamente estaría observando ese espacio. Y la buena noticia sobre mucho de esto es que debería funcionar sin que la gente necesite optar por ello. Así que deberíamos poder comenzar a usar algunas de estas cosas para la gente y su proyecto debería volverse más rápido y mejor. Esa es la idea. Quiero decir, podría señalar planes específicos que tenemos para Nuxt, pero creo que el gran titular es ese, diría yo. Así que, esos fueron mis dos centavos finales.

Entonces, esos fueron mis dos centavos finales. Perfecto, gracias. Sí, también vi que la comunidad de Nuxt está dispuesta a enfocarse mucho en temas de rendimiento. Por ejemplo, la última vez me encontré con cosas específicas de hidratación como Astro sobre, oye, ¿cuándo quieres que tu aplicación se hidrate? ¿Cuándo la ves, cuándo está en el viewport?

Así que sí. En general, creo que la mayoría de los frameworks ahora, como los meta frameworks, tienden a ir en la misma dirección donde apuntan al mismo objetivo. Ellos solo tienen diferentes herramientas y ecosistemas. Pero al final, tal vez en dos o tres años, todo será increíblemente rápido y con muchos plugins y todo. Así que sí, quiero decir, ya tenemos algo así con Nuxt, así que eso es muy bueno.

Sí. Eduardo, ¿algún comentario? Quiero decir, hemos estado hablando durante mucho tiempo, así que realmente ya no hay una pregunta. No sé si responderías. Sí, quiero decir, claro. Pero es más como, ¿crees que de tu lado, también podrías... Creo que es la misma pregunta. ¿De nuevo, el futuro? ¿O es el rendimiento? Es más como, desde tu punto de vista, ¿crees que podrías hacer algo revolucionario en términos de rendimiento? ¿O es más como refinar y agregar características y algo más? De mi lado ahora mismo, no estoy enfocado en el rendimiento porque el equipo está haciendo un mejor trabajo estableciendo la base.

Y yo me encuentro reutilizando las bases que funcionan bien. Aunque hay lugares donde podría mejorar. Hay cosas en el rendimiento, hay un problema abierto, por ejemplo, que es interesante para el router de Vue, que es sobre tener muchas rutas. Así que este es un caso muy específico. Y si tienes muchas rutas, el matcher existente no está diseñado para ser eficiente en ese escenario. Y así que inicialmente diseñé el router para poder conectar otro matcher. Es decir, el router está dividido en múltiples partes, y la lógica del matcher maneja una parte del enrutamiento. Y puedes pasar, quiero decir, no puedes pasarlo, pero el código ya está preparado para pasar un matcher. Ha sido así durante cuatro años. Así que pasas otro matcher, como un trip, pierdes algunos de los beneficios de tener el enrutamiento basado en RareGix, pero ganas en rendimiento. Así que creo que para estos sitios web que necesitan el rendimiento, no necesitan las rutas basadas en RareGix, pero prefieren el rendimiento. Y hasta ahora, no he tenido tiempo de implementarlo porque necesito enfocarme en otras cosas. Y también me estoy enfocando en las finanzas de mi lado. Así que estoy tratando de equilibrar eso.

Sí, perfecto. Maldita sea, no lo sabía. Lo escuchaste aquí primero, creo. ¿Qué dijiste? Dije, lo escuchaste aquí primero. Este es el comienzo de un nuevo amanecer brillante. Vamos. Tal vez vayamos hacia la segunda pregunta que tenía, que es como si tuvieras una lista de deseos como hasta hoy, ¿qué pedirías en términos de Vue o Nuxt o cualquier cosa relacionada, incluso Vite? Sí. Y Vite. Oh, eso es lo que tengo. Solo ESM. Estoy teniendo algo simple para bibliotecas. No, pero... ¿Tal vez Daniel? Creo que hay mucho legado. Oh, Eduardo, lo siento. Sí, ¿Eduardo? Sí, lo siento. Sé que lo entendiste. No, no, no. Quiero decir, ese fue un buen comienzo. Legado, ese siempre es un buen tema para empezar. Legado, sí. Quiero decir, creo que sufrimos mucho. Los usuarios sufrieron mucho. Mi equipo sufrió mucho por todo el fiasco requerido de ESM, todo el fiasco de typescript ESM, command.js. Entonces, es un dolor tanto para los mantenedores como para los consumidores porque hay personas que consumen de diferentes maneras. No es realmente la parte del proyecto que actualizas o te importa actualizar porque, bueno, no está en una biblioteca, así que no ves mucho sobre eso. No agrega nada. Pero, para los mantenedores, necesitamos mantener múltiples partes de las bibliotecas, múltiples exportaciones, múltiples salidas. Y es difícil. Creo que, Daniel, lo has visto más porque en Nuxt, ves más problemas al respecto, ¿verdad? Como, personas abriendo problemas de palabras. También es difícil de depurar para ti y para ellos.

Entonces, ¿emocionado por Node? Absolutamente. Es genial. Y están requiriendo ESM. Además, ¿no tenemos hoy en día herramientas muy buenas que te permiten trabajar con ESM o command.js? Como, Ben está haciendo eso, si no me equivoco, donde podrías simplemente volcar ambos. Quiero decir, al mismo tiempo, no estoy seguro si está funcionando bien, pero al menos es algo que tenemos. Así que, eso es bueno, agradable.

Daniel, ya que fuiste el primero en responder, ¿puedes señalar algunas cosas que te gustaría mejorar con respecto a Nuxt? Quiero decir, probablemente tengas muchas. Así que, sí, tengo una larga lista de cosas que me gustaría mejorar en Nuxt. Entonces, ¿cuáles son algunas cosas que me gustaría señalar? Entonces, soporte multi-app, entonces, federación de módulos, o incluso una especie de federación de módulos ligera, donde tienes una especie de aplicación Nuxt que podría, digamos, importar un solo componente en tiempo de ejecución desde otra aplicación o algo así. Entonces, como, podrías tener una especie de aplicación Nuxt como anfitrión, y podría consumir diferentes tipos de cosas.

También estamos ya, ya tenemos soporte experimental para fuentes remotas para islas de servidor, componentes de servidor. Entonces, puedes crear y podrías, por ejemplo, tener un punto final que renderice componentes, digamos, para tu biblioteca de componentes o CMS. Y luego podrías tener múltiples sitios web que consuman estos componentes. Y básicamente, podrías hacer eso hoy. Pero de nuevo, no hablamos mucho sobre eso. No hemos estabilizado completamente el conjunto de características. Y así, creo que eso es algo que disfrutaré ver. Estoy esperando una de las cosas que viene en Vite y de la que nos aprovecharemos en Nuxt y en Nitro, que es el soporte de entornos. Entonces, la idea, entonces, en este momento cuando estás construyendo una aplicación Nuxt, la estás construyendo en un entorno de desarrollo. Y luego cuando la despliegas, se despliega en Azure o Vercel o Cloudflare o algún otro entorno.

Y así, hay diferencias entre estos que pueden morderte, volver a morderte. Entonces, a veces las personas despliegan y dicen, oh, algo no está funcionando para mí. Y lo rastreamos con, oh, como Azure se comporta de esta manera. Y así, pero no sabrás eso en desarrollo, lo cual es un dolor y puede ser una fuente de errores. Entonces, Vite está experimentando con la idea. Hay un problema abierto para hablar sobre ello. Tener la idea de tener realmente entornos en el contexto de Vite. Entonces, lo interesante de eso para mí es que nos permite tal vez hablar sobre tener, por ejemplo, entornos de desarrollo. Y Nitro ya está siguiendo este camino. Creo que probablemente antes de que Vite lo hiciera, ahora es difícil de decir, pero Nitro también está siguiendo esta ruta.

Entonces, por ejemplo, si estás construyendo para Cloudflare, ¿puedes acceder a esos Cloudflare primitives en desarrollo en el servidor? Bueno, sí, puedes, gracias a un módulo experimental que Puyo creó. Y ese es el tipo de cosas que creo que nos gustaría ver desplegadas más ampliamente. Entonces, nuevamente, aumentando la diferencia entre dev y prod, haciendo eso en Vite, haciendo eso en Nuxt, haciendo eso en Nitro, y realmente teniendo este tipo de enfoque mucho más sin fisuras, lo cual creo, nuevamente, cuantas menos diferencias tengas entre desarrollo y producción, más estable y más confiado estarás cuando despliegues tu aplicación.

Entonces, sí. En cuanto a los micro frontends, nunca he trabajado realmente con ellos. Tal vez, Maya, ¿conoces alguna empresa que los use? ¿Los usas en Microsoft? Porque hasta ahora, sé que la mayoría de las empresas solo hacen su propio código fuente. ¿Tienes tal vez algún usuario para eso?

No, diría que no conozco ningún grupo en Microsoft que realmente esté usando micro frontends, pero es muy común, es un concepto de moda, creo. Quiero decir, he escuchado a la gente hablar de ello por un tiempo, y creo que mi amiga Natalia, Natalia Kim de Microsoft, también está trabajando y promoviendo sobre micro frontend. Pero nunca me ha llegado sobre el micro frontend. Es como que el concepto es agradable, pero a veces simplemente no me convence sobre el micro frontend. Así que, nunca lo he probado, para ser honesto. Aunque, me gustaría intentarlo.

¿Es el web component similar al micro frontend? Vamos, no es correcto. No es lo mismo, ¿verdad? No, el micro frontend es más como si tienes un shell y dentro tienes varios frontends. Así que, eso es realmente agradable. Si, por ejemplo, tienes varios equipos, equipos grandes trabajando en características y no quieres bloquearlos. Así que, eso es muy bueno para ese caso. Pero necesitas tener como una especie de tienda general que los interconecte. Así que, eso es bastante complejo. Y lo disfruto. Puede causar mucho, creo que puede causar mucha complejidad.

Usualmente, la mayoría del equipo está trabajando en un producto o una característica. Y, ya sabes, no es una característica. Es un producto o un proyecto y una aplicación. Así que, a menos que realmente tengas que compartir el mismo componente en todas partes, entonces eso puede funcionar. Pero de nuevo, el concepto es agradable, pero necesitas ver en la realidad dónde está realmente el caso de uso. Como cuáles son los problemas subyacentes en mantenerlo. Así que, quiero decir, no es solo un componente porque realmente podrías traer muchos frameworks dentro de él. Por ejemplo, podrías tener un Nuxt y dentro React, Svelte, Vue, Svelte, React. Así que, sí, es como un caso de uso específico. Tal vez tenga más sentido para bibliotecas, creo. Pero sí, no he visto algo así todavía. Yo tampoco. Tal vez, Alex, ¿tal vez lo viste como consultor en algún lugar? Así que, como, sí y no.

He escuchado a muchas personas hablar sobre ello. Tengo muchas personas usándolo. Y creo que entiendo el atractivo de una cierta parte de los micro-frontends. Entiendo la idea de decir, tenemos una aplicación enorme y tenemos equipos responsables de diferentes partes y deberían tener control autónomo sobre cómo desplegar, sobre qué usar y no deberían esperar a otros equipos porque entonces las cosas se retrasarán. Deberían tener su propio camino, su propio CI, sus propias integraciones y así sucesivamente. Así que, es realmente como la forma de microservicio en el backend, pero también dividido en el front end. Entiendo la idea detrás de esto.

Pero como ya mencionaste, y como el problema típico, los micro-frontends traen otro conjunto de problemas. Así que, comienza con, bueno, el rendimiento, por ejemplo. Bueno, si tienes un gran SPA detrás de la autenticación, tal vez entonces no sea tan importante que cargues, si ese es el caso, como 10 frameworks diferentes en 11 versiones diferentes. Si haces eso, no tienes que hacerlo, ¿verdad? No tienes que cargar un framework diferente para un microservicio diferente. Y por otro lado está, bueno, como dijiste, la gestión de estado, ¿verdad? Comunicación, además de cómo lidiar con eso.

Y creo que, como Visionvise, si usas un framework que tiene bastante buen soporte para eso, que realmente dice, bueno, oye, puedes integrar ciertas aplicaciones y obtienes esa libertad de despliegue y la libertad de, bueno, elección, digamos, y los equipos pueden trabajar de manera autónoma. Eso puede funcionar bastante bien. Pero no me he encontrado con una solución que sea como, bueno, sí, eso es increíblemente cómo funcionaría. Y ni siquiera comenzamos con el renderizado del lado del servidor y la parte de rendimiento allí. Creo que, sí, eso abre otra caja de Pandora.

Sí, sí. Sí, sí. Tal como dijo Alex, los microservicios pueden funcionar. ¿Estás cortando un poco, Maya? ¿Podrías repetir, por favor? La mayoría de nuestro proyecto, es fácil dividir uno. ¿Puedes oírme? Sí, ¿podrías repetir los últimos 15 segundos, por favor? Sí. Así que solo estaba diciendo que los microservicios, pueden funcionar. Realmente demostraron que funcionan en el backend porque literalmente se trata solo de comunicación con los servidores y realmente puedes tener servidores más pequeños. Pero el frontend es más complejo que el backend porque en el frontend también tienes que lidiar con interfaces de usuario, comunicación con diferentes componentes a diferentes componentes. Así que sí, puede ser complejo. Puede ser muy, muy difícil de manejar, si no tienes cuidado con ello. Sí, especialmente si quieres una experiencia sin problemas que sea realmente fluida porque si es desordenado en el backend, realmente no lo ves. Puedes sentirlo, pero en el frontend, es más complicado. Tenemos algunas preguntas en Slido.

Uno de ellos es sobre web components. La pregunta es como, ¿qué pasa con los web components dominando el mundo? Así que no estoy seguro exactamente de lo que significa, pero ¿crees que tal vez en algún momento, usaremos más y más web components en general? Quiero decir, sé que Vue es muy bueno en términos de web components, en cómo puedes exportarlos y usarlos fácilmente en comparación con todos los frameworks. Pero sí, ¿crees que esto será muy popular o solicitado por mucha gente?

¿Daniel? ¿Algo sobre web components? Lo siento. Lo siento, Daniel. Adelante. No hay problema. Así que quiero decir, los web components, siento que han tenido mucha promesa. La gente ha pensado que esta va a ser la solución para muchas cosas. Así que es una forma de distribuir un solo componente de una manera que funcione en múltiples frameworks. Y si miras, por ejemplo, Cal.com, recientemente lanzaron algunos primitives, que son React components. Bueno, eso es una pena, ¿verdad? Porque significa que tienes que tener una aplicación React para poder incrustar esos componentes. Así que ahora necesitamos Vue components. Y los web components, en cierto modo, están abordando eso. Así que puedes escribir web components, compilarlos, y pueden ser usados en cualquier lugar. Y así Vue CLI tiene un gran soporte para exportar Vue en web components y consumirlos. Dicho esto, hay muchos puntos dolorosos alrededor de los web components, incluyendo en el renderizado del lado del servidor. Y parece haber una desconexión de alguna manera entre la fricción y la dificultad de usarlos y la promesa que se mantiene. Lo que significa que, ahora mismo, si me preguntas, ¿soy optimista sobre los web components? No lo soy. Creo que la promesa, por supuesto, es fantástica, y me encantaría ver eso. Pero la realidad es muy diferente. Y no quita el dolor. Lo que puedes hacer es envolver el dolor. Así que puedes construir, por ejemplo, un módulo de Nuxt que lo maneje por ti. Y eso es lo que actualmente recomendaría. Así que hay algunos grandes módulos como Prashant, por ejemplo, y Steve están manteniendo un módulo de Nuxt para alguna biblioteca de web components, y haciendo un trabajo fantástico al meterse debajo de la piel de la biblioteca y averiguar cómo hacer que funcione correctamente con el renderizado del lado del servidor. Así que, quiero decir, puedes usar eso y no experimentar el dolor. Pero el dolor sigue ahí. Simplemente está siendo soportado por los mantenedores del módulo. Así que no tengo nada en principio en contra de los web components, pero solo reconozco que ahora mismo, traen mucho dolor, particularmente si quieres hacer cosas como renderizarlos en el lado del servidor.

Entonces, por ejemplo, está Mitosis, que es una solución de Builder.io, en la que codificas tu componente en un formato común que luego se exporta a diferentes frameworks. Esa es una opción. Creo que Anthony en algún momento propuso una solución muy experimental, ReactiveView, o algo así, que te permitía usar directamente React en Vue. No estoy seguro de que lo recomendaría hoy en día. Y puede que haya otras soluciones también, al problema central, que creo que querríamos resolver, que es, ¿cómo tener interoperabilidad entre frameworks y bits individuales de componentes? Pero no estoy seguro de que los web components sean la respuesta en este momento. Pero al mismo tiempo, no estoy seguro de que haya alternativas tremendamente mejores disponibles.

Entonces, esa es mi opinión. Estoy de acuerdo. Aunque sea agnóstico y muy bueno, al final, lo que importa es ir rápido a veces y tener un buen ecosistema. Así que, si necesitas construirlo siempre desde cero sin muchas herramientas, eso puede ser un poco molesto. Y de nuevo, sí, como dijiste, Mitosis es una muy buena alternativa y muy agradable. Maya, ¿tienes algún comentario emocionante sobre los web components?

Bueno, lo que quiera decir, Daniel ya lo dijo todo. Está bien. Literalmente, mi punto de vista es el mismo que el suyo. Está bien. La próxima vez, Konstantin, Maya debería hablar, porque estamos bastante alineados, sospecho. Así que, ella puede hablar por mí y yo hablaré por ella sobre eso. Oh, está bien. Eso será interesante. ¿Tal vez tienes alguna experiencia con eso?

Bueno, ya lo escuchaste. ¿Tal vez tienes alguna experiencia con los web components, Maya? Sí, bueno, básicamente, la forma en que trabajo, tenemos un sistema de diseño que llamamos Fluent UI. Entonces, nuestro sistema de diseño tiene dos partes. Una es componentes de React para proyectos de React, y la otra son web components para proyectos de React. La otra son web components para el resto, que si escribes un proyecto en Vue, tienes que usar web components. O Angular, también usas web components. Así que, literalmente, tendemos a cambiar a React en lugar de elegir Vue porque usar web components en Vue no, ya sabes, no viene naturalmente, y los web components tienen muchos problemas cuando empiezas a trabajar con complejidad. Además, realmente no tienes mucha experiencia de usuario, sino más bien experiencia de desarrollador que puede ayudarte a trabajar con web components sin problemas. Por eso es bastante difícil para mí trabajar con ellos.

Está bien. ¿Alex? Entonces, para añadir a lo que ya se dijo, creo que los web components, especialmente con respecto a la renderización del servicio o la compatibilidad con SEO y demás, dieron un gran paso adelante con el shadow DOM declarativo que está disponible en todos los navegadores ahora. Así que, eso es genial. Pero quiero dar un ángulo diferente a todo esto. Como, estoy de acuerdo, las promesas, pueden no cumplirse tan fácilmente. Todavía necesitamos una buena solución para la gestión de plantillas y estados, lo que otros frameworks ya tienen. Pero enfrentémoslo de esa manera. Los web components son ahora mismo, y no hay mejor alternativa, si quieres mantenerte cerca del estándar, ¿verdad? Si escribes un web component ahora, la probabilidad de que todavía funcione en 10 años es bastante buena.

Si abres un proyecto de Node de hace 10 años, la posibilidad de que aún funcione, bueno, dada la versión de Node, podría ser, pero luego puede haber otras cosas. ¿Hace dos semanas, dices? Oh, sí, justo. Justo. Entonces, he estado con bastantes empresas, así que, está bien, quieren construir software que debería seguir funcionando en 10 años porque lo despliegan en máquinas y no pueden simplemente actualizarlo cada año. O digamos, deliberadamente, está bien, no queremos elegir un framework porque queremos adherirnos lo más posible a los estándares del navegador. Y entonces los web components son la mejor manera de ir al final. No importa si te gusta que sean basados en clases, que haya mucha fricción con respecto a la gestión de estados y plantillas, pero si solo quieres depender del estándar, eso es lo que hay. Y también creo que habrá más y más mejoras, dado que este es el estándar y también tengo la sensación de que, digamos, el dolor que la gente experimenta con los web components, que también llegó a las personas responsables de los estándares, para el desarrollo, y así sucesivamente. Así que, creo que veremos mejoras en el futuro. ¿Alcanzaremos alguna vez la plena interoperabilidad? Probablemente no, pero tal vez obtengamos algo que funcione y sea menos doloroso y divertido de usar. Así que, veamos a dónde va esto. Sí. Incluso tenemos algunas noticias increíbles de tc39 con muchas propuestas para tal vez incluso tener como tipos integrados en vanilla JS. Así que, sí, eso es bastante loco y emocionante. Uno picante también, en realidad. Sí, cierto. ¿Tal vez tenemos algún comentario sobre eso, Eduardo? ¿Web components? Creo que los web components simplemente perdieron el momento. Fue demasiado tarde para la fiesta, en otras palabras. Los frameworks estaban demasiado establecidos. Hace 10 años hubiera sido bueno, ¿crees? No, tal vez 15. Vaya. Pero así no es como funcionan las cosas en las especificaciones, son mucho más lentas, debido a cuántas cosas tienen que manejar cuando hacen las especificaciones. Así que, ahora es demasiado tarde. Es como, las cosas que son interesantes son más como un punto intermedio, otra capa de abstracción que convierte las cosas, como Mitosis, que de alguna manera se parece a Wasp. Así que, tener ese lenguaje que es una abstracción para un mejor rendimiento, no para todo, pero. Así que, es interesante, ¿verdad? Te pierdes, es como una oportunidad perdida en cierto modo. Pero, porque también no, es demasiado, es demasiado, la API es demasiado mala en comparación con cualquier otro framework. Como la API en los web components es simplemente mala. Nadie escribe web components porque, quiero decir, directamente, porque la API es tan limitada. Y escribes algo en Svelte, en Vue, tal vez Sully, no estoy seguro.

Pero personalmente optaría por Vue, Svelte si quiero construir un web component. Definitivamente no React. Por supuesto, React parece más simple para interactuar con web components, porque la API es más limitada. Tienen menos características que frameworks como Vue, Svelte, Sully. Pero luego, si estás acostumbrado a algo como Vue y Svelte, que es genial, entonces los web components parecen una mierda. Es como volver a hace 15 años o JavaScript, lo cual es demasiado a veces para React.

Entonces, si estás haciendo web components durante 15 años, eso también es un buen argumento en el lado opuesto. Es como, maldita sea, Vue, Vue.js es una mierda. Hay demasiada sintaxis de azúcar. Quiero decir, algunas personas realmente se quejan de eso. No estoy hablando del azúcar, estoy hablando de características. Y es más sobre que solo tienes cosas básicas. Tienes muchas limitaciones en los web components, como los eventos y esas cosas. Sí, la experiencia de desarrollo es por lo tanto mala. Y luego tienes todas las capas. Hay tantas capas hoy en día, con Vite y todos los servidores de desarrollo, los frameworks. Hay mucho que ponerse al día. No hay manera de que vayas a tener algo nativamente que sea solo la mitad de bueno que lo que tienes con un framework. Solo el tiempo. Especialmente con cosas como la autenticación y muchos módulos de Nuxt que la gente quiere hoy en día, que están resolviendo muchos problemas grandes de manera simple.

Tal vez como un resumen, porque estamos alrededor de cinco minutos, ¿podríamos tal vez tener una rápida ronda de los mayores éxitos de Nuxt hasta ahora? ¿O las mayores lecciones? Solo estoy fusionando dos preguntas. Entonces, si pudiéramos tener 60 segundos de cada uno de ustedes pensando, oye, ¿por qué Nuxt lo hizo genial en los últimos años? Maja, ¿primero? Bueno, debo decir lo que más me gusta cuando cambio a Nuxt 3, el tiempo de inicio es mucho más rápido que antes. Y eso es gracias al equipo. Y la segunda cosa es que la estructura del proyecto de Nuxt se ha vuelto mucho más simple, como más simple y más fácil de entender y más fácil de navegar también. Y sí. Así que, eso ha sido lo principal, el rendimiento de Nuxt. Comenzamos un proyecto, para agregar algunas características, para agregar un nuevo módulo dentro, fue mucho más fácil que antes. Además, la sintaxis se está volviendo mucho, mucho más fluida. Cierto. Daniel? 60 segundos.

Creo que uno de los... Entonces, éxitos, uno de ellos es TypeScript y nuestra capacidad para decirle a la gente en el punto de uso, muchas cosas que no sabían antes. Entonces, todo, desde el nombre del middleware hasta lo que es un layout, hasta algo como rutas de tipo unplugged de Eduardo, que le dice a la gente cuáles son las rutas válidas.

Entonces, creo que eso es un gran éxito. Creo que nuestro mayor fracaso hasta ahora fue la migración a la versión 3 y no lanzar más pronto y más rápido y mantener a la gente más actualizada. Los cambios importantes, creo que no hicimos un gran trabajo con eso. Cierto. Y en un mes más o menos, tendrás la oportunidad de ver si hemos aprendido la lección. Sí.

Maldición. Emocionado por Nuxt 4. Vamos. Eduardo, ¿tu opinión sobre esto? ¿O de tu lado o de mí personalmente? Sí, tal vez sobre la migración o cualquier cosa buena que haya sucedido. También eres muy bienvenido a comentar sobre cualquiera de mis fracasos, Eduardo. Como, eso sería... ¿Tu fracaso? Bien. 60 segundos para criticar a Daniel. Disparando tiros. Más flexiones. No, honestamente, siento que Nuxt hizo un gran trabajo en la migración. Personalmente, tuve un gran tiempo migrando. Es solo que hay algunos problemas que son inherentes a la tecnología en sí. Las capas añaden complejidad y depuración a veces, migrar a veces es difícil. Pero es cierto que tomó tiempo para que Nuxt se pusiera al día. Pero es porque tenían... Quiero decir, explicaron todo en publicaciones de blog. Entonces, ¿qué estoy repitiendo cosas? Pasaron por Vite, Webpack, y luego los refactores unplugged.

Hubo tantas mejoras en Nuxt 3 que son completamente invisibles porque están en NGS. Y así que creo que eso es un éxito. Honestamente, en realidad, cuando eres consciente de todas estas cosas, es impresionante, ¿verdad?

El fracaso está más en el lado de Vue para algunas de las migraciones. Algunas de las cosas tomaron mucho tiempo. Creo que la migración... Podríamos haber colaborado un poco mejor con las empresas que necesitaban ayuda con Vue 2. Pero de nuevo, no sé si están dispuestas a pagar. Pero eso es un requisito en algún momento. De lo contrario, supongo que será agotador no tener ningún apoyo de las empresas que necesitan soporte legacy.

De hecho. Así que tal vez haya algo ahí, ¿verdad? Es un fracaso. Sí. Desde nuestro lado también. De hecho, sí. Tener más empresas involucradas sería bueno. Cierto.

¿Qué hay de ti, Alex? ¿Algún gran logro? Sí, seré breve. Grandes éxitos. Tenemos tres cosas. La primera es más una broma. Merch. Merch es increíble, pero no puedes comprarlo. Eso es desafortunado. Espero que tengamos una tienda de merch algún día. Dedos cruzados. Pero en serio, los mayores logros... La experiencia del desarrollador. Y lo que valoro aún más, y no hay mucho que valore más que la experiencia del desarrollador, la contribución a todo el ecosistema de JavaScript. Y eso es bastante grande. Quiero decir, ver a dónde va Andreas, ver dónde se está utilizando el código, y también la inspiración para otros autores de frameworks y autores de bibliotecas también.

Fallo, bueno, la migración de Nuxt 2 a Nuxt 3 ya se mencionó, pero también allí, creo que durante ese tiempo, la comunicación podría haber sido mucho mejor. Pero eso está detrás de nosotros. Eso es el pasado.

Y lo haremos mucho mejor, como dijo Daniel. Y eso es todo. Sí, conclusión perfecta sobre eso. Y para el merch, tenemos la camiseta de Vue.

js Live. Así que sí, no es el gran merch, pero aún así, es un comienzo. Así que gracias de nuevo por la increíble discusión. Un gran aplauso para todos los panelistas. Déjame poner algunos aplausos. Vamos. Y sí, vamos a tomar una breve pausa y volveremos en unos minutos. Quédense ahí. Nos vemos pronto.