Lovable’s OJ rewrites Vite’s dev server in Rust, reducing memory use and preview times as AI lowers the cost of open source reimplementation.
- Sarah Gooding
Lovable is beginning to replace Vite inside its cloud preview environments with OJ, a Rust-based build tool created for the demands of running around one million short-lived development sandboxes per day.
The company reported that OJ reduced median sandbox acquisition time from 14.5 seconds to 3 seconds and cut the memory used by the dev server process by roughly 6.5x in a controlled production rollout.
OJ arrives as part of the trend toward rewriting JavaScript tooling in Rust. Other examples include pnpm 12’s Rust rewrite, SWC, Biome, Oxc, Rolldown, and parts of Turbopack.
pnpm’s Rust rewrite was led by its original maintainers. Rspack preserves much of webpack’s configuration and API, while Biome offers a Rust-based formatter with high Prettier compatibility. OJ takes a more company-specific approach: Lovable rebuilt one layer of a general-purpose dependency around the demands of its own infrastructure. Vite creator Evan You expects AI to make that approach much more common.
OJ Rewrites Vite’s Dev Server Layer
OJ has been described as a Rust rewrite of Vite, but both tools use Rolldown for bundling and Oxc for parsing and transformation. Rolldown and Oxc are maintained by the VoidZero team and already power Vite 8.
“It is not an entire rewrite of Vite,” Evan You said on X. The development server is the part Lovable rebuilt in Rust.
OJ moves the file watcher, module graph, compiler coordination, hot updates, and WebSocket handling into a Rust binary. It can read an existing vite.config.ts
and run Vite and Rollup-style plugins through a compatibility bridge, starting a small Node process when an application needs JavaScript plugins or server-side modules.
The narrower target gives Lovable room to optimize aggressively. Vite supports a much wider range of frameworks, plugins, application patterns, and downstream tools. OJ only needs to cover the paths Lovable depends on for its preview sandboxes.
Lovable engineers contend that OJ’s narrower target has not limited it to simple applications. “These are not toy apps,” OJ creator Raphael Amorim wrote after testing it against Excalidraw and Twenty, which “both run on OJ unchanged.” The compatibility work covered regex aliases, source files outside the application root, TypeScript enums, import.meta.env
, and plugin virtual modules. Twenty’s frontend alone contains roughly 15,000 modules.
OJ Uses Less Memory, but Vite Nearly Matches Its Cold Start
Lovable compared bundle-mode OJ with Vite’s default unbundled development mode on a synthetic application containing 10,000 React components. OJ cold-started in about 1.2 seconds, compared with 4.9 seconds for Vite, and used about 115 MB of memory as compared to more than 1.5 GB.
Evan You called the benchmark “somewhat misleading” because Vite has its own bundled development mode. The current OJ benchmark puts the comparable cold-start results much closer: 1,315 milliseconds for bundled OJ and 1,528 milliseconds for bundled Vite on the 10,000-component test.
Memory remains far apart. OJ used 115 MB in that test, compared with 1,751 MB for Vite’s bundled mode. Hot module replacement was effectively even.
Lovable engineer Jonathan Grahl explained why that gap matters to the company: “Memory is a dedicated resource (compared to CPU which is highly shareable); which makes it expensive.” He said OJ’s development server was idling at around 400 MB and that Lovable hoped to push it lower so it could pack more sandboxes onto each host.
When another developer asked how much of the memory advantage survived once the Node plugin host was running with a real vite.config
, OJ creator Raphael Amorim said tests still showed OJ using less than one-third as much memory.
Lovable also disclosed that one of its real-application comparisons included vite-plugin-checker
on the Vite side. That plugin starts a TypeScript worker, while OJ does not currently support it and skipped the work. The caveat weakens the largest speed comparison, but it does not explain away OJ’s much lower memory use.
In production, the gains extended beyond dev-server startup. OJ’s smaller binary and sandbox image reduced the provisioning time before an application could begin serving.
AI Could Produce a Wave of Company-Specific “Slop Forks”
Native rewrites were already accelerating before the current generation of coding agents. AI changes who can afford to undertake them, how narrow a project can be, and what downstream users may choose to maintain for themselves. Evan You sees consequences for both open source maintainers and the companies that depend on their work:
“Open source dynamics is changing. With the cost of re-implementation collapsing due to AI, we will likely continue to see more ‘tailored projections’ of open source dependencies that are re-implemented under different constraints to optimize for specific use cases (TanStack’s redact comes to mind). A possible future is instead of maintainers being overwhelmed by thousands of slop PRs, everyone just maintains their own slop fork. I am honestly not sure if that’s good or not, but I think it’s quite likely what will happen in a few years.”
TanStack’s Redact, the example You cited as a “tailored projection," preserves React’s APIs and existing application imports while replacing the runtime with a smaller, synchronous implementation.
OJ takes a similar approach to Vite compatibility, preserving the pieces Lovable needs while replacing the layer that costs the company the most in its sandbox fleet.
AI makes these projects easier to attempt. Teams can study an established implementation, generate compatibility tests, translate components into another language, and close behavioral gaps much faster. Instead of persuading an upstream project to accept changes optimized for one company’s workload, they can maintain their own compatible implementation.
That freedom comes with more fragmentation. Each new implementation has to track upstream behavior, dependency releases, security patches, and edge cases. A Vite-compatible server does not automatically receive a fix made in Vite’s Node development server, and compatibility can mean something different for every fork.
OJ, Redact, and Rspack keep familiar APIs while replacing the underlying code. AI makes that easier. An established project can remain the standard even as more companies replace parts of it for their own workloads.
That is the risk behind everyone maintaining their own "slop fork." Changes that once might have gone upstream can now more easily be slotted into a company’s own version. Users may see the same imports and configuration, but fixes and improvements are now split across several projects. If that becomes common, more engineering work could move into downstream implementations even as the original project’s API becomes more influential.