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. Suena como mucho tiempo en el mundo del front-end. Y, por supuesto, Vue ya no es una tecnología nueva, pero en esta charla veremos parte de su historia y también veremos lo que estamos haciendo para mantenerlo vivo y en buen estado. Bien, vamos directo al grano. En primer lugar, algunos números sobre Vue hoy en día. Aquí están algunas estadísticas combinadas de Vue.js y Vue 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 de npm y más de 1 billón de solicitudes mensuales de CDN en jsdeliver. También queremos hablar sobre el impacto técnico de Vue, porque a pesar de usarlo a diario, tal vez muchos usuarios nuevos hoy no están tan familiarizados con su historia y con las ideas que surgieron de Vue y que también han influido en otras tecnologías, ¿verdad? En 2014, Vue fue el primer framework de JavaScript en implementar la reactividad basada en seguimiento profundo. Ahora, la reactividad basada en seguimiento es un paradigma que se remonta a Knockout.js y Meteor Tracker. Es una tecnología aún más antigua que Vue, pero Vue fue el primero en aplicar este principio a objetos profundos. Por lo tanto, puedes mutar un objeto y las cosas simplemente funcionan, y Vue fue el primer framework en hacerlo. Vue también fue el primer framework en combinar la idea de componentes de un solo archivo con herramientas de compilación. La idea de componentes de un solo archivo no es necesariamente nueva. De hecho, hubo un proyecto interno en Google cuando trabajaba allí que fue una fuente de inspiración. Pero Vue fue el primero en combinar esta idea con una herramienta de compilación llamada Browserify en el backend, y más tarde también admitimos Webpack. Pero la capacidad de utilizar lenguajes adicionales en estos bloques de script, plantilla o estilo, es única. Por lo tanto, antes podías usar CoffeeScript, hoy en día principalmente puedes usar TypeScript, puedes usar SAS, LASP, preprocesadores, puedes usar PostCSS para procesar tu CSS, incluso puedes usar POD, que antes se llamaba Jade, para diferentes plantillas en texto con plantillas. Por lo tanto, Vue fue el primer framework en admitir este tipo de uso. Y la API de Composición fue la primera en combinar la reactividad estilo Signo, que es también la reactividad basada en seguimiento de la que hablamos antes, con modelos de componentes modernos. Por lo tanto, puedes usar referencias de Vue 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 en día. Vue también fue el primero en explorar un azúcar de reactividad impulsado por el compilador para Signos en forma de la transformación de reactividad, que fue una propuesta experimental con la que trabajamos durante un período de tiempo, pero al final decidimos que no era la mejor dirección para Vue. Sin embargo, estamos muy 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. Por lo tanto, podría ser más adecuado para Svelte, pero creemos que Vue está en un lugar bastante bueno con su propio paradigma. Ahora, Vue también es único en el sentido de que admite tanto el renderizado con plantillas como el renderizado con funciones de virtual DOM.

Esto ofrece un buen equilibrio que brinda familiaridad a los usuarios que prefieren la sintaxis de plantillas y una experiencia de desarrollo más fluida para las personas que prefieren las plantillas con estilo HTML. Pero al mismo tiempo, en casos de uso avanzados y para los autores de bibliotecas, aún puedes omitir la capa de plantillas y escribir funciones de renderizado manualmente, lo que te brinda mucha más flexibilidad para realizar funciones avanzadas. Y finalmente, Vue fue el 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 por piezas individuales pero con un diseño coherente que puedes adoptar y usar de forma incremental según tus necesidades del framework. Creo que Vue es el primero en pionerar esta idea y también es el único que la ha implementado realmente bien. Ahora, mirando hacia atrás, aquí tienes una breve cronología de lo que hizo Vue. Hicimos el primer lanzamiento con el nombre de Vue.js en 2013. Esa fue la primera vez que apareció el nombre de Vue.js. Pero el anuncio público fue en febrero de 2014. Permaneció como un proyecto secundario para mí durante mucho tiempo y me llevó bastante tiempo pulirlo lo suficiente como para sentirme cómodo y seguro de compartirlo con el mundo. En octubre de 2015, alcanzamos la versión 1.0. En realidad, me 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 principal, en la que implementamos el renderizado utilizando el virtual DOM, 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 3.0 tomó mucho, mucho más tiempo de lo esperado debido a la magnitud de los cambios y el impacto en el ecosistema que creó. Vue 2 ya se usaba ampliamente y el trabajo en 3.0 fue un proceso de aprendizaje para nosotros. Definitivamente hubo altibajos, se cometieron errores y se aprendieron lecciones. Por lo tanto, 3.0 se lanzó suavemente en septiembre de 2020 y finalmente se convirtió en la versión predeterminada en enero de 2022. Todo el proceso llevó algunos años. Pero estamos muy contentos de que el ecosistema finalmente haya adoptado Vue 3 y veremos algunas estadísticas más adelante. Por lo tanto, Vue 2 ha alcanzado oficialmente el final de su vida útil en diciembre de 2023. Realmente animamos a los usuarios que todavía están en Vue 2 a considerar la actualización, o deben buscar el soporte relevante para mantener sus versiones de Vue 2 en funcionamiento. Ahora, este fue realmente un momento nostálgico en el que todavía tengo esta publicación de blog en algún lugar hablando sobre la primera semana de lanzamiento de Vue.js y estaba muy 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, hubo momentos, altibajos donde la realidad golpea. No sé si alguien ha oído hablar del ciclo de adopción de tecnología. Cuando se lanza una nueva tecnología, hay un desencadenante tecnológico. Hay un pico de expectativas infladas. Luego está la prueba de desilusión, la pendiente de iluminación y finalmente se alcanza la meseta de productividad.

Ahora, diría que hay un proceso muy similar cuando te adentras en el open source con el tiempo. Cuando te adentras por primera vez en el open source, hay una gran emoción, un pico de emoción y producción. Trabajaba casi todo el día, todos los días en Vue cuando estaba impulsando el lanzamiento inicial y también impulsando la versión 1.0, impulsando la versión 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 correctas. Se tarda mucho tiempo en darse cuenta de que no puedes complacer a todos y a veces tienes que tomar decisiones difíciles. Y finalmente llegamos a 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 desafío principal por el que tienes que pasar. Y si estás trabajando en proyectos de open source, definitivamente habrá momentos como este. Y solo sé 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. Realmente espero que todos los que trabajan en open source puedan salir del abismo y alcanzar esta meseta equilibrada de productividad. Aquí hay algunos gráficos. Si miras mis gráficos de contribuciones en GitHub, verás que definitivamente hay momentos de agotamiento y dudas. Quiero ser muy abierto al respecto. 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? Habrá un momento en el que necesiten ajustarse. Hay momentos en los que necesitan tomar un descanso, necesitarán encontrar inspiración, necesitan ir y recargarse y encontrar su motivación nuevamente. Así que esto sucede, es normal. Quiero normalizar esto para los mantenedores de open source para que nos sintamos menos presionados y espero ver a pocos mantenedores compañeros agotarse. Y no hubiera sido posible llevarlo a cabo sin el apoyo de la comunidad AmazingView. Así que estoy poniendo la palabra aquí tres veces porque es tan importante. Si yo fuera Steve... Ahem! Lo siento. Corta esta parte. De acuerdo. Gracias. Estoy poniendo la palabra aquí tres veces porque es simplemente así de importante.

La comunidad de View es lo que más me enorgullece. View se trata de las 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 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 los miembros de nuestro equipo, a los colaboradores, a los mantenedores de bibliotecas del ecosistema, a los socios de la comunidad, a los organizadores de conferencias y meetups, a los defensores de View y a los patrocinadores. Ahora hablemos un poco sobre la sostenibilidad e independencia, que creo que también es otro aspecto que hace que View sea único. Actualmente, View es el único marco principal que sigue siendo independiente, es decir, no es predominantemente propiedad de una sola corporación. ¿Por qué es esto importante, podrían preguntar? La razón, creo, es que no estamos limitados por el apoyo financiero de una sola entidad, lo que significa que no nos dejaremos influir en las decisiones técnicas solo porque un gran patrocinador quiere que vayamos en una dirección determinada, ¿verdad? Todos nuestros patrocinadores, todos nuestros colaboradores financieros están descentralizados y realmente no tienen un gran poder de influencia en las decisiones técnicas del proyecto. Por lo tanto, el proyecto puede operar considerando únicamente los intereses de los usuarios y cada opinión de los usuarios recibirá igual consideración. Otro aspecto importante del ecosistema de View es la mentalidad colaborativa. Gracias a la independencia, el ecosistema de View es único en la forma en que genera muchos esfuerzos destacados que benefician más que al propio marco. Si todo fuera por beneficios, esto sería bastante diferente. La comunidad de View ha sido la fuente de múltiples esfuerzos que han beneficiado a todo el ecosistema de JavaScript en su conjunto. Solo para nombrar algunos, tenemos Vite, tenemos Bolar, tenemos Un.js, Nitro y algunas herramientas de desarrollo intermarco en las que se está trabajando. Todos estos son de miembros de la comunidad de View y Vite. Y finalmente, quiero echar un vistazo al estado actual y al futuro de View. 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. Obviamente, todavía se están ejecutando muchas aplicaciones heredadas de View 2 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 destacada en 3.4 fue un sistema de reescritura completa del posture que es dos veces más rápido que antes. Así que una cosa que quiero enfatizar es que incluso si View es un marco 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 seguiremos investigando estas oportunidades y encontrando mejoras de rendimiento y de experiencia para nuestros usuarios. Ahora, 3.4 también incluyó un sistema de reactividad más eficiente que redujo muchos cálculos innecesarios en las propiedades computadas. También estabilizamos el modelo definido y lanzamos VBind, el mismo nombre, shorthand on. Ambos tienen grandes mejoras en la experiencia de desarrollo. Ahora, el cambio más reciente y notable en 3.4 es que en un parche reciente, lanzamos algunas mejoras de rendimiento de la representación en el servidor bastante importantes.

Ahora esto fue en gran medida desencadenado por una prueba de referencia pública que ha estado circulando en Twitter. Al inspeccionar la prueba de referencia, pude identificar algunos casos en los que algunas de las optimizaciones estaban afectando el rendimiento de View en la prueba original. Ahora, con esos cambios implementados en 3.4.22, vemos una mejora impresionante de 3.8 veces en esa prueba solo para View. Y para Nuxt, también hay una mejora muy, muy notable de 1.77 veces. Daniel también ha enviado una solicitud de extracción que optimiza el uso de Nuxt al usar datos asíncronos, evitando el uso de estructuras de datos profundas al obtener los datos, que será la configuración predeterminada en Nuxt 4.0, lo que mejora aún más el rendimiento en esa prueba. Entonces, si estás usando Nuxt o estás utilizando el renderizado en el servidor con View, asegúrate de actualizar a la última versión. Ahora hablemos un poco sobre lo que está planeado para la próxima versión, 3.5 y más allá. En primer lugar, estamos implementando aún más mejoras en la eficiencia de la reactividad. La rama menor actual en GitHub es la rama en desarrollo para 3.5 y ya se han fusionado dos solicitudes de extracción muy importantes para el sistema de reactividad. La solicitud de extracción número 10407 proporciona una reescritura del sistema de reactividad nuevamente. La estructura interna de seguimiento de datos se ha refactorizado con una mejora del 56% en el uso de memoria. El uso de memoria es bastante importante porque en aplicaciones intensivas en datos, la recolección de basura puede afectar negativamente el rendimiento. Por lo tanto, utilizar menos memoria ayudará mucho en aplicaciones altamente dinámicas. La solicitud de extracción 9511 proporciona una ganancia de 10 veces al realizar un seguimiento de matrices reactivas grandes. Esto ha sido en realidad una fuente bastante común de cuellos de botella de rendimiento cuando tienes matrices realmente grandes y las colocas en una estructura de datos profunda. Esta solicitud de extracción proporciona una forma más inteligente de evitar el seguimiento de dependencias innecesarias al iterar sobre estas matrices más grandes y proporciona ganancias muy, muy significativas en estos casos. También estamos pensando en estabilizar las props reactivas para estructurar, ya que estamos viendo comentarios bastante positivos en la discusión del RFC. Pero antes de hacerlo finalmente, te animamos a que expreses tu opinión en el RFC para ayudarnos a tomar una decisión final. También hay mejoras planificadas para SSR en 2.5, siendo la principal la estabilización de suspense. Ha sido experimental durante mucho tiempo y estamos deseando estabilizarlo. Además, hay pequeñas APIs como useID, mejoras en la calidad de vida como la comprobación de validez de anidación HTML incorporada, que te ayudarán a detectar casos en los que accidentalmente colocas divs dentro de peas o peas dentro de divs. También vamos a analizar la posibilidad de una hidratación diferida incorporada utilizando componentes asíncronos como límites. Ahora, muchos de ustedes probablemente están interesados en el estado del modo vapor. Estamos haciendo grandes avances en el modo vapor. Por lo tanto, ya puede ejecutar ToDoMVC en caso de que no lo supieras. Ya puedes probarlo en el playground. Si descargas las diapositivas más tarde, deberías poder encontrar el enlace y probarlo. O puedes ir al repositorio central de vapor en GitHub y verlo. Deberías poder encontrar el enlace allí. El enfoque actual del modo vapor es la implementación de componentes.

Y la buena noticia es que casi hemos terminado. Si observas el problema vinculado aquí, hemos cubierto muchas partes de los componentes y solo quedan algunas cosas. Una vez que terminemos los componentes, el siguiente enfoque será la interoperabilidad entre vapor y el virtual DOM, es decir, poder compilar e incrustar componentes de 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 colaboradores que ayudan con vapor. Es realmente emocionante ver esto porque es una implementación bastante avanzada y me alegra ver que, al establecer la dirección inicial, muchos miembros de la comunidad están colaborando para ayudarnos a trabajar en vapor en paralelo con el trabajo principal de Vue. Y finalmente, queremos mejorar la experiencia de desarrollo. Algunos de los trabajos que he estado haciendo fuera de Vue es mejorar aún más Vite invirtiendo en herramientas de nivel inferior. Muchos de ustedes sabrán que hemos comenzado un nuevo paquete basado en Rust llamado Rodown, que está destinado a ser compatible con Vite en el futuro. Rodown ahora es de código abierto y estamos viendo un gran rendimiento. Actualmente hemos terminado el empaquetado básico, la división básica de fragmentos y el soporte de mapas de origen. Con todo esto implementado, podemos ejecutar algunas pruebas de rendimiento y actualmente somos de 1.5 a 2 veces más rápidos que ES build, lo cual es muy impresionante. También estamos contribuyendo a OXC, que es la herramienta de lenguaje de nivel inferior, un posible JavaScript basado en Rust que estamos utilizando dentro de Rodown. Y tenemos una relación de colaboración muy estrecha con el equipo de OXC. También tenemos miembros del equipo trabajando en extraer capas reutilizables entre Nuxt y las herramientas de desarrollo de Vue y potencialmente utilizar el mismo kit para admitir otro tipo de herramientas de desarrollo en el futuro. También hemos realizado mejoras continuas en VolR V2, es decir, las herramientas de lenguaje de Vue. VolR V2 se lanzó con soporte para el modo híbrido, lo que nos permite utilizar el servidor de lenguaje TypeScript único para inferir todo el proyecto, tanto los archivos TS como los archivos Vue. Esto es muy eficiente en cuanto a memoria y rendimiento, pero hay muchos casos especiales y aún hay algunos detalles que debemos estabilizar. Pero estamos viendo una gran promesa en el rendimiento de esta dirección. Y finalmente, los 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. Los Signos, si no estás familiarizado con el término, son primitivas de reactividad similares a los refs de Vue. Entonces, si has usado los refs de Vue, 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 nativa impulsada por Signos de addVue/Reactividad, el motor de reactividad de nivel inferior que impulsa a Vue correctamente. Al utilizar Signos nativos, deberíamos poder tener menos código para mantener y empaquetar, por lo tanto, menos código para mantener en la base de código de Vue y menos código para enviar a los usuarios finales. Debería haber un mejor rendimiento y consumo de memoria porque los Signos nativos se pueden implementar en lenguajes nativos y existe la posibilidad de interoperabilidad entre frameworks, piensa en el uso de Vue en varios 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 alcanzar una implementación muy interoperable cuando realmente se implemente. Eso es todo por hoy, pero estamos lejos de terminar. Así que Vue tiene 10 años, pero todavía hay mucho por hacer. Experimentamos un período de fragmentación durante la transición de Vue 2.3, pero ahora que Vue 2 ha llegado 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 como 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. Nos enorgullece decir que nos mantenemos fieles a esa afirmación. Es posible que no seamos la solución más moderna en la actualidad, pero estamos aquí para quedarnos y siempre estaremos mejorando, una cosa a la vez.

Gracias. ¿Cuál es tu versión actual y la herramienta de construcción que utilizas? Veo que el 52% de las personas todavía utilizan 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 el día de hoy. Desafortunadamente, no todos. Veo que Vue 2 SPA es del 9%. Oh, acaba de ser superado por Vue 3, otra configuración. Genial. 16% todavía utiliza Vue 2. Aunque sigue siendo mejor que hace un año, así que sí. Sí.

Ok, volvamos a las preguntas y respuestas, finalmente, disculpa por la espera. Hola, soy un desarrollador de React. Recientemente, comencé a aprender Vue.js. Mi pregunta es cómo convertirme en un experto 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 API de Composición tiene muchas similitudes con los hooks de React. Deberías sentirte como en casa. De hecho, debería haber un poco menos de preocupación en cuanto al seguimiento de dependencias, pasar arreglos de dependencias, no necesitas preocuparte por eso en Vue. Creo que lo primero que debes hacer es leer la documentación y creo que los conceptos más importantes, como el flujo de estado y el modelo de componentes, de hecho, son muy similares entre estos frameworks populares. Deberías aprenderlos rápidamente. Creo que si quieres profundizar más, lee algo de código fuente, por ejemplo, bibliotecas como Vue.use. Eso es algo que realmente recomiendo. Echa un vistazo a cómo las personas extraen estas utilidades comunes en composables reutilizables de Vue, también conocidos como hooks. Creo que es una excelente manera de familiarizarte con cómo funciona la reactividad de Vue.

De acuerdo. La pregunta más votada es, la primera ha estado presente durante mucho tiempo pero aún se advierte que es experimental y probablemente cambiará. ¿Esto sigue siendo correcto? Todavía es experimental. Estamos planeando estabilizarlo pronto. De hecho, no creo que la API vaya a cambiar mucho. Así que principalmente se trata de asegurarse de que, si hay algo que quieras cambiar, probablemente no afectará mucho a los usuarios finales. ¿Tal vez tengas una ETA amplia? ¿Como en 2025 o fin de año? Este año. Este año, con suerte. Genial.

Y tal vez una actualización rápida sobre el complemento de Vue.js en VS Code. Sí. En la reciente versión 2.0, sé que ha habido algunos problemas con algunos usuarios. Algunos de los problemas se deben en realidad a errores en VS Code. Y luego hay un problema reciente donde, si verificas la versión de la extensión de Vue en VS Code, si está en 2.0, está atascada en una versión antigua. Haz una nueva búsqueda e instala la antigua y luego instala la versión 2.0.14 o superior para obtener actualizaciones automáticas continuas. Así que ese es un problema con el que estamos tratando de comunicarnos con VS Code para resolver. 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.