00:00:00- Así que la versión pública final de V+ será probablemente,
00:00:03se sentirá como algo divertido.
00:00:06- Este es Evan Yu.
00:00:07- Evan Yu.
00:00:09- Evan Yu.
00:00:10- ¡Evan Yu!
00:00:10- Creé Vue, creé Vite.
00:00:14Ahora dirijo una empresa llamada Voice Zero.
00:00:16- ¿En qué se diferencia Vite de Vite+?
00:00:19- Tu experiencia de desarrollo será exactamente como
00:00:21la de Vite hoy en día.
00:00:22Pero si quieres ir más allá,
00:00:24estará ahí para acompañarte en todo el camino.
00:00:26- ¿Cómo están usando la IA tú y tu equipo?
00:00:28- Empezamos a hacer experimentos locos
00:00:30como portar el compilador de Angular a Rust.
00:00:32- ¿Qué opinas de los React Server Components?
00:00:34- He sido escéptico desde el primer día.
00:00:36- Normalmente, cuando presento un podcast,
00:00:39pido a los invitados que se presenten ellos mismos.
00:00:40Pero creo que si alguien está viendo esto
00:00:42y no sabe quién eres, me sorprendería muchísimo.
00:00:44Creo que eres alguien muy conocido.
00:00:46Pero todo el mundo debería saber,
00:00:48o la mayoría debería saber quién eres.
00:00:49- Al menos han oído hablar de Vite o Vue, sin duda.
00:00:53- Sí, yo hice Vue e hice Vite.
00:00:57Ahora dirijo una empresa llamada Voice Zero
00:00:59donde trabajamos en aún más proyectos de código abierto.
00:01:03Están Rolldown, Vitest, OXC.
00:01:07Y bueno, Vue y Vite son probablemente más populares,
00:01:11pero algunas de las cosas en las que trabajamos en Voice Zero
00:01:14también son geniales.
00:01:15Porque Rolldown es un empaquetador basado en Rust.
00:01:18OXC es una cadena de herramientas completa en Rust que incluye
00:01:22desde el analizador hasta el resolutor, transformador,
00:01:25minificador, etcétera.
00:01:28Y sobre OXC, tenemos OXLint y OXFormat,
00:01:32que es un linter compatible con ESLint
00:01:35y un formateador compatible con Prettier.
00:01:37Y hay más cosas en las que seguimos trabajando, pero sí.
00:01:41Así que por ahora queremos hablar principalmente del código abierto.
00:01:45- Claro.
00:01:45Dado que trabajas en tantas cosas,
00:01:47¿cómo divides tu tiempo?
00:01:50- Bueno, yo personalmente no escribo código
00:01:52para todos estos proyectos.
00:01:53De hecho, escribo mucho menos código hoy en día
00:01:56desde que fundé la empresa.
00:01:58En la empresa hay muchos ingenieros
00:02:01que son mucho mejores que yo en Rust
00:02:03y ahora están todos obsesionados con la IA.
00:02:05Así que es como mitad ellos y mitad Cursor o Codex
00:02:10ejecutando un montón de código en Rust.
00:02:12Y yo tengo que decidir qué hacer
00:02:17en muchas de las decisiones de experiencia de desarrollo (DX),
00:02:22decidir en qué queremos enfocarnos a continuación.
00:02:25Y obviamente también están los productos,
00:02:28como pensar en cómo convertir esto en un producto
00:02:31que genere ingresos,
00:02:32que es algo en lo que todavía estamos trabajando.
00:02:34Sí, son todas las cosas que conlleva
00:02:39dirigir una empresa hoy en día.
00:02:41- ¿De dónde surgen este tipo de ideas
00:02:43para los nuevos proyectos de código abierto?
00:02:45¿Vienen principalmente de necesidades internas
00:02:48de las que te das cuenta que podrían ayudar
00:02:49a resolver problemas de otras personas también?
00:02:53- En realidad, todo empieza con Vite, ¿sabes?
00:02:56Cuando creé Vite, solo estaba experimentando.
00:03:01Empezó como un prototipo
00:03:03y luego pensé: necesitamos un empaquetador.
00:03:07Empezamos con este servidor de desarrollo
00:03:10ESM nativo y totalmente sin empaquetar, ¿no?
00:03:13Esa idea funcionó genial para código simple,
00:03:16pero luego empezamos a meter dependencias grandes
00:03:18y nos dimos cuenta de que esto no iba a escalar bien
00:03:21si cargabas todas las dependencias sin empaquetar.
00:03:24Por ejemplo, si cargas algo como lodash-es,
00:03:26que son unos 700 archivos.
00:03:28Así que dijimos: vale,
00:03:30necesitamos algo para empaquetar las dependencias.
00:03:34En ese entonces estaban Rollup, esbuild y Webpack.
00:03:41Webpack no genera ESM, así que no podíamos usarlo.
00:03:47Miré Rollup y Rollup es bastante lento.
00:03:50Es muy lento comparado con esbuild, ¿verdad?
00:03:53Es más rápido que Webpack, pero lento comparado con esbuild.
00:03:56Así que usamos esbuild para pre-empaquetar las dependencias,
00:03:59lo cual es increíblemente rápido.
00:04:00Luego servimos todo el código fuente como ESM sin empaquetar
00:04:02y eso funcionó de maravilla.
00:04:04Pero cuando llegó el momento de producción,
00:04:06originalmente pensamos: vale,
00:04:08usemos simplemente esbuild para empaquetarlo todo
00:04:10para producción.
00:04:11Y ahí notamos que esbuild tiene un control muy limitado
00:04:14sobre cómo se dividen los fragmentos (chunks).
00:04:17Algo muy común si construyes aplicaciones grandes
00:04:19porque quieres poder controlar,
00:04:21por ejemplo, que estas dependencias de librería
00:04:24vayan en un fragmento de proveedor para que se cacheen mejor.
00:04:26No quiero que ese fragmento cambie nunca.
00:04:28Para que tenga un hash consistente.
00:04:32Así, aunque cambie mi código fuente,
00:04:33el hash de ese fragmento debería seguir siendo el mismo.
00:04:35De modo que los usuarios siempre lo tengan en caché
00:04:38cuando visiten el sitio web.
00:04:39Hay muchas optimizaciones de este tipo
00:04:41que esbuild simplemente no permite.
00:04:44Tiene un comportamiento por defecto para dividir fragmentos
00:04:47y ya está.
00:04:49Su sistema de complementos también es menos flexible." : "
00:04:53Si un complemento decide
00:04:56que va a procesar un archivo, se acabó.
00:04:59Ningún otro complemento puede tocarlo después.
00:05:02En cambio, habíamos usado mucho Rollup,
00:05:05conocíamos bien su sistema de complementos.
00:05:08Así que lo que terminamos haciendo fue: vale,
00:05:10usaremos Rollup para el empaquetado de producción,
00:05:13pero esbuild para el pre-empaquetado de desarrollo.
00:05:15Era como si cada herramienta hiciera
00:05:20lo que mejor sabía hacer en esa combinación.
00:05:23De hecho, incluso hoy Vite 6 todavía se basa
00:05:26en esta combinación.
00:05:27Y eso funciona bastante bien para mucha gente, ¿verdad?
00:05:31Pero obviamente hay problemas porque esbuild
00:05:35está escrito en Go y Rollup en JavaScript,
00:05:40lo que significa que la compilación de producción
00:05:41sigue siendo bastante lenta comparada con,
00:05:43empaquetadores basados totalmente en Rust como Rspack.
00:05:47Y para el servidor de desarrollo, como esbuild
00:05:52y Rollup tienen sistemas de complementos distintos,
00:05:55no podemos aplicar los mismos complementos
00:05:57a las dependencias durante el desarrollo,
00:05:59pero sí se aplican a las dependencias
00:06:01durante la compilación de producción.
00:06:03Y luego hay problemas sutiles de interoperabilidad.
00:06:07Como cuando tienes un grafo mixto de ESM y CommonJS,
00:06:10esbuild y Rollup lo manejan de forma ligeramente diferente.
00:06:13Hay diferencias en el comportamiento del tree shaking.
00:06:15Aunque ambos hacen un buen trabajo,
00:06:18nosotros también parcheamos todas esas inconsistencias
00:06:22y demás.
00:06:22Hicimos que las cosas funcionaran, pero en el fondo sabíamos:
00:06:25son dos cosas distintas que de alguna manera
00:06:29hemos remendado juntas, ¿verdad?
00:06:31Así que para, A: hacer la compilación de producción más rápida
00:06:35y B: hacer que el desarrollo y la producción sean más consistentes.
00:06:40Lo mejor es tener un solo empaquetador
00:06:42que haga ambas cosas, ¿no?
00:06:44Pero el problema es que esbuild es rápido,
00:06:47pero no es muy extensible.
00:06:50La base de código es... es todo Go.
00:06:54Evan Wallace, que es el autor de esbuild,
00:06:57obviamente es un científico loco, un genio,
00:06:59e hizo esbuild extremadamente rápido,
00:07:02pero no es especialmente apto para que otros
00:07:05lo extiendan o hagan un fork
00:07:07o mantengan una capa encima.
00:07:10No es fácil hacer eso.
00:07:12Además, es muy difícil convencer a Evan Wallace
00:07:15de que haga cosas que no quiere hacer
00:07:17porque no necesita el dinero y no le importa.
00:07:21Entonces pensamos: ¿y qué pasa con Rollup?
00:07:27¿Podemos hacer que Rollup sea más rápido?
00:07:28Hubo algunos experimentos,
00:07:30pero fundamentalmente Rollup está escrito en JavaScript,
00:07:33y JavaScript es de un solo hilo.
00:07:36Probamos cosas como hilos de trabajo, complementos en workers.
00:07:41El mantenedor de Rollup intentó meter un analizador en Rust," : "
00:07:47el analizador de SWC dentro de Rollup.
00:07:50Eso no mejoró el rendimiento de forma notable
00:07:54porque cuando tienes un sistema mixto de Rust y JS,
00:07:57siempre existe el coste de transferencia de estado.
00:07:59Estás pasando grandes trozos de cadenas de texto de un lado a otro.
00:08:02Si alguna vez necesitas clonar la memoria, se vuelve aún más lento.
00:08:05Resulta que la ganancia bruta de rendimiento de Rust,
00:08:09cuando solo tienes el analizador en Rust
00:08:12pero todo lo demás está en JavaScript,
00:08:13se ve contrarrestada por el coste de transferencia de datos.
00:08:16Así que terminó teniendo casi el mismo rendimiento.
00:08:19Concluimos que acelerar drásticamente Rollup
00:08:23no es técnicamente posible.
00:08:26Así que la única opción es reescribirlo,
00:08:30reescribir un empaquetador diseñado
00:08:33esencialmente para Vite, y que sea veloz, ¿verdad?
00:08:37Así empezó la búsqueda de pensar: vale,
00:08:40¿qué deberíamos hacer?
00:08:42Decidimos que, básicamente,
00:08:44la idea original era portar Rollup a Rust.
00:08:48No un fork, sino portarlo.
00:08:49Queríamos llevar Rollup a Rust.
00:08:51Por eso el proyecto se llama Rolldown.
00:08:53Como Roll-up (enrollar), Roll-down (desenrollar).
00:08:54Empezó como un traslado directo,
00:08:58pero nos dimos cuenta de que el código escrito en JavaScript
00:09:02no es fácil de portar directamente a Rust
00:09:06porque JavaScript es muy dinámico.
00:09:08Es un lenguaje dinámico, ¿verdad?
00:09:11Incluso si usas TypeScript,
00:09:13puedes mutar las cosas tanto como quieras.
00:09:16Y Rust es muy estricto con la memoria.
00:09:19Es estricto con los ciclos de vida, la propiedad, etc.
00:09:23Así que tienes que estructurar las cosas de forma muy distinta
00:09:25a como lo haces en JavaScript.
00:09:27Por lo que nunca será sencillo
00:09:29simplemente portar código JavaScript existente
00:09:31a un lenguaje como Rust.
00:09:33Es prácticamente una reescritura.
00:09:35Y al final, de hecho,
00:09:37también queríamos lo mejor de ambos mundos.
00:09:42Rollup en sí tiene un núcleo bastante ligero.
00:09:45Si quieres convertir Rollup
00:09:47en algo listo para producción,
00:09:49es algo bastante complejo
00:09:51porque necesitas el complemento de resolución de Node,
00:09:54ya que resolver módulos de Node no es una función nativa.
00:09:56Tienes que añadirlo como complemento.
00:09:58Necesitas el complemento de CommonJS para soportar esos módulos
00:10:03porque el núcleo de Rollup es solo para ESM.
00:10:06Y luego tienes que añadir un montón de complementos
00:10:10como define, inject, replace.
00:10:14Muchas de estas funciones vienen integradas en esbuild,
00:10:17pero requieren complementos en Rollup.
00:10:20Y lo peor es que la mayoría de estos complementos en JavaScript
00:10:25se implementan analizando de nuevo todo el árbol sintáctico (AST).
00:10:30Cada complemento tiene que volver a
00:10:33tomar el código del complemento anterior,
00:10:36analizarlo, transformarlo,
00:10:38generar nuevo código y nuevos mapas de fuente.
00:10:41Y luego tienes que fusionar todos esos mapas de fuente.
00:10:43Por eso los sistemas de compilación en JS se vuelven lentos
00:10:46porque cada complemento repite esto una y otra vez.
00:10:49Así que dijimos: vale, necesitamos que esto esté integrado.
00:10:53Acabamos teniendo el alcance de esbuild,
00:10:56pero con la estructura de API de Rollup; eso es Rolldown.
00:11:01Pero para construir Rolldown, pensamos:
00:11:03necesitamos un analizador, todas las transformaciones...
00:11:07Necesitamos un minificador y un resolutor.
00:11:10¿Cómo conseguimos eso?
00:11:12Y ahí es donde entra OXC.
00:11:14OXC es el conjunto de herramientas de lenguaje de bajo nivel
00:11:17que te proporciona todo eso.
00:11:20El autor de OXC trabajaba en ByteDance en ese entonces
00:11:25y yo le había echado el ojo al proyecto hacía tiempo.
00:11:28Boshen es el autor de OXC
00:11:30y ahora es nuestro vicepresidente de ingeniería en Voice Zero.
00:11:33No se unió a la empresa en cuanto la fundé.
00:11:36Intenté que se uniera, pero él estaba como:
00:11:38no sé, bueno...
00:11:39Pero empezamos a construir Rolldown sobre OXC de todas formas.
00:11:44Pensamos: esto es material del bueno.
00:11:45Yo creía en esto porque,
00:11:47bueno, analicé todas las opciones disponibles.
00:11:51Quería algo que fuera modular.
00:11:54Algo donde cada parte de la cadena de herramientas" : "
00:11:57se pudiera usar individualmente como librerías (crates).
00:12:00Y también quería que fuera extremadamente rápido.
00:12:03Comparamos OXC con SWC.
00:12:06El analizador de OXC es como tres veces más rápido
00:12:09que el de SWC, estando ambos escritos en Rust,
00:12:12debido a una serie de decisiones de diseño
00:12:15y detalles técnicos de bajo nivel
00:12:18que llevaron a esta diferencia de rendimiento.
00:12:20Lo principal es que Boshen ha estado obsesionado
00:12:24con el rendimiento del análisis y el enlazado
00:12:27durante la mayor parte del tiempo antes de unirse.
00:12:30Por ejemplo,
00:12:32OXC utiliza algo llamado asignador de arena (arena allocator),
00:12:34que pone toda la memoria para el AST
00:12:39en un bloque de memoria consecutivo.
00:12:41Simplemente reserva un gran bloque
00:12:43y coloca el AST directamente ahí.
00:12:45Así se tarda mucho menos en liberar la memoria.
00:12:50Esto también permite cosas interesantes
00:12:53que habilitan complementos de JS rápidos en OXLint,
00:12:57porque esa memoria consistente nos permite
00:12:59pasar todo el bloque de memoria a JavaScript
00:13:01sin clonarlo, y luego deserializarlo en el lado de JS.
00:13:05Hay muchos beneficios,
00:13:06pero en aquel entonces, al ver el proyecto,
00:13:10quedé realmente impresionado,
00:13:10decidimos construir Rolldown sobre él
00:13:13y finalmente convencimos a Boshen de unirse.
00:13:16Ahora el alcance de la empresa es básicamente
00:13:21tener este stack vertical en Rust
00:13:24que empieza desde el analizador.
00:13:26Cubre todo hasta el empaquetado para Vite,
00:13:29y luego tenemos Linter, Formateador, TestRunner...
00:13:33Tenemos una cadena de herramientas completa.
00:13:34Y lo siguiente que vamos a hacer,
00:13:37en lo que ya llevamos tiempo trabajando,
00:13:40es unir todas estas piezas en un paquete coherente
00:13:43para que no tengas que instalar cinco cosas separadas
00:13:47solo para que la aplicación básica funcione, ¿verdad?
00:13:50Tampoco necesitas tener
00:13:51seis o siete archivos de configuración distintos.
00:13:55Los ponemos todos en un solo archivo,
00:13:57y garantizamos que funcionen juntos
00:13:59porque se basan en el mismo analizador," : "
00:14:02el mismo flujo de transformación y el mismo resolutor.
00:14:05Así no habrá sorpresas.
00:14:07Por ejemplo, si usas Webpack y Jest,
00:14:10tienes que configurar la lógica de resolución por separado
00:14:14porque simplemente no usan lo mismo.
00:14:16Así que la visión es realmente esa:
00:14:19construir un stack vertical
00:14:22que funcione de forma consistente en todas partes.
00:14:25Hacer que la experiencia de desarrollo sea lo más sencilla
00:14:29y rápida posible, ¿no?
00:14:30El rendimiento es un factor clave.
00:14:32Lo doy por sentado,
00:14:34pero probablemente habréis visto tuits sobre cómo Rolldown
00:14:39es unas 20 veces más rápido que Rollup.
00:14:43OXLint es de 50 a 100 veces más rápido que ESLint.
00:14:47OXFormat es de 30 a 40 veces más rápido que Prettier.
00:14:51Nuestro objetivo es que sea tan compatible
00:14:57que puedas migrar sin grandes refactorizaciones,
00:15:00obteniendo estos enormes incrementos de rendimiento.
00:15:04Y ahora tus pruebas, tus revisiones de código
00:15:08y todo lo demás será mucho más fluido.
00:15:12Y eso permitiría a la gente
00:15:15crear más aplicaciones en menos tiempo.
00:15:17- You know, I love how quickly that sort of escalates
00:15:20de: "necesitamos esta herramienta de construcción para Vue" a:
00:15:22"bueno, ahora quiero mejorar esta otra pieza".
00:15:24"Y ahora esta otra parte".
00:15:25Como dices, realmente controláis
00:15:27todo el stack vertical.
00:15:29Es muy impresionante y va muy rápido.
00:15:32Les decía a los chicos antes de empezar
00:15:33que en uno de mis antiguos trabajos,
00:15:35empezamos en un proyecto heredado (legacy)
00:15:37que usaba Webpack y tardaba como 50 minutos en compilar.
00:15:40No tenía idea de qué pasaba,
00:15:42pero lo primero que les dije fue:
00:15:43tenemos que cambiar esto a Vite inmediatamente.
00:15:46Porque para cambiar un poco de CSS,
00:15:47tenías que esperar como dos minutos
00:15:49a que se recompilara todo.
00:15:49Y yo pensaba: esto no está bien.
00:15:52Necesitamos recarga en caliente de módulos (HMR).
00:15:54Al guardar el archivo, el cambio debería verse al instante.
00:15:57Vite ayudó muchísimo con eso.
00:15:59Y creo que el progreso y el ritmo
00:16:02que ha tomado Vite es super impresionante.
00:16:05He visto que tiene como 200 millones de descargas en NPM
00:16:07al mes o alguna locura así.
00:16:09Es—
00:16:10- Sí, hace poco superamos los 50 millones semanales.
00:16:13- Eso es una locura.
00:16:15- Estaba pensando en esos 50 millones.
00:16:19Probablemente hay un poco de inflación
00:16:21por todas esas aplicaciones creadas por IA.
00:16:23Que son solo apps temporales de usar y tirar.
00:16:26Aun así, demuestra que mucha gente,
00:16:29o probablemente muchos agentes de IA, lo están usando.
00:16:33- Iba a decir que el equipo de ingeniería
00:16:34de Betaslack son grandes fans de Vite.
00:16:36Usan Rails en el backend con Vue en el frontend.
00:16:40Tienen algunas preguntas que iré haciendo
00:16:42a lo largo del podcast según surjan.
00:16:46Pero mencionaste algo sobre el empaquetado,
00:16:48y una de sus preguntas era:
00:16:49como ellos usan "import maps" en Rails,
00:16:52¿dónde ves el futuro del empaquetado?
00:16:54Porque no hace falta empaquetar mucho
00:16:56si usas "import maps".
00:16:57Así que, ¿hacia dónde crees que va esto?
00:17:00- De hecho, tengo una página dedicada en
00:17:02la documentación de Rolldown,
00:17:04donde el título de la sección es:
00:17:07¿Por qué seguimos necesitando empaquetadores?
00:17:10- ¿Te lo han preguntado mucho, por casualidad?
00:17:13- Sí, además DHH es muy vocal
00:17:16sobre el "no bundling, no build".
00:17:18Así que hay que prestar atención a eso.
00:17:20Y bueno, los "import maps" funcionan hasta cierto punto,
00:17:24pero no empaquetar es un concepto
00:17:29que solo sirve hasta cierta escala.
00:17:35Si tu aplicación tiene menos de mil módulos,
00:17:39probablemente todo el grafo de módulos cargue
00:17:41en un par de cientos de milisegundos,
00:17:43y eso es totalmente aceptable.
00:17:45Y si sabes que trabajas bajo esa restricción,
00:17:48es genial, la verdad.
00:17:50Carga solo lo necesario por defecto,
00:17:53lo que significa que si tienes una aplicación grande
00:17:56y cada página está aislada,
00:17:58tienes este sub-grafo de módulos
00:18:00y funciona bastante bien.
00:18:01Por eso Vite funciona bien en desarrollo.
00:18:05Pero no es la panacea
00:18:07porque lo que notamos con el propio Vite,
00:18:09y la razón por la que trabajamos en algo
00:18:12llamado modo de empaquetado completo en Rolldown,
00:18:15es que el modo sin empaquetar tiene sus límites,
00:18:18y el cuello de botella es realmente el número de módulos.
00:18:21Hay muchísimas aplicaciones en las que
00:18:25se cargan miles y miles de módulos
00:18:29durante el desarrollo, ¿sabes?
00:18:32Podrías estar cargando 3000 módulos
00:18:33y eso colapsaría el navegador.
00:18:36El cuello de botella está en la red,
00:18:38porque con ESM nativo,
00:18:40envías una petición HTTP por cada módulo que traes.
00:18:44Y si tienes un grafo de importación profundo,
00:18:46tiene que traer el primer módulo,
00:18:49darse cuenta de que necesita otros más
00:18:52y traer esos.
00:18:53Y luego los siguientes...
00:18:54tienes que recorrer todo el grafo paso a paso
00:18:57antes de poder evaluar el primer módulo de importación.
00:19:00Si tienes una mala conexión,
00:19:04puedes tener múltiples viajes de ida y vuelta en la red
00:19:06antes de poder renderizar lo más mínimo.
00:19:09Y si tienes miles de módulos,
00:19:13la red amplifica el problema.
00:19:17Incluso en desarrollo local, con el servidor de Vite,
00:19:20si tienes más de 3000 módulos,
00:19:23tardará uno o dos segundos en cargar localmente.
00:19:27Imagina lo que eso haría en producción
00:19:29a través de internet, ¿verdad?
00:19:31Realmente no quieres eso, porque si lo empaquetas,
00:19:35probablemente tardará unos 100 milisegundos.
00:19:38Es una optimización gratuita
00:19:40que siempre deberías aprovechar
00:19:41cuando pasas de cierto umbral.
00:19:45Creo que el principal argumento para evitar el empaquetado
00:19:47y las herramientas de construcción es que la gente se hartó
00:19:52de configurar las herramientas.
00:19:55Seguramente se toparon con errores,
00:19:56o problemas de configuración que no sabían resolver.
00:20:01Y como Webpack lo hizo tan complicado,
00:20:04todo el mundo empezó a pensar que,
00:20:06cuando se trata de configurar el empaquetador,
00:20:08"no es trabajo para mí, no quiero hacerlo".
00:20:11Creo que la gente tiene cierto resentimiento
00:20:14cuando oyen hablar de la etapa de construcción,
00:20:16y piensan: "es malo, quiero evitarlo".
00:20:19En cierto modo, lo que queremos con este
00:20:22conjunto de herramientas es,
00:20:24hacer que estos conceptos sean muy sencillos.
00:20:28Nunca será sencillo para apps grandes y complejas,
00:20:32¿verdad?
00:20:34Pero queremos que sea lo bastante simple para una app nueva
00:20:37para que no tengas que comerte mucho la cabeza
00:20:41si tu aplicación no es super complicada.
00:20:45Deberías poder decir: vale, arranco esta app,
00:20:48usa Vite y sé que todo irá genial.
00:20:50De hecho, sé que hay una gema de la comunidad
00:20:55llamada ruby-vite o vite-rails
00:20:59que hace que Vite funcione muy bien en Rails.
00:21:05Creo que el entorno sin construcción tiene sus ventajas.
00:21:12Te hace sentir cómodo porque sabes que
00:21:14evitas un montón de dependencias
00:21:17e incertidumbres que podrían romper las cosas.
00:21:20Creo que también hay gente que ha
00:21:23perdido la confianza en los sistemas de construcción:
00:21:26"siempre habrá algo que falle".
00:21:29"La compilación se romperá al actualizar una dependencia"." : "
00:21:33Y el no-build lo evita, lo cual es tentador.
00:21:36Pero al final del día,
00:21:37si la tecnología es lo bastante buena y estable,
00:21:41siempre quieres la mejor experiencia para tus usuarios,
00:21:45y no empaquetar nada significa quedarte
00:21:48en una restricción de tamaño de aplicación muy limitada.
00:21:52Tienes que preocuparte por la optimización,
00:21:54porque tienes que pensar:
00:21:57¿estoy importando demasiado por accidente
00:22:01en la página que estoy visitando?
00:22:03¿Cómo gestiono la caché de mis módulos de forma inteligente?
00:22:06Creo que incluso en Rails sin empaquetar,
00:22:08necesitas algún paso de preprocesado
00:22:11para sellar los módulos y que se cacheen bien.
00:22:15Inevitablemente, hay que prestar atención
00:22:18a la optimización para que las cosas funcionen.
00:22:21Diría que funciona para un número
00:22:24considerable de casos, pero no es—
00:22:29no va a cubrir todos los casos.
00:22:31Hay gente que construye aplicaciones muy grandes,
00:22:35con muchísimas funcionalidades.
00:22:37No puedes obligarles a no empaquetar nada
00:22:39y encerrarles en esta situación de
00:22:42rendimiento imposible de optimizar.
00:22:45- Para los que no estén familiarizados con ello,
00:22:49¿en qué se diferencia Vite de Vite+?
00:22:54¿Y qué saca la gente de eso?
00:22:57- En cuanto a Vite+, estamos pasando por un
00:23:02pequeño cambio de rumbo sobre lo que debería ser ahora mismo.
00:23:06La idea es que, si te acabas de meter
00:23:11en el desarrollo con JavaScript desde cero,
00:23:14si eres nuevo en esto,
00:23:17tienes un ordenador nuevo sin nada instalado..." : "
00:23:21¿Cómo pasas de cero a una aplicación funcional
00:23:25con HMR, mejores prácticas,
00:23:28linter, formato y tests ya resueltos para ti?
00:23:33Ahora mismo hay mucho que aprender.
00:23:36Lo primero es:
00:23:38¿Qué es Node.js?
00:23:39¿Cómo lo instalo?
00:23:40¿Qué es un gestor de versiones de Node?
00:23:42¿Qué gestor de paquetes debería usar?
00:23:44¿Qué herramienta de construcción?
00:23:45¿Qué linter?
00:23:47Tienes que responder a todas estas preguntas.
00:23:49Queremos eliminar todas esas dudas.
00:23:50Te damos este punto de partida de opinión marcada
00:23:52y es como,
00:23:54ni siquiera necesitas instalar Node.js.
00:23:57Estamos experimentando con esta nueva forma
00:23:59de trabajar con Vite+: es como un curl," : "
00:24:03un `curl -fsSL https://vplus.dev/install | bash`.
00:24:08Y luego `vp new` para un proyecto nuevo,
00:24:15luego `vp dev` y ya tienes
00:24:17todo el ecosistema configurado.
00:24:21Tienes el linter, el formateador,
00:24:25el gestor de tests y el empaquetador; también puedes usarlo
00:24:28para montar un monorepo.
00:24:31Tiene empaquetado de librerías.
00:24:32Planeamos añadir funciones como lint-staged
00:24:39o gestión de registros de cambios (changelogs).
00:24:41Si tienes un gran monorepo de librerías,
00:24:44está algo llamado `vp run`
00:24:49que es un ejecutor similar a `pnpm run`,
00:24:52pero un poco más sofisticado,
00:24:57tipo Nx, que puede determinar
00:24:59el orden correcto para ejecutar tus tareas
00:25:03y cachearlas de forma inteligente.
00:25:04Aunque esto es opcional.
00:25:07Es todo un conjunto de cosas que,
00:25:11si no necesitas lo adicional,
00:25:13puedes tratarlo como el Vite básico, ¿no?
00:25:17Tu experiencia de desarrollo será exactamente
00:25:18como la de Vite hoy en día.
00:25:20Pero si quieres ir más allá,
00:25:24escalar hasta un monorepo
00:25:27listo para producción empresarial, te acompaña en todo.
00:25:31Y además, como está construido sobre
00:25:33tecnologías probadas
00:25:35que la gente ya usa en esas situaciones..." : "
00:25:39Eso es lo que esperamos aportar.
00:25:44Estamos convirtiendo a muchos usuarios actuales
00:25:47a nuestras ofertas de código abierto,
00:25:48gente que migra de Webpack a Vite
00:25:52o de ESLint a OXLint.
00:25:54Lo que esperamos que sea Vite+ es
00:25:57la respuesta a: ¿qué hago
00:26:00si acabo de empezar con JavaScript?" : "
00:26:02¿Cuál es la forma más rápida y sencilla de empezar?
00:26:05Quiero responder a eso
00:26:07y también hacer que funcione de maravilla con la IA.
00:26:11- Entonces, ¿el objetivo de la empresa es...?
00:26:14A mucha gente le da miedo oír
00:26:15que hay una empresa detrás de proyectos de código abierto,
00:26:17porque podríais empezar a poner muros de pago en funciones,
00:26:20pero ¿vuestro objetivo sigue siendo que
00:26:23uno siempre pueda hacer lo que hace Vite+ por su cuenta?
00:26:25Solo que con mucha configuración,
00:26:26y que Vite+ es solo una conveniencia
00:26:29que lo empaqueta todo en uno, como dijiste.
00:26:31Así que nunca cobraríais por una función.
00:26:34- Sí, ya dimos unas pinceladas de la idea
00:26:37detrás de la licencia de Vite+, ¿verdad?
00:26:39Dijimos: vale, si tu empresa
00:26:41pasa de cierto umbral, tienes que pagar." : "
00:26:44Esa idea ha ido evolucionando
00:26:46porque hemos hablado con muchas empresas interesadas
00:26:50y estamos buscando el equilibrio adecuado
00:26:53entre ponerlo en manos de más gente
00:26:56y crear valor, frente a capturar valor nosotros
00:27:00para ser sostenibles, ¿no?
00:27:02Creo que vamos a subir mucho ese umbral.
00:27:07Así que solo una categoría muy pequeña de empresas
00:27:11tendría que pagar por ello.
00:27:14La mayoría de usuarios deberían poder disfrutarlo
00:27:17gratis y, además, tenemos...
00:27:20estamos trabajando en ideas que son más como un servicio
00:27:25en lugar de solo pagar por funciones.
00:27:27Un servicio que se complementa con Vite+
00:27:31para mejorar la calidad del código,
00:27:35monitorizar esa calidad
00:27:37y darte ideas o consejos,
00:27:39ayudarte a mejorar cosas.
00:27:41Porque hay mucho conocimiento específico
00:27:44que ahora podemos escalar mediante agentes de IA." : "
00:27:48Esa es la dirección que estamos explorando.
00:27:51- Vale, también me preguntaba,
00:27:53si Vite+ lo hace todo tan cómodo,
00:27:56¿crees que la IA puede hacer eso con las soluciones actuales?
00:28:00¿O has tenido alguna experiencia
00:28:02pidiéndole a la IA que junte el formato,
00:28:05el linter, la construcción y todo lo demás?" : "
00:28:07¿No crees que va a depender de tecnología vieja
00:28:09por sus datos de entrenamiento y crear un lío?
00:28:13- Vemos muchas aplicaciones creadas por IA
00:28:17que todavía usan Vite 4, por ejemplo, ¿no?
00:28:20Porque algo importante es que cuando sacamos una versión," : "
00:28:26cuando lanzamos funciones, los modelos tardan
00:28:29en entrenarse con esos datos.
00:28:31Los modelos siempre irán por detrás de las novedades
00:28:34y la tecnología; por eso queremos que,
00:28:37por ejemplo, si sacamos una versión de Vite+,
00:28:41venga con su propio...
00:28:44traerá su propio archivo de instrucciones (agent.md) y habilidades.
00:28:47Así, al actualizar Vite+, se actualiza,
00:28:50parcheará la parte relevante en tu agent.md
00:28:54y enlazará a las habilidades actualizadas
00:28:58en tu paquete de NPM.
00:29:00Y también,
00:29:05podríamos darte un "prompt" que te diga:
00:29:08si quieres actualizar de esta versión a esta otra,
00:29:10este prompt ayudará a tu agente a hacerlo mejor.
00:29:13Mucho de esto tendrá que venir
00:29:17de los autores de las herramientas.
00:29:19Porque hemos notado una cosa:
00:29:22OXLint, OXFormat y Vitest
00:29:26se usan en OpenClaude, ¿no?
00:29:29OpenClaude es una base de código loquísima.
00:29:31Son 54.000 líneas de JavaScript
00:29:34avanzando a un ritmo frenético.
00:29:36Y el autor fusiona cambios sin leerlos.
00:29:40Y hay muchas cosas
00:29:43que simplemente no tienen sentido ahí.
00:29:45Viendo algunas PR para actualizar OXLint
00:29:46o para adoptarlo,
00:29:51vemos opciones alucinadas que no existen.
00:29:54Y decimos: espera, no tenemos esta opción," : "
00:29:57tenemos que...
00:29:59Y luego, cuando hace el chequeo de tipos," : "
00:30:00simplemente lo "arregla" así:
00:30:04"Vale, desactivo esta regla".
00:30:06"Así pasará el tipo".
00:30:07La IA tomará atajos
00:30:09si no le pones límites, ¿verdad?
00:30:12Y lo más importante es que Peter," : "
00:30:15el autor de OpenClaude,
00:30:18no es un desarrollador de TypeScript.
00:30:20Simplemente eligió TypeScript para hacerlo.
00:30:22No es un experto en herramientas.
00:30:25No tiene experiencia en este campo.
00:30:26La IA le ayudó a hacerlo.
00:30:29Pero como autores de las herramientas que usa la IA," : "
00:30:30notamos dónde falla.
00:30:35Y es como: vale, si sigues haciendo esto
00:30:38sin que nosotros te lo señalemos,
00:30:41tu código se desmoronará en tres meses.
00:30:44Este es el valor
00:30:46que creemos que podemos aportar en la era de la IA:
00:30:50¿cómo te aseguras de que lanzas rápido
00:30:54sin romper nada?
00:30:58¿Cómo seguir lanzando funciones rápido con IA?
00:30:59Porque la velocidad de generación de código
00:31:03está aumentando masivamente por los agentes, ¿no?
00:31:06La gente puede lanzar funciones mucho más rápido que antes." : "
00:31:11Pero, ¿se revisan bien todas estas funciones?
00:31:14Cuando fusionas 20 PR al día,
00:31:19¿sigue la base de código,
00:31:22bien mantenida como debería?
00:31:25La salud del código es muy volátil.
00:31:26Así que tienes que parar de vez en cuando
00:31:30como hacemos en el desarrollo humano, ¿no?
00:31:33Lanzas funciones un tiempo,
00:31:36luego tienes que parar y pensar:
00:31:37vale, tenemos que limpiar esto.
00:31:38Pagar la deuda técnica acumulada.
00:31:40Con los agentes de IA lanzamos mucho más rápido,
00:31:42pero también acumulamos deuda técnica mucho más rápido." : "
00:31:45Así que hay que usar la IA para pagar esa deuda también.
00:31:49Creo que esta es la parte
00:31:53que la gente está pasando por alto
00:31:56y que necesita una solución ahora mismo.
00:31:57- Sí, eché un vistazo a OpenClaude,
00:32:00como decías, y es un poco caótico.
00:32:03Es un gran ejemplo de lo que pasa
00:32:05cuando sueltas a la IA a su aire
00:32:07y dejas que haga lo que quiera
00:32:09sin ningún tipo de supervisión.
00:32:11Han sido unas semanas divertidas en internet
00:32:13viendo cómo eso se hacía tendencia y lo que hacía." : "
00:32:16Pero también quería preguntar sobre el papel de la IA," : "
00:32:19¿cambias la forma de hacer un formateador
00:32:22o un linter para que los agentes de IA los usen mejor?
00:32:26¿Eso moldea el futuro,
00:32:29o crees que hacer formateadores
00:32:31y linters rápidos ya ayuda de por sí en la era de la IA?" : "
00:32:34Obviamente, al ser rápidos, los agentes pueden usarlos." : "
00:32:38- Es una muy buena reflexión
00:32:40porque estamos empezando a pensar en ese problema." : "
00:32:45El alcance original de estos linters
00:32:48y formateadores es masivo,
00:32:50porque intentamos ser compatibles
00:32:53con ESLint y Prettier,
00:32:54que llevan en producción muchísimos años,
00:32:56donde la gente tiene reglas personalizadas,
00:33:00casos de uso heredados...
00:33:03e intentamos ser 100% compatibles.
00:33:06Es una cantidad de trabajo enorme
00:33:09que por fin hemos logrado, porque hace poco alcanzamos
00:33:13la compatibilidad total con los complementos de ESLint." : "
00:33:17Pasamos todas sus pruebas de complementos
00:33:21y también logramos una conformidad del 100%
00:33:23con Prettier en nuestro formateador, ¿sabes?
00:33:25Estos dos hitos significan que, vale,
00:33:28ya podemos recomendar con confianza a la gente
00:33:31que se pase a nuestras herramientas; ¿y qué es lo siguiente?" : "
00:33:34Esa es la pregunta clave.
00:33:38¿Cómo deben adaptarse el linter y el formato
00:33:40cuando son agentes los que los usan?
00:33:44Es una cuestión en la que estamos trabajando activamente." : "
00:33:49Sí.
00:33:53- Básicamente, estamos esperando una respuesta para eso." : "
00:33:54Sigue evolucionando, sí.
00:33:57La IA está cambiando muchas cosas
00:33:59en el mundo de la programación, es interesante de ver." : "
00:34:01- Volviendo al tema de Vite+...
00:34:04Lo mostraste en la ViteConf 2025
00:34:06y enseñaste una función llamada `vite install`." : "
00:34:10Mi pregunta es, ¿sigue existiendo esa función?
00:34:14¿Y qué tanto se va a solapar Vite+
00:34:17con algo como Bun?
00:34:19- Es una buena pregunta.
00:34:21Las cosas han cambiado un poco desde la ViteConf." : "
00:34:23Yo diría que la versión,
00:34:27la versión pública final de Vite+ será probablemente," : "
00:34:30se sentirá como algo parecido a Bun en cierto sentido." : "
00:34:33La experiencia de inicio, como decía,
00:34:38si tienes un ordenador limpio y dices:
00:34:41"quiero empezar a crear una web app
00:34:43lo más rápido posible".
00:34:45Solo haces el curl del script,
00:34:46obtienes un binario global llamado `vp` y," : "
00:34:51cuando estás dentro de un proyecto..." : "
00:34:56Si tienes un archivo `.node-version`
00:35:02y un campo de gestor de paquetes en el `package.json`," : "
00:35:04que es lo habitual para especificar estas cosas,
00:35:06el entorno de JS en el que trabajas..." : "
00:35:11Vite+... cuando dices `vp run build`,
00:35:15usará automáticamente,
00:35:20incluso si solo dices `vp build` o `vp lint` o lo que sea," : "
00:35:22cualquier cosa que implique ejecutar JavaScript,
00:35:26elegirá automáticamente la versión correcta de Node
00:35:28y el gestor de paquetes adecuado por ti.
00:35:31Así que en un proyecto con Vite+ habilitado," : "
00:35:36de hecho, aunque no uses Vite+ en ese proyecto," : "
00:35:40siempre que uses
00:35:44estas fuentes de entorno convencionales,
00:35:45puedes usar Vite+ como sustituto de NVM.
00:35:48Puedes usarlo como sustituto de Corepack.
00:35:52Simplemente dejas de pensar en las versiones.
00:35:55La idea es que, al ejecutar tu flujo de trabajo," : "
00:35:59lo haces a través de... también dejas de usar `npm run`." : "
00:36:02Usas `vp run`.
00:36:05Así que al hacer un `vp run`,
00:36:06usará el Node correcto,
00:36:10usará la versión correcta del gestor de paquetes.
00:36:14Y hará lo correcto.
00:36:16El `install` significa que simplemente..." : "
00:36:19no tenemos un gestor de paquetes propio todavía." : "
00:36:24Es más como un equivalente a Corepack
00:36:27donde... no sé si has usado el paquete `ni`," : "
00:36:30de Anthony Fu.
00:36:34`ni` básicamente deduce el
00:36:36gestor de paquetes correcto a usar,
00:36:41ya sea para ejecutar, instalar o desinstalar," : "
00:36:45lo que sea, ¿no?
00:36:48`vp install` es básicamente eso,
00:36:49más la parte de gestión del propio gestor de paquetes." : "
00:36:51Eso es lo que hace Corepack, ¿verdad?
00:36:56Incluso si no tienes nada más instalado,
00:36:58entras en un proyecto y el `package.json` dice que el
00:37:01gestor de paquetes es `pnpm` en cierta versión." : "
00:37:03Al ejecutar `vp install`, comprobará
00:37:07si esa versión de pnpm está instalada.
00:37:08Si no lo está, la instalará
00:37:12y ejecutará el proceso con `pnpm install`.
00:37:14Queremos ir más allá
00:37:16de solo el linter y el formato.
00:37:20Se trata de todo lo habitual que necesitas
00:37:25en tu flujo de trabajo de JavaScript, ¿no?
00:37:31Queremos eliminar estos problemas comunes
00:37:34para que un principiante ni tenga que pensarlo." : "
00:37:36La primera vez que montes un proyecto,
00:37:40usaremos la última LTS de Node y recomendaremos pnpm." : "
00:37:43Y también escribiremos esa información en tu proyecto." : "
00:37:45Así, la próxima vez que entres,
00:37:50siempre usará la combinación correcta de cosas.
00:37:53- ¿Por qué recomiendas pnpm, por curiosidad?
00:37:55- Simplemente tiene el equilibrio adecuado entre funciones," : "
00:37:59precisión, eficiencia de disco y velocidad,
00:38:02además de un buen soporte para espacios de trabajo (workspaces)," : "
00:38:06como los catálogos... ya sabes.
00:38:10Cuando comparamos todas las
00:38:15funciones de los espacios de trabajo,
00:38:19vimos que pnpm seguía ofreciendo el mejor equilibrio." : "
00:38:21Sabemos que Bun es ridículamente rápido,
00:38:25pero pnpm ha sido lo bastante rápido para muchos de nosotros." : "
00:38:29Y tampoco descartamos la posibilidad
00:38:33de soportar Bun en nuestro entorno
00:38:35y en la gestión de versiones del gestor de paquetes." : "
00:38:37Podrás decir: "quiero usar Bun"
00:38:40y simplemente lo ejecutaremos con Bun.
00:38:42- Con Vite 6, creo que dijiste que iba a salir
00:38:44después del Año Nuevo Lunar, ¿no?
00:38:49- Sí.
00:38:52- ¿En qué cosas de la beta
00:38:54os estáis centrando antes del lanzamiento final?
00:38:58- Es todo estabilidad.
00:39:00CI del ecosistema;
00:39:04tenemos un sistema de CI masivo para el ecosistema
00:39:06donde ejecutamos Vite 6 en proyectos que dependen de él." : "
00:39:10Algo que logramos hace poco es que,
00:39:15todas las pruebas de SvelteKit pasen en Vite 6." : "
00:39:17Eso es un gran paso para nosotros,
00:39:21porque la estabilidad es lo más importante." : "
00:39:24Si lo piensas,
00:39:27estamos cambiando dos empaquetadores
00:39:28por uno nuevo que hemos hecho desde cero." : "
00:39:30Es como cambiar los motores de un avión en pleno vuelo
00:39:33esperando que siga volando sin problemas." : "
00:39:36Nunca se es lo bastante cuidadoso con esto.
00:39:40- Iba a preguntar antes: ¿la elección de Rust
00:39:43fue porque la gente de tu equipo
00:39:46ya lo conocía?
00:39:48Veo que mucha gente en el mundo de TypeScript
00:39:49prefiere Go porque les parece más cercano para portar el código," : "
00:39:51y por eso incluso el equipo de TypeScript está usando Go
00:39:55para su compilador.
00:39:57- Sí, creo que la decisión del equipo de TypeScript
00:39:58de pasarse a Go es porque,
00:40:02como dije, Go es un lenguaje mucho más fácil para portar TS," : "
00:40:04ya que el modelo mental es mucho más parecido." : "
00:40:09Uno de los grandes impedimentos para nosotros
00:40:13es que Go tiene un soporte para WebAssembly algo deficiente." : "
00:40:17Genera binarios de WASM enormes
00:40:21y su rendimiento en WebAssembly
00:40:26no es tan bueno comparado con Rust." : "
00:40:29Y sobre Rust, el tema es que,
00:40:32sí, mucho tiene que ver con el talento disponible," : "
00:40:35gente apasionada que
00:40:39ya ha invertido en el ecosistema." : "
00:40:41Por ejemplo, cuando buscamos
00:40:44cimientos sobre los que construir," : "
00:40:46no había un analizador ni una cadena de herramientas
00:40:48tan bien implementada y modular." : "
00:40:54Básicamente, OXC está hecho para construir encima, ¿no?" : "
00:40:59Son utilidades de bajo nivel.
00:41:04No vemos un equivalente así en el mundo de Go." : "
00:41:08Esbuild tiene su propio analizador y todo,
00:41:11pero es un sistema monolítico enorme." : "
00:41:14No puedes simplemente extraer su analizador y usarlo." : "
00:41:18Además, todas las funciones de esbuild,
00:41:23como los define, los inject o las transformaciones..." : "
00:41:25para obtener el mejor rendimiento," : "
00:41:30se implementan en tres pasadas de AST,
00:41:33lo que significa que en la misma pasada," : "
00:41:36puedes tener preocupaciones mezcladas:" : "
00:41:37haciendo una transformación por aquí,
00:41:39un "inject" por allá,
00:41:41y una modificación de código por otro lado." : "
00:41:42Eso no es ideal para un sistema extensible donde," : "
00:41:45por ejemplo,
00:41:51queremos poder añadir más transformaciones
00:41:54y permitir que la gente las active o desactive." : "
00:41:57Queremos que la gente escriba sus propias transformaciones." : "
00:42:01Quieres un sistema de linter que esté
00:42:03claramente estructurado por capas
00:42:07para que más gente pueda trabajar en él a la vez." : "
00:42:09Simplemente tiene que ver con lo que tenemos a mano." : "
00:42:13Rust también es muy potente." : "
00:42:16Es cierto que escribir buenas transformaciones con Rust es difícil." : "
00:42:22Tuvimos que dedicar bastante tiempo
00:42:26a encontrar una buena arquitectura
00:42:28para el flujo de visitantes y transformadores,
00:42:31por los problemas de propiedad de memoria;
00:42:34cuando bajas mucho en un árbol
00:42:37y necesitas cambiar el árbol padre,
00:42:39se vuelve muy complicado, ¿sabes?" : "
00:42:42Pero encontramos una solución." : "
00:42:44En Go es mucho más fácil, pero al pensarlo," : "
00:42:45queremos que nuestras herramientas puedan compilarse
00:42:49a WebAssembly y ejecutarse en el navegador." : "
00:42:51Rolldown puede ejecutarse en el navegador
00:42:53y hacerlo a una velocidad muy decente." : "
00:42:57Digo, esbuild también puede hacerlo,
00:42:59pero el WebAssembly de Rust es simplemente mejor." : "
00:43:01- La otra pregunta que te iba a hacer
00:43:05sobre el equipo construyendo en Rust y demás:
00:43:07¿cómo estáis usando la IA tú y el equipo?" : "
00:43:09Dijiste antes que mucha gente
00:43:12del equipo la está utilizando." : "
00:43:14¿Te parece que la IA es buena en el trabajo que hacéis?" : "
00:43:16Siento que en el desarrollo web básico," : "
00:43:19hay muchísimos ejemplos en GitHub de eso." : "
00:43:21Así que la IA está muy bien entrenada." : "
00:43:23Pero lo que hacéis vosotros es un nivel más bajo" : "
00:43:25o al menos de una alta complejidad técnica." : "
00:43:28¿Es útil la IA ahí o seguís haciendo
00:43:30mucho código a mano?
00:43:32- Definitivamente es útil.
00:43:34Lo que pasa es que este campo cambia muy rápido." : "
00:43:38Creo que por estas fechas el año pasado, yo era escéptico." : "
00:43:41Pensaba: bueno, lo he probado y no me sirve
00:43:45porque mi trabajo es de muy bajo nivel." : "
00:43:49Pero Boshen, que lidera OXC,
00:43:52es probablemente la persona más convencida
00:43:59de la IA en la empresa ahora mismo." : "
00:44:03Empezó a volverse loco con los experimentos." : "
00:44:04El mes pasado hubo una semana
00:44:07en la que lanzó unas 60 PR con IA," : "
00:44:11ejecutando agentes en paralelo." : "
00:44:13Incluso empezamos a hacer experimentos locos
00:44:16como portar el compilador de Angular a Rust," : "
00:44:19se lo lanzamos para ver si funcionaba." : "
00:44:24Y de alguna manera, está funcionando." : "
00:44:27Quizás tengamos algo en esa línea en el futuro." : "
00:44:29Nuestra percepción sobre el alcance
00:44:33de las capacidades de la IA se refresca cada pocos meses" : "
00:44:39con los nuevos modelos que salen," : "
00:44:43mejores entornos de ejecución
00:44:46y nuevas prácticas como usar el modo de planificación" : "
00:44:48o escribir el archivo agent.md." : "
00:44:51Usas estos trucos y te das cuenta de que,
00:44:55efectivamente, cada vez es mejor." : "
00:45:00La adopción y el uso varían según la persona, ¿no?" : "
00:45:03Animamos a todos en la empresa
00:45:06a usarla en la medida que consideren oportuna." : "
00:45:08Les damos un crédito mensual
00:45:13para que puedan usar Claude Pro si quieren." : "
00:45:18Algunos están muy contentos
00:45:22y son bastante vocales al respecto." : "
00:45:24Y obviamente están entregando PRs muy buenas." : "
00:45:27Depende mucho de lo bien que sepas usarla." : "
00:45:33Una parte es la capacidad bruta del modelo." : "
00:45:36Otra es el entorno que utilices," : "
00:45:40pero creo que la capa del entorno (harness)
00:45:45es como los frameworks de JS en su día." : "
00:45:49Todo el mundo está haciendo su propia versión." : "
00:45:52Y todos hacen más o menos lo mismo." : "
00:45:54Quizás uno tiene un par de trucos bajo la manga," : "
00:45:57pero a los pocos meses, todo el mundo lo hace, ¿no?" : "
00:46:00Va a ser un campo muy competitivo y con los modelos igual." : "
00:46:03Cada pocos meses..." : "
00:46:08ahora está por salir Sonnet 3.7." : "
00:46:11DeepSeek está por lanzar un nuevo modelo." : "
00:46:13Esto solo va a ir a mejor." : "
00:46:17Está claro que la IA es extremadamente capaz
00:46:18si se la guía correctamente,
00:46:21pero esa guía sigue siendo fundamental." : "
00:46:23No puedes esperar que alguien sin idea de Rust
00:46:26pueda trabajar en la base de código de OXC, ni con IA." : "
00:46:32Seguramente ni sabría cómo darle las instrucciones (prompts)." : "
00:46:34Pero alguien que ya sea eficiente en OXC
00:46:37como ingeniero de Rust, con la ayuda de la IA" : "
00:46:41se vuelve mucho más productivo
00:46:45y puede lanzar más funciones más rápido." : "
00:46:50Esa es mi visión general." : "
00:46:54Yo probablemente soy de los que..." : "
00:46:58la cantidad de código que produzco con IA es mínima
00:47:00comparada con otros ingenieros de la empresa." : "
00:47:03La uso más para investigar y como muro de resonancia." : "
00:47:08- Es un mundo muy raro
00:47:13hacia el que va la programación,
00:47:16y me cuesta estar al día de
00:47:20cuántos sub-agentes hay que usar," : "
00:47:25agentes en paralelo, qué archivo markdown debes tener
00:47:27ahora en tu repositorio." : "
00:47:29Cambia todo el tiempo." : "
00:47:32Tengo curiosidad por ver dónde acabaremos
00:47:34en el futuro." : "
00:47:37- Volviendo a Vite por un momento." : "
00:47:38En Vite 6 lanzasteis soporte para React Server Components." : "
00:47:40En mi opinión, los React Server Components
00:47:43no han sido el éxito rotundo que el equipo esperaba." : "
00:47:43Hay algunos frameworks que no los aceptan," : "
00:47:47como TanStack." : "
00:47:52E incluso Remix ha tomado un rumbo propio." : "
00:47:54¿Qué opinas tú de los RSC
00:47:57y por qué crees que no han calado como deberían?" : "
00:48:00- Sí, siempre he sido muy conservador con eso
00:48:01o escéptico desde el primer día." : "
00:48:04Por eso nunca nos planteamos implementar
00:48:07algo parecido en Vue." : "
00:48:10Creo que la cuestión fundamental es qué problema real
00:48:14está intentando resolver." : "
00:48:17Y creo que se le dio demasiado bombo." : "
00:48:20Al intentar entusiasmar a la gente," : "
00:48:23se vendió como la solución definitiva." : "
00:48:28Que iba a ser lo mejor de la historia." : "
00:48:30Que haría todos los sitios web más rápidos." : "
00:48:35Y cuando llega, la gente se da cuenta:" : "
00:48:38quizás no debería usarlo en todos los casos." : "
00:48:40Solo beneficia en ciertos tipos de situaciones." : "
00:48:42En otros casos, es solo una serie de compromisos." : "
00:48:44Porque las partes que viven en el servidor..." : "
00:48:48ahora todas las interacciones requieren
00:48:51un viaje de ida y vuelta a la red." : "
00:48:54Y eso es bastante malo
00:48:56para la experiencia de "offline-first", en mi opinión." : "
00:48:59Además, no puedes escapar totalmente del coste de hidratación," : "
00:49:04bajo mi punto de vista." : "
00:49:06Estás compensando parte de la hidratación del cliente," : "
00:49:08pasándosela al servidor, ¿verdad?" : "
00:49:10Ahora asumes el coste en cada petición;" : "
00:49:14estás haciendo más trabajo en el servidor." : "
00:49:20Hay teorías conspiranoicas
00:49:21de que Vercel lo impulsa para vender más computación." : "
00:49:26No creo que sea eso exactamente, ¿verdad?" : "
00:49:29Pero es cierto que usar RSC
00:49:31implica más carga en el servidor." : "
00:49:33Ejecutas más cosas allí," : "
00:49:38consumes más minutos de procesamiento." : "
00:49:44Al final hay otros beneficios, como que
00:49:47si dejas parte en el servidor, ahorras en tamaño de paquete." : "
00:49:51Pero hay muchas formas de resolver ese problema
00:49:52que no implican necesariamente
00:49:54tener que ejecutar un servidor de Node.js, ¿no?" : "
00:49:56Y mucho de esto es mi opinión personal." : "
00:49:59En el frontend solemos decir: vale," : "
00:50:01la arquitectura importa de verdad." : "
00:50:02¿Quieres una SPA?" : "
00:50:06which doesn't necessarily involve
00:50:07RSC es aún más específico." : "
00:50:10¿Necesitas RSC? Es una pregunta muy importante" : "
00:50:14y muy difícil de responder." : "
00:50:17Y si dices que sí," : "
00:50:19tienes que ser consciente del precio que pagas," : "
00:50:21porque creo que una de las razones" : "
00:50:24de que no se adoptara bien es que, primero," : "
00:50:27es extremadamente complicado." : "
00:50:31Es algo difícil de explicar." : "
00:50:33Cómo funciona es difícil de explicar." : "
00:50:35Tuvimos que profundizar mucho" : "
00:50:37porque requiere una orquestación a nivel de herramienta de build" : "
00:50:39para que todo el sistema funcione, ¿no?" : "
00:50:43Muy poca gente entiende realmente" : "
00:50:46cómo funciona RSC en crudo." : "
00:50:48La mayoría lo conoce a través de la implementación" : "
00:50:50de Next.js, porque un RSC puro es algo que un usuario medio" : "
00:50:52no sabría configurar por su cuenta, ¿verdad?" : "
00:50:56Tendrías que entender muy bien cómo encaja todo" : "
00:50:58para montar algo desde cero" : "
00:51:02con React puro y Vite o Webpack." : "
00:51:04No es para el desarrollo del día a día." : "
00:51:07Por eso quieres usar un framework." : "
00:51:11Están hechos para eso." : "
00:51:14Pero para usar RSC en un framework," : "
00:51:17el framework tiene que tomar decisiones de diseño" : "
00:51:20sobre cómo presentar RSC" : "
00:51:23de forma que ofrezca una experiencia de desarrollo decente." : "
00:51:27Y creo que Next.js no dio en el clavo, yo diría." : "
00:51:29La confusión entre `use server` y `use client`," : "
00:51:30el grafo mixto donde al marcar algo como `use server`," : "
00:51:33otras cosas simplemente dejan de funcionar." : "
00:51:36Te limitas a usar solo ciertas cosas" : "
00:51:39y luego importas una dependencia" : "
00:51:42y resulta que no funciona en `use server`." : "
00:51:47Ahora tienes que volver a `use client`." : "
00:51:51Todo este tira y afloja," : "
00:51:55creo que son esos pequeños detalles molestos" : "
00:51:58en la experiencia de desarrollo lo que hace pensar a la gente:" : "
00:52:01"para obtener los beneficios prometidos," : "
00:52:03ahora tengo que aguantar estos problemas de DX" : "
00:52:06todo el tiempo, para siempre"." : "
00:52:08¿De verdad merece la pena?" : "
00:52:10Es normal que la gente se pregunte" : "
00:52:12si realmente quiere usarlo." : "
00:52:15Incluso para los autores de frameworks, ¿no?" : "
00:52:20Vercel tenía una relación muy estrecha con el equipo de React" : "
00:52:24para colaborar e iterar rápido." : "
00:52:27Pero para terceros... ni siquiera diría terceros," : "
00:52:28porque técnicamente Vercel es un tercero, ¿no?" : "
00:52:35Pero para otros frameworks como Remix o TanStack," : "
00:52:37no es tan sencillo trabajar en esto," : "
00:52:40porque muchas de las iteraciones de la API" : "
00:52:42del equipo de React priorizan a Next.js." : "
00:52:45No les critico por ello," : "
00:52:49porque Vercel es su socio de diseño." : "
00:52:52Quieren trabajar con ellos" : "
00:52:57para pulir esta función y lanzarla," : "
00:53:02lo cual tiene sentido." : "
00:53:06Pero por eso," : "
00:53:08Next.js era básicamente la única forma real" : "
00:53:13de que la gente usara RSC." : "
00:53:15Y esa experiencia no ha sido genial." : "
00:53:17Creo que por eso no ha salido como podría." : "
00:53:19Además, la premisa general es que," : "
00:53:21incluso en un mundo ideal donde RSC tuviera una DX perfecta," : "
00:53:25no creo que fuera a ser la solución para todo." : "
00:53:29Hay que estar muy bien formado para saber" : "
00:53:31dónde tiene sentido y dónde no." : "
00:53:33Demasiados compromisos." : "
00:53:38- Supongo que no ha habido presión" : "
00:53:41para implementar algo parecido en Vue," : "
00:53:46porque obviamente todo vuelve a Vercel." : "
00:53:49Compraron Nuxt Labs," : "
00:53:50que es el meta-framework sobre Vue" : "
00:53:52para juntarlo todo." : "
00:53:54¿Cómo ha sido la relación entre Nuxt y Vue" : "
00:53:57ahora que Vercel son los dueños?" : "
00:53:59- Sinceramente, no ha cambiado mucho." : "
00:54:01Creo que Vercel no ha intervenido apenas tras la adquisición," : "
00:54:03así que el equipo de Nuxt está contento de poder" : "
00:54:05seguir haciendo lo que hacen." : "
00:54:08Seguramente hay esfuerzos para" : "
00:54:09que Nuxt funcione mejor en Vercel," : "
00:54:13hacerlo un ciudadano de primera clase." : "
00:54:14Pero Vercel es consciente" : "
00:54:18de la imagen que tiene en la comunidad" : "
00:54:21y tendrán mucho cuidado de no dañarla más." : "
00:54:24Tras adquirir Nuxt," : "
00:54:25lo último que querrían hacer" : "
00:54:30es obligar a Nuxt a hacer cosas que a la gente no le gusten." : "
00:54:32- Por desgracia, Evan ha tenido que irse antes" : "
00:54:34para atender una llamada importante," : "
00:54:38pero agradecemos mucho su tiempo" : "
00:54:43y todas sus ideas sobre las preguntas que hicimos." : "
00:54:47Si tenéis algún invitado que os gustaría ver en el podcast," : "
00:54:50por favor, decidlo en los comentarios." : "
00:54:52Y si tenéis algún comentario en general," : "
00:54:54hacédnoslo saber también." : "
00:54:56Nos encantará escucharlo." : "
00:54:58Buscadnos en cualquier plataforma de podcasts" : "
00:55:00como Spotify o Apple Podcasts." : "
00:55:04Y hasta la próxima, un saludo por mi parte." : "
00:55:06- Adiós por mi parte." : "
00:55:08- Adiós de mi parte." : "
00:55:10- Ha sido un placer, gracias a todos." : "
00:55:11- Muchas gracias por acompañarnos." : "
00:55:12Find us on anywhere you listen to podcasts
00:55:15like Spotify or Apple Podcasts.
00:55:17And until next time, it's a bye from me.
00:55:20- Bye from me.
00:55:21- Bye from me.
00:55:21- It's a pleasure, thank you all.
00:55:23- Thank you very much for joining us.