Un Año en Vue 3

Hola a todos. Soy Evan, y gracias por sintonizar Vue.js Live. Hoy, hablaré sobre lo que ha estado sucediendo después de un año del lanzamiento de Vue 3, qué ha cambiado, qué se ha lanzado y algunas de las lecciones que hemos aprendido en el camino.

Y lo más importante, también hablaré sobre lo que viene a continuación. Vue 3 se lanzó el 18 de septiembre de 2020. Es una locura pensar que ya ha pasado más de un año. Durante este último año, lanzamos otras dos versiones menores, 3.1 y 3.2. 3.1 se centró principalmente en la construcción de la migración, y 3.2, de la cual hablaremos un poco más tarde, lanzó un montón de nuevas mejoras. Y entre eso, tuvimos 52 versiones de parches y prelanzamiento.

Hoy, Vue 3 ha superado los 1.2 millones de descargas por mes. Pero muchos de ustedes probablemente se estén preguntando, ¿por qué aún no hemos cambiado vuejs.org y las etiquetas de npm para que por defecto sean Vue 3? La respuesta corta es, sucederá muy, muy pronto. La respuesta más larga es, bueno, estaba planeado, pero solo hasta cierto punto. Cuando se lanzó por primera vez Vue 3, sabíamos que no estaba listo para una adopción masiva instantánea, notablemente, algunas bibliotecas centrales todavía estaban en beta, la nueva extensión de DevTools no estaba lista, y el soporte de IDE y la historia de las herramientas estaban ambos faltantes. Además, los proyectos principales del ecosistema como Nuxt y Vuetify también necesitaban tiempo para presentar una versión compatible con Vue 3. Así que optamos intencionalmente por una estrategia de lanzamiento suave. Esto permitiría a los primeros adoptantes comenzar a usar Vue 3, mientras nos daba tiempo para estabilizar el núcleo y darle al ecosistema el tiempo para ponerse al día.

Pero tenemos que admitir, este lanzamiento suave tomó mucho más tiempo del que esperábamos. Aquí voy a ser completamente honesto y discutir algunas de las lecciones que hemos aprendido. El principal problema que hizo que el ecosistema alrededor de Vue 3 se moviera más lento son los cambios radicales entre Vue 2 y Vue 3. Debido a los cambios radicales, fue un desafío para los proyectos existentes migrar. Con menos usuarios finales pasando a Vue 3, los autores de las bibliotecas también tuvieron menos incentivos para actualizar sus bibliotecas para soportar Vue 3. Y porque muchas bibliotecas no soportaban Vue 3, los usuarios finales no podían actualizar sus proyectos. Entonces, ves que estamos en una especie de punto muerto aquí. Esto se abordó hasta cierto punto a través de la construcción de la migración. Pero también se lanzó un poco tarde, ¿verdad? Se lanzó en julio de 2020, julio de 2021. Mucho más tarde de lo que esperábamos. En un mundo ideal, obviamente queríamos hacer que Vue 3 fuera 100% compatible con versiones anteriores. Sin embargo, en la realidad, implica algunos compromisos extremadamente difíciles. Imagina reingeniería de una hélice a un jet mientras está volando. Bueno, tal vez eso sea un poco exagerado, pero permíteme profundizar un poco en esto.

¿Qué tipo de actualizaciones consideramos mayores? Tengan en cuenta que no estoy hablando de un SemVer mayor. Estoy hablando de algo que típicamente solo hacemos a un framework quizás una vez cada pocos años, ¿verdad? Las razones comunes para tales actualizaciones mayores incluyen, primero, corregir defectos arquitectónicos de diseño. Segundo, introducir nuevas capacidades fundamentales, y tercero, eliminar la deuda técnica de la arquitectura existente. Tengan en cuenta, estos usualmente implican refactorización masiva o incluso reescritura desde cero, que fue el caso de Vue 3.

Los rasgos comunes de estas razones centrales son que son extremadamente costosos de hacer de manera incremental, ¿verdad? Porque algunos de los problemas están arraigados en la arquitectura y sin revisar la arquitectura, algunas de las mejoras simplemente no eran posibles en primer lugar. Entonces, hacer tales grandes actualizaciones mientras se mantiene la total compatibilidad con versiones anteriores a veces es simplemente prohibitivamente costoso de hacer, ¿verdad? ¿Por qué? Porque la total compatibilidad con versiones anteriores es una carga que se acumula con cada nuevo cambio mayor introducido. Cuanto más ambiciosos son los nuevos cambios, más deuda técnica se acumulará durante el proceso.

A largo plazo, hará que el proceso sea aún más difícil, añadir nuevas características, mucho más difícil. Y lo más importante, se vuelve cada vez más costoso mantener el software a largo plazo. Ahora, por otro lado, podemos reducir el alcance de los cambios para hacer las cosas más factibles, pero esto también resulta en mejoras menos ambiciosas, menos posibilidades exploradas y potencialmente estancamiento. Así que es casi como si hubiera un montón de perillas que puedes intentar girar, pero cuando giras una de ellas, las otras se moverán en reacción a la que estás girando.

Entonces, aquí visualicé algunos de los factores que tenemos que considerar mientras hacemos actualizaciones mayores en cuatro perillas, ¿verdad? Estas son la compatibilidad con versiones anteriores, qué tan fácil es actualizar, el costo para implementar y mantener los cambios y mantenerlo a largo plazo, y finalmente, el nivel de mejoras que estos cambios pueden provocar. Entonces, en el caso de Vue 3, el ejemplo es si giramos la compatibilidad con versiones anteriores al 100%, esto hará que sea extremadamente fácil de actualizar, pero también aumentará significativamente los costos de implementación y mantenimiento. Y si intentamos empujar la escala de mejora hasta el 100% al mismo tiempo, aumentará el costo a una escala casi inviable. Ahora, si giramos la perilla de compatibilidad un poco hacia abajo a un 90%, ahora podemos tener tanto un costo razonable como mejoras bastante importantes, pero la actualización del usuario sufrirá, ¿verdad? Se volverá más difícil actualizar. Así que esto esencialmente resume los compromisos que hemos optado en Vue 3, ¿verdad? Intentamos mantener la mayoría de los conceptos del framework y las APIs intactas mientras introducíamos nuevas capacidades. Así que la API es 90% compatible, no es 100% compatible. Lo más importante, algunos de los aspectos internos han cambiado, ¿verdad? Pero pudimos traer actualizaciones mayores en casi todos los aspectos desde el rendimiento hasta el tamaño del paquete hasta la arquitectura interna, la mantenibilidad a largo plazo, la integración de TypeScript, ¿verdad? Es una mejora en todos los aspectos. Desafortunadamente, también tuvimos que introducir algunos de los pequeños cambios disruptivos. Muchos de los cambios de la API pública ahora están cubiertos en la construcción compacta. Sin embargo, algunos de los intercambios son más fundamentales, por ejemplo, el cambio de usar getters-setters de ES5 a proxies para el sistema de reactividad o cambiar el formato del DOM virtual subyacente. Estos cambios fueron necesarios para el nivel de mejoras que estábamos buscando. Sin embargo, también hicieron que fuera más desafiante para los proyectos existentes actualizar, especialmente las aplicaciones con dependencias externas que dependen del comportamiento interno de Vue 2. Este es el mayor obstáculo que hemos visto en la práctica.

Ahora, no estoy tratando de buscar excusas al hablar de todo esto. Mirando hacia atrás, probablemente podríamos haber hecho algunas cosas mucho mejor, especialmente con los cambios disruptivos para hacer el proceso de actualización más suave. Podríamos haber introducido una construcción compacta antes y definitivamente deberíamos haber trabajado en los nuevos documentos antes también. Pero en última instancia, todavía creo que hacer que Vue 3 sea 100% compatible con versiones anteriores, especialmente con otras bibliotecas que dependían del comportamiento interno de Vue 2, es algo que simplemente era demasiado costoso para comprometerse. No podríamos obtener el nivel de mantenibilidad y el nivel de mejoras que queremos, que tenemos ahora mismo al mismo tiempo, si nos comprometemos a la compatibilidad total con versiones anteriores. Así que, suficiente sobre los cambios disruptivos, pero ahora hablemos de algo más optimista.

La buena noticia es, creo que el punto de inflexión está muy cerca y veremos la adopción de Vue 3 crecer significativamente en 2022. Ahora, fuera de Vue en sí, una de las razones por las que este cambio mayor, este cambio a Vue 3 por defecto se ha retrasado tanto tiempo es que hemos dedicado mucho tiempo a estabilizar Vite. Así que esto es una especie de desvío que esperamos que valga la pena a largo plazo. Vite es una nueva herramienta de construcción que mejora enormemente la experiencia de desarrollo con un tiempo de inicio del servidor increíblemente rápido y un rendimiento de reemplazo de módulos en caliente.

Ahora, hoy Vite ya ha superado 1 millón de descargas mensuales en NPM y se está utilizando activamente en muchos proyectos de producción. También cambiaremos nuestra herramienta recomendada para Vue 3 a una configuración basada en Vite muy pronto. Si aún no has probado Vite, confía en mí, te va a sorprender. Así que definitivamente pruébalo, échale un vistazo. Anthony de nuestro equipo y el equipo de Vite y Alex de la Escuela Vue van a hablar sobre Vite en sus charlas. Así que definitivamente mantén un ojo en esas.

Aunque mi enfoque principal sigue siendo Vue como desarrollador de código abierto, mi objetivo final es ayudar a otros desarrolladores a hacer su trabajo más rápido. Por eso estoy particularmente orgulloso de que aunque Vite fue creado inicialmente específicamente para Vue, ahora ha evolucionado en una herramienta agnóstica de marcos que puede beneficiar a todos los desarrolladores web. Otro aspecto para el aumento de la adopción de Vue 3 es que IE 11 está saliendo a un ritmo más rápido. Dado que Vue 3 ya no soporta IE 11, esto ha sido una de las preocupaciones para muchos usuarios. La buena noticia es, cada vez más grandes actores están dejando de dar soporte a IE 11. Uno de los más recientes es Google Search que ahora oficialmente deja de dar soporte a IE 11 en su producto principal. Todavía tiene una experiencia de respaldo pero esencialmente dijeron, no vamos a invertir más soporte en IE 11. Y esto es lo que dijeron, hicimos los cálculos, es hora. Así que esperamos que esto también envíe una señal a más y más empresas para empezar a dejar de dar soporte a IE 11 juntas.

Lo más importante y probablemente lo que más nos importa como usuarios es que el ecosistema realmente está alcanzando ahora. NUTS 3, acaba de entrar en beta pública con toneladas de mejoras, características increíbles. Muchos de ustedes probablemente, han estado esperando esto y Alex del equipo de NUTS hablará de ello muy pronto. ViewUse es otro proyecto que manifiesta el poder de la Composition API. Es una gran colección de utilidades de la Composition API que van desde las APIs de los navegadores hasta las APIs de los sensores de los dispositivos, fusiones hasta la animación, hasta la gestión del estado. La mejor parte es, puedes usar tantas de ellas como quieras en tu proyecto sin ninguna de las desventajas de las mezclas, ¿verdad? Sin conflictos de nombres de espacio, soporta completamente el tree shaking. Así que definitivamente échale un vistazo si aún no lo has hecho. Ahora, si estás buscando marcos de componentes de interfaz de usuario, también ya hay muchas opciones que son estables para V3. Quasar 2 ya es estable. Virtify todavía está en alfa pero alcanzará la beta en diciembre. John Leeder hablará de esto probablemente en su charla.

También existen otras excelentes opciones, como naive UI, prime view, element plus y design view. Y si estás construyendo algo específicamente para móviles, también hay excelentes opciones, ¿verdad? Ionic view se construyó desde cero con V3. También existen versiones compatibles con V3 de vent UI y un nuevo proyecto llamado Valet. Así que también revisa estas opciones si estás construyendo para móviles.

Además del ecosistema, también enviamos más mejoras en view en sí en 3.2. La característica nueva más importante en 3.2 es script setup, que mejoró significativamente la ergonomía al usar la Composition API dentro de los componentes de archivo único. Ahora, debido a las limitaciones de tiempo, no voy a mostrar todas las características en 3.2, pero después de la charla, revisa estas diapositivas. Hay enlaces a todo lo que mencioné. También tuvimos publicaciones de blog anunciando 3.2, así que revisa esas si estás interesado. También mejoramos enormemente el soporte de IDE para los componentes de archivo único de view a través de la extensión Vola, que ahora es la nueva recomendación. Así que si todavía estás usando Vedar, definitivamente considera cambiar a Vola para probarlo. Y WebStorm también ha estado haciendo un gran trabajo en mantenerse al día con nuestras últimas ediciones de sintaxis. Así que WebStorm ya soporta script setup también en los componentes de archivo único de view. Ahora también tenemos una herramienta dedicada llamada ViewTSC, que puede comprobar el tipo de componentes de view junto con los archivos TS normales. Así que puede tratar tanto los archivos de view como los archivos TS en el mismo proyecto, y es un paso de comprobación de tipo. Puedes hacer esto en tus pipelines de CI, así que no tienes que, así que puedes confiar en la retroalimentación instantánea del IDE durante el desarrollo y luego ejecutar esto durante la construcción o durante el CI. 3.2 también envió mejoras de rendimiento importantes para el sistema de reactividad y en términos de renderizado, también está la nueva directiva Vmemo, que te da la oportunidad de hacer ajustes muy detallados, muchas optimizaciones, en casos donde es extremadamente exigente. Nah, pero en la mayoría de los casos, el rendimiento del renderizado ya es bastante bueno. Y finalmente, tenemos algunos RFC pendientes que pueden introducir aún más mejoras ergonómicas para la Composition API. Por ejemplo, el RFC de transformación de ref que nos permite usar refs con reactividad, pero sin la necesidad de usar dot value en todas partes. Así que si te ha molestado dot value, definitivamente revisa este RFC. Creemos que todo esto combinado llevará a Vue 3 a un nuevo nivel.

Pero por supuesto, también queremos ayudar a los usuarios de Vue 2 a migrar, o si no pueden, beneficiarse de algunas de estas nuevas mejoras. Así que primero, enviamos la construcción de migración en 3.1. Eso puede ayudar a los proyectos elegibles a migrar de forma incremental a Vue 3. Típicamente, lo que hemos encontrado es que deberías ser capaz de migrar a Vue 3 a través de la construcción de migración, a menos que tengas algunas dependencias duras que son irremplazables, pero también dependen del comportamiento interno de Vue 2. Ahora, autores de bibliotecas. Nuestra recomendación para los autores de bibliotecas es escribir la mayoría de su lógica usando la Composition API, y luego puedes dirigirte tanto a Vue 2 como a Vue 3 a través de la utilidad vue-demi. Detecta automáticamente la versión correcta de Vue y luego alias tus APIs a la versión correcta. Los usuarios de Vue 2 también pueden disfrutar de la velocidad de VEET a través de VEET plugging Vue 2.

Y puedes comenzar a usar script setup con Vue 2 a través de desenchufar script setup Vue 2. Ahora, ambos complementos están escritos por miembros del equipo central.

También no nos hemos olvidado de 2.7. Así que lo principal que queremos hacer en 2.7 es retroportar composition API de nuevo a Vue 2 para que los usuarios de Vue 2 ya no necesiten usar un paquete externo para usar composition API. Esto está planeado para el primer trimestre de 2022.

Por último, pero no menos importante, estamos trabajando en una revisión completa de vuejs.org. Desearía que hubiéramos hecho esto antes, pero estoy muy, muy emocionado por esta iteración porque trae tantas mejoras. Como puedes ver, habrá diseños completamente nuevos con modo oscuro. El sitio está completamente reconstruido en VitePress. VitePress es el sucesor de VuePress, que ahora está construido sobre Vue 3 y Vite. Puede generar estáticamente el sitio a partir de Vue y Markdown.

Los nuevos docs actualizarán recommendations y best practices. Hay información muy dispersa sobre cuál es la mejor opción para usar, qué deberías usar, cómo deberías configurar un proyecto para Vue 3, ¿verdad? Está un poco por todas partes en los docs actuales y de toda la información que ha estado alrededor. Así que los nuevos docs consolidarán todo ello y habrá la recomendación por defecto. Y puedes ir allí, puedes encontrar cuál es la mejor manera de hacer las cosas.

Y también hemos reestructurado los caminos de aprendizaje. Correcto, así que dividimos el nuevo contenido en tres partes principales, la guía, los ejemplos y el tutorial. Así que la guía tendrá muchas partes reescritas para reflejar las últimas best practices. Y lo más importante, la guía se escribirá de tal manera que tenga el mismo flujo, los mismos conceptos, pero puedes alternar entre la API de opciones y la composition API para ver cómo se comparan o simplemente te quedas con la API que prefieres durante el proceso de aprendizaje. Todos los ejemplos también estarán disponibles en ambos estilos de API y habrá muchos ejemplos nuevos también. Habrá una introducción reescrita y una visión general del framework, página de preguntas y respuestas y un nuevo tutorial para el aprendizaje práctico.

Así que como he mencionado, el cambio de view dos a view tres está a la vuelta de la esquina. Ocurrirá tan pronto como los nuevos docs estén listos. Y eso será muy pronto. Después de eso, Vue.js.org se establecerá por defecto en los nuevos docs para view tres. NPM distacts, review y otras bibliotecas centrales apuntarán todas a las versiones de view tres por defecto. Los repositorios de GitHub seguirán estando separados. Esto es principalmente porque queremos preservar los enlaces de los problemas ya que son un recurso importante para los usuarios que buscan desde Google e intentan encontrar respuestas a problemas pasados. Así que mantendremos los repositorios separados. En su lugar, renombraremos el repositorio Vue.next a Vue.js slash core.

Y eso es todo. Estoy ansioso por mostrarles el nuevo Vue.js.org una vez que esté terminado y espero que estén tan emocionados como yo.

Así que muchas gracias. Entonces, echemos un vistazo a lo que la gente está usando hoy. Aparentemente, la gran mayoría todavía está usando Vue 2 pero planea migrar a Vue 3. Así lo dijo el 57% de ustedes. Un afortunado 30% de ustedes ya están usando simplemente Vue 3 y el 13% está contento con Vue 2.

¿Es eso sorprendente? No realmente. Sí, eso es más o menos lo que yo... Me alegra ver que tanta gente está planeando migrar a Vue 3. Sí, pero también creo que para algunos proyectos como si ha estado funcionando bien, es estable. Para cierto tipo de proyectos, realmente no necesitas actualizar porque a veces siempre tienes que considerar el costo frente a los beneficios, ¿verdad? Específicamente para un escenario. Como si es un proyecto heredado, no tienes mucho ancho de banda, ¿verdad? En muchos sentidos, actualizar, puede que no resulte en ninguna diferencia importante desde la perspectiva del usuario, pero simplemente te va a costar mucho tiempo. Así que en esos casos, creo que tiene sentido quedarse en la versión que funciona para ti.

Y sí, y que el 30% ya esté en Vue 3 es genial. Esperemos que más proyectos nuevos también comiencen en Vue 3 con todas las cosas que mencioné en la charla. Creo que todavía escuché a algunas personas preocupadas por IE 11, pero soy muy optimista de que va a morir antes de lo que pensamos. Así que crucemos los dedos. Vale. Bien.

Entonces, volviendo a la primera pregunta. ¿Cómo ha sido la mudanza a Singapur? Como pueden ver, todavía estoy en el hotel de cuarentena con dos niños. Así que ha sido un poco desafiante, pero lo estamos manejando. De hecho, creo que apenas logré superar el jet lag porque es un jet lag de 12 horas. Y tienes que hacerlo con dos niños. Así que ha sido bastante duro. Pero una vez que salgamos de la cuarentena, creo que entonces tendremos que ponernos en movimiento, empacar, desempacar cosas y todo eso. Así que todavía queda algo de tiempo. Así que todavía no estoy realmente en modo de trabajo, pero la comida ha sido genial. Así que esa es la buena parte.

La comida es importante. Bueno, siguiente pregunta. ¿Es probable que PNIA se convierta en la solución predilecta de la community para la state management? Sí, creo que PNIA es, Eduardo ha estado haciendo muchas cosas geniales con PNIA. Así que una de las cosas más grandes que sabemos que no es ideal para la forma actual de UX, con Vue 3 es su soporte para TypeScript, porque todas las funciones de envío dependen mucho de las cadenas de texto. Así que realmente no obtienes suficiente comprobación de tipos en todos los servicios de API. Así que PNIA esencialmente está diseñado con todo eso en mente. También es más simple, ¿verdad? Menos verboso. También te da esta forma de definir una tienda utilizando la pura composition API, que también se alinea mejor con el sistema de reactivity de Vue 3. Así que en general, creo que PNIA definitivamente está avanzando en la dirección correcta. De hecho, muchos de los diseños que ves en PNIA se superponen con la propuesta que hemos estado discutiendo internamente sobre cómo debería ser Vuex Next. Así que Kiah y Eduardo han estado trabajando juntos. Hemos estado haciendo una lluvia de ideas sobre cómo debería ser Vuex, pero algunas de las cosas que surgieron, se sienten muy diferentes a la forma actual de Vuex. Así que esencialmente, es una pregunta interesante si todavía debería llamarse Vuex, ¿verdad? Si se ve muy diferente. Bueno, fundamentalmente, creo que lo que realmente queremos en una solución de state management es previsibilidad, soporte de tipos, integración de herramientas de desarrollo, que maneje SSR para ti con la menor sobrecarga posible. Así que PNIA logra todo eso. Y de alguna manera, PNIA es esencialmente esta especie de juguemos con la próxima iteración de Vuex, pero bajo un nombre diferente. Así que si tuviera que introducir un sistema de state management en una aplicación hoy, probablemente también usaría PNIA. Así que, quiero decir, para casos incluso más simples, simplemente usaría un objeto reactivo como un singleton, lo exportaría desde un archivo e importaría en un montón de componentes, especialmente si no necesito renderización del lado del servidor. Si necesito renderización del lado del servidor, todavía puedo hacerlo. Simplemente puedo proporcionarlo e inyectarlo desde la raíz de la aplicación, y eso es más o menos lo que estamos haciendo en BPRESS. Es muy simple porque simplemente proporcionas, inyectas un montón de Refs u objetos reactivos, y esa es otra forma de state management. Por supuesto, eso sólo cubre casos simples porque no te da integración con DevTools, inspeccionabilidad, y PDM cubre todo eso, mientras mantiene la API simple. Así que, creo que es una gran solución.

Muy bien. La siguiente pregunta es una que también me intriga mucho. ¿Sigue siendo la API de opciones la forma recomendada por defecto para construir componentes de UI? Bueno, esto se responderá de manera más adecuada en los próximos docs. Ya he escrito la nueva sección de introducción, así que para reformular todo eso, esencialmente tendremos tanto la API de opciones como la API de composición como opciones igualmente viables. Y cuál elegir dependerá de varios factores.

En primer lugar, ¿estás usando una herramienta de compilación? Si no estás usando una herramienta de compilación, la API de composición va a ser un poco verbosa porque no puedes confiar en ninguna de estas mejoras de calidad de vida en tiempo de compilación como la sintaxis de script setup o ref sugar, ¿verdad? Así que en esos casos, la API de opciones también, si no estás usando una herramienta de compilación, la complejidad general de tu aplicación probablemente esté en el rango de baja a media, ¿verdad? Así que la API de opciones definitivamente seguirá siendo muy viable o incluso, sabes, probablemente mejor adaptada en esos escenarios. Pero si estás usando un paso adulto, estás usando TypeScript o tienes la intención de escalar tu aplicación, sabes, van a haber varios desarrolladores trabajando en ella. Diría que la API de composición con TypeScript y script setup va a ser una opción muy, muy fuerte, sabes, en términos de lanzador de mantenibilidad, productividad, soporte de herramientas de IDE y todo va a ser una muy buena elección. Pero también he oído, sabes, argumentos donde depende de la composición de tu equipo, ¿verdad? Si tu equipo está cómodo con TypeScript y, sabes, el equipo es esencialmente porque todos tenemos algún tipo de preferencia técnica o gusto diferente, ¿verdad? Es importante considerar cuando eliges una API, qué tipo de productividad, ¿mejora la productividad de todo tu equipo en su conjunto, ¿verdad? Porque en algunos casos, si estás trabajando con muchos principiantes, a veces la API de Opciones te da mejores guardrails porque te permite hacer las cosas sin pensar demasiado en cómo funciona la reactividad. Así que la API de Composición, por otro lado, es un poco más libre. Permite a los desarrolladores experimentados organizar mejor tu código, usar patrones avanzados, extraer y reutilizar la lógica de formas muy elegantes, pero también requiere que te sientas algo cómodo con el concepto de cómo funciona el sistema de reactividad en Vue. Así que tienes que tener un sólido entendimiento de cómo Vue rastrea las cosas, cómo se activan las cosas para poder usar la API de Composición correctamente. Así que es una especie de compromiso. Así que tienes que elegir en base a con lo que te sientas más cómodo, con lo que se sienta más cómodo tu equipo. Pero a un nivel muy alto, voy a decir que ambas son opciones muy viables. Así que una pregunta de seguimiento a eso. Perdón. ¿Cuánto tiempo se seguirá soportando la API de Opciones? ¿Hay algún plan en algún momento para migrar completamente de ella? Realmente no. Así que el costo de soportar la API de Opciones en Vue 3 es muy, muy bajo. Realmente no hay... Son sólo unas pocas cientos de líneas de código. Así que una vez que... Realmente no hay mucha razón para que la eliminemos. Lo que pasa es que, en nuestra documentación, en la nueva documentación, ¿verdad? Escribimos la documentación de manera que el flujo principal de la guía se mantiene igual, pero tenemos algo que te permite alternar entre la API de competición y la API de Opciones cuando quieras, y es persistente. Así que una vez que tienes una preferencia de la API, todo el sitio esencialmente funciona con ese estilo de API. Así que todavía puedes leer la misma guía. Es lo mismo. Todavía estamos introduciendo los mismos conceptos en la guía, pero será en la API que hayas elegido ver. Pero también puedes decir cuando estás leyendo la misma sección de la guía, puedes alternar entre ellas para ver la comparación entre ellas para entender mejor la relación entre ellas. Creo que también, el hecho de que pudimos reescribir la guía de esa manera también muestra que las dos API son realmente sólo diferentes interfaces de los mismos conceptos subyacentes.

Así que sigue siendo lo mismo cómo funciona Vue, cómo funciona el sistema de reactivity, cómo todo encaja, ¿verdad? Los conceptos fundamentales siguen siendo los mismos. Realmente es sólo una cuestión de cómo prefieres expresar tus intenciones utilizando diferentes estilos. Bueno, eso es todo. La pregunta original es no, no va a desaparecer. Así que realmente no hay ningún plan. Vale. Siguiente pregunta. ¿Nos permitirá Vue demi utilizar múltiples nodos raíz en nuestros componentes y seguir siendo compatible con Vue 2? Desafortunadamente, no, porque Vue demi está cubriendo estrictamente, Vue demi está cubriendo estrictamente sólo las APIs de reactivity. Así que esencialmente hace un puente entre tus importaciones a APIs como REF, reACTIV, a Vue 3 si existe o a añadir Vue slash Composition API, que es el plugin de Composition API para Vue 2. Si quieres múltiples nodos raíz en Vue 2 real, desafortunadamente eso no es posible debido a cómo funciona el sistema de renderizado de Vue 2, pero puedes usar la Migration Build, Vue 3 Migration Build, que tiene el comportamiento de Vue 2 pero soporta las características de Vue 3. Así que échale un vistazo, revisa la Migration Build. Si tu aplicación no es compleja, especialmente si tu aplicación no tiene dependencias como Nuxt o Vue Defy, entonces Migration Build probablemente te llevará a Vue 3 sin cambiar demasiado el code. Entonces puedes migrar pieza por pieza esas características obsoletas. Vale, nuestra siguiente pregunta es, ¿se moverá el Vue CLI a Vite? ¿Y si es así, cuándo? Así que, en resumen. Así que Vue CLI esencialmente va a estar en modo de mantenimiento pronto porque toda la architecture de Vue CLI está basada en webpack. Y cuando nos movamos a Vite, va a ser mucho más fundamental que... Sabes, lo que pasa es que cuando empiezas una nueva aplicación con el plugin de Vite, se siente prácticamente igual desde la perspectiva del code fuente. Así que todas las características eran más o menos las mismas. La única diferencia es que nuestra nueva herramienta de andamiaje llamada create Vue va a ser mucho menos opinada y mucho más ligera. Así que no intenta ser tan abarcante como Vue CLI donde te da su propio sistema de plugins. Estamos esencialmente diciendo que sólo uses el sistema de plugins de Vite, aprovecha el ecosystem de Vite en lugar de tener un jardín amurallado con plugins que sólo funcionan con Vue CLI. Así que esto también, estratégicamente esto también porque a lo largo de los años, Soda que mantiene Vue CLI ha estado gastando tanto tiempo porque teníamos un alcance muy ambicioso para Vue CLI pero nos dimos cuenta a largo plazo, que muchas cosas pueden hacerse a un nivel más bajo en lugar de tenerlas específicamente para Vue CLI. Así que la nueva herramienta de andamiaje es esencialmente una capa delgada encima de Vite. Si necesitas características adicionales especiales, tenemos opciones por defecto como TypeScript o configurar TypeScript o test runner u otras cosas. Pero en general, Vite intenta centrarse específicamente sólo en un paso de construcción y en el servicio. Así que, digamos que quieres pretty o ES linked, no vamos a realmente guiarte sobre cómo hacer eso. En cambio, te vamos a dirigir a la documentation o a las soluciones de la community que ya funcionan para cualquier tipo de proyecto de Vite, en lugar de sólo para Vue CLI. Vale. Vale. La siguiente pregunta es, ¿planea Vue seguir soportando la instalación de CDN y por qué tantos plugins sólo están disponibles como instalaciones de NPM? Así que Vue siempre soportará el uso de CDN.

El hecho de que los plugins solo soporten la instalación de NPM, honestamente, no lo creo porque muchas bibliotecas de la comunidad de Vue también tienen sus propias compilaciones CDN, ¿verdad? Así que creo que esto es, así que si una biblioteca puede soportar una compilación CDN, pero no lo hace, creo que es más un problema de la biblioteca, ¿verdad? Porque técnicamente cualquier versión de Vue siempre puede ser utilizada a través del CDN. Ahora, por supuesto, hay desventajas en eso porque no puedes hacer tree shaking. Así que si haces todo a través del CDN, vas a terminar con mucho código no utilizado. Pero quiero decir que sigue siendo viable si toda tu configuración no es realmente complicada para justificar un paso de construcción. Así que sí, la respuesta corta es que siempre se soportará una compilación CDN.

Bueno, ahora, última pregunta rápida. Si estamos empezando un nuevo proyecto, ¿deberíamos usar V2 o V3? Definitivamente V3. Vamos. Tenía la sensación de que esa sería la respuesta. Muy bien. Evan, muchas gracias por unirte a nosotros hoy. Gracias. Ha sido un placer.