Lovable hat Vite in Rust neu geschrieben... (gewissermaßen)
BBetter Stack
Computing/SoftwareSmall Business/StartupsInternet Technology
Transcript
00:00:00Es gibt wieder einen Rewrite in Rust: Dieses Mal wurde der Dev-Server
00:00:03von Vite vom Lovable-Team in Rust neu geschrieben. Er soll viermal weniger
00:00:07Speicher verbrauchen und doppelt so schnell starten. Untersuchen wir diese Behauptung also mal,
00:00:12da sie etwas irreführend sein könnte, und schauen wir, ob sich ein Wechsel lohnt,
00:00:15und was der Erfinder von Vite über die Zukunft von Open Source denkt.
00:00:24Das Projekt heißt OJ, kurz für Orange Juice. Die Idee dahinter ist eine einzige
00:00:29Rust-Binary, die ich auf mein Vite-Projekt richte und die einfach läuft. Sie liest meine Vite-Config,
00:00:33führt meine Plugins aus, aber der Dev-Server darunter – also File Watcher,
00:00:38Module Graph, Hot Module Replacement und React Fast Refresh – wurde komplett in Rust neu geschrieben.
00:00:44Lustigerweise geschah das mit Rolldown und Oxc, was auch Vite nutzt und von void0
00:00:49gepflegt wird. Um es selbst zu testen, habe ich eine TanStack-App gebaut und verglichen,
00:00:53wie sie sich mit “vite dev” vs. “oj dev” verhält. Oberflächlich wirken beide fast identisch,
00:00:58und alles funktioniert: Server-Side Rendering, Hydration, Server Functions, Fast Refresh,
00:01:03dynamische File-Routes, Server-Routes, Tailwind und Asset-Imports. Aber beim genauen Hinsehen
00:01:07fielen mir ein paar kleine Unterschiede auf. Der erste betraf Fast Refresh: Wenn ich eine Datei editiere,
00:01:13behält der Zähler bei Vite seinen Zustand, aber unter OJ wird er auf 0 zurückgesetzt.
00:01:17Das deutet darauf hin, dass OJ einen Full Reload macht statt nur die geänderte Komponente zu laden.
00:01:22Ich wollte dieses Verhalten dann in einer normalen React-App ohne TanStack Start testen,
00:01:26und interessanterweise hat es dort geklappt. Dieselbe Änderung behält den Zähler bei,
00:01:30ohne die ganze Seite zu aktualisieren – es macht also ein echtes Hot Update. Warum es diesen
00:01:35Unterschied zwischen TanStack Start und React gibt, weiß ich nicht; vermutlich ein Randfall,
00:01:39den sie noch nicht bedacht haben. Der zweite Unterschied betraf die
00:01:42Server Function. Sie misst den Speicher des gesamten Prozessbaums des Dev-Servers
00:01:46aus der App heraus. Bei Vite liegt er bei ca. 380 MB über zwei Prozesse, bei OJ
00:01:53sind es ca. 320 MB, ebenfalls über zwei Prozesse. Bei einer kleinen App wie dieser ist der
00:01:59Speicherverbrauch also etwa gleich, wobei OJ nur minimal vorn liegt. Ist das Projekt damit
00:02:04völlig nutzlos? Nein, denn dafür ist OJ gar nicht gebaut. OJ entfaltet seine Stärke
00:02:09erst bei wirklich großen Apps. Ich habe das in einer React-App mit 5000 Komponenten getestet,
00:02:14mit einem Skript, das jeweils den Dev-Server startet, die Seite im echten Chrome öffnet,
00:02:19stoppt sobald die tiefste Komponente im DOM ist, und dann den Speicher des Prozessbaums misst.
00:02:24OJs normaler Modus ist ca. 1,7-mal schneller beim Rendering als Standard-Vite und braucht nur ein Viertel
00:02:29Um Vite gegenüber fair zu bleiben: Vite 8.1 hat eine experimentelle Funktion namens “bundled dev mode” veröffentlicht,
00:02:34und aktiviert erreicht Vite 1,18 Sekunden – also etwas schneller als OJs
00:02:40Normalmodus, spart aber keinen Speicher. OJ hat ebenfalls einen Bundle-Modus, der es
00:02:45noch schneller macht (ca. 0,89 Sekunden) und den Speicher bei etwa einem Viertel von Vite hält.
00:02:51OJ bietet also echte Speichervorteile, und das ist genau der Grund, warum Lovable
00:02:55dieses Projekt entwickelt hat. Lovable-Previews nutzen einen echten Vite-Dev-Server, und laut Lovable
00:03:00führen sie rund eine Million dieser Sandboxes pro Tag aus. Bei dieser Skalierung
00:03:04wird der Ressourcenverbrauch extrem wichtig. Lovable baute OJ für Previews, die sofort starten
00:03:09und leicht bleiben, ohne das Ökosystem aufzugeben, das die App überhaupt erst ermöglicht.
00:03:13Sie haben auch eine smarte Designentscheidung für diesen Anwendungsfall (KI-Agenten) getroffen.
00:03:17Ein Mensch speichert meist eine Datei nach der anderen, aber ein Agent schreibt schnell 10 Dateien auf einmal.
00:03:22Vite würde jedes Speichern als einzelnes Update behandeln, aber bei OJ bilden Watcher,
00:03:26Module Graph, Compiler und Hot Updates eine Pipeline. So wird eine Serie in ein Update zusammengefasst.
00:03:32Es gibt auch eine Schranke, die Updates zurückhält, bis der Agent selbst
00:03:35einen Flush-Endpunkt aufruft, sodass die Vorschau nur fertige Änderungen übernimmt. Wie man sieht,
00:03:40ist das ein sehr spezifisches Projekt für Lovables eigenen Zweck. Genau das hat auch
00:03:45Vite-Erfinder Evan You angemerkt. Sein erster Punkt in diesem Tweet ist, dass es beeindruckend ist
00:03:49und Lovables Problem gut löst, aber eben kein kompletter Rewrite von Vite ist. Es ist nur der Dev-Server,
00:03:54und er basiert auf Rolldown und Oxc von void0 – es ersetzt diese also keineswegs.
00:04:00Parser, Transformer und Production-Bundler in OJ stammen alle von void0;
00:04:04Lovable hat nur den Server drumherum geschrieben. Man kann sich das so vorstellen: Vite ist ein Node-Prozess,
00:04:08der Rust steuert, während OJ ein Rust-Prozess ist, der Rust steuert, mit einer JavaScript-Schicht
00:04:13in der Mitte zur Kommunikation mit Vites Plugin-API. Evan betont außerdem,
00:04:17dass OJ nur deshalb so schnell ist, weil es nur eine Art von App unterstützt: OJ funktioniert nämlich nur
00:04:22mit den React-Apps, die Lovable generiert. Vite hingegen muss
00:04:27jedes Framework, jede ungewöhnliche Config und jedes Tool abdecken und belässt Dinge wie
00:04:31esbuild oder das React-Plugin bewusst als separate Pakete, die man bei Bedarf hinzufügt.
00:04:36Danach weist er auf Schwächen im Benchmark hin: Der Kaltstart im Blogpost
00:04:40beinhaltet “vite-plugin-checker”, das TypeScript im Hintergrund ausführt. OJ unterstützt
00:04:45dieses Plugin gar nicht und überspringt die Arbeit komplett. Er merkt auch an, dass Vites Bundled Dev
00:04:50Mode nah an OJs Kaltstart heranreicht – genau wie in unseren Messungen. Aber er gibt zu,
00:04:55dass OJ deutlich weniger Speicher verbraucht und Vite das verbessern sollte.
00:04:59Evans letzter Punkt im Tweet ist der spannendste: Die Dynamik in Open Source verändert sich.
00:05:03Der Aufwand für Re-Implementierungen ist durch KI extrem gesunken. Wir werden also mehr
00:05:08maßgeschneiderte Projektionen von Open-Source-Tools sehen: dieselbe Dependency, neu gebaut unter den
00:05:13Vorgaben einer Komponente für genau einen Zweck. Er nennt TanStacks Redact als weiteres Beispiel.
00:05:19Eine mögliche Zukunft: Statt dass Maintainer von Tausenden PRs überrollt werden, pflegt
00:05:23einfach jeder seinen eigenen Fork. Ehrlich gesagt weiß er nicht, ob das gut ist,
00:05:28hält es aber für recht wahrscheinlich in den nächsten Jahren. Einerseits sind solche Forks für
00:05:33Maintainer besser als unzählige PRs, andererseits riskieren wir eine Fragmentierung des Ökosystems.
00:05:39Erst die Zeit wird zeigen, wohin sich das entwickelt und wie die Zukunft von Open Source aussieht.
00:05:43Insgesamt ist das kaum ein Tool für jemanden außerhalb von Lovable – außer man hat
00:05:47exakt dieselben Probleme mit Millionen Vite-Dev-Servern in Sandboxes. Denn mal ehrlich:
00:05:52Ist euch Vite auf dem Laptop jemals zu langsam vorgekommen oder hat zu viel Speicher verbraucht?
00:05:57Mir persönlich nicht. Dennoch ist es ein cooles Projekt und stark, dass sie es umgesetzt haben.
00:06:01Schreibt mir eure Meinung dazu in die Kommentare. Abonniert den Kanal und wie immer:
00:06:04Bis zum nächsten Mal!
00:06:09Bis zum nächsten Mal!
Community Posts
No posts yet. Be the first to write about this video!
Write about this video