10 Años de Vue: el Pasado y el Futuro

Hola a todos y bienvenidos a Vue.js Live 2024. Soy Evan Yew, el creador de Vue y Vite. Hoy estoy muy emocionado de compartir con ustedes una retrospectiva de 10 años sobre Vue.js. Sí, escucharon bien. Vue ya tiene 10 años. Parece mucho tiempo en el mundo del front-end. Y por supuesto, Vue ya no es una tecnología nueva, pero en esta charla veremos algo de su historia y también veremos lo que estamos haciendo con Vue para mantenerlo vivo y bien.

Bien, vamos a sumergirnos directamente en ello. En primer lugar, Vue hoy en algunos números. Aquí hay algunas estadísticas combinadas de Vue.js slash Vue y Vue.js slash Core en GitHub. Hoy tenemos más de 9,326 commits en los dos repositorios. Hemos lanzado más de 493 versiones de Vue. Tenemos más de 2 millones de usuarios en todo el mundo, 250,000 estrellas en GitHub, 4.9 millones de descargas semanales en npm y más de 1 mil millones de solicitudes mensuales de CDN en jsdeliver.

Y también queremos hablar sobre algunos de los impactos técnicos de Vue, porque a pesar de usarlo día a día, tal vez muchos usuarios nuevos hoy no estén tan familiarizados con su historia y qué ideas surgieron primero de Vue y qué ideas influyeron en otras tecnologías, ¿verdad? En 2014, Vue fue el primer framework de JavaScript en hacer reactividad profunda basada en seguimiento. Ahora, la reactividad basada en seguimiento es un paradigma que se remonta a Knockout.js y Meteor Tracker. Esa es una tecnología aún más antigua que Vue, pero Vue fue el primero en aplicar este principio a objetos profundos. Así que puedes tener un objeto mutado y las cosas simplemente funcionan, y Vue fue el primer framework en hacer eso. Vue también fue el primer framework en combinar la idea de componentes de un solo archivo con herramientas de construcción. La idea de componentes de un solo archivo no es necesariamente nueva. De hecho, había un proyecto interno en Google cuando trabajaba allí, fue una fuente de inspiración. Pero Vue fue el primero en combinar esta idea con una herramienta de construcción llamada Browserify Backend, y más tarde, también soportamos Webpack. Pero la capacidad de componentes de un solo archivo con herramientas de construcción, la singularidad de eso es que podemos usar lenguajes adicionales en estos bloques de script o plantilla o estilo. Así que podías usar CoffeeScript en ese entonces, hoy puedes usar principalmente TypeScript, puedes usar SAS, LASP, preprocesadores, puedes usar PostCSS para procesar tu CSS, incluso puedes usar POD, que se llamaba Jade en ese entonces, diferentes plantillas en texto con plantillas. Así que Vue fue el primer framework en soportar este tipo de uso. Y Composition API fue el primero en combinar la reactividad estilo Signo, que también es la reactividad basada en seguimiento de la que hablamos antes, con modelos de componentes modernos. Así que puedes usar Vue refs en una sintaxis de configuración de script con modelos de componentes modernos, y Vue fue el primero en combinar ese modelo en el modelo de componente que todos conocemos hoy. Y Vue también fue el primero en explorar un azúcar de reactividad impulsado por compilador para Signos en forma de la transformación de reactividad, que fue una propuesta experimental con la que trabajamos durante un tiempo, pero al final decidimos que no era la mejor dirección para Vue. Sin embargo, estamos bastante contentos de ver que esta dirección está siendo adoptada por otros frameworks, por ejemplo, Svelte 5, que también está explorando esta dirección. Así que podría ser un mejor ajuste para Svelte, pero creemos que Vue está en un muy buen lugar con su propio paradigma. Ahora, Vue también es único en soportar funciones de renderizado tanto de plantilla como de DOM virtual.

Esto ofrece un muy buen equilibrio que brinda familiaridad a los usuarios que prefieren la sintaxis de plantillas y una experiencia de desarrollador más fluida para las personas que prefieren plantillas estilo HTML. Pero al mismo tiempo, en casos de uso avanzados y para autores de bibliotecas, aún puedes omitir la capa de plantillas y pasar a escribir funciones de renderizado manualmente que te brindan mucha más flexibilidad para realizar características avanzadas.

Y finalmente, Vue fue pionero en el concepto de un framework progresivo, la idea de un framework que no es monolítico, la idea de que un framework puede estar compuesto de piezas individuales pero con un diseño coherente que puedes adoptar y usar de manera incremental según cuánto necesites del framework. Creo que Vue es el primero en ser pionero en esta idea, y también es el único que la ha implementado realmente bien.

Ahora, mirando hacia atrás, aquí hay una breve línea de tiempo de lo que hizo Vue. Hicimos el primer lanzamiento con el nombre Vue.js en 2013. Esa fue la primera vez que apareció el nombre Vue.js. Pero el anuncio público fue en febrero de 2014. Permaneció como un proyecto paralelo para mí durante mucho tiempo, y me tomó bastante tiempo pulirlo lo suficiente como para sentirme cómodo, para sentirme seguro de compartirlo con el mundo. En octubre de 2015, alcanzamos la versión 1.0. De hecho, tomé un largo descanso para impulsarlo hacia la versión 1.0. Y después de la versión 1.0, la sintaxis de plantillas se estableció en gran medida. En la versión 2.0, hicimos la reescritura mayor, en la cual implementamos el renderizado para usar DOM virtual, y se lanzó en octubre de 2016. 2016 también fue el año en que comencé a trabajar en Vue a tiempo completo. Ahora, el trabajo en Vue 3 realmente comenzó en septiembre de 2018. Eso fue hace mucho tiempo. Pero la versión 3.0 tomó mucho, mucho más tiempo de lo esperado debido a la escala de cambios y el impacto en el ecosistema que creó. Vue 2 ya era muy, muy utilizado, y el trabajo en la versión 3.0 fue un proceso de aprendizaje para nosotros. Definitivamente hubo altibajos, errores que se cometieron y lecciones aprendidas. Así que la versión 3.0 se lanzó suavemente en septiembre de 2020, y eventualmente se convirtió en la versión predeterminada en enero de 2022. Así que todo el proceso tomó unos años. Pero estamos realmente contentos de que el ecosistema finalmente haya adoptado Vue 3, y veremos algunas estadísticas más adelante. Así que Vue 2 ha llegado oficialmente al final de su vida útil en diciembre de 2023. Y realmente animamos a los usuarios que aún están en Vue 2 a considerar actualizarse, o deberían buscar el soporte relevante para mantener sus versiones de Vue 2 en funcionamiento.

Ahora, esto fue realmente como un momento nostálgico donde todavía tengo esta publicación de blog en algún lugar hablando sobre la primera semana de lanzamiento de Vue.js, y estaba realmente feliz de haber obtenido unos cientos de estrellas en GitHub en la primera semana, lo cual fue un gran logro para mí en ese entonces. Pero después del lanzamiento inicial, ¿verdad? Hubo momentos, hubo altibajos donde la realidad golpea. Así que no sé si alguien ha oído hablar del ciclo de adopción tecnológica. Hay, siempre que surge una nueva tecnología, hay un desencadenante tecnológico. Hay un pico de expectativas infladas.

Ahora, diría que hay un proceso muy similar cuando te adentras en open source con el tiempo. Ahora, cuando entras por primera vez en open source, hay una gran emoción, un pico de emoción y producción. Estaba trabajando casi todo el día, todos los días en Vue cuando estaba impulsando el lanzamiento inicial y también impulsando la 1.0, impulsando la 2.0. Esos fueron los momentos en los que podía trabajar en ello todo el día.

Pero también hay momentos de agotamiento y dudas cuando hay errores, problemas, personas criticando las decisiones de diseño que tomamos. Y tuve que ajustarme a estos comentarios con el tiempo. Tuve que aprender cuáles son las decisiones realmente correctas. Te lleva mucho tiempo darte cuenta de que no puedes complacer a todos y a veces simplemente tienes que tomar decisiones difíciles. Y eventualmente alcanzamos la pendiente de reequilibrio y alcanzamos la meseta de productividad.

Pero obviamente hay desafíos cuando necesitas superar esos períodos de agotamiento. Y eso es lo que llamo el abismo. Para muchos mantenedores de open source, cruzar este abismo es el gran desafío que tienes que atravesar. Y si estás trabajando en proyectos de open source, definitivamente habrá momentos como este. Y solo debes saber que tienes que aprender a ajustarte a cómo lidiar con esto y necesitas aprender a encontrar un equilibrio entre tus metas, tu vida, tu trabajo y el open source. Y realmente espero que todos los que trabajan en open source puedan salir del abismo y alcanzar esta meseta equilibrada de productividad.

Así que aquí hay algunos gráficos. Si miras mis gráficos de contribuciones en GitHub, verás que definitivamente hay momentos de agotamiento y dudas. Así que quiero ser realmente abierto sobre esto. Quiero que todos sepan que incluso detrás de algunos de los proyectos de open source más exitosos, los mantenedores también son humanos, ¿verdad? Así que habrá un momento en el que necesiten ajustarse. Hay momentos en los que necesitan tomarse un descanso, necesitarán encontrar inspiración, necesitan ir y recargar y encontrar su motivación nuevamente. Así que esto sucede, esto es normal. Y quiero normalizar esto para los mantenedores de open source para que nos sintamos menos presionados y espero ver a pocos compañeros mantenedores agotarse. Y no habría sido posible continuar sin el apoyo de la comunidad AmazingView. Así que estoy poniendo la palabra aquí tres veces porque así de importante es. Si yo fuera Steve... ¡Ahem! Lo siento. Corta esta parte. Bien. Gracias. Estoy poniendo la palabra aquí tres veces porque así de importante es.

La comunidad de View es la única cosa de la que estoy más orgulloso. View trata sobre personas, es la comunidad más diversa, inclusiva, acogedora, y de mente abierta que conozco, llena de personas increíbles y maravillosas. Sin la comunidad, nunca habría tenido la energía y la persistencia para seguir trabajando en View y superar esos abismos o períodos de agotamiento. Así que View no estaría donde está hoy sin todos ustedes. Así que aquí está mi más profundo agradecimiento a nuestros miembros del equipo, a los contribuyentes, a los mantenedores de bibliotecas del ecosistema, a los socios de la comunidad, organizadores de conferencias y encuentros, defensores de View y patrocinadores.

Bien. Ahora hablemos un poco sobre sostenibilidad e independencia, que creo que es otro aspecto que realmente hace que View sea único. View es actualmente el único framework mainstream que sigue siendo independiente, es decir, no está dominado por una sola corporación. ¿Por qué es esto importante, te preguntarás? La razón, creo, es que no estamos limitados por el apoyo financiero de una sola entidad, lo que significa que no vamos a ser influenciados en las direcciones técnicas solo porque un gran patrocinador quiera que vayamos en cierta dirección, ¿verdad? Todos nuestros patrocinadores, todos nuestros apoyos financieros están descentralizados y realmente no tienen un fuerte poder de influencia en las decisiones técnicas tomadas para el proyecto. Así que el proyecto puede operar únicamente considerando los intereses de los usuarios y la opinión de cada usuario recibirá igual consideración. Y otro aspecto importante del ecosistema de View es la mentalidad colaborativa. Gracias a la independencia, ¿verdad?, el ecosistema de View es único en la forma en que genera muchos, muchos esfuerzos notables que terminan beneficiando más que al propio framework. Si las cosas fueran por beneficios, esto se vería bastante diferente. La comunidad de View ha sido la fuente de múltiples esfuerzos que beneficiaron a todo el ecosistema de JavaScript en su conjunto. Solo por nombrar algunos, tenemos Vite, tenemos Bolar, tenemos Un.js, Nitro, y algunos trabajos de herramientas de desarrollo entre frameworks que se están llevando a cabo. Todos estos de miembros de la comunidad de View y Vite.

Y finalmente, quiero echar un vistazo al estado actual y al futuro de View. Así que el uso de View 3 ha aumentado un 77.6% en el último año, un crecimiento muy fuerte para View 3 y también está ocupando un porcentaje mucho mayor de las descargas totales de View y ahora constituye más del 58.3% del uso total de MPM. Muchas aplicaciones heredadas de View 2 obviamente todavía están funcionando y la gente seguirá trabajando en ellas. Así que todavía es bueno ver que el porcentaje de View 3 sigue creciendo con el tiempo. Ahora, 3.4 es la versión menor actual que se lanzó en diciembre de 2023. La característica principal en 3.4 fue una postura completamente reescrita que es dos veces más rápida que antes. Así que una cosa que realmente quiero enfatizar es incluso si View es un framework de 10 años y View 3 en sí mismo tiene casi seis años, la base de código tiene seis años, todavía estamos encontrando muchas oportunidades de mejora aquí y allá. Y siempre vamos a seguir explorando estas oportunidades y encontrando ganancias de rendimiento y mejoras de experiencia para nuestros usuarios. Ahora, 3.4 también lanzó un sistema de reactividad más eficiente que redujo muchos cálculos innecesarios en propiedades computadas. También estabilizamos el modelo definido y lanzamos VBind, mismo nombre, abreviatura en. Ambos con grandes mejoras en la experiencia del desarrollador. Ahora, el cambio más reciente notable en 3.4 es que en un parche reciente, lanzamos algunas mejoras bastante importantes en el rendimiento del renderizado del lado del servidor.

Ahora, esto fue en gran medida desencadenado por un benchmark público que ha estado circulando en Twitter. Y al inspeccionar el benchmark, pude identificar algunos casos donde algunas de las optimizaciones estaban llevando a un bajo rendimiento de View en el benchmark original. Así que ahora con esos cambios implementados en 3.4.22, vemos una impresionante mejora de 3.8x en ese benchmark solo para View. Y para Nuxt, también hay una mejora muy, muy notable de 1.77x. Y Daniel también ha enviado una solicitud de extracción que optimizó el uso de Nuxt al usar datos asincrónicos que evita el uso de estructuras de datos profundas al obtener los datos, lo cual será el valor predeterminado en Nuxt 4.0, lo que nuevamente mejora el rendimiento en ese benchmark bastante. Así que si estás usando Nuxt, o estás usando renderizado del lado del servidor con View, tus otros métodos, asegúrate de actualizar a la última versión.

Así que hablemos un poco sobre lo que está planeado para la próxima versión en 3.5 y más allá. Así que primero que nada, estamos lanzando aún más mejoras en la eficiencia de la reactividad. Así que la rama menor actual en GitHub es la rama en desarrollo para 3.5 ya ha fusionado dos solicitudes de extracción muy importantes para el sistema de reactividad. La PR número 10407 proporciona una reescritura del sistema de reactividad nuevamente. Así que la estructura de datos de seguimiento interno ha sido refactorizada con una mejora del 56% en el uso de memoria. Así que el uso de memoria es bastante importante porque en aplicaciones intensivas en datos, la recolección de basura puede ser realmente un asesino del rendimiento. Así que usar menos memoria va a ayudar mucho para aplicaciones altamente dinámicas. Ahora, la 9511 proporciona una ganancia de 10 veces al rastrear grandes arrays reactivos. Ahora, esto ha sido en realidad una fuente bastante común de cuello de botella de rendimiento cuando tienes arrays realmente, realmente grandes y los pones en una estructura de datos profunda. Ahora, esta PR en realidad proporciona una forma más inteligente de evitar el seguimiento de dependencias innecesarias al iterar a través de estos arrays más grandes y proporciona ganancias muy, muy significativas en estos casos. También estamos pensando en estabilizar las props reactivas para estructurar porque estamos viendo comentarios bastante positivos en la discusión del RFC. Pero antes de que finalmente hagamos eso, te animaríamos a expresar tu opinión en el RFC para ayudarnos a tomar una decisión final. También hay mejoras planificadas para SSR en 2.5, pero la principal es estabilizar suspense. Ha sido experimental durante mucho tiempo y realmente estamos deseando estabilizarlo. Y luego hay pequeñas APIs como useID, mejoras de calidad de vida como la verificación de validez de anidamiento de HTML incorporada, te ayudan a detectar casos donde accidentalmente estás poniendo divs dentro de ps o ps dentro de divs. Y también vamos a considerar la posibilidad de hidratación perezosa incorporada usando componentes asincrónicos como límites.

Ahora, muchos de ustedes probablemente estén curiosos sobre el estado del modo vapor. Ahora, estamos haciendo grandes progresos en el modo vapor. Así que ya puede ejecutar ToDoMVC en caso de que no lo supieras. Así que puedes probarlo en el playground ya. Así que allí, si descargas las diapositivas más tarde, deberías poder encontrar el enlace y probarlo. O puedes ir al repositorio principal de vapor en GitHub y verlo. Deberías poder encontrar el enlace allí. El enfoque actual para el modo vapor es la implementación de componentes.

Y la buena noticia es que estamos casi allí. Así que si miras el problema vinculado aquí, hemos cubierto muchas de las partes de los componentes y solo quedan algunas cosas. Y una vez que terminemos los componentes, el próximo enfoque será la interoperabilidad entre vapor y DOM virtual, es decir, poder compilar e incrustar componentes vapor en tus aplicaciones actuales. Ese será el próximo gran hito a alcanzar. El modo vapor es un esfuerzo de equipo. Está siendo liderado por Kevin, y tenemos muchos grandes contribuyentes ayudando con vapor.

Es realmente emocionante de ver porque esta es una implementación bastante avanzada, y me alegró ver que al establecer la dirección inicial, muchos miembros de la comunidad están dando un paso adelante para ayudarnos a trabajar en vapor en paralelo al trabajo principal de Vue. Y finalmente, queremos más experiencia de desarrollo. Así que parte del trabajo que he estado haciendo fuera de Vue es seguir mejorando Vite invirtiendo en cadenas de herramientas de bajo nivel.

Así que muchos de ustedes pueden saber que hemos comenzado un nuevo paquete basado en Rust llamado Rodown, que está destinado a apoyar Vite en el futuro. Rodown ahora es de código abierto, y estamos viendo un gran rendimiento. Y actualmente hemos terminado el empaquetado básico, la división básica de fragmentos y el soporte de mapas de origen. Y con todo esto implementado, podemos ejecutar algunos benchmarks, y actualmente estamos siendo de 1.5 a 2 veces más rápidos que ES build, lo cual es súper impresionante. Y también estamos contribuyendo a OXC, que es la cadena de herramientas de lenguaje de bajo nivel, JavaScript basado en Rust que estamos usando dentro de Rodown. Y estamos teniendo una relación de colaboración muy estrecha con el equipo de OXC. Y también tenemos miembros del equipo trabajando en extraer capas reutilizables entre Nuxt y las herramientas de desarrollo de Vue y potencialmente usar el mismo kit para apoyar otro tipo de herramientas de desarrollo en el futuro. Y también tenemos mejoras continuas en VolR V2, es decir, herramientas de lenguaje de Vue. Así que VolR V2 se lanzó con el soporte para modo híbrido, lo que nos permite usar el único servidor de lenguaje TypeScript para soportar la inferencia de todo el proyecto, tanto archivos TS como Vue. Ahora, esto es muy, muy eficiente en términos de memoria, rendimiento, pero hay muchos casos límite, y todavía hay algunos bordes ásperos que necesitamos estabilizar. Pero estamos viendo una promesa realmente, realmente grande en el rendimiento de esta dirección. Bien, y finalmente, Signos nativos. Esto es algo de lo que quiero hablar un poco más. En caso de que no lo sepas, hay una propuesta de TC39 para agregar Signos como una característica nativa del lenguaje JavaScript y ahora está en la Etapa 1. Signos, si no estás familiarizado con el término, son primitivas de reactividad similares a Vue refs. Así que si has usado Vue refs, has usado Signos. El equipo de Vue ha estado involucrado en la discusión de la propuesta desde el principio, y estamos experimentando con la posibilidad de una versión de Vue slash reactivity impulsada por Signal nativo, el motor de reactividad de bajo nivel que impulsa Vue propiamente dicho. Al usar Signos nativos, deberíamos poder tener menos código para mantener y empaquetar, así que menos código para mantener en la base de código de Vue, menos código para enviar a los usuarios finales. Debería haber un mejor rendimiento y consumo de memoria porque los Signos nativos pueden ser implementados en lenguajes nativos, y hay potencial para la interoperabilidad entre frameworks, piensa en el uso de Vue entre frameworks. Si podemos usar Vue use en múltiples frameworks, eso sería un sueño.

Así que esperamos que esto suceda en el futuro, y estamos trabajando con otros participantes en la propuesta para asegurarnos de que alcancemos una implementación muy interoperable cuando realmente se concrete. Así que eso es todo por hoy, pero estamos lejos de haber terminado. Así que Vue tiene 10 años, pero aún queda mucho por hacer. Experimentamos un período de fragmentación durante la transición de Vue 2.3, pero ahora que Vue 2 está oficialmente al final de su vida útil, el ecosistema de Vue 3 está prosperando con utilidades de mayor calidad, bibliotecas de componentes, renderizadores personalizados y meta frameworks que nunca antes. Y estamos aquí para apoyar más de esto en los próximos años.

Hemos sobrevivido a los ciclos de moda de JavaScript. Vue está aquí para ayudarte a hacer tu trabajo, no para venderte un servicio de pago. Estamos orgullosos de decir que nos mantenemos fieles a esa declaración. Puede que no seamos la solución más moderna hoy en día, pero estamos aquí para quedarnos, y siempre estaremos mejorando constantemente, una cosa a la vez.

Gracias. Entonces, ¿cuál es tu versión actual y el marco de herramientas de construcción? Puedo ver que el 52% de las personas todavía están en Vue 3 y Vite SPA. El segundo más utilizado es Nuxt 3. Así que eso es bueno, al menos todos se han migrado a Vue 3 hasta hoy. Desafortunadamente, no todos. Veo que Vue 2 SPA es como el 9%. Oh, acaba de ser superado por Vue 3, otra configuración. Genial. 16%, Vue 2 todavía. Quiero decir, es mejor que hace un año, así que, sí. Sí.

Bien, ahora volvamos a la sesión de preguntas y respuestas, finalmente, lo siento por V4. Hola, soy un desarrollador de React. Recientemente, comencé a aprender Vue.js. Así que mi pregunta es cómo convertirse en un profesional en Vue. ¿Cuál es tu consejo para un principiante en Vue.js? Claro, creo que debería ser un poco más fácil ya que ya conoces React. La Composition API tiene muchas similitudes con los hooks de React. Así que deberías sentirte como en casa. De hecho, debería haber un poco menos de preocupación en términos de seguimiento de dependencias, pasar matrices de dependencias, no necesitas preocuparte por eso en Vue. Así que creo que lo primero que quieres hacer es simplemente leer la documentación, y creo que el mayor – muchos de los conceptos como el flujo de estado, el modelo de componentes, de hecho, son realmente similares entre estos frameworks principales. Así que deberías captar eso muy rápido. Creo que si quieres avanzar más, lee algo de código fuente de, por ejemplo, bibliotecas como Vue.use. Eso es algo que realmente recomiendo. Echa un vistazo a cómo la gente extrae estas utilidades comunes en composables reutilizables de Vue, también conocidos como hooks. Creo que esa es una muy buena manera de familiarizarse más con cómo funciona la reactividad de Vue.

Bien. Entonces, la pregunta más votada es, la primera ha estado presente durante mucho tiempo pero aún se advierte como experimental y probablemente cambie. ¿Esto sigue siendo correcto? Sigue siendo experimental. Planeamos estabilizarla pronto. De hecho, no creo que la API vaya a cambiar mucho. Así que es principalmente asegurarse de que – si hay algo que quieras cambiar, probablemente no afectará mucho a los usuarios finales. ¿Tendrás tal vez como un ETA amplio? ¿Como 2025 o el fin del año? Este año. Este año, con suerte. Genial.

Y tal vez una actualización rápida sobre el plugin de Vue.js en VS Code. Sí. Entonces, la reciente versión 2.0, sé que ha habido bastantes problemas con algunos usuarios. Así que algunos de los problemas son en realidad debido a errores en VS Code. Y luego hay un problema reciente donde si estás – verifica tu versión de la extensión Vue de VS Code. Si está en 2.0, está atascada en una versión antigua. Haz una nueva búsqueda para instalar la antigua y luego instala la versión que es 2.0.14 o superior para que obtengas actualizaciones automáticas continuas. Así que es un problema que estamos tratando de resolver en contacto con VS Code. Así que ni siquiera es un problema de Vue.js.

Perfecto. Así que gracias de nuevo por todas esas preguntas, Evan. Nos vemos en otra ocasión y que tengas un día increíble. Adiós. Gracias. Igualmente. Adiós.