10 Años de OSS Independiente: Una Retrospectiva

Hola a todos. Estoy realmente emocionado de estar aquí. De hecho, esta es mi séptima u octava vez en Ámsterdam. Pero quiero entrar en la charla rápidamente porque me di cuenta muy tarde de que solo tengo 20 minutos y tengo 40 diapositivas o algo así. Voy a intentar ir rápido, de lo contrario no podré terminar a tiempo.

Esta charla es sobre una retrospectiva de diez años en los diez años de trabajo en open source. Sobre mí, soy un desarrollador independiente de open source, y he sido independiente desde 2016, así que eso es un poco más de ocho años, pero mi primera incursión en open source fue lanzando Vue.js allá en 2014. Este año marca diez años de trabajo en open source y construyendo en abierto. Ahora estoy basado en Singapur y trabajo a tiempo completo en Vue, Vite y un montón de otros proyectos de open source relacionados. Antes de dedicarme a tiempo completo, trabajé brevemente en Google, y luego en una start-up 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 él? 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. Bien, genial. Entonces, 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 allí. Pero si tomamos una instantánea breve de Vue hoy, 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 en 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 mil millones de solicitudes mensuales de CDN en JSDeliver. Cada año, miro estos números y me maravillo de la escala a 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. Ninguna expectativa en absoluto.

Incluso cuando decidí que quería empezar a trabajar en ello a tiempo completo. Así que es un viaje bastante increíble. Pero demos un paso atrás y pensemos, hablemos un poco sobre los primeros días. No profundizaré demasiado en las pequeñas historias de cómo comenzó todo, 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 unos cientos de estrellas en GitHub y estaba en la luna por ello. Estaba realmente emocionado. Pero eso fue solo el comienzo, así que la emoción realmente no duró tanto, para ser honesto.

Pero echemos un vistazo a la breve línea de tiempo. El primer lanzamiento, con el nombre Vue.js, fue en realidad en 2013. Era privado. Solo lo puse en NPM pero no le dije a nadie. El primer anuncio público es en febrero de 2014. Alcanzó la versión 1.0 en octubre de 2015. 2.0 en 2016, 3.0 comenzó en septiembre de 2018. Y sublanzamiento, septiembre de 2020. 3.0 finalmente se convirtió en el predeterminado en enero de 2020. Y en diciembre de 2023, finalmente declaramos que Vue 2 llegó al final de su vida útil. Así que esa es una visión muy, muy rápida, ¿verdad? Pero realmente no quiero pasar esta charla hablando de todos los pequeños cambios que ocurrieron con el tiempo sobre Vue. Porque quiero que esta charla sea más sobre el viaje, el sentimiento, ya sabes, el tipo de cómo las cosas han cambiado para mí en el transcurso 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 es febrero de 2014 cuando lancé Vue por primera vez. Y hubo bastantes meses justo después de eso en los que no escribí ningún código en GitHub en absoluto porque estaba bastante agotado, ¿verdad? Así que esto sucede bastante. ¿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 con el tiempo, probablemente experimentes alguna forma de agotamiento, ¿verdad? Porque la expectativa que los usuarios de código abierto ponen en ti, especialmente cuando tienes un proyecto que ha crecido más de lo que esperabas, es tremenda, ¿verdad? Así que me gusta hacer una analogía con este ciclo de adopción de tecnología que muchos de ustedes probablemente han visto. Usualmente cuando sale una nueva tecnología, hay este pico de expectativas infladas. Y luego simplemente cae fuerte en esta fase de desilusión donde dices, esto es una porquería. Y luego necesitas como cruzar ese abismo para poder volver a la pendiente de la iluminación y la meseta de la productividad al final. Así que hago una analogía de eso con la participación en código abierto. Cuando te involucras en código abierto, y esto es personalmente para mí, cuando me involucré por primera vez en código abierto, hay un pico de emoción y producción.

Estaba como, wow, mi proyecto 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 arreglar cada error. Y luego, sabes, a medida que tu base de usuarios comienza a crecer, se revelan más fallos en la cosa que pensabas que era perfecta. Y te das cuenta, está bien, 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é en ello. Oh, tal vez debería 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 es lo mismo para mí. Y ha habido múltiples veces en las que he estado pasando por este tipo de pensamiento si debería seguir trabajando en esto, ¿tiene siquiera sentido? ¿Todavía vale la pena perseguirlo y dedicarle todo el tiempo? Y solo la cantidad de presión que recibes, cada día te despiertas, recibes 20 problemas de personas que encuentran que tu software simplemente no funciona. Eso es difícil, ¿verdad? Así que con el tiempo, he aprendido a ajustar, reajustar. 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 de una vez que entras en esta fase de agotamiento, muchos de ellos simplemente nunca salen de ella. Simplemente se detienen allí, abandonan el proyecto. Y es por eso que vemos todo el cambio de diferentes soluciones que aparecen y desaparecen. ¿Verdad?

Entonces, si puedes superar ese abismo, y encuentras paz contigo mismo, y eres como encuentras un buen equilibrio de entender tu responsabilidad, y el límite de tus capacidades, y trazas una buena línea entre cuánto quieres poner en tus proyectos y cuánto quieres obtener de la vida, ¿verdad?, necesitas encontrar ese equilibrio para poder seguir trabajando en código abierto productivamente. Y eso no es algo fácil de hacer, ¿verdad? Entonces, esto es cuando lancé Vue por primera vez, y hay múltiples otras fases en mi carrera donde simplemente dejé de escribir código por unos meses. Estoy como, estoy harto de esto. No quiero hacerlo más. Pero luego vuelvo. Eventualmente, ¿verdad? Así que incluso hoy, a veces, sabes, como saqué todo el gráfico de todo el camino desde 2014 hasta 2022. Y hay múltiples eventos de la vida, ¿verdad? Los mantenedores de código abierto también tienen todas estas cosas sucediendo en la vida, teniendo bebés, mudándose a nuevos lugares, teniendo COVID. Así que mi punto aquí es 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 pasar por muchos desafíos y encontrar lo que es significativo para nosotros para mantenernos motivados en trabajar en estas cosas. Así que mi esperanza es que cuando estés usando un proyecto de código abierto, no necesariamente de mí, sino de cualquier otra persona que amablemente compartió su trabajo contigo de forma gratuita, pienses en lo que han pasado en el tiempo que no ves, el esfuerzo que han puesto en ello, tal vez los agotamientos que han enfrentado. Y simplemente apreciarlo un poco más. Y pensar en retribuir. Pensar en apoyarlos. Pensar en, ya sabes, contribuir, ayudarlos a solucionar problemas, o donar, patrocinarlos. Hay muchas maneras en las que puedes ayudar. Y para mí personalmente, gran parte de la lucha proviene también de manejar el creciente alcance de los proyectos, ¿verdad? Vue como un framework, comenzó como un script muy simple que puedes incluir en tu etiqueta de script en una página y simplemente funcionará.

Fuera del núcleo de Vue, también tenemos la documentación que tenemos como cientos de páginas de toda esta información detallada, ¿verdad? Y necesita mantenerse actualizada. Tenemos el enrutador oficial, tenemos bibliotecas oficiales de gestión de estado, tenemos la cadena de herramientas de construcción, que de alguna manera terminé construyendo una herramienta de construcción yo mismo porque quería mejorar la cadena de herramientas de Vue. Y luego está el soporte IDE, que está tratando de hacer que todo el typescript y CSS, lenguaje incrustado, funcione bien 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 sincronizado. Cuando hicimos Vue 3, nos tomó dos años poner todas estas cosas al día con Vue 3. Así que, ya sabes, manejar el alcance creciente fue extremadamente desafiante.

Y luego también necesitamos lidiar con muchas decisiones difíciles, ¿verdad? La transición de Vue 2 a Vue 3, si eres un usuario de Vue, probablemente sepas que no fue suave. Se cometieron muchos errores y se aprendieron muchas lecciones. También tuvimos que reinventar 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 antiguas APIs. Tenemos que pasar por largas discusiones en RFCs y debates, tratando de convencer a la gente de que esto es realmente algo bueno que puede ayudarte de ciertas maneras.

Así que, una realización eventual que obtuve de todas estas luchas es que soy solo una persona. No puedo escribir todo el código. No puedo responder a todas tus preguntas. No puedo arreglar 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 esto es tan importante, porque esto es lo que hizo posible Vue. Verás, lucho como una sola persona, pero lo logramos porque no soy solo yo, es todo un equipo, toda una comunidad. Así que, Vue no estaría donde está hoy sin las personas a su alrededor, ¿verdad? Por eso decimos que el código abierto se trata de personas. Así que aquí está mi más profundo agradecimiento a nuestros miembros del equipo, colaboradores, mantenedores de bibliotecas del ecosistema, patrocinadores, organizadores de conferencias y encuentros, socios comunitarios, defensores, todas estas personas, no solo contribuyendo en forma de código, sino simplemente contribuyendo a hacer que la gente se conecte alrededor del proyecto, y ayudándolo a mejorar en todos los aspectos posibles, ¿verdad? Al mismo tiempo, mi rol comenzó a evolucionar de solo escribir código. A veces desearía poder simplemente centrarme en escribir código, pero hoy en día, hay mucho trabajo fuera del código que se trata de mentoría a personas en el ecosistema, ayudando a los miembros del equipo a crecer en roles más grandes. Dirección técnica, simplemente tratando de asegurarme de que todos estos proyectos se muevan de manera cohesiva. Gestión comunitaria, prácticamente tuiteando. Relaciones con patrocinadores. En realidad, tuvimos que hacer el proyecto sostenible, y esa es una parte de Vue de la que estoy bastante orgulloso y luego están las asociaciones comerciales. Hay empresas construyendo sobre Vue, construyendo en el ecosistema de Vue, y quieren colaborar y retribuir a Vue, y así todas estas relaciones que tenemos que manejar simplemente fuera del trabajo.

Es como una gestión de proyectos a tiempo completo fuera de solo escribir código. Algo de lo que estoy realmente orgulloso es que en realidad distribuimos una cantidad muy justa de dinero a Vue y a los contribuyentes de Vue en nuestros ecosistemas. Cada año, en realidad distribuimos más de $270,000 a nuestros contribuyentes en el ecosistema. Además de posiciones completas y patrocinios que nuestros contribuyentes reciben debido a su participación en los proyectos. A veces, ya sabes, algunos contribuyentes, por ejemplo, a Vue o Vue conseguirían un trabajo porque una empresa quiere contratar a un contribuyente principal o quiere que sigan trabajando en estos proyectos de código abierto. Así que se crean oportunidades.

En el frente técnico, solo quiero mencionar algunas cosas. A pesar de ser un framework de diez años, todavía estamos implementando mejoras internas muy significativas. Recientemente tuvimos un analizador reescrito 2x más rápido, tuvimos mejoras de 3.9x en los benchmarks de SSR, y tuvimos un nuevo lanzamiento próximo en 3.5 que reduce el uso de memoria del sistema de reactividad en un 56 por ciento y mejora el manejo de grandes arreglos reactivos hasta diez veces. Así que todavía estamos muy vivos y enviando cambios internos muy significativos. Y luego hay cosas más ambiciosas en marcha como Vapor Mode, esta es una estrategia de compilación inspirada en Solid que toma la misma sintaxis de componentes de Vue y produce algo que es más eficiente. Actualmente, todavía está en progreso, pero casi hemos terminado con los componentes, y la siguiente etapa es realmente tratar de permitir a los usuarios inventar componentes Vapor en las aplicaciones de Vue de hoy. Tenemos una nueva herramienta de desarrollo que está por llegar que simplemente tiene mejor UX, más características, más 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 la fuente de múltiples esfuerzos que beneficiaron a todo el ecosistema JS más allá de solo Vue, ¿verdad? Así que V es el ejemplo principal, y luego está Volar que es el framework subyacente para nuestro soporte IDE pero en realidad ahora también se está utilizando para soportar otros lenguajes incrustados como Astral, o MDX, y JetBrains de hecho está usando Volar para soportar, tratando de usar eso para soportar el servidor de lenguaje Angular también. Así que utilidades entre frameworks como en la sección unjs, si nunca lo has revisado, busca por ello. Tiene muchas cosas buenas que puedes reutilizar. Vienen del equipo de Nux, pero son agnósticas al 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 realmente rápido a la parte de Vite.

Hablemos de Vite. Cómo comenzó, el 20 de abril de 2020, mientras me iba a dormir, simplemente tuve esto, simplemente hizo clic cómo hacer el reemplazo de módulo en caliente sobre un ADBSN. Lo hizo y se convirtió en Vite. Así es como va.

Recientemente cruzamos los 13 millones de descargas semanales. Eso es, ¿cuánto es eso? ¿Más de 15 millones por mes? Tenemos un enorme ecosistema de todas las herramientas que o bien están construidas sobre Vite, o soportan Vite, o aprovechan Vite hasta cierto punto para algunas de sus características. Probablemente veas muchos logotipos familiares aquí. Así que, sí, en perspectiva, probablemente ahora estamos en la mitad de webpacks. Esperamos que esa brecha se reduzca aún más este año.

La filosofía de Vite es que queremos construir una herramienta de construcción que sea ligera y extensible, impulsar la web moderna, tomamos un enfoque pragmático hacia el rendimiento, y queremos apoyar frameworks de nivel superior. Queremos construir un ecosistema colaborativo entre frameworks donde 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.

Así que, si tienes, si echamos un vistazo al panorama de meta-frameworks hoy, entonces, aparte de Next.js, todo lo demás está o en Vite, o moviéndose a Vite. Así que, 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 concentrar su energía en cosas que realmente importan, diferenciaciones que realmente importan, que atienden a diferentes necesidades.

Junto con el lado técnico, Vite ha crecido una comunidad increíblemente asombrosa entre frameworks. Esta es una imagen del panel del equipo de Vite en Vue.js Amsterdam el año pasado, también en Ámsterdam, lo cual es realmente genial. Tenemos contribuyentes de todo el mundo, de diferentes frameworks. Entonces, ¿qué sigue para Vite? Queremos hacer dos cosas. La primera es Vite internamente en la línea de lanzamiento 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. Por otro lado, queremos mejorar Vite desde la base.

Estamos construyendo uno nativo sobre la cadena de herramientas JavaScript nativa llamada OXC. para soportar 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 y tratando de idear mejores abstracciones para que todos estos diferentes frameworks puedan reutilizar los mismos primitivos para soportar mejor sus necesidades de alto nivel. Rowdown es un empaquetador basado en Rust diseñado para Vite. Se creó, el proyecto se inició para abordar algunos problemas en Rowdown, a saber, necesitamos mejor consistencia entre desarrollo y producción, mejor rendimiento de construcción en producción, y necesitamos mejor calidad de los activos de construcción en producción. Para lograr estos objetivos, esencialmente estamos tratando de construir un empaquetador que se apoye en los hombros de gigantes, ¿verdad? Así que queremos la velocidad de VS build. Queremos el ecosistema de plugins de Vite y Rollup.

También queremos el control de activos de producción de Webpack, ¿verdad? Hay cosas buenas sobre estos empaquetadores existentes que queremos juntarlas y adaptarlas a las necesidades de Vite, y eso es Rowdown.

Así que Rowdown ahora mismo está en progreso. El primer hito de empaquetado de bibliotecas está completo, y el siguiente paso en el que estamos trabajando es la compatibilidad de plugins de Vite y Rollup y el control avanzado de fragmentos para la salida orientada a aplicaciones, así que división avanzada de fragmentos y 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á más tarde 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 hechos, algunos están en progreso, por ejemplo, el transformador, actualmente acabamos de terminar las transformaciones de TypeScript, y luego hay formateadores y minificadores que están en progreso. Podrías preguntarte por qué LXC, ¿por qué no construir sobre SWC, o biome? Probablemente escribiremos algo más completo sobre la razón por la que elegimos construir sobre LXC, pero, a muy alto nivel, tiene mejor rendimiento. Está específicamente diseñado para ser utilizado como componentes en herramientas de nivel superior, y es actualmente el analizador más rápido, más eficiente en memoria y más compatible con las especificaciones que es un analizador de JavaScript que está escrito en Rust. Tiene un estilo de código más simple que nos facilita entenderlo. Esa es probablemente la razón principal por la que elegí LXC, porque simplemente no podía entender cómo con algunas de sus soluciones existentes. Nuestra visión final para esto es que el equipo de V, el equipo de Rodan y el equipo de LXC trabajen juntos para crear esta cadena de herramientas unificada agnóstica de tiempo de ejecución para JavaScript y la web. Puedes ver la pila de capas aquí es V como la herramienta de construcción, Rodan es el parachoques de soporte, y LXC como la cadena de herramientas de lenguaje de bajo nivel. El significado, el valor de una cadena de herramientas unificada es que ahora podemos tener un formato AST consistente que maneja todo.

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

Estas cosas no necesariamente tienen que ser construidas por nosotros. Podrían ser construidas por ti sobre la pila que proporcionamos, así que una interoperabilidad eficiente entre plugins de Rust y JS, instrumentación de código, 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 realmente hacer estas cosas avanzadas. De lo contrario, nos estamos enfocando en hacer que nuestras construcciones sean lo suficientemente rápidas para ahorrar minutos de CI, ¿verdad? Únete a nosotros si te apasiona el futuro de las herramientas de JS, revisa estos proyectos en GitHub, y damos la bienvenida a cualquier forma de contribución e involucramiento.

Gracias. APLAUSOS. Hemos recibido algunas de sus preguntas. Aún pueden enviar todas sus preguntas a Slido, por favor. Hemos recibido bastantes, así que espero que estén listos. Primero, la gente quiere saber cómo te ganas la vida como desarrollador de código abierto. Mencionaste un poco sobre los patrocinios, pero ¿cómo lo hiciste en los primeros días? Principalmente son patrocinios. En los primeros días, había un amigo que era CTO en una empresa llamada Strikingly, y son una gran tienda de Ruby y han estado involucrados en código abierto durante mucho tiempo. Cuando el CTO era mi amigo, y cuando escuchó sobre mi plan de hacer más código abierto, él decidió que la empresa pondría su fondo de apoyo de código abierto para apoyarme durante seis meses, así que eso realmente ayudó en los primeros días, pero luego comencé a obtener, creo, cuando decidí hacerlo a tiempo completo, tenía alrededor de $1,500 al mes de Patreon. Y, afortunadamente, solo 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 pago para Vue, y luego colaboramos con algunas empresas que están construyendo productos comerciales sobre Vue, así que hay diferentes fuentes combinadas de estos. Múltiples fuentes.

Genial, gracias por eso. La siguiente pregunta más valorada fue, ¿dónde puedo conseguir esta increíble sudadera que estás usando? ¿Esta? Desafortunadamente, fue hecha en un lote pequeño solo para los miembros del equipo, pero si la gente la quiere podemos tal vez ... Contribuir un poco más y tal vez ... Probablemente la haremos, sí. Otra pregunta importante. Al principio, ¿cómo te aseguraste de que pudieras crear conciencia sobre tus proyectos de código abierto? Tuitear mucho. ¡Tuitear mucho! No tuiteo tanto como lo hacía en los primeros días, pero creo que cuando recién comencé con Vue, simplemente me metía en cada discusión de Hacker News o discusión de Reddit sobre cosas de front end e intentaba hacerme ver, pero ya no hago eso, pero en los primeros días probablemente esa era la forma de menor costo de hacerlo. Bien, gracias. Luego, recientemente hemos visto actores malintencionados incrustándose en la comunidad de código abierto para entregar malware. ¿Cuál es tu opinión sobre este problema? Lo siento, ¿cuál es la pregunta? Para entregar malware. Creo que este es definitivamente un problema preocupante. Hay muchas cosas en el código abierto que se construyen sobre la buena voluntad, y simplemente asumimos que las personas son amables, por lo que eso abre brechas para los actores malintencionados. Es desafortunado 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 luego corromperán la confianza que hemos construido a lo largo del ecosistema. Es triste, pero creo que, ya que eso ya ha sucedido, las personas deben ser más vigilantes. De hecho, hemos recibido acercamientos de la Fundación JS sobre algunas cosas relacionadas con Vue en el pasado también. Creo que, como mantenedores, solo tenemos que ser más vigilantes, y como usuarios, también pueden ayudar reportando cualquier cosa que consideren sospechosa.

Gracias. Definitivamente una preocupación. Veamos, ¿cuál? Bien, hagamos este. ¿No falta la prueba en tu visión? No incluí VTest en el gráfico, y me disculpo con Vladimir, quien es el mantenedor principal de VTest. Pero VTest es una pieza muy importante de la cadena de herramientas también, y podrá aprovechar las mismas partes subyacentes que estamos construyendo para VT, porque VTest está construido sobre VT. Sí. Muy bien, perfecto, así que un saludo para ellos.

Veamos. Con una comunidad en crecimiento, patrocinadores y otras partes interesadas, ¿cómo te alineas en nuevas ideas y determinas la dirección hacia la que se dirige Vue? Nos enfocamos principalmente en las necesidades de la comunidad. Lo que pasa con los patrocinios de Vue es que no tenemos estos grandes patrocinadores únicos que podrían dictar la dirección técnica de Vue. La fuente de patrocinios que recibimos está muy distribuida, por lo que ningún patrocinador individual realmente tiene voz sobre lo que deberíamos hacer a continuación. Es prácticamente sin ataduras, y somos muy explícitos al respecto, así que si patrocinas el proyecto Vue, realmente no haremos nada especial solo para tus necesidades.

Queremos enfocarnos principalmente en lo que los usuarios necesitan, y también tratar de evaluar cuál es la tendencia general de hacia dónde se mueve el ecosistema, por lo que queremos que Vue se mantenga moderno, competitivo, pero también enfocarnos en los problemas reales que reportan los usuarios. Perfecto, y creo que siguiendo un poco con eso también es, ¿qué tan difícil fue dejar ir y aceptar que otras personas tienen opiniones y también quieren contribuir a tus proyectos? Creo que en los primeros días, definitivamente cuando comencé, tiendes a pensar, por supuesto mi framework es el mejor, y cualquiera que piense que no es así 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, la gente tiene diferentes opiniones, la gente tiene diferentes preferencias. Algunas personas vienen de un fondo de Java y simplemente les gustan las cosas que se parecen a Java. Algunas personas vienen de un fondo de programación funcional, y simplemente quieren tener componentes funcionales, y algunas personas que comienzan con HTML CSS simple encontrarán Vue más familiar y más amigable para entrar, ¿verdad? Así que creo que es realmente inútil tratar de convencer a personas que simplemente no son tu audiencia objetivo para que estén de acuerdo contigo, y creo que eso es inútil. El objetivo para que todos estos frameworks coexistan es que cada uno de ellos encuentre su audiencia feliz, para que sus usuarios estén en un camino feliz con su framework elegido, 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 material 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? ¿Tienes algún web assembly en mente? Desafortunadamente, no hay web assembly. Creo que la gente ha preguntado si permitirías que la gente escriba en Rust y lo deje correr en el navegador.

Creo que en general, la escala de rendimiento que hemos visto de todos los experimentos simplemente no justifica la complejidad añadida, especialmente cuando piensas en Rust compilado a 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 a nivel nativo real que querrías. Y luego está la sobrecarga de comunicarse entre web assembly y el DOM porque el DOM siempre estará ahí y siempre será un cuello de botella importante.