Un año en Vue 3

Rate this content
Bookmark

Vue 3 puede sonar nuevo para muchos usuarios, pero en realidad ya ha sido lanzado hace más de un año. ¿Cómo evolucionó Vue 3 durante este período? ¿Por qué tardó tanto en ponerse al día el ecosistema? ¿Qué hemos aprendido de este proceso? ¿Qué viene a continuación? ¡Discutiremos estas preguntas en esta charla!

20 min
20 Oct, 2021

Video Summary and Transcription

Vue 3 ha experimentado una adopción significativa y mejoras en rendimiento, tamaño del paquete, arquitectura e integración con TypeScript. El ecosistema alrededor de Vue 3 se está poniendo al día, con nuevas herramientas y frameworks en desarrollo. La documentación de Vue.js.org está siendo completamente renovada. PNIA está emergiendo como la solución de gestión de estado preferida para Vue 3. La API de opciones y la API de composición son ambas opciones viables en Vue 3, la elección depende de factores como la complejidad y la familiaridad con TypeScript. Vue 3 continúa admitiendo la instalación a través de CDN y se recomienda para nuevos proyectos.

Available in English

1. Introducción a Vue 3 y sus desafíos

Short description:

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 enviado y algunas de las lecciones que hemos aprendido en el camino. Vue 3 ha superado 1.2 millones de descargas al mes. Optamos intencionalmente por una estrategia de lanzamiento suave para permitir que los primeros adoptantes comiencen a usar Vue 3 mientras nos damos tiempo para estabilizar el núcleo y dar tiempo al ecosistema para ponerse al día. El principal problema que causó que el ecosistema alrededor de Vue 3 se moviera más lento son los cambios incompatibles entre Vue 2 y Vue 3.

Hola a todos. Aquí 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 enviado 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 increíble 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 migración, y 3.2, del cual hablaremos un poco más tarde, incluyó muchas mejoras nuevas. Y entre eso, tuvimos 52 versiones de parche y prelanzamiento.

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

Pero tenemos que admitir que este lanzamiento suave llevó mucho más tiempo de lo que esperábamos. Aquí seré completamente honesto y hablaré sobre algunas de las lecciones que hemos aprendido. El principal problema que causó que el ecosistema alrededor de Vue 3 se moviera más lento son los cambios incompatibles entre Vue 2 y Vue 3. Debido a los cambios incompatibles, fue un desafío migrar proyectos existentes. Con menos usuarios finales que se mudan a Vue 3, los autores de bibliotecas también tenían menos incentivos para actualizar sus bibliotecas para admitir Vue 3. Y debido a que muchas bibliotecas no admitían Vue 3, los usuarios finales no podían actualizar sus proyectos. Entonces, estamos en una especie de punto muerto. Esto se abordó en cierta medida a través de la compilación de migración. Pero también se envió un poco tarde, ¿verdad? Se envió en 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 hacia atrás. Sin embargo, en realidad, implica algunos compromisos extremadamente difíciles. Imagina reingenierizar una hélice en un jet mientras está volando. Bueno, tal vez eso sea un poco exagerado, pero déjame profundizar un poco más en esto.

2. Consideraciones para Actualizaciones Mayores en Vue 3

Short description:

Las actualizaciones mayores en un framework generalmente se realizan una vez cada varios años para corregir fallas de diseño arquitectónico, introducir nuevas capacidades y eliminar deudas técnicas. Sin embargo, mantener la compatibilidad total hacia atrás se vuelve prohibitivamente costoso a medida que se acumula con cada cambio importante. Optamos por un compromiso en Vue 3, manteniendo la mayoría de los conceptos y APIs intactos mientras introducimos nuevas capacidades. Aunque algunos aspectos internos han cambiado, logramos importantes actualizaciones en rendimiento, tamaño del paquete, arquitectura, mantenibilidad e integración de TypeScript. Se requirieron pequeños cambios disruptivos para estas mejoras, pero dificultaron la actualización de proyectos que dependían del comportamiento interno de Vue 2.

¿Qué tipo de actualizaciones consideramos importantes? Tenga en cuenta que no estoy hablando de una versión importante de SemVer. Me refiero a algo que normalmente solo hacemos en un framework tal vez una vez cada varios años, ¿verdad? Las razones comunes para estas actualizaciones importantes incluyen, en primer lugar, corregir fallas de diseño arquitectónico. En segundo lugar, introducir nuevas capacidades fundamentales y, en tercer lugar, eliminar la deuda técnica de la arquitectura existente. Tenga en cuenta que esto generalmente implica una refactorización masiva o incluso una reescritura desde cero, como fue el caso de Vue 3.

Las características comunes de estas razones principales son que son extremadamente costosas de realizar de manera incremental, ¿verdad? Debido a que algunos de los problemas están arraigados en la arquitectura y sin una revisión completa de la arquitectura, algunas de las mejoras simplemente no serían posibles en primer lugar. Por lo tanto, realizar estas grandes actualizaciones manteniendo la compatibilidad total hacia atrás a veces resulta prohibitivamente costoso, ¿verdad? ¿Por qué? Porque la compatibilidad total hacia atrás es una carga que se acumula con cada cambio importante introducido. Cuanto más ambiciosos sean los nuevos cambios, más deuda técnica se acumulará durante el proceso.

A largo plazo, esto dificultará aún más el proceso de agregar nuevas funciones. Y lo más importante, se vuelve cada vez más costoso mantener el software a largo plazo. Por otro lado, podemos reducir el alcance de los cambios para que las cosas sean más factibles, pero esto también resulta en mejoras menos ambiciosas, menos posibilidades exploradas y potencialmente estancamiento. Es como si hubiera una serie de perillas que se pueden girar, pero cuando giras una de ellas, las demás se mueven en reacción a la que estás girando.

Entonces, aquí visualicé algunos de los factores que debemos tener en cuenta al realizar actualizaciones importantes en cuatro perillas, ¿verdad? Estas son la compatibilidad hacia atrás, la facilidad de actualización, el costo de implementar y mantener los cambios y mantenerlo a largo plazo, y finalmente, el nivel de mejoras que estos cambios pueden aportar. En el caso de Vue 3, el ejemplo es que si giramos la perilla de compatibilidad hacia atrás al 100%, esto facilitará enormemente la actualización, pero también aumentará significativamente los costos de implementación y mantenimiento. Y si intentamos llevar la escala de mejora al 100% al mismo tiempo, el costo se volverá casi inasumible. Ahora, si giramos un poco hacia abajo la perilla de compatibilidad, digamos al 90%, ahora podemos tener un costo razonable y mejoras importantes, pero la actualización de los usuarios sufrirá, ¿verdad? Se volverá más difícil de actualizar. Esto resume básicamente los compromisos que hemos elegido en Vue 3. Intentamos mantener la mayoría de los conceptos y APIs del framework intactos mientras introducimos nuevas capacidades. Por lo tanto, la API es compatible en un 90%, no en un 100%. Lo más importante es que algunos aspectos internos han cambiado, ¿verdad? Pero logramos importantes actualizaciones en casi todos los aspectos, desde el rendimiento hasta el tamaño del paquete, la arquitectura interna, la mantenibilidad a largo plazo y la integración de TypeScript. Es una mejora en todos los aspectos. Desafortunadamente, también tuvimos que introducir algunos pequeños cambios disruptivos. Muchos de los cambios en la API pública ahora están cubiertos en la versión compacta. Sin embargo, algunos de los cambios son más fundamentales, por ejemplo, el cambio de usar getters y setters de ES5 a proxies para el sistema de reactividad o el cambio en el formato subyacente del DOM virtual. Estos cambios fueron necesarios para el nivel de mejoras que estábamos buscando. Sin embargo, también dificultaron la actualización de proyectos existentes, especialmente las aplicaciones con dependencias externas que se basan en el 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 que el proceso de actualización sea más fluido. Podríamos haber introducido una versión compacta antes y definitivamente deberíamos haber trabajado en la nueva documentación antes también. Pero en última instancia, sigo creyendo que hacer que Vue 3 sea 100% compatible hacia atrás, especialmente con otras bibliotecas que se basaban en el comportamiento interno de Vue 2, es algo que simplemente era demasiado costoso para comprometerse. No podríamos haber obtenido el nivel de mantenibilidad y las mejoras que tenemos en este momento al mismo tiempo si nos comprometemos con la compatibilidad total hacia atrás. Así que, suficiente sobre los cambios disruptivos, pero ahora hablemos de algo más optimista.

3. Adopción de Vue 3 y Ecosistema

Short description:

Se espera que la adopción de Vue 3 crezca significativamente en 2022. Hemos dedicado tiempo a estabilizar Vite, una nueva herramienta de compilación que mejora enormemente la experiencia de desarrollo. Vite ha superado el millón de descargas mensuales en NPM y será la herramienta recomendada para Vue 3. Los principales actores están dejando de dar soporte a IE 11, lo que indica la necesidad de que las empresas hagan lo mismo. El ecosistema está avanzando, con NUTS 3 en fase beta pública y ViewUse ofreciendo potentes utilidades para la API de Composición. Los frameworks estables de componentes de UI para V3 incluyen Quasar 2 y Virtify (beta en diciembre).

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

Hoy en día, Vite ya ha superado el millón de descargas mensuales en NPM y se utiliza activamente en muchos proyectos de producción. También cambiaremos nuestra configuración de herramientas recomendadas para Vue 3 a una basada en Vite muy pronto. Si aún no has probado Vite, créeme, te sorprenderá. Así que definitivamente pruébalo, échale un vistazo. Anthony de nuestro equipo y el equipo de Vite, y Alex de Vue School, hablarán sobre Vite en sus charlas. Así que definitivamente mantén un ojo en ellas.

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. Es por eso que estoy particularmente orgulloso de que, aunque Vite fue creado inicialmente específicamente para Vue, ahora se ha convertido en una herramienta agnóstica de frameworks que puede beneficiar a todos los desarrolladores web. Otro aspecto para aumentar la adopción de Vue 3 es que IE 11 está desapareciendo a un ritmo más rápido. Dado que Vue 3 ya no es compatible con IE 11, esto ha sido una preocupación para muchos usuarios. La buena noticia es que cada vez más actores importantes están dejando de dar soporte a IE 11. Uno de los más recientes es Google Search, que ahora ha dejado oficialmente de dar soporte a IE 11 en su producto principal. Aún tiene una experiencia de respaldo, pero básicamente dijeron que no invertirán más en el soporte de IE 11. Y esto es lo que dijeron: hicimos los cálculos, es hora. Así que esperemos que esto también envíe una señal a más y más empresas para que dejen de usar IE 11 juntos.

Lo más importante y probablemente lo que más nos importa a nosotros, como usuarios, es que el ecosistema está alcanzando rápidamente. NUTS 3, que recientemente entró en fase beta pública, tiene muchas mejoras y 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 muestra el poder de la API de Composición. Es una gran colección de utilidades para la API de Composición que van desde las API del navegador hasta las API de sensores de dispositivos, fusiones, animaciones y gestión de estado. Lo mejor de todo es que puedes usar tantas como quieras en tu proyecto sin ninguno de los inconvenientes de las mezclas, ¿verdad? Sin conflictos de nombres de espacio, compatible con tree shaking. Así que definitivamente échale un vistazo si aún no lo has hecho. Ahora, si estás buscando frameworks de componentes de UI, ya hay muchas opciones estables para V3. Quasar 2 ya es estable. Virtify todavía está en fase alfa pero alcanzará la beta en diciembre. John Leeder hablará de esto probablemente en su charla.

4. Ecosistema y Mejoras de Vue 3

Short description:

Hay otras excelentes opciones para construir con Vue 3, incluyendo naive UI, prime view, element plus y design view. Para el desarrollo móvil, hay opciones como Ionic view, vent UI y Valet. Vue 3.2 introdujo script setup, mejoró el soporte de IDE y mejoras de rendimiento. La directiva Vmemo permite ajustes detallados para la optimización de renderizado. Las RFC pendientes ofrecen posibles mejoras ergonómicas. Los usuarios de Vue 2 pueden migrar de forma incremental utilizando la versión de migración y aprovechar la utilidad vue-demi para apuntar a ambas versiones. VEET enchufando Vue 2 proporciona beneficios de velocidad para los usuarios de Vue 2.

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

Además del ecosistema, también hemos lanzado más mejoras en Vue mismo en la versión 3.2. La característica más importante en 3.2 es script setup, que mejora significativamente la ergonomía al usar la API de composición dentro de los componentes de archivo único. Debido a las limitaciones de tiempo, no voy a mostrar todas las características de 3.2, pero después de la charla, revisa estas diapositivas. Hay enlaces a todo lo que mencioné. También hemos publicado entradas de blog de anuncios para 3.2, así que revisa eso si estás interesado. También hemos mejorado en gran medida el soporte de IDE para los componentes de archivo único de Vue a través de la extensión Vola, que ahora es la nueva recomendación. Entonces, si todavía estás usando Vedar, definitivamente considera cambiar a Vola para probarlo. Y WebStorm también ha hecho un gran trabajo al mantenerse al día con nuestras últimas ediciones de sintaxis. Ahora WebStorm ya admite script setup en los componentes de archivo único de Vue. Ahora también tenemos una herramienta dedicada llamada ViewTSC, que puede verificar el tipo de componentes de Vue junto con archivos TS normales. Puede tratar tanto los archivos de vista como los archivos TS en el mismo proyecto, y es un solo paso de verificación de tipos. Puedes hacer esto en tus canalizaciones de compilación de CI, para que no tengas que, para que puedas confiar en la retroalimentación instantánea del IDE durante el desarrollo y luego ejecutar esto durante la compilación o durante CI. 3.2 también incluye importantes mejoras de rendimiento para el sistema de reactividad y en términos de renderizado, también está la nueva directiva Vmemo, que te brinda la oportunidad de realizar ajustes muy detallados, muchas optimizaciones, en casos donde es extremadamente exigente. Pero en la mayoría de los casos, el rendimiento de renderizado ya es bastante bueno. Y finalmente, tenemos algunas RFC pendientes que pueden introducir aún más mejoras ergonómicas para la API de composición. Por ejemplo, la RFC de transformación de ref que nos permite usar refs con reactividad, pero sin la necesidad de usar 'dot value' en todas partes. Entonces, si te ha molestado 'dot value', definitivamente revisa esta RFC. Creemos que todos estos elementos combinados llevarán a Vue 3 a un nivel completamente nuevo.

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. En primer lugar, lanzamos la versión de migración en 3.1. Eso puede ayudar a proyectos elegibles a migrar de forma incremental a Vue 3. Por lo general, lo que hemos encontrado es que deberías poder migrar a Vue 3 a través de la versión de migración, a menos que tengas algunas dependencias difíciles de reemplazar pero que también dependan del comportamiento interno de Vue 2. Ahora, para los autores de bibliotecas, nuestra recomendación es escribir la mayor parte de tu lógica utilizando la API de composición y luego puedes apuntar tanto a Vue 2 como a Vue 3 utilizando la utilidad vue-demi. Detecta automáticamente la versión correcta de Vue y luego asigna tus API a la versión correcta. Los usuarios de Vue 2 también pueden disfrutar de la velocidad de VEET a través del enchufe VEET para Vue 2.

5. Vue 3 Overhaul and Documentation

Short description:

Y puedes comenzar a usar script setup con Vue 2 a través de la desconexión de script setup Vue 2. Estamos trabajando en una revisión completa de vuejs.org, que traerá muchas mejoras. La nueva documentación consolidará la información dispersa y proporcionará recomendaciones. Los caminos de aprendizaje se han reestructurado, con la guía que ofrece la alternancia entre la API de opciones y la API de composición. El cambio de Vue 2 a Vue 3 ocurrirá pronto, y Vue.js.org utilizará por defecto la nueva documentación para Vue 3.

Y puedes comenzar a usar script setup con Vue 2 a través de la desconexión de script setup Vue 2. Ahora, ambos complementos son creados por miembros del equipo principal.

También nos hemos olvidado de 2.7. Entonces, lo principal que queremos hacer en 2.7 es retroportar la API de composición a Vue 2 para que los usuarios de Vue 2 ya no necesiten usar un paquete externo para utilizar la API de composición. Esto está planeado para el primer trimestre de 2022.

Por último, estamos trabajando en una revisión completa de vuejs.org. Desearía haberlo hecho antes, pero estoy muy, muy emocionado por esta iteración porque trae muchas mejoras. Como puedes ver, habrá nuevos diseños con modo oscuro. El sitio se ha reconstruido por completo en VitePress. VitePress es el sucesor de VuePress, que ahora se basa en Vue 3 y Vite. Puede generar estáticamente el sitio a partir de Vue y Markdown.

La nueva documentación actualizará las recomendaciones y las mejores prácticas. Hay información muy dispersa sobre cuál es la mejor opción a utilizar, qué deberías usar, cómo debes configurar un proyecto para Vue 3, ¿verdad? Está un poco disperso en la documentación actual y en toda la información que ha estado disponible. Así que la nueva documentación consolidará todo eso y habrá una recomendación por defecto. Y puedes ir allí, puedes encontrar cuál es la mejor manera de hacer las cosas.

También hemos reestructurado los caminos de aprendizaje. Así es, dividimos el nuevo contenido en tres partes principales, la guía, los ejemplos y el tutorial. Entonces, la guía tendrá muchas partes reescritas para reflejar las últimas mejores prácticas. 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 API de composición para ver cómo se comparan o simplemente seguir la API que prefieras durante el proceso de aprendizaje. Todos los ejemplos también estarán disponibles en ambos estilos de API y también habrá muchos ejemplos nuevos. Habrá una introducción reescrita y una descripción general del framework, una página de preguntas y respuestas y un nuevo tutorial para el aprendizaje práctico.

Como mencioné, el cambio de Vue 2 a Vue 3 está a la vuelta de la esquina. Ocurrirá tan pronto como la nueva documentación esté lista. Y eso será muy pronto. Después de eso, Vue.js.org utilizará por defecto la nueva documentación para Vue 3. Las distribuciones de NPM, las revisiones y otras bibliotecas principales apuntarán por defecto a las versiones de Vue 3. Los repositorios de GitHub seguirán siendo separados. Esto se debe principalmente a que queremos conservar los enlaces de los problemas ya que son un recurso importante para los usuarios que buscan en Google y tratan de encontrar respuestas a problemas pasados. Así que mantendremos los repositorios separados. En su lugar, renombraremos el repositorio Vue.next a Vue.js/core.

6. Vue 3 Adoption and Challenges

Short description:

No puedo esperar para mostrarte el nuevo Vue.js.org una vez que esté listo. Todavía hay personas que usan Vue 2 pero planean migrar a Vue 3. No es sorprendente que algunos proyectos no necesiten actualizarse debido a los costos en comparación con los beneficios. El 30% de los usuarios ya están en Vue 3. El traslado a Singapur ha sido desafiante, pero lo estamos manejando y la comida ha sido genial.

Y eso es todo. No puedo esperar para mostrarte el nuevo Vue.js.org una vez que esté listo y espero que estés tan emocionado como yo.

Así que muchas gracias. Veamos qué están usando las personas hoy en día. Aparentemente, la gran mayoría todavía está usando Vue 2 pero planean migrar a Vue 3. Así que el 57% de ustedes dijo eso. Un afortunado 30% ya está usando Vue 3 y el 13% está contento con Vue 2.

¿Es eso sorprendente en absoluto? No realmente. Sí, eso es más o menos lo que... Me alegra ver que muchas personas están planeando migrar a Vue 3 sin embargo. Sí, pero también creo que tiene total sentido para algunos proyectos si ha estado funcionando bien, es estable. Para ciertos tipos de proyectos, realmente no necesitas actualizar porque a veces siempre tienes que considerar el costo versus los beneficios, ¿verdad? Específicamente para un escenario. Como si fuera un proyecto heredado, no tienes mucho ancho de banda, ¿verdad? De muchas maneras, actualizar puede que no resulte en ninguna diferencia importante desde la perspectiva del usuario, pero solo te llevará mucho tiempo. Entonces, en esos casos, creo que tiene total sentido quedarse en la versión que funcione para ti.

Y sí, el 30% que 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 morirá antes de lo que pensamos. Así que crucemos los dedos. De acuerdo. Bien.

Volviendo a la primera pregunta. ¿Cómo ha sido el traslado a Singapur? Como puedes ver, todavía estoy en el hotel de cuarentena con dos niños. Ha sido un poco desafiante, pero lo estamos manejando. De hecho, creo que apenas logré superar el desfase horario porque hay una diferencia horaria de 12 horas. Así que ha sido bastante difícil pero una vez que salgamos de la cuarentena, creo que tendremos que empezar a movernos, empacar, desempacar cosas y todo eso. Así que todavía falta un poco de tiempo. Todavía no estoy realmente en modo de trabajo, pero la comida ha sido genial.

7. PNIA as the Go-To State Management Solution

Short description:

PNIA probablemente se convierta en la solución de gestión de estado preferida por la comunidad en Vue 3. Aborda las limitaciones de la forma actual de UX, especialmente en términos de soporte de TypeScript. PNIA ofrece una forma más simple y menos verbosa de definir una tienda utilizando la API de composición pura, alineándose bien con el sistema de reactividad de Vue 3. Los diseños en PNIA se superponen con la propuesta para Vuex Next, planteando la pregunta de si aún debería llamarse Vuex. PNIA proporciona previsibilidad, soporte de tipos, integración de herramientas de desarrollo y manejo de SSR con un sobrecosto mínimo. Para casos más simples, se puede utilizar un objeto reactivo como singleton, mientras que la representación en el lado del servidor se puede lograr inyectándolo desde la raíz de la aplicación. PDM ofrece integración con DevTools y capacidad de inspección, lo que lo convierte en una excelente solución.

La comida es importante. Bien, entonces la siguiente pregunta. ¿Es probable que PNIA se convierta en la opción preferida por la comunidad para la gestión de estado? Sí, creo que PNIA lo es, Eduardo ha estado haciendo muchas cosas geniales con PNIA. 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 de TypeScript, porque todas las funciones de envío dependen tanto de las cadenas. Por lo tanto, no obtienes suficiente verificación de tipos en todos los servicios de API. Por lo tanto, PNIA está diseñado teniendo todo eso en cuenta. También es más simple, ¿verdad? Menos verboso. También te brinda una forma de definir una tienda utilizando la API de composición pura, lo cual también se alinea mejor con el sistema de reactividad de Vue 3. En general, creo que PNIA definitivamente va 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. Entonces, Kiah y Eduardo han estado trabajando juntos. Hemos estado pensando en cómo debería ser Vuex, pero algunas de las cosas que hemos propuesto son muy diferentes a la forma actual de Vuex. Entonces, en esencia, es una pregunta interesante de si aún debería llamarse Vuex, ¿verdad? Si se ve muy diferente. Bueno, fundamentalmente, creo que lo que realmente queremos en una solución de gestión de estado es previsibilidad, soporte de tipos, integración de herramientas de desarrollo y manejo de SSR con el menor sobrecosto posible. Entonces, PNIA logra todo eso. Y de alguna manera, PNIA es esencialmente esta especie de vamos a jugar con la próxima iteración de Vuex, pero con un nombre diferente. Entonces, si tuviera que introducir un sistema de gestión de estado en una aplicación hoy, probablemente también usaría PNIA. Entonces, quiero decir, para casos aún más simples, simplemente usaría un objeto reactivo como singleton, lo exportaría desde un archivo de importación y lo usaría en varios componentes, especialmente si no necesito representación en el lado del servidor. Si necesito representación en el lado del servidor, aún puedo hacerlo. Simplemente puedo proporcionarlo inyectándolo desde la raíz de la aplicación, y eso es lo que estamos haciendo en BPRESS. Es muy simple porque solo proporcionas, inyectas un montón de Refs u objetos reactivos, y esa es otra forma de gestión de estado. Por supuesto, eso solo cubre casos simples porque no te brinda integración con DevTools, capacidad de inspección y PDM cubre todo eso, manteniendo al mismo tiempo una API simple. Entonces, creo que es una excelente solución.

8. Options API vs Composition API

Short description:

Tanto la API de opciones como la API de composición son opciones igualmente viables en Vue 3. La elección depende de factores como el uso de una herramienta de compilación, la complejidad de la aplicación, la familiaridad del equipo con TypeScript y la productividad y mantenibilidad deseadas. La API de opciones es adecuada para aplicaciones de baja a mediana complejidad y principiantes, ya que proporciona mejores guías. La API de composición ofrece más flexibilidad para desarrolladores experimentados, pero requiere una comprensión sólida del sistema de reactividad de Vue. La API de opciones seguirá siendo compatible en Vue 3, y la documentación permite alternar entre las dos APIs para compararlas y comprender su relación.

De acuerdo. La siguiente pregunta es una que también me intriga mucho. ¿La API de opciones sigue siendo la forma recomendada por defecto para construir componentes de interfaz de usuario? Bueno, esto se responderá de manera más adecuada en la próxima documentación. Ya he escrito la nueva sección de introducción, así que para resumir 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 utilizando una herramienta de compilación? Si no estás utilizando una herramienta de compilación, la API de composición de opciones será un poco verbosa porque no puedes confiar en ninguna de estas mejoras de calidad de vida en tiempo de compilación, como la configuración de script o la sintaxis de azúcar ref, ¿verdad? Entonces, en esos casos, la API de opciones también, si no estás utilizando una herramienta de compilación, la complejidad general de tu aplicación probablemente esté en el rango bajo a medio, ¿verdad? Entonces, la API de opciones definitivamente seguirá siendo muy viable o incluso, probablemente más adecuada en esos escenarios. Pero si estás utilizando una pila de desarrollo moderna, estás utilizando TypeScript o planeas escalar tu aplicación, ya sabes, habrá varios desarrolladores trabajando en ella. Diría que la API de composición con TypeScript y la configuración de script será una opción muy, muy sólida, en términos de mantenibilidad, productividad, soporte de herramientas de IDE y todo eso. Pero también he escuchado argumentos donde depende de la composición de tu equipo, ¿verdad? Si todo tu equipo se siente cómodo con TypeScript y, ya sabes, el equipo es esencialmente porque todos tenemos algún tipo de preferencia o gusto técnico 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 brinda mejores guías porque te permite hacer las cosas sin pensar demasiado en cómo funciona la reactividad. Por otro lado, la API de composición es un poco más libre. Permite a los desarrolladores experimentados organizar mejor su código, utilizar patrones avanzados, extraer y reutilizar la lógica de formas muy elegantes, pero también requiere que te sientas cómodo con el concepto de cómo funciona el sistema de reactividad en Vue. Así que es una especie de compensación. Así que debes elegir en función de con qué te sientas más cómodo, con qué se sienta más cómodo tu equipo. Pero a un nivel muy alto, diría que ambas son opciones igualmente viables. Entonces, una pregunta de seguimiento a eso. Disculpa. ¿Cuánto tiempo se seguirá dando soporte a la API de opciones? ¿Hay algún plan en algún momento de eliminarla por completo? No realmente. El costo de mantener el soporte de la API de opciones en Vue 3 es muy, muy bajo. Realmente no hay... Son solo varias cientos de líneas de código. Entonces, una vez que... Realmente no hay muchas razones para eliminarla. Lo que sucede es que en nuestra documentación, en la nueva documentación, ¿verdad? Escribimos la documentación de una manera en la que el flujo principal de la guía sigue siendo el mismo, pero tenemos algo que te permite alternar entre la API de composición y la API de opciones en cualquier momento que desees, y es persistente. Entonces, una vez que tienes una preferencia de API, todo el sitio funciona esencialmente con ese estilo de API. Así que aún puedes leer la misma guía. Es la misma. Todavía estamos presentando los mismos conceptos en la guía, pero se mostrará 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 y comprender mejor la relación entre ellas. Creo que también, el hecho de que hayamos podido reescribir la guía de esa manera también muestra que las dos APIs son realmente solo interfaces diferentes de los mismos conceptos subyacentes.

QnA

Conceptos de Vue, Vue Demi, Vue CLI y Soporte de CDN

Short description:

Los conceptos fundamentales de Vue siguen siendo los mismos, pero se pueden utilizar diferentes estilos para expresar intenciones. Vue demi solo cubre las API de reactividad y no puede habilitar múltiples nodos raíz en Vue 2. Vue CLI estará en modo de mantenimiento a medida que Vite se convierta en la herramienta fundamental. La nueva herramienta de esqueleto, create Vue, es más ligera y menos dogmática. Vue seguirá admitiendo la instalación a través de CDN.

Entonces, aún es igual cómo funciona Vue, cómo funciona el sistema de reactividad, cómo todo encaja, ¿verdad? Los conceptos fundamentales siguen siendo los mismos. Es realmente solo 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 un plan. De acuerdo. Siguiente pregunta. ¿Vue demi nos permitirá usar múltiples nodos raíz en nuestros componentes y seguir siendo compatibles con Vue 2? Desafortunadamente, no, porque Vue demi cubre estrictamente solo las API de reactividad. Básicamente, conecta tus importaciones a API como REF, reACTIV, ya sea a Vue 3 si existe o a la API de composición de Vue 2. Si deseas tener múltiples nodos raíz en Vue 2, desafortunadamente eso no es posible debido a cómo funciona el sistema de renderizado de Vue 2, pero puedes usar la versión de migración, Vue 3 Migration Build, que tiene el comportamiento de Vue 2 pero admite las características de Vue 3. Así que échale un vistazo, prueba la versión de migración. Si tu aplicación no es compleja, especialmente si no tiene dependencias como Nuxt o Vue Defy, es probable que la versión de migración te permita pasar a Vue 3 sin cambiar demasiado código. Luego puedes migrar gradualmente esas características obsoletas. De acuerdo, nuestra próxima pregunta es, ¿el CLI de Vue se moverá a Vite? Y si es así, ¿cuándo? En resumen, el CLI de Vue estará en modo de mantenimiento pronto porque toda la arquitectura del CLI de Vue se basa en webpack. Y cuando nos mudemos a Vite, será mucho más fundamental que... Sabes, cuando inicias una nueva aplicación de Vite con el complemento de Vite, se siente prácticamente igual desde la perspectiva del código fuente. Todas las características son prácticamente las mismas. La única diferencia es que nuestra nueva herramienta de esqueleto llamada create Vue será mucho menos dogmática y más liviana. No intenta ser tan abarcadora como el CLI de Vue, que tiene su propio sistema de complementos. Básicamente, estamos diciendo que uses el sistema de complementos de Vite, aproveches el ecosistema de Vite en lugar de tener un jardín amurallado con complementos que solo funcionan con el CLI de Vue. Esto también es estratégico porque a lo largo de los años, Soda, quien mantiene el CLI de Vue, ha estado invirtiendo mucho tiempo porque teníamos un alcance muy ambicioso para el CLI de Vue, pero nos dimos cuenta de que a largo plazo, muchas cosas se pueden hacer a un nivel más bajo en lugar de tenerlas específicamente para el CLI de Vue. La nueva herramienta de esqueleto es esencialmente una capa sobre Vite. Si necesitas características adicionales especiales, tenemos opciones predeterminadas como TypeScript o configuración de TypeScript, o ejecución de pruebas u otras cosas. Pero en general, Vite se enfoca específicamente en el paso de compilación y en el servidor de desarrollo. Digamos que quieres usar Pretty o ESLint, no vamos a guiarte en cómo hacerlo. En su lugar, te vamos a dirigir a la documentación o a soluciones de la comunidad que ya funcionan para cualquier tipo de proyecto de Vite, en lugar de solo para el CLI de Vue. De acuerdo. De acuerdo. La siguiente pregunta es, ¿Vue planea seguir admitiendo la instalación a través de CDN y por qué muchos complementos solo están disponibles como instalaciones de NPM? Vue siempre admitirá el uso de CDN.

Soporte de CDN y Recomendación de Vue 3

Short description:

El hecho de que los complementos solo se puedan instalar a través de NPM no significa que no se admitan las compilaciones de CDN. Muchas bibliotecas de la comunidad de Vue tienen sus propias compilaciones de CDN. Si bien el uso de un CDN tiene desventajas como la incapacidad de realizar tree shaking y el potencial de código no utilizado, sigue siendo una opción viable para configuraciones simples. Entonces, la respuesta breve es que siempre se admitirá una compilación de CDN. Si estás comenzando un nuevo proyecto, se recomienda usar Vue 3 en lugar de Vue 2. Gracias, Evan, por unirte a nosotros hoy.

El hecho de que los complementos solo admitan la instalación a través de NPM, honestamente, no lo creo porque muchas bibliotecas de la comunidad de Vue también tienen sus propias compilaciones de CDN, ¿verdad? Entonces creo que esto es, si una biblioteca puede admitir una compilación de 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 se puede usar a través de CDN. Ahora, por supuesto, hay desventajas en eso, porque no se puede realizar tree shaking. Entonces, si haces todo a través de CDN, terminarás con mucho código no utilizado. Pero aún así, es viable si tu configuración en general no es lo suficientemente complicada como para requerir un paso de compilación. Entonces, sí, la respuesta breve es que siempre se admitirá una compilación de CDN.

De acuerdo, ahora, última pregunta rápida. Si estamos comenzando 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. Ha sido un placer.

Check out more articles and videos

We constantly think of articles and videos that might spark Git people interest / skill us up or help building a stellar career

Vue.js London Live 2021Vue.js London Live 2021
34 min
Everything Beyond State Management in Stores with Pinia
Top Content
When we think about Vuex, Pinia, or stores in general we often think about state management and the Flux patterns but not only do stores not always follow the Flux pattern, there is so much more about stores that make them worth using! Plugins, Devtools, server-side rendering, TypeScript integrations... Let's dive into everything beyond state management with Pinia with practical examples about plugins and Devtools to get the most out of your stores.
Vue.js London Live 2021Vue.js London Live 2021
8 min
Utilising Rust from Vue with WebAssembly
Top Content
Rust is a new language for writing high-performance code, that can be compiled to WebAssembly, and run within the browser. In this talk you will be taken through how you can integrate Rust, within a Vue application, in a way that's painless and easy. With examples on how to interact with Rust from JavaScript, and some of the gotchas to be aware of.
Vue.js London Live 2021Vue.js London Live 2021
24 min
Local State and Server Cache: Finding a Balance
Top Content
How many times did you implement the same flow in your application: check, if data is already fetched from the server, if yes - render the data, if not - fetch this data and then render it? I think I've done it more than ten times myself and I've seen the question about this flow more than fifty times. Unfortunately, our go-to state management library, Vuex, doesn't provide any solution for this.For GraphQL-based application, there was an alternative to use Apollo client that provided tools for working with the cache. But what if you use REST? Luckily, now we have a Vue alternative to a react-query library that provides a nice solution for working with server cache. In this talk, I will explain the distinction between local application state and local server cache and do some live coding to show how to work with the latter.
Vue.js London 2023Vue.js London 2023
30 min
Stop Writing Your Routes
The more you keep working on an application, the more complicated its routing becomes, and the easier it is to make a mistake. ""Was the route named users or was it user?"", ""Did it have an id param or was it userId?"". If only TypeScript could tell you what are the possible names and params. If only you didn't have to write a single route anymore and let a plugin do it for you. In this talk we will go through what it took to bring automatically typed routes for Vue Router.

Workshops on related topic

Vue.js London Live 2021Vue.js London Live 2021
169 min
Vue3: Modern Frontend App Development
Top Content
Featured WorkshopFree
The Vue3 has been released in mid-2020. Besides many improvements and optimizations, the main feature of Vue3 brings is the Composition API – a new way to write and reuse reactive code. Let's learn more about how to use Composition API efficiently.

Besides core Vue3 features we'll explain examples of how to use popular libraries with Vue3.

Table of contents:
- Introduction to Vue3
- Composition API
- Core libraries
- Vue3 ecosystem

Prerequisites:
IDE of choice (Inellij or VSC) installed
Nodejs + NPM
Vue.js London Live 2021Vue.js London Live 2021
117 min
Using Nitro – Building an App with the Latest Nuxt Rendering Engine
Top Content
Workshop
We'll build a Nuxt project together from scratch using Nitro, the new Nuxt rendering engine, and Nuxt Bridge. We'll explore some of the ways that you can use and deploy Nitro, whilst building a application together with some of the real-world constraints you'd face when deploying an app for your enterprise. Along the way, fire your questions at me and I'll do my best to answer them.
JSNation 2022JSNation 2022
141 min
Going on an adventure with Nuxt 3, Motion UI and Azure
WorkshopFree
We love easily created and deployed web applications! So, let’s see what a very current tech stack like Nuxt 3, Motion UI and Azure Static Web Apps can do for us. It could very well be a golden trio in modern day web development. Or it could be a fire pit of bugs and errors. Either way it will be a learning adventure for us all. Nuxt 3 has been released just a few months ago, and we cannot wait any longer to explore its new features like its acceptance of Vue 3 and the Nitro Engine. We add a bit of pizzazz to our application with the Sass library Motion UI, because static design is out, and animations are in again.Our driving power of the stack will be Azure. Azure static web apps are new, close to production and a nifty and quick way for developers to deploy their websites. So of course, we must try this out.With some sprinkled Azure Functions on top, we will explore what web development in 2022 can do.
Vue.js London 2023Vue.js London 2023
137 min
TresJS create 3D experiences declaratively with Vue Components
Workshop
- Intro 3D - Intro WebGL- ThreeJS- Why TresJS- Installation or Stackblitz setup - Core Basics- Setting up the Canvas- Scene- Camera- Adding an object- Geometries- Arguments- Props- Slots- The Loop- UseRenderLoop composable- Before and After rendering callbacks- Basic Animations- Materials- Basic Material- Normal Material- Toon Material- Lambert Material- Standard and Physical Material- Metalness, roughness - Lights- AmbientLight- DirectionalLight- PointLights- Shadows- Textures- Loading textures with useTextures- Tips and tricks- Misc- Orbit Controls- Loading models with Cientos- Debugging your scene- Performance
Vue.js London Live 2021Vue.js London Live 2021
176 min
Building Vue forms with VeeValidate
Workshop
In this workshop, you will learn how to use vee-validate to handle form validation, manage form values and handle submissions effectively. We will start from the basics with a simple login form all the way to using the composition API and building repeatable and multistep forms.

Table of contents:
- Introduction to vee-validate
- Building a basic form with vee-validate components
- Handling validation and form submissions
- Building validatable input components with the composition API
- Field Arrays and repeatable inputs
- Building a multistep form
Prerequisites:
VSCode setup and an empty Vite + Vue project.
Vue.js London Live 2021Vue.js London Live 2021
116 min
Building full-stack GraphQL applications with Hasura and Vue 3
Workshop
The frontend ecosystem moves at a breakneck pace. This workshop is intended to equip participants with an understanding of the state of the Vue 3 + GraphQL ecosystem, exploring that ecosystem – hands on, and through the lens of full-stack application development.

Table of contents
- Participants will use Hasura to build out a realtime GraphQL API backed Postgres. Together we'll walk through consuming it from a frontend and making the front-end reactive, subscribed to data changes.
- Additionally, we will look at commonly-used tools in the Vue GraphQL stack (such as Apollo Client and Urql), discuss some lesser-known alternatives, and touch on problems frequently encountered when starting out.
- Multiple patterns for managing stateful data and their tradeoffs will be outlined during the workshop, and a basic implementation for each pattern discussed will be shown.
Workshop level

NOTE: No prior experience with GraphQL is necessary, but may be helpful to aid understanding. The fundamentals will be covered.