Lovable reescreveu o Vite em Rust... (mais ou menos)

Autoria: Better Stack · Assistir no YouTube

Vídeo de autoria do canal indicado, não da IANIA; todos os direitos pertencem ao criador. Transcrição, resumo e tradução gerados automaticamente; o conteúdo no idioma original é preservado na versão em idioma original.

Idioma original: inglês

Vídeo original: Lovable Rewrote Vite in Rust… (kind of) · Canal: Better Stack · 05:50 · Assistir no YouTube

Tópicos: Engenharia de software com IA, Ferramentas de desenvolvimento com IA, Open source e ecossistemas de software

Resumo

O vídeo analisa o OJ, um servidor de desenvolvimento escrito em Rust pela equipe da Lovable para projetos Vite, e compara seu desempenho com o Vite em diferentes cenários. Em aplicativos grandes, o OJ pode reduzir bastante o uso de memória e acelerar a inicialização, embora parte da comparação envolva recursos que o OJ não oferece. O projeto é voltado às necessidades específicas da Lovable, como executar muitos previews e agrupar as alterações feitas por agents. Evan You destaca que o OJ não substitui o Vite por completo e aponta possíveis efeitos das reimplementações específicas sobre o ecossistema open source.

Pontos-chave

OJ é um binário Rust que usa a configuração e os plugins existentes de projetos Vite, mas implementa em Rust componentes do servidor de desenvolvimento.
Em um aplicativo pequeno, o teste encontrou uso de memória semelhante entre Vite e OJ.
Em um aplicativo React com 5.000 componentes, o modo normal do OJ chegou a uma página renderizada cerca de 1,7 vez mais rápido e usou aproximadamente um quarto da memória do Vite.
O modo bundle do Vite reduziu a diferença de velocidade, mas não trouxe a mesma economia de memória; o modo bundle do OJ foi ainda mais rápido no teste.
No teste com TanStack Start, o OJ reiniciou o estado do contador após uma edição, embora o teste em um aplicativo React simples tenha mostrado atualização sem recarregar a página inteira.
O OJ agrupa várias alterações feitas em sequência em uma única atualização e pode aguardar um sinal de flush antes de aplicá-las ao preview.
Evan You observa que o OJ atende a um caso de uso específico e não é uma reescrita completa do Vite; ele também não oferece suporte a todos os frameworks e plugins.
A discussão levanta a possibilidade de que a IA facilite a criação de versões adaptadas de ferramentas open source, mas isso também pode fragmentar o ecossistema.

Capítulos

Início	Capítulo	Resumo
00:00	O que é o OJ	O vídeo apresenta o servidor de desenvolvimento em Rust da Lovable e explica como ele se integra a projetos Vite existentes.
02:07	Comparação de desempenho	Testes em um aplicativo React grande mostram diferenças de velocidade e uso de memória entre o OJ e os modos do Vite.
03:41	O escopo do projeto e as ressalvas de Evan You	O vídeo explica por que o OJ foi criado para as necessidades da Lovable e por que não equivale a uma reescrita completa do Vite.
04:44	Benchmarks e o futuro do open source	Evan You ressalta diferenças na comparação e discute como reimplementações específicas podem afetar a manutenção e a fragmentação do open source.
05:17	Conclusão	O vídeo pondera os possíveis benefícios e custos das versões adaptadas e conclui que o OJ provavelmente interessa sobretudo à Lovable.

Citações

Supostamente, ele alcança um uso de memória quatro vezes melhor e inicializações a frio duas vezes mais rápidas. — 00:00

O OJ parece mesmo trazer benefícios reais de memória, e esse é basicamente o motivo pelo qual a Lovable criou o projeto. — 02:40

O custo de reimplementar algo despencou por causa da IA. — 04:44

Por um lado, forks lentos são melhores para os maintainers do que um monte de PRs lentos; por outro, há o risco de fragmentar o ecossistema. — 05:17

Conceitos e entidades

OJ (ferramenta): Servidor de desenvolvimento escrito em Rust pela Lovable para projetos Vite, com foco em previews leves e rápidos.
Vite (ferramenta): Ferramenta de desenvolvimento web cujo servidor de desenvolvimento é parcialmente reimplementado pelo OJ.
Rust (conceito): Linguagem usada para implementar o servidor de desenvolvimento do OJ.
Lovable (empresa): Empresa que criou o OJ para reduzir o custo de recursos dos previews executados em seus sandboxes.
Evan You (pessoa): Criador do Vite, citado no vídeo ao comentar o propósito e as limitações do OJ.
Rollup (ferramenta): Ferramenta que, junto com Oxc, é mencionada como parte da base técnica usada pelo OJ.
Oxc (ferramenta): Conjunto de ferramentas mantido pela Void Zero e usado pelo OJ em componentes como parser e transformer.
Void Zero (empresa): Empresa que mantém ferramentas usadas pelo OJ, incluindo componentes do ecossistema Oxc.
TanStack Start (ferramenta): Framework usado no teste do vídeo para comparar o comportamento do Vite e do OJ.
Redact (ferramenta): Projeto de TanStack citado por Evan You como outro exemplo de uma ferramenta adaptada a um caso específico.

Tradução completa (pt-BR)

00:00 Você pode adicionar mais um à contagem, pois houve outra reescrita em Rust: desta vez, o servidor de desenvolvimento do V foi reescrito em Rust pela equipe da Lovable, supostamente alcançando um uso de memória quatro vezes melhor e inicializações a frio duas vezes mais rápidas. Então, vamos investigar essa afirmação, porque ela pode ser um pouco enganosa, e depois ver se é algo para o qual você deveria migrar no futuro, além de descobrir o que o criador do V acha que isso significa para o futuro do open source. O projeto de que estou falando se chama OJ, também conhecido como orange juice, e a ideia é que ele seja um único binário Rust que posso apontar para meu projeto V existente e

00:32 ele simplesmente o executa. Ele lê minha configuração do V, continua executando meus plugins V existentes, mas o servidor de desenvolvimento por baixo deles — ou seja, o observador de arquivos, o grafo de módulos, o hot module reloading e o fast refresh do React — foi todo reescrito em Rust. Curiosamente, isso foi feito usando Rollup e Oxc, que o próprio V8 usa e que a Void Zero mantém. Para experimentar por conta própria, criei um app TanStack para ver se havia alguma diferença entre executá-lo com V dev ou OJ dev. À primeira vista, eles parecem funcionar de maneira quase idêntica, e tudo funciona: renderização no servidor, hidratação, funções de servidor, fast refresh, arquivos

01:03 de rota dinâmicos, rotas de servidor, Tailwind e importações de recursos. Mas, investigando um pouco mais a fundo, notei algumas diferenças pequenas. A primeira foi no fast refresh aqui. Se eu editar um arquivo, o contador do V mantém o estado, mas no OJ o contador volta a zero, o que indica que o OJ faz um recarregamento completo, em vez de atualizar apenas o componente que mudou. Na verdade, decidi tentar testar o mesmo comportamento em um app React simples, que não era o TanStack Start, e, curiosamente, pareceu funcionar aqui. A mesma edição mantém o contador igual e não atualiza a página inteira, então parece estar fazendo uma atualização a quente de verdade. Não sei por que há essa diferença

01:36 entre o TanStack Start e um app React simples; talvez seja apenas um daqueles casos extremos que ainda não consideraram. A segunda diferença que notei foi na função de servidor. Essa função mede a memória de toda a árvore de processos do servidor de desenvolvimento, de dentro do app. Neste app com V, são cerca de 380 MB em dois processos; com OJ, cerca de 320 MB, também em dois processos. Então, em um app pequeno como este, o uso de memória parece ser mais ou menos o mesmo, com o OJ ficando só um pouquinho à frente. Isso significa que este projeto é completamente inútil? Bem, não, porque não é para isso que

02:07 o OJ foi criado. O OJ funciona melhor em apps realmente grandes. Quando testei isso em um app React com 5.000 componentes, usando um script que inicia o código de cada servidor de desenvolvimento, abre a página em um navegador Chrome real, para o cronômetro quando o componente mais profundo está no DOM e, então, mede a memória de toda a árvore de processos, o modo normal do OJ chega a uma página renderizada cerca de 1,7 vez mais rápido que o V padrão e usa aproximadamente um quarto da memória. Para ser justo com o V, a versão 8.1 do V lançou um recurso experimental chamado modo de desenvolvimento com bundle; se você o ativar, o V chega a 1,18 segundo. Então, na verdade, um pouco mais rápido que o modo normal do OJ, mas não economiza memória.

02:40 E o OJ também tem um modo bundle que, quando usado, o deixa ainda mais rápido: cerca de 0,89 segundo. E ele mantém o uso de memória em aproximadamente um quarto do V. Então, o OJ parece trazer benefícios reais de memória, e essa é basicamente a razão pela qual a Lovable criou o projeto. As prévias da Lovable executam um servidor de desenvolvimento V de verdade, e a Lovable diz que roda cerca de um milhão dessas sandboxes por dia. Nessa escala, o consumo de recursos realmente começa a importar. Então, a Lovable criou o OJ para obter prévias que iniciam instantaneamente e continuam leves, sem abrir mão do ecossistema que

03:11 faz o app funcionar desde o início. Também tomaram uma decisão de design bem interessante pensando nesse caso de uso: os agents. Ao editar, uma pessoa normalmente salva um arquivo de cada vez, mas um agent pode gravar uns 10 de uma vez, e o V trataria cada um desses salvamentos como uma atualização. No OJ, porém, o observador, o grafo de módulos, o compilador e as atualizações a quente formam um único pipeline, então várias alterações seguidas são agrupadas em uma só atualização. Há também uma opção que você pode ativar para que as atualizações fiquem retidas até o próprio agent enviar uma solicitação a um endpoint de flush. Assim, a prévia só aplica uma alteração concluída. Dá para ver que este é um projeto muito específico

03:41 para resolver os casos de uso da própria Lovable, e foi isso que o criador do V, Evan You, também reconheceu. O primeiro ponto do tuíte dele é que se trata de um projeto realmente impressionante, que resolve bem um problema da Lovable, mas não é uma reescrita completa do V. É apenas o servidor de desenvolvimento e também foi construído sobre Rollup e Oxc, mantidos pela Void Zero, então dificilmente os substitui. O parser, o transformer e o empacotador de produção do OJ são todos da Void Zero. A Lovable só escreveu o servidor em torno deles. Dá para pensar nele assim: o V é um processo Node que controla Rust, enquanto o OJ é um processo Rust que controla Rust, com uma

04:12 camada intermediária em JavaScript para que ainda possa se comunicar com a API de plugins do V. Evan também observa que o OJ consegue ser rápido porque só dá suporte a um tipo de app. Na verdade, o OJ funciona apenas com apps React, ou seja, aqueles que a Lovable está gerando. O V, por outro lado, precisa dar suporte a todos os frameworks, a toda configuração estranha e a todas as ferramentas criadas em torno dele. Ele deixa deliberadamente coisas como o ESBuild ou o plugin do React em pacotes separados, para que você possa adicioná-los por conta própria se precisar. Depois disso, ele também aponta os problemas do benchmark. A inicialização a frio do V no artigo inclui o plugin V Checker, que executa TypeScript em um worker em segundo plano, mas

04:44 o OJ não dá suporte a esse plugin, então simplesmente ignora esse trabalho por completo. Ele também aponta que, no V com o modo de desenvolvimento com bundle, a inicialização a frio fica mais próxima da do OJ, exatamente como vimos nos nossos números. Mas admite que o OJ usa bem menos memória e que o V provavelmente deveria tentar melhorar isso. O último ponto de Evan no tuíte é o que acho mais interessante: a dinâmica do open source está mudando. O custo de reimplementar algo caiu drasticamente por causa da IA, então veremos mais do que ele chama de versões adaptadas de ferramentas open source: a mesma dependência, reconstruída dentro das restrições de um componente para atender a um caso de uso específico. Ele dá o Redact, da TanStack, como

05:17 outro exemplo. Um futuro possível é que, em vez de os mantenedores ficarem sobrecarregados com milhares de PRs lentos, todo mundo simplesmente mantenha seu próprio fork lento. Mas, sinceramente, ele diz que não tem certeza se isso é bom; ainda assim, acha bastante provável que seja o que vai acontecer daqui a alguns anos. Por um lado, forks lentos são melhores para os mantenedores do que uma pilha de PRs lentos. Por outro, corremos o risco de fragmentar o ecossistema. Acho que só o tempo dirá como isso vai se desenrolar e qual será o futuro do open source. No geral, esta não é uma ferramenta que alguém além da Lovable vá usar, a menos que aparentemente enfrente exatamente os mesmos problemas com milhões de servidores de desenvolvimento V3 em

05:50 sandboxes. E, quer dizer, você realmente percebeu o V8 ficando lento no seu próprio laptop ou usando memória demais? Eu, pessoalmente, não, mas este ainda é definitivamente um projeto legal, e é legal que tenham feito isso. Então, me conte nos comentários o que você acha. Já que está por aqui, inscreva-se. Como sempre, até a próxima.

Transcrição original

[00:00] You can add one to the counter as there’s been another Rust rewrite, this time being the V dev server rewritten in Rust by the lovable team, supposedly achieving four times better memory usage and two times quicker cold starts. So, let’s go ahead and investigate that claim as it might be a little bit misleading, then see if this is something you should switch to in the future, and also what the V creator thinks this means for the future of open source. So, the project I’m talking about is called OJ, aka orange juice, and the idea is that it’s one Rust binary that I can point at my existing V project and

[00:32] it just runs it. It reads my V config, it still runs my existing V plugins, but the dev server underneath them, so the file watcher, module graph, hot module reloading, and React fast refresh, has all been rewritten in Rust. Funnily enough, this has been done using Rollup down and Oxi, which V8 itself uses and Void Zero maintains. Now, to give this a go myself, I built a TanStack app to see if there’s any differences between running this with V dev or OJ dev. On the surface, it seems they work nearly identically and everything works like server-side rendering, hydration, server functions, fast refresh, dynamic file

[01:03] routes, server routes, Tailwind, and asset imports, but digging a bit deeper, I did notice a few minor differences. The first one was on the fast refresh here. If I edit a file, the V counter here retains its state, but under OJ, the counter resets back to zero, indicating that OJ does a full reload instead of just the component that changed. I actually decided to try and test the same behavior in a plain React app that wasn’t TanStack start, and interestingly, it actually seemed to work here. So, the same edit here keeps the counter the same and it’s not updating the whole page, so it seems to be doing a real hot update. So, I don’t know why there is a difference there

[01:36] between TanStack start and a plain React app, maybe it’s just one of those edge cases that they haven’t considered yet. The second difference that I noticed was with the server function. This server function measures the memory of the dev server’s whole process tree from inside the app, and on this app under V, it’s about 380 MB across two processes, and under OJ, it’s about 320 MB, also across two processes. So, on a small app like this one, it seems the memory usage is roughly the same with OJ only coming out a tiny bit ahead. So, does this mean this project is absolutely useless then? Well, no, because this isn’t really what

[02:07] OJ is built for. OJ actually works best on really big apps. When I tested this on a React app with 5,000 components with a script that spawns each dev server code, opens the page in a real Chrome browser, stops the clock when the deepest component is in the DOM, and then samples the memory of that whole process tree, OJ’s normal mode is about 1.7 times faster to a painted page than default V and uses about a quarter of the memory. Now, to be fair to V, V8.1 did ship an experimental feature called bundle dev mode, and if you turn that on, V actually gets to 1.18 seconds. So, actually a bit quicker than OJ’s normal

[02:40] mode, but it doesn’t save you on memory. And OJ also has a bundle mode as well, which when used makes it quicker again, about 0.89 seconds, and it keeps the memory about a quarter of V’s. So, OJ does seem to have some real memory benefits, and that’s kind of the entire reason that Lovable made this project. Lovable previews run a real V dev server, and Lovable says they run around a million of those sandboxes a day, and at a scale like that, resource consumption really starts to matter. So, Lovable built OJ to get previews that start instantly and stay light without having to give up the ecosystem that

[03:11] makes the app work in the first place. They also made quite a cool design decision around that use case, aka agents. When editing, a person will typically save one file at a time, but an agent can write 10 or so in a burst, and V would actually treat each one of these saves as an update. But in OJ, the watcher, module graph, compiler, and hot updates are one pipeline, so a burst is coalesced into one update. There’s also a gate that you can switch on where updates are held until the agent itself posts to a flush endpoint, so the preview only applies a finished change. You can see this is a very specific

[03:41] project to solve Lovable’s own use cases, and that’s what V’s creator, Evan You, also acknowledged. His first point in his tweet is that it’s a really impressive project that solves Lovable’s own problem well, but it’s not an entire V rewrite. It’s just the dev server and it’s also built on Rollup and Ox C, which Void Zero maintains, so it’s hardly replacing them. The parser, the transformer, and the production bundler in OJ are all Void Zero ones. Lovable just wrote the server around them. You can essentially think of it as V is a node process that drives Rust, whereas OJ is a Rust process driving Rust with a

[04:12] layer in the middle being JavaScript, so it can still talk to V’s plugin API. Evan then also goes on to point out that OJ gets to be fast because it only supports one shape of app. OJ actually only works with React apps, aka the ones that Lovable is generating. V on the other hand has to support every framework, every weird config, every tool built around it, and it deliberately leaves things like ES build or the React plugin as separate packages, so you can add them yourself if they’re needed. After this, he then also picks out the flaws in the benchmark. The blog’s V cold start includes V plugin checker, which runs TypeScript in a background worker, but

[04:44] OJ doesn’t actually support that plugin, so it skips that work entirely. He also points out that in V with the bundle dev mode, it is closer to OJ’s cold start, which is the exact same as what we saw in our numbers, but he does admit that OJ uses significantly less memory, and V should probably aim to improve that. Evan’s final point in this tweet is the one that I find most interesting. Open source dynamics is changing. The cost of re-implementing something has collapsed because of AI, so we’re going to see more of what he calls tailored projections of open source tools. So, the same dependency rebuilt under one component’s constraints to fit one use case. He gives TanStack’s Redact as

[05:17] another example. A possible future is that instead of maintainers being overwhelmed by thousands of slow PRs, everyone just maintains their own slow fork. He says honestly though, he’s not sure if that’s a good thing, but he thinks it’s quite likely that’s what’s going to happen in a few years. So, on one hand, slow forks are better for maintainers than a load of slow PRs would be, but we do risk fragmentation of the ecosystem. I guess only time is going to tell how this will play out and what the future of open source is going to be. Overall, this is not really a tool that anyone besides Lovable is going to use unless you seemingly face the exact same issues of millions of V3

[05:50] dev servers in sandboxes. And I mean, have you really noticed V8 being slow on your own laptop or using too much memory? I personally haven’t, but this is definitely still a cool project and it’s cool that they’ve done this. So, let me know in the comments what you think about it. While you’re there, subscribe. As always, see you in the next one.