Lovable reescribió Vite en Rust... (más o menos)
BBetter Stack
Computing/SoftwareSmall Business/StartupsInternet Technology
Transcript
00:00:00Sumen otro a la lista de reescrituras en Rust. Esta vez le tocó al servidor
00:00:03de desarrollo de Vite, reescrito en Rust por el equipo de Lovable, logrando supuestamente
00:00:07un consumo de memoria cuatro veces menor y arr
00:00:12Vamos a analizar esa afirmación, ya que puede ser un poco engañosa,
00:00:15y veremos si vale la pena cambiar en el futuro y qué opina el creador de Vite.
00:00:24El proyecto del que hablo se llama OJ (Orange Juice), y la idea es que
00:00:29es un binario de Rust que apunto a mi proyecto de Vite y simplemente corre.
00:00:33Lee la configuración de Vite, ejecuta los plugins existentes, pero el servidor por debajo,
00:00:38es decir, el observador de archivos, grafo de módulos, HMR y React Fast Refresh, se reescribió en Rust.
00:00:44Curiosamente, se hizo usando Rolldown y Oxc, que el propio Vite usa y voidzero mantiene.
00:00:49Para probarlo, construí una app con TanStack para comparar
00:00:53las diferencias entre ejecutar Vite dev u OJ dev. A primera vista, funcionan casi idéntico,
00:00:58y todo corre bien: SSR, hidratación, funciones de servidor, Fast Refresh,
00:01:03rutas de archivo dinámicas, rutas de servidor, Tailwind e importación de assets.
00:01:07Pero al indagar más, noté sutiles diferencias. La primera fue con el Fast Refresh.
00:01:13Si edito un archivo, el contador de Vite conserva su estado, pero con OJ,
00:01:17el contador vuelve a cero, indicando que OJ recarga todo en lugar de solo el componente modificado.
00:01:22Decidí probar este mismo comportamiento en una app simple de React sin TanStack Start,
00:01:26y curiosamente ahí sí pareció funcionar. La misma edición mantiene el contador,
00:01:30sin actualizar toda la página, haciendo una recarga en caliente real.
00:01:35No sé a qué se deba la diferencia entre TanStack Start y React puro,
00:01:39tal vez sea un caso aislado aún no contemplado. La segunda diferencia
00:01:42fue con la función de servidor. Esta función mide la memoria de todo el proceso del servidor
00:01:46desde la app. En esta app con Vite, ronda los 380 MB en dos procesos, y con OJ,
00:01:53unos 320 MB en dos procesos. En una app pequeña como esta, el uso de memoria
00:01:59es similar, con OJ apenas un poco por delante. ¿Significa que el proyecto no sirve?
00:02:04Para nada, porque OJ no fue diseñado para esto. De hecho, brilla
00:02:09en aplicaciones muy grandes. Al probarlo en React con 5000 componentes y un script que
00:02:14inicia el servidor, abre la página en Chrome, detiene el reloj al cargar el componente final
00:02:19y mide la memoria del proceso completo, el modo normal de OJ es 1.7 veces más rápido
00:02:24al renderizar que Vite por defecto, y consume cerca de un cuarto de memoria.
00:02:29Siendo justos con Vite, la versión 6.1 incluyó una función experimental de desarrollo empaquetado,
00:02:34y al activarla, Vite alcanza 1.18 segundos, un poco más rápido que el modo normal
00:02:40de OJ, pero no reduce el uso de memoria. OJ también tiene un modo empaquetado que,
00:02:45al usarse, baja a 0.89 segundos, manteniendo la memoria en un cuarto respecto a Vite.
00:02:51Así que OJ sí ofrece mejoras reales de memoria, y esa es la razón por la que Lovable
00:02:55creó este proyecto. Las vistas previas de Lovable corren un servidor Vite real, y afirman
00:03:00ejecutar alrededor de un millón de esos entornos aislados al día. A esa escala,
00:03:04el consumo de recursos resulta crucial. Lovable creó OJ para lograr vistas previas instantáneas
00:03:09y ligeras, sin abandonar el ecosistema que hace funcionar la app.
00:03:13Tomaron una decisión de diseño interesante para este caso, los agentes. Al editar,
00:03:17una persona suele guardar un archivo a la vez, pero un agente puede escribir 10 de golpe,
00:03:22y Vite procesaría cada guardado como una actualización, mientras que en OJ,
00:03:26el observador, el grafo, el compilador y las actualizaciones forman una sola canalización.
00:03:32También hay una opción que retiene los cambios hasta que el agente envía
00:03:35una señal de confirmación, aplicando la vista previa solo cuando el cambio termina.
00:03:40Se nota que es un proyecto muy específico para Lovable, y eso mismo señaló
00:03:45Evan You, creador de Vite. Su primer punto en Twitter es que impresiona y resuelve
00:03:49su problema, pero no es una reescritura total de Vite. Solo abarca el servidor de desarrollo,
00:03:54y está construido sobre Rolldown y Oxc que mantiene void0, así que no los reemplaza.
00:04:00El analizador, el transformador y el empaquetador en OJ pertenecen a void0;
00:04:04Lovable solo escribió el servidor en torno a ellos. En esencia,
00:04:08Vite es un proceso Node impulsando Rust, mientras que OJ es Rust impulsando Rust,
00:04:13con una capa intermedia de JavaScript para comunicarse con la API de plugins de Vite.
00:04:17Evan también señala que OJ logra ser rápido porque solo admite un tipo de app:
00:04:22las aplicaciones de React que Lovable genera. En cambio, Vite
00:04:27debe soportar todo framework, configuración atípica y herramienta del entorno,
00:04:31dejando cosas como esbuild o el plugin de React como paquetes independientes para añadirlos si se requieren.
00:04:36Además, remarca fallos en la comparativa. El arranque en frío de Vite en el blog
00:04:40incluye vite-plugin-checker, que ejecuta TypeScript en segundo plano, pero OJ no soporta
00:04:45ese plugin, omitiendo ese trabajo. Muestra que con el modo de desarrollo empaquetado
00:04:50en Vite, los tiempos se acercan al arranque de OJ, coincidiendo con nuestras cifras,
00:04:55aunque admite que OJ usa significativamente menos memoria y Vite debería mejorar eso.
00:04:59El punto final de Evan me parece el más interesante: la dinámica del software libre
00:05:03está cambiando, el costo de reimplementar cayó por la IA, y veremos más
00:05:08proyecciones a la medida de herramientas de código abierto; es decir, la misma dependencia
00:05:13reconstruida bajo ciertas restricciones para un caso específico. Cita a TanStack Redact como ejemplo.
00:05:19Un futuro posible es que, en vez de mantener proyectos abrumados por miles de PRs,
00:05:23cada quien mantenga su propia versión adaptada. Comenta que no está seguro de si es positivo,
00:05:28pero le parece muy probable que ocurra en unos años. Por un lado,
00:05:33estas adaptaciones ayudan a los mantenedores, pero se arriesga la fragmentación del ecosistema.
00:05:39Solo el tiempo dirá cómo se desarrollará esto y cuál será el futuro del código abierto.
00:05:43En general, no es una herramienta que alguien fuera de Lovable vaya a usar,
00:05:47a menos que tengan el problema de millones de servidores Vite aislados. Y francamente,
00:05:52¿han notado que Vite vaya lento en sus laptops o consuma demasiada memoria?
00:05:57En lo personal no, pero sigue siendo un proyecto interesante e ingenioso.
00:06:01Déjenme sus opiniones en los comentarios. Mientras tanto, suscríbanse y,
00:06:04como siempre, nos vemos en el próximo.
00:06:09Nos vemos en el próximo.
Community Posts
No posts yet. Be the first to write about this video!
Write about this video