Lovable Rewrote Vite in Rust... (kind of)

Author: Better Stack · Watch on YouTube

Video authored by the channel shown, not by IANIA; all rights belong to the creator. Transcript and summary generated automatically; the original-language content is preserved.

Original language: English

Original video: Lovable Rewrote Vite in Rust… (kind of) · Channel: Better Stack · 05:50 · Watch on YouTube

Topics: Software engineering with AI, AI developer tools, Open source and software ecosystems

Summary

Lovable’s OJ is a Rust-based replacement for Vite’s development server, designed to work with existing Vite projects and plugins. In the video’s tests, OJ offers little advantage on a small app, but on a large React app it starts faster and uses substantially less memory, especially in bundle mode. Its speed and focus reflect Lovable’s specific needs, and it supports only React apps while relying on Void Zero’s tooling. The video also considers Evan You’s view that AI may make tailored forks of open-source tools more common, potentially increasing ecosystem fragmentation.

Key points

OJ, or Orange Juice, is a Rust binary that runs an existing Vite project, using its configuration and plugins while replacing the development server.
The rewritten parts include the file watcher, module graph, hot module reloading, and React Fast Refresh.
In the TanStack app test, OJ and Vite worked similarly overall, but OJ reset component state during Fast Refresh where Vite retained it.
On the small test app, memory use was roughly similar: about 380 MB for Vite and 320 MB for OJ.
On a React app with 5,000 components, OJ’s normal mode reached a painted page about 1.7 times faster than default Vite and used about a quarter of the memory.
Vite’s experimental bundle dev mode was slightly faster than OJ’s normal mode in the test, but did not reduce memory use; OJ’s bundle mode was faster still.
OJ is tailored to Lovable’s large volume of preview sandboxes and can coalesce bursts of agent edits into one update.
OJ supports React apps rather than Vite’s broader range of frameworks and configurations, and it uses Void Zero’s parser, transformer, and production bundler.
Evan You argues that AI may make tailored projections or forks of open-source tools more common, bringing both potential benefits for maintainers and a risk of ecosystem fragmentation.

Chapters

Start	Chapter	Summary
00:00	What OJ changes	The video introduces Lovable’s Rust-based Vite dev server and explains how it fits into an existing Vite project.
01:36	Testing performance	Small-app results show similar memory use, while tests on a large React app reveal stronger speed and memory benefits for OJ.
03:11	Lovable’s use case and OJ’s scope	OJ is designed for Lovable’s agent-driven previews, and Evan You notes that it is a focused dev-server replacement rather than a full Vite rewrite.
04:44	Benchmarks and open-source forks	The video discusses benchmark caveats and the possibility that AI will encourage tailored forks, with both maintenance benefits and fragmentation risks.

Quotes

there’s been another Rust rewrite — 00:00

OJ actually works best on really big apps. — 02:07

a burst is coalesced into one update. — 03:11

Open source dynamics is changing. — 04:44

we do risk fragmentation of the ecosystem. — 05:17

Concepts and entities

OJ, Vite, Rust, Lovable, Evan You, Rollup, Oxc, Void Zero, TanStack Start, Redact

Full transcript (original language)

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.