O Lovable reescreveu o Vite em Rust... (mais ou menos)
BBetter Stack
Computing/SoftwareSmall Business/StartupsInternet Technology
Transcript
00:00:00Você pode adicionar mais um à contagem, pois houve outra reescrita em Rust, desta vez o servidor de
00:00:03desenvolvimento do Vite sendo reescrito em Rust pela equipe da Lovable, supostamente alcançando quatro vezes menos
00:00:07uso de memória e inicializações a frio duas vezes mais rápidas. Então vamos investigar essa afirmação, pois ela pode ser
00:00:12um pouco enganosa, e depois ver se isso é algo para o qual você deve mudar no futuro,
00:00:15e também o que o criador do Vite acha que isso significa para o futuro do código aberto.
00:00:24O projeto de que estou falando se chama OJ, ou Orange Juice, e a ideia é que ele seja um único
00:00:29binário em Rust que posso apontar para o meu projeto Vite existente e ele simplesmente roda. Ele lê minha
00:00:33configuração do Vite, ainda roda meus plugins do Vite existentes, mas o servidor de dev por baixo deles, ou seja, o observador
00:00:38de arquivos, o grafo de módulos, o hot module reloading e o react fast refresh foram todos reescritos em Rust.
00:00:44Curiosamente, isso foi feito usando rolldown e oxy, que o próprio Vite usa e a void zero
00:00:49mantém. Agora, para testar isso eu mesmo, criei um app com TanStack para ver se há diferenças
00:00:53entre rodar isso com Vite dev ou OJ dev. Na superfície, parece que eles funcionam de forma quase idêntica,
00:00:58e tudo funciona, como renderização no servidor, hidratação, funções de servidor, fast refresh,
00:01:03rotas dinâmicas de arquivos, rotas de servidor, Tailwind e importação de assets, mas analisando um pouco mais a fundo,
00:01:07notei algumas pequenas diferenças. A primeira foi no fast refresh. Se eu edito um arquivo,
00:01:13o contador do Vite mantém o estado, mas no OJ, a contagem é reiniciada para zero,
00:01:17indicando que o OJ faz um recarregamento completo em vez de apenas do componente alterado. Eu decidi tentar
00:01:22testar esse mesmo comportamento em um app React comum que não usava TanStack Start,
00:01:26e, curiosamente, pareceu funcionar aqui. A mesma edição mantém a contagem igual,
00:01:30e não atualiza a página inteira, então parece estar fazendo uma atualização instantânea real. Não sei o motivo
00:01:35de haver essa diferença entre o TanStack Start e um app React comum, talvez seja apenas um daqueles
00:01:39casos isolados que eles ainda não consideraram. A segunda diferença que notei foi com a
00:01:42função de servidor. Essa função mede a memória de toda a árvore de processos do servidor de dev por
00:01:46dentro do app, e neste app rodando no Vite, é cerca de 380MB em dois processos, e no OJ,
00:01:53é cerca de 320MB também em dois processos. Então, em um app pequeno como este, parece que o uso
00:01:59de memória é praticamente o mesmo, com o OJ levando uma vantagem muito pequena. Isso significa que este projeto é
00:02:04totalmente inútil? Bem, não, porque não é realmente para isso que o OJ foi criado. O OJ funciona
00:02:09melhor em aplicações realmente grandes. Quando testei em um app React com 5.000 componentes, com um script que
00:02:14inicia cada código de servidor dev, abre a página em um navegador Chrome real, para o cronômetro quando o
00:02:19componente mais profundo está no DOM, e então amostra a memória de toda essa árvore de processos, o modo normal do OJ
00:02:24é cerca de 1,7 vez mais rápido para renderizar a página do que o Vite padrão, e usa cerca de um quarto da
00:02:29memória. Para ser justo com o Vite, o Vite 8.1 lançou um recurso experimental chamado modo dev empacotado,
00:02:34e se você o ativa, o Vite chega a 1,18 segundo, um pouco mais rápido que o modo normal do OJ,
00:02:40mas não economiza memória. E o OJ também tem um modo empacotado, que quando usado
00:02:45o torna ainda mais rápido, em cerca de 0,89 segundo, e mantém a memória em cerca de um quarto da do Vite.
00:02:51Portanto, o OJ parece ter vantagens reais de memória, e esse é o motivo principal pelo qual a Lovable
00:02:55criou este projeto. As pré-visualizações da Lovable executam um servidor de dev do Vite real, e a Lovable afirma rodar cerca de
00:03:00um milhão desses ambientes de teste por dia, e em uma escala como essa, o consumo de recursos
00:03:04realmente começa a importar. Por isso, a Lovable construiu o OJ para obter pré-visualizações que iniciem instantaneamente e permaneçam leves,
00:03:09sem precisar abrir mão do ecossistema que faz o app funcionar em primeiro lugar.
00:03:13Eles também tomaram uma decisão de design muito interessante em torno desse caso de uso, ou seja, os agentes. Ao editar,
00:03:17uma pessoa normalmente salva um arquivo por vez, mas um agente pode gravar cerca de 10 em um disparo,
00:03:22e o Vite trataria cada um desses salvamentos como uma atualização, mas no OJ, o observador,
00:03:26o gráfico de módulos, o compilador e as atualizações rápidas são um fluxo único, então o disparo é unificado em uma só atualização.
00:03:32Há também uma trava que você pode ativar onde as atualizações ficam retidas até que o próprio agente
00:03:35faça uma requisição de liberação, fazendo com que a pré-visualização aplique apenas a alteração finalizada. É possível ver que este é
00:03:40um projeto muito específico para resolver o caso de uso da própria Lovable, e foi isso que o criador do Vite, Evan You,
00:03:45também reconheceu. O primeiro ponto dele neste tweet é que é um projeto realmente impressionante que resolve
00:03:49bem o problema da Lovable, mas não é uma reescrita completa do Vite. É apenas o servidor de dev,
00:03:54e também é construído sobre o Rolldown e o Oxy, que a void0 mantém, então dificilmente irá substituí-los.
00:04:00O analisador, o transformador e o empacotador de produção no OJ são todos da void0,
00:04:04a Lovable apenas escreveu o servidor em volta deles. Você pode pensar essencialmente nisso como o Vite sendo um processo Node
00:04:08que roda Rust, enquanto o OJ é um processo Rust rodando Rust, com uma camada no meio
00:04:13em JavaScript para ainda se comunicar com a API de plugins do Vite. Evan continua destacando
00:04:17que o OJ consegue ser rápido porque suporta apenas um formato de app. O OJ na verdade só funciona com
00:04:22os apps em React, ou seja, os que a Lovable está gerando. O Vite, por outro lado, precisa
00:04:27suportar todos os frameworks, todas as configurações estranhas, todas as ferramentas criadas ao redor dele, e mantém deliberadamente
00:04:31coisas como o ESBuild ou o plugin do React como pacotes separados, para que você possa adicioná-los se forem
00:04:36necessários. Depois disso, ele também aponta as falhas no benchmark. A inicialização a frio do Vite no blog
00:04:40inclui o Vite plugin checker, que roda o TypeScript em segundo plano, mas o OJ na verdade não
00:04:45suporta esse plugin, então ignora esse trabalho completamente. Ele também aponta que no Vite, com o modo dev
00:04:50empacotado, fica mais próximo da inicialização a frio do OJ, exatamente o mesmo que vimos em nossos números, mas ele
00:04:55admite que o OJ usa significativamente menos memória, e que o Vite provavelmente deveria focar em melhorar isso.
00:04:59O ponto final de Evan neste tweet é o que acho mais interessante. A dinâmica do código aberto está
00:05:03mudando, o custo de reimplementar algo despencou por conta da IA, então veremos mais
00:05:08do que ele chama de projeções sob medida de ferramentas de código aberto, ou seja, a mesma dependência, recriada sob as
00:05:13restrições de um componente para se adequar a um caso de uso. Ele dá o redact do TanStack como outro exemplo. Um futuro
00:05:19possível é que, em vez de mantenedores sobrecarregados com milhares de PRs genéricas, todos
00:05:23apenas mantenham sua própria versão adaptada. Ele diz francamente que não tem certeza se isso é algo bom, mas
00:05:28acha bastante provável que seja o que vai acontecer em alguns anos. Por um lado, versões adaptadas são melhores
00:05:33para os mantenedores do que um monte de PRs, mas corremos o risco de fragmentar o ecossistema. Acho que
00:05:39apenas o tempo dirá como isso vai se desenrolar e qual será o futuro do código aberto.
00:05:43No geral, esta não é bem uma ferramenta que alguém além da Lovable vá usar, a menos que você
00:05:47enfrente exatamente os mesmos problemas de milhões de servidores de dev do Vite em ambientes de teste, e quero dizer,
00:05:52você realmente já notou o Vite lento em algum momento no seu próprio notebook ou usando memória demais? Eu pessoalmente
00:05:57não notei, mas este ainda é definitivamente um projeto legal, e é muito bacana que eles tenham feito isso,
00:06:01então me diga nos comentários o que você achou. Aproveite para se inscrever e, como sempre,
00:06:04nos vemos no próximo vídeo.
00:06:09Nos vemos no próximo vídeo.
Community Posts
No posts yet. Be the first to write about this video!
Write about this video