10 Años de OSS Independiente: Una Retrospectiva

Esta charla trata sobre una retrospectiva de diez años sobre el trabajo en código abierto. Acerca de mí, soy un desarrollador independiente de código abierto y he sido independiente desde 2016, así que eso son un poco más de ocho años, pero mi primera incursión en el código abierto fue el lanzamiento de Vue.js en 2014. Este año marca diez años de trabajo en código abierto y construcción en público. Ahora estoy basado en Singapur y trabajo a tiempo completo en Vue, Vite y otros proyectos de código abierto relacionados. Antes de trabajar a tiempo completo, trabajé brevemente en Google y luego en una startup llamada Meteor.js. Eso es suficiente sobre mí.

Cosas en las que trabajo. Trabajo en dos cosas, principalmente. Una es Vue, que es un framework de JavaScript para el front-end creado en 2014. ¿Cuántos de ustedes han oído hablar de ello? Gracias. La otra herramienta es una herramienta de construcción para el front-end llamada Vite. ¿Cuántos de ustedes están usando Vite? Wow. Genial. Así que Vite fue creado en 2020, hace unos cuatro años. Así que hablemos primero de Vue. Es un proyecto de diez años. Tomó mucho tiempo llegar hasta aquí. Pero si hacemos una breve instantánea de Vue hoy en día, tenemos dos repositorios en GitHub, uno para Vue 2 y otro para Vue 3. Combinando estos dos repositorios, tenemos más de 9,000 commits, más de 500 lanzamientos, más de 250,000 estrellas en GitHub, 5 millones de descargas semanales de npm y 2.2 millones de usuarios en todo el mundo. Estas son estadísticas de nuestra extensión de herramientas de desarrollo. Tiene más de 1,000 millones de solicitudes mensuales de CDN en JSDeliver. Cada año, miro estos números y me maravillo de la escala en la que Vue ha crecido, y creo que probablemente, la gente me ha hecho la misma pregunta tantas veces. ¿Esperabas que esto sucediera cuando comenzaste a trabajar en Vue? Y la respuesta obvia es no. No tenía idea de cómo iba a ser. Sin expectativas en absoluto.

Incluso cuando decidí que quería comenzar a trabajar en ello a tiempo completo. Así que es un viaje bastante asombroso. Pero retrocedamos un poco y hablemos un poco sobre los primeros días. No voy a profundizar demasiado en las pequeñas historias de cómo todo comenzó, por qué tuve la idea. Pero el humilde comienzo en las primeras fases cuando lancé Vue por primera vez en febrero de 2014, el resultado fue que obtuve unas pocas cientos de estrellas en GitHub y estaba muy emocionado al respecto. Pero eso fue solo el comienzo, así que la emoción realmente no duró mucho, para ser honesto.

Pero echemos un vistazo a la breve línea de tiempo. El primer lanzamiento, con el nombre de Vue.js, fue en realidad en 2013. Fue privado. Solo lo puse en NPM pero no se lo dije a nadie. El primer anuncio público fue en febrero de 2014. Alcanzó la versión 1.0 en octubre de 2015. La versión 2.0 en 2016, la versión 3.0 comenzó en septiembre de 2018. Y el sublanzamiento en septiembre de 2020. La versión 3.0 finalmente se convirtió en la predeterminada en enero de 2020. Y en diciembre de 2023, finalmente declaramos que Vue 2 llegó a su fin de vida. Así que esa es una visión general muy, muy rápida, ¿verdad? Pero realmente no quiero pasar esta charla hablando de todos los pequeños cambios que ocurrieron a lo largo del tiempo en Vue. Porque quiero que esta charla sea más sobre el viaje, el sentimiento, ya sabes, cómo han cambiado las cosas para mí a lo largo de trabajar en un proyecto que creció más allá de mis expectativas. Así que hubo muchos altibajos.

Una cosa muy obvia, si miras, profundizas en mi perfil de GitHub y ves, hay un gráfico aquí. Así que eso fue en febrero de 2014 cuando lancé Vue por primera vez. Y hubo varios meses después de eso en los que no escribí ningún código en GitHub en absoluto porque estaba bastante agotado, ¿verdad? Esto sucede bastante a menudo. ¿Cuántos de ustedes aquí mantienen un proyecto de código abierto? No muchos de ustedes. Pero si has mantenido un proyecto de código abierto a lo largo del tiempo, probablemente hayas experimentado alguna forma de agotamiento, ¿verdad? Porque las expectativas que los usuarios de código abierto depositan en ti, especialmente cuando tienes un proyecto que ha crecido más de lo que esperabas, son tremendas, ¿verdad? Me gusta hacer una analogía con este ciclo de adopción de tecnología que muchos de ustedes probablemente han visto. Por lo general, cuando sale una nueva tecnología, hay este pico de expectativas infladas. Y luego cae en picado a esta fase de desilusión donde piensas, esto es una porquería. Y luego necesitas cruzar ese abismo para poder volver a la pendiente de la iluminación y al plateau de la productividad al final. Así que hago una analogía de eso con la participación en el código abierto. Cuando te involucras en el código abierto, y esto es personalmente para mí, cuando me involucré por primera vez en el código abierto, hubo un pico de emoción y producción.

Estaba como, wow, mi cosa está recibiendo atención en Hacker News, está obteniendo estrellas en GitHub, todas estas personas usando mi software, y estoy tratando de responder a cada problema en GitHub, tratando de solucionar cada error. Y luego, ya sabes, a medida que tu base de usuarios comienza a crecer, se revelan más fallas en la cosa que pensabas que era perfecta. Y te das cuenta, okay, tal vez podría mejorar aquí, tal vez podría mejorar allá. Oh, espera, este otro proyecto ha estado haciendo esto todo este tiempo, lo cual nunca pensé. Oh, tal vez debería simplemente cerrar este proyecto y pedirle a la gente que use la otra cosa. ¿Verdad? Así que es muy común que los desarrolladores de código abierto pasen por esta fase de agotamiento y dudas sobre sí mismos. Y lo mismo me pasa a mí. Ha habido múltiples ocasiones en las que he pasado por este tipo de pensamiento, si debería seguir trabajando en esto, ¿tiene sentido siquiera? ¿Vale la pena seguir invirtiendo tanto tiempo? Y la cantidad de presión que recibes, cada día te despiertas y tienes 20 problemas de personas que encuentran que tu software simplemente no funciona. Eso es duro, ¿vale? Con el tiempo, he aprendido a ajustarme, a reajustarme. Con el tiempo, he aprendido a encontrar paz conmigo mismo y reconocer que las cosas no pueden ser perfectas. Y creo que para la mayoría de los proyectos de código abierto y para la mayoría de los mantenedores de código abierto, hay este proceso en el que una vez que entras en esta fase de agotamiento, muchos de ellos simplemente no salen de ella. Simplemente se detienen allí, abandonan el proyecto. Y por eso vemos todo este cambio de diferentes soluciones que surgen y desaparecen. ¿Verdad? Entonces, si puedes superar ese abismo, y encuentras paz contigo mismo, y entiendes tus responsabilidades y los límites de tus capacidades, y estableces un buen límite entre cuánto quieres invertir en tus proyectos y cuánto quieres obtener de la vida, ¿verdad?, necesitas encontrar ese equilibrio para poder seguir trabajando en el código abierto de manera productiva. Y eso no es algo fácil de hacer, ¿verdad? Así que esto fue cuando lancé Vue por primera vez, y hay múltiples otras etapas en mi carrera en las que dejé de escribir código durante unos meses. Estaba como, ya no quiero hacer esto. Pero luego vuelvo. Eventualmente, ¿verdad? Incluso hoy en día, a veces, saco todo el gráfico desde 2014 hasta 2022. Y hay múltiples eventos de la vida, ¿verdad? Los mantenedores de proyectos de código abierto también tienen todas estas cosas que suceden en la vida, tener hijos, mudarse a nuevos lugares, tener COVID. Así que mi punto principal aquí es que cuando la gente piensa en alguien como yo que ha estado trabajando en código abierto durante diez años, no siempre es un camino fácil. Tenemos que enfrentar muchos desafíos y encontrar lo que nos resulta significativo para mantenernos motivados en trabajar en estas cosas. Así que espero que cuando uses un proyecto de código abierto, no necesariamente de mi parte, sino de cualquier otra persona que amablemente haya compartido su trabajo contigo de forma gratuita, pienses en lo que han pasado durante el tiempo que no ves, el esfuerzo que han puesto en ello, tal vez los agotamientos por los que han luchado. Y simplemente aprecia un poco más. Y piensa en devolver algo. Piensa en apoyarlos. Piensa en contribuir, ayudar a solucionar problemas o donar, patrocinarlos. Hay muchas formas en las que puedes ayudar. Y para mí personalmente, gran parte de la lucha también proviene de manejar el creciente alcance de los proyectos, ¿verdad? Vue como un framework comenzó como un script muy simple que podías incluir en tu etiqueta de script en una página y simplemente funcionaba. Con el tiempo, el alcance se expandió mucho.

Fuera del núcleo de Vue, también tenemos la documentación, que tiene cientos de páginas con toda esta información detallada, ¿verdad? Y debe mantenerse actualizada. Tenemos el enrutador oficial, tenemos bibliotecas oficiales de gestión de estado, tenemos la cadena de herramientas de compilación, de alguna manera terminé construyendo una herramienta de compilación yo mismo porque quería mejorar la cadena de herramientas de Vue. Y luego está el soporte de IDE, que intenta hacer que todo el lenguaje TypeScript y CSS incrustado funcione correctamente en los componentes de un solo archivo de Vue. Es muy complicado. Es mucho trabajo. Y luego están las herramientas de desarrollo del navegador. Necesitamos mantener todo el ecosistema en sincronía. Cuando hicimos Vue 3, nos llevó dos años poner todas estas cosas al día con Vue 3. Así que, ya sabes, manejar el creciente alcance fue extremadamente desafiante.

Y luego también tenemos que lidiar con muchas decisiones difíciles, ¿verdad? La transición de Vue 2 a Vue 3, si eres usuario de Vue, probablemente sabes que no fue fácil. Se cometieron muchos errores y se aprendieron muchas lecciones. También reinventamos prácticamente el framework con la API de composición, que abrió un nuevo paradigma pero también creó fragmentación. Algunos usuarios de Vue prefieren las API antiguas. Tuvimos que pasar por largas discusiones en RFC y debates, tratando de convencer a las personas de que esto es realmente algo bueno que puede ayudarte de ciertas maneras. Así que, una realización que eventualmente obtuve de todas estas luchas es que soy solo una persona. No puedo escribir todo el código. No puedo responder todas tus preguntas. No puedo solucionar todos tus errores. Y eso está bien, porque el proyecto ya no soy solo yo. Es una comunidad. Así que seré como Steve Ballmer y repetiré esto tantas veces como quiera, porque es tan importante, porque esto es lo que hizo posible Vue. Verás, lucho como una sola persona, pero lo superamos porque no soy solo yo, es todo un equipo, toda una comunidad. Vue no estaría donde está hoy sin las personas que lo rodean, ¿verdad? Por eso decimos que el código abierto se trata de las personas. Así que aquí está mi más profundo agradecimiento a los miembros del equipo, colaboradores, mantenedores de bibliotecas del ecosistema, patrocinadores, organizadores de conferencias y reuniones, socios de la comunidad, defensores, todas estas personas, no solo contribuyendo en forma de código, sino también contribuyendo a conectar a las personas en torno al proyecto y ayudándolo a mejorar en todos los aspectos posibles, ¿verdad? Al mismo tiempo, mi papel comenzó a cambiar de simplemente escribir código. A veces desearía poder concentrarme solo en escribir código, pero hoy en día, hay mucho trabajo fuera del código que implica la mentoría de personas en el ecosistema, ayudar a los miembros del equipo a crecer en roles más grandes, dirección técnica, asegurarse de que todos estos proyectos se muevan de manera cohesiva, gestión de la comunidad, básicamente tuitear, relaciones con patrocinadores. De hecho, tuvimos que hacer que el proyecto fuera sostenible, y eso es algo de lo que estoy bastante orgulloso en Vue, y luego hay asociaciones comerciales. Hay empresas que construyen sobre Vue, que construyen en el ecosistema de Vue, y quieren colaborar y devolver a Vue, y todas estas relaciones que tenemos que gestionar fuera del trabajo.

Es como una gestión de proyectos a tiempo completo además de solo escribir código. Algo de lo que estoy muy orgulloso es que realmente distribuimos una cantidad justa de dinero a Vue y a los colaboradores de Vue en nuestro ecosistema. Cada año, distribuimos más de $270,000 a nuestros colaboradores en el ecosistema. Además, nuestros colaboradores reciben posiciones y patrocinios completos debido a su participación en los proyectos. A veces, algunos colaboradores, por ejemplo, de Vue, consiguen un trabajo porque una empresa quiere contratar a un colaborador principal o quiere que sigan trabajando en estos proyectos de código abierto. Se crean oportunidades.

En el frente técnico, solo quiero mencionar algunas cosas. A pesar de ser un framework de diez años, seguimos implementando mejoras internas significativas. Recientemente, hemos tenido un analizador reescrito que es dos veces más rápido, hemos logrado mejoras del 3.9x en las pruebas de rendimiento de SSR y en la próxima versión 3.5 hemos reducido el uso de memoria del sistema de reactividad en un 56 por ciento y mejorado el manejo de matrices reactivas grandes hasta diez veces. Así que seguimos muy activos y realizando cambios internos significativos. También hay proyectos más ambiciosos en marcha, como el Modo Vapor, que es una estrategia de compilación inspirada en Solid que toma la misma sintaxis de componentes de Vue y produce algo más eficiente en rendimiento. Actualmente, todavía está en proceso, pero casi hemos terminado con los componentes y la siguiente etapa es permitir a los usuarios inventar componentes Vapor en las aplicaciones de Vue actuales. También tenemos una nueva herramienta de desarrollo que está por venir y que tiene una mejor experiencia de usuario, más características, mejor rendimiento y más fluidez.

Otra cosa que quiero mencionar sobre el ecosistema de Vue es la mentalidad colaborativa. La comunidad de Vue ha sido fuente de múltiples esfuerzos que han beneficiado a todo el ecosistema de JS más allá de Vue, ¿verdad? V es el ejemplo principal, y luego está Volar, que es el framework subyacente para nuestro soporte de IDE, pero que también se utiliza ahora para admitir otros lenguajes integrados como Astral o MDX, y JetBrains de hecho está utilizando Volar para admitir el servidor de lenguaje de Angular. También hay utilidades interframework como en la sección unjs, si nunca lo has revisado, búscalo. Tiene muchas cosas interesantes que puedes reutilizar. Provienen del equipo de Nux, pero son independientes del framework, y Nitro es un framework del lado del servidor que te permite construir más fácilmente un framework de pila completa combinado con Vite. Solo me quedan tres minutos, así que tengo que ir muy rápido con la parte de Vite.

Hablemos de Vite. Cómo comenzó, el 20 de abril de 2020, mientras me iba a dormir, simplemente tuve esta idea, simplemente hizo clic en cómo hacer la sustitución de módulos en caliente sobre un ADBSN. Lo hice y se convirtió en Vite. Así es como va.

Recientemente superamos los 13 millones de descargas semanales. ¿Cuánto es eso? ¿Más de 15 millones al mes? Tenemos un gran ecosistema de todas las herramientas que se construyen sobre Vite, que admiten Vite o aprovechan Vite en cierta medida para algunas de sus características. Probablemente veas muchos logotipos familiares aquí. Entonces, sí, en perspectiva, probablemente ahora estemos a la mitad de webpack. Esperemos que podamos ver que esa brecha se reduzca aún más a finales de este año.

La filosofía de Vite es construir una herramienta de construcción ligera y extensible, impulsar la web moderna, tomar un enfoque pragmático hacia el rendimiento y admitir frameworks de alto nivel. Queremos construir un ecosistema colaborativo entre frameworks en el que todos estén tratando de construir algo mejor para la web, y todos puedan centrarse en innovaciones que importan en lugar de reinventar la rueda, porque Vite se ha convertido en la capa de infraestructura compartida. Si observamos el panorama de los meta-frameworks hoy en día, aparte de Next.js, todo lo demás está en Vite o se está trasladando a Vite. Es algo bueno que todos estos diferentes frameworks ahora puedan compartir una base común y evitar tener que reinventar lo mismo una y otra vez. Creo que eso es bueno para la estabilidad y les permite centrar su energía en cosas que realmente importan, diferenciaciones que realmente importan y que se adaptan a diferentes necesidades. Junto con el aspecto técnico, Vite ha desarrollado una comunidad muy impresionante entre frameworks. Esta es una foto del panel del equipo de Vite en Vue.js Amsterdam del año pasado, también en Ámsterdam, lo cual es realmente genial. Tenemos colaboradores de todo el mundo, de diferentes frameworks. ¿Qué sigue para Vite? Queremos hacer dos cosas. La primera es Vite internamente en la línea de versiones actual de Vite, 5.3 y Vite 6, queremos hacer una API de entorno que se centre en un mejor soporte para los meta-frameworks que tenemos hoy en día. Por otro lado, queremos mejorar Vite desde el principio. Estamos construyendo uno nativo sobre una cadena de herramientas nativa de JavaScript llamada OXC para admitir mejor los frameworks que se ejecutan en múltiples entornos, navegador, Node.js, workers, y actualmente es experimental en Vite 6 alpha. Esto está más orientado a los autores de frameworks, así que no profundizaré demasiado en los detalles, pero la idea es que estamos escuchando activamente las necesidades de las personas que construyen sobre Vite e intentamos encontrar mejores abstracciones para que todos estos diferentes frameworks puedan reutilizar los mismos elementos básicos para admitir mejor sus necesidades de alto nivel.

Rowdown es un empaquetador basado en Rust diseñado para Vite. Se creó el proyecto para abordar algunos problemas en Rowdown, como la necesidad de una mejor consistencia en el desarrollo y producción, un mejor rendimiento en la construcción de producción y una mejor calidad de los activos de construcción de producción. Para lograr estos objetivos, básicamente estamos tratando de construir un empaquetador que se apoye en los hombros de gigantes, ¿verdad? Queremos la velocidad de VS build. Queremos el ecosistema de complementos de Vite y Rollup.

También queremos el control de activos de producción de Webpack, ¿verdad? Hay cosas interesantes en estos empaquetadores existentes que queremos unir y adaptar a las necesidades de Vite, y eso es Rowdown.

Por lo tanto, Rowdown está en progreso. La primera etapa de empaquetado de bibliotecas está completa y el siguiente paso en el que estamos trabajando es la compatibilidad de Vite y los plugins de Rollup, así como el control avanzado de fragmentos para la salida orientada a aplicaciones, como la división avanzada de fragmentos y la federación de modelos en el futuro.

LXC es la base sobre la que se construye Rowdown. El autor Boston tiene otra charla que se transmitirá de forma remota sobre LXC, pero, en general, es una cadena de herramientas de lenguaje para JavaScript escrita en Rust que incluye un analizador, un transformador, un resolutor, un enlazador, un formateador y un minificador. Algunos de estos ya están completos, otros están en progreso, por ejemplo, el transformador, acabamos de terminar las transformaciones de TypeScript, y luego está el formateador y los minificadores que están en progreso. Puede que te preguntes por qué LXC, por qué no construir sobre SWC o Biome. Probablemente escribamos algo más completo sobre la razón por la que elegimos construir sobre LXC, pero, en términos generales, tiene un mejor rendimiento. Está diseñado específicamente para ser utilizado como componentes en herramientas de nivel superior, y es actualmente el analizador más rápido, eficiente en memoria y compatible con las especificaciones que existe, un analizador de JavaScript escrito en Rust. Tiene un estilo de código más simple que facilita su comprensión. Esa es probablemente la razón principal por la que elegí LXC, porque no podía entender cómo funcionaban algunas de las soluciones que existen. Nuestra visión final es que el equipo de V, el equipo de Rodan y el equipo de LXC trabajen juntos para crear esta cadena de herramientas unificada y agnóstica del entorno de ejecución para JavaScript y la web. Aquí puedes ver la estructura de capas: V como la herramienta de construcción, Rodan como el soporte adicional, y LXC como la cadena de herramientas de lenguaje de nivel inferior. El significado, el valor de una cadena de herramientas unificada es que ahora podemos tener un formato AST consistente que maneje todo.

Básicamente, la visión para la que Rome fue creada originalmente, pero de alguna manera nunca se logró. Creo que ahora tenemos muchas más posibilidades de hacerla realidad porque ya tenemos muchas de estas partes construidas, y muchas personas ya las están utilizando, y realmente vemos una buena oportunidad de construir esta base para futuras posibilidades emocionantes, ¿verdad?

Estas cosas no necesariamente tienen que ser construidas por nosotros. Pueden ser construidas por ti sobre la base que proporcionamos, por lo que la interoperabilidad eficiente entre Rust y los complementos de JS, la instrumentación de código, las optimizaciones avanzadas de activos y la razón por la que nos enfocamos tanto en el rendimiento es porque necesitas un rendimiento extremo para desbloquear el presupuesto para poder hacer estas cosas avanzadas. De lo contrario, nos enfocamos en hacer que nuestras compilaciones sean lo suficientemente rápidas como para ahorrar minutos en la CI, ¿verdad? Únete a nosotros si te apasiona el futuro de las herramientas de JS, echa un vistazo a estos proyectos en GitHub y damos la bienvenida a cualquier forma de contribución e involucramiento.

Gracias. APLAUSOS. Hemos recibido algunas de sus preguntas. Todavía pueden enviar todas sus preguntas a Slido, por favor. Hemos recibido bastantes, así que espero que estén listos. En primer lugar, la gente quiere saber cómo te ganas la vida como desarrollador de código abierto. Mencionaste los patrocinios un poco, pero ¿cómo lo hiciste en los primeros días? Principalmente a través de patrocinios. En los primeros días, había un amigo que era CTO en una empresa llamada Strikingly, y son una gran empresa de Ruby y han estado involucrados en el código abierto durante mucho tiempo. Cuando el CTO era mi amigo, y cuando se enteró de mi plan de hacer más código abierto, decidió que la empresa destinaría su fondo de apoyo al código abierto para apoyarme durante seis meses, así que eso realmente ayudó en los primeros días, pero luego empecé a recibir, creo, cuando decidí hacerlo a tiempo completo, tenía alrededor de $1,500 al mes de Patreon. Y, afortunadamente, siguió creciendo con el tiempo, así que ahora tenemos una fuente bastante estable de donaciones de patrocinadores y también tenemos asociaciones con personas que crean contenido de pago para Vue, y luego colaboramos con algunas empresas que están construyendo productos comerciales sobreVue, por lo que hay diferentes fuentes combinadas de esto. Múltiples fuentes.

Genial, gracias por eso. La siguiente pregunta con mayor puntuación fue, ¿dónde puedo conseguir esa increíble sudadera que estás usando? ¿Esta? Desafortunadamente, se hizo en una pequeña cantidad solo para los miembros del equipo, pero si la gente la quiere, tal vez... Contribuyan un poco más y tal vez... Probablemente la haremos, sí. Otra pregunta importante. Al principio, ¿cómo te aseguraste de poder crear conciencia sobre tus proyectos de código abierto? Tuitea mucho. ¡Tuitea mucho! Ya no tuiteo tanto como en los primeros días, pero creo que cuando recién comencé conVue, simplemente me metía en todas las discusiones de Hacker News o Reddit sobre cosas de front-end e intentaba hacerme notar, pero ya no lo hago, pero en los primeros días probablemente sea la forma más económica de hacerlo. Correcto, gracias. Luego, recientemente hemos visto a actores malintencionados infiltrándose en la comunidad de código abierto para distribuir malware. ¿Cuál es tu opinión sobre este problema? Lo siento, ¿cuál es la pregunta? Para distribuir malware. Creo que definitivamente es un problema preocupante. Hay muchas cosas en el código abierto que se basan en la buena voluntad, y simplemente asumimos que las personas son amables, por lo que eso abre brechas para los actores malintencionados. Es lamentable porque las personas abusarán de la buena voluntad de la comunidad de código abierto y nos obligarán a ser más cautelosos y corromperán la confianza que hemos construido a lo largo del ecosistema. Es triste, pero creo que, dado que eso ya ha sucedido, las personas simplemente deben ser más vigilantes. En realidad, hemos recibido comunicación de la JS Foundation sobre algunas cosas relacionadas con Vue en el pasado también. Creo que, como mantenedores, simplemente tenemos que ser más vigilantes, y como usuarios, también puedes ayudar informando cualquier cosa que te parezca sospechosa.

Gracias. Definitivamente una preocupación. Veamos, ¿cuál? Correcto, hagamos esta. ¿No falta testing en tu visión? No incluí VTest en el gráfico, y pido disculpas a Vladimir, quien es el principal mantenedor de VTest. Pero VTest también es una parte muy importante de la cadena de herramientas, y podrá aprovechar las mismas partes subyacentes que estamos construyendo para VT, porque VTest se basa en VT. Sí. Muy bien, perfecto, así que un reconocimiento para ellos. Veamos. Con una comunidad en crecimiento, patrocinadores y otras partes interesadas, ¿cómo se alinean en nuevas ideas y determinan la dirección hacia la que se dirige Vue? Mayormente nos enfocamos en las necesidades de la comunidad. Lo que sucede con los patrocinios de Vue es que no tenemos grandes patrocinadores individuales que puedan dictar la dirección técnica de Vue. Las fuentes de patrocinio que recibimos están muy distribuidas, por lo que ningún patrocinador tiene realmente influencia en lo que debemos hacer a continuación. Es prácticamente sin condiciones, y somos muy explícitos al respecto, por lo que si patrocinas el proyecto Vue, no haremos nada especial solo para tus necesidades. Queremos enfocarnos principalmente en lo que los usuarios necesitan, y también tratar de evaluar hacia dónde se mueve la tendencia general del ecosistema, por lo que queremos que Vue se mantenga moderno, competitivo, pero también enfocarnos en los problemas reales reportados por los usuarios. Perfecto, y creo que siguiendo con eso un poco más, ¿qué tan difícil fue dejar ir y aceptar que otras personas tienen opiniones y también quieren contribuir a tus proyectos? Creo que al principio, definitivamente cuando comencé, solía pensar que, por supuesto, mi framework es el mejor, y cualquiera que piense lo contrario está equivocado, y debatiré con ellos en Internet, pero, ya sabes, después de unos años, te das cuenta de que la web es muy grande, el ecosistema es enorme, es muy diverso, las personas tienen diferentes opiniones, las personas tienen diferentes preferencias. Algunas personas vienen de un entorno de Java y les gustan las cosas que se parecen a Java. Algunas personas vienen de un entorno de programación funcional y solo quieren tener componentes funcionales, y algunas personas que comienzan con HTML y CSS simples encontrarán Vue más familiar y más amigable para comenzar, ¿verdad? Así que creo que es inútil tratar de convencer a personas que no son tu público objetivo de que estén de acuerdo contigo, y creo que eso es inútil. El objetivo de todos estos frameworks para coexistir es que cada uno encuentre su público objetivo feliz, para que sus usuarios estén en un camino feliz con el framework que elijan, y todos sean más productivos. Creo que ese es el buen resultado que queremos ver, ¿verdad? Así que no se trata de convertir a personas que ni siquiera les gusta tu trabajo para que se conviertan en usuarios. Eso es inútil. Sí. Muy bien. Gracias por eso. Hagamos uno más. Porque es el más votado, ¿cómo ves el futuro de Vue? ¿Tiene web assembly? Desafortunadamente, no hay web assembly. Creo que la gente ha preguntado si permitirías a las personas escribir Rust y ejecutarlo en el navegador. Creo que en general, la escala de rendimiento que hemos visto en todos los experimentos simplemente no justifica la complejidad añadida, especialmente cuando piensas en Rust compilado o en otros lenguajes compilados a web assembly, ya es más lento que los binarios nativos reales y tampoco es realmente comparable al rendimiento nativo real que deseas. Y luego está el costo de comunicación entre web assembly y el DOM porque el DOM siempre estará ahí y siempre será un cuello de botella importante. Y luego, por ejemplo, si ejecutas la diferenciación del virtual DOM en el hilo de web assembly, hay mucha información que necesitarás pasar entre web assembly y el hilo principal de JavaScript, y esa es la realización de que el costo compensa muchas de las ganancias de rendimiento, y ahora te quedas con mucha complejidad adicional en tu configuración de compilación y distribución, pero no realmente ganancias de rendimiento notables para probablemente la mayoría de los casos de uso diario. Hay buenos casos en los que, por ejemplo, quieres hacer codificación de video en el navegador, probablemente deberías aprovechar algo como web assembly, pero usarlo para escribir tu código de componente diario? No creo que sea una buena idea. Muy bien, muchas gracias por responder todas estas preguntas, y gracias a todos, por hacer preguntas. Por favor, sigan haciendo preguntas a lo largo del evento. Esto es genial.