Median sandbox acquisition time: 14.5s to 3s (Source: Lovable, reported by Socket.dev (September 2026))
A Dev Server Rebuilt for One Company's Scale
Lovable, the AI app-building platform, is beginning to replace Vite inside its cloud preview environments with OJ, a Rust-based tool built for the demands of running roughly one million short-lived development sandboxes per day. OJ is not a full rewrite of Vite. It replaces one layer — the file watcher, module graph, compiler coordination, hot updates, and WebSocket handling in the dev server — while continuing to rely on Rolldown and Oxc, the same bundling and parsing engines that already power Vite 8. "It is not an entire rewrite of Vite," Vite creator Evan You said on X.
The Speed Gap Narrows. The Memory Gap Doesn't.
Lovable's initial comparison pitted bundle-mode OJ against Vite's default unbundled development mode on a synthetic application with 10,000 React components, finding OJ cold-starting in about 1.2 seconds against 4.9 seconds for Vite. Evan You called that comparison "somewhat misleading" because Vite has its own bundled development mode. Once both tools were compared in bundled mode, the cold-start gap nearly closed: 1,315 milliseconds for OJ versus 1,528 milliseconds for Vite. Lovable also disclosed that one of its real-application comparisons included a Vite plugin, vite-plugin-checker, that starts a TypeScript worker OJ does not currently support and skips — a caveat that weakens the largest speed claim without addressing the memory gap. OJ creator Raphael Amorim said the tool has been tested against production-scale codebases, including Excalidraw and Twenty, whose frontend alone contains roughly 15,000 modules and "both run on OJ unchanged."
AI Lowers the Cost of Forking Shared Infrastructure
OJ is one entry in a wider shift toward rewriting JavaScript tooling in Rust, alongside pnpm's Rust rewrite, SWC, Biome, Oxc, Rolldown, and parts of Turbopack. What distinguishes OJ, in Evan You's framing, is that it is a company-specific reimplementation: Lovable rebuilt one layer of a general-purpose dependency around its own sandbox fleet rather than contributing the changes upstream. Evan You said he expects AI to make that approach "much more common," pointing to TanStack's Redact — which preserves React's APIs while replacing the runtime with a smaller, synchronous implementation — as a similar "tailored projection." The tradeoff is fragmentation: a Vite-compatible server does not automatically receive a fix made in Vite's own development server, and what "compatible" means can differ from one fork to the next. As AI lowers the cost of translating an established project into a narrower, company-specific version, more of the engineering work behind widely used developer infrastructure could move into separately maintained forks even as the original project's interfaces remain the standard.
What Budget Holders Should Ask
The operative question for organizations that depend on AI-assisted development platforms, or that maintain their own build and preview infrastructure, is not whether a Rust rewrite runs faster. It is whether any team has quietly forked shared tooling to solve a scaling problem, and who owns the job of pulling upstream security fixes into that fork once it diverges. Budget holders overseeing engineering and security spend should ask their teams to list any internally maintained forks or reimplementations of open-source build tools or frameworks, and confirm there is a defined process for tracking upstream patches once a compatibility layer exists between the fork and the original project.
