„It is up to 100x faster than v2“ – mit diesem Satz beginnt die Ankündigung der ersten Alpha von Parcel 3. Dahinter steht kein kleiner Versionssprung: Der Bundler wurde in Rust neu geschrieben. Für dich bedeutet das kürzere Startzeiten, weniger Speicherverbrauch und ein anderes Plugin-Modell. Dieser Text ordnet die Parcel-3-Alpha ein, erklärt die Zahlen und was sie für JavaScript- und TypeScript-Projekte praktisch bedeuten.
Was der Rust-Rewrite in Parcel 3 ändert
In Parcel 2 waren bereits mehrere Bausteine in Rust geschrieben: der JavaScript-Compiler auf Basis von SWC, Lightning CSS sowie die HTML- und SVG-Transformatoren. Der Kern des Bundlers blieb jedoch JavaScript. Dort lagen die Grenzen, die das Team beschreibt: kein gemeinsamer Speicher zwischen Threads, hoher Speicherverbrauch, Garbage Collection und der Aufwand, Werte zwischen Workern und über Sprachgrenzen zu serialisieren. Jeder Schritt funktionierte, aber Daten mussten ständig kopiert und weitergereicht werden.
Der Rust-Rewrite entfernt diese Zwischenschritte. CLI, Dev-Server, Transformatoren, Bundler und Optimierer liegen jetzt in einem einzigen nativen Programm. Das Binary ist eigenständig und hängt nicht mehr von Node ab. Parcel 3 ist damit ein Rust-Bundler im wörtlichen Sinn. Das ändert, wie Arbeit auf Kerne verteilt wird, und zwar nicht nur an der Oberfläche.
Das Team betont, dass dieselben Compiler wie in Version 2 zum Einsatz kommen. Der Geschwindigkeitsgewinn entsteht nicht durch andere Werkzeuge, sondern durch den Rahmen, in dem sie laufen. Nicht jede Codebasis wird deshalb automatisch 100-mal schneller. Der Umbau verbessert vor allem, wie Parcel Arbeit verteilt, speichert und zwischen Verarbeitungsschritten weitergibt.
Parcel 3 Performance-Benchmark: kalte Builds statt Cache-Feinbau
Die Ankündigung nennt einen konkreten Vergleich: React Spectrum, ein großes TypeScript-Monorepo, einmal mit Parcel 2 und einmal mit Parcel 3 als kalter Development-Build. Dazu kommen ein Storybook mit rund 100 Einträgen, Makros und portierten Plugins, eine Dokumentationsseite mit etwa 340 Seiten, React Server Components, MDX und Tailwind sowie ein Library-Build über rund 160 Pakete und mehr als 14.000 Ausgabedateien. Das sind keine Spielzeugprojekte; an solchen Lasten zeigen sich Architekturentscheidungen. „Bis zu 100x schneller“ ist ein Best-Case-Wert und kein Versprechen für jedes Projekt. Er zeigt aber die Größenordnung, die der Wegfall des JavaScript-Kerns möglich macht.
Interessanter als der Spitzenwert ist der Umgang mit Caching. Parcel 2 hatte stark in Platten-Caching und inkrementelle Builds investiert. Das war sinnvoll, solange die eigentliche Arbeit langsam war: Wenn ein Build ohnehin mehrere Minuten dauert, lohnt es sich, Zwischenergebnisse zu speichern. Parcel 3 dreht die Logik um. Wenn kalte Builds schnell genug sind, wird das Zwischenlager selbst zum Kostenfaktor, weil jede mögliche Invalidierung von Dateien, Umgebungsvariablen, Optionen und Konfigurationen verfolgt werden muss. Diese Buchführung erzeugt Overhead und Fehler mit veralteten Cache-Einträgen.
Die neue Architektur setzt deshalb auf schnelle kalte Builds und behält nur inkrementelle In-Memory-Rebuilds. Ergebnisse müssen nicht mehr für jede Transformation auf die Platte geschrieben werden. Bei Änderungen, die nicht deterministisch sind, etwa an Plugins oder Konfiguration, macht Parcel 3 lieber einen vollständigen Rebuild. Das ist unspektakulärer als ein ausgeklügeltes Cache-System, aber robuster. Du verbringst weniger Zeit mit der Frage, ob ein seltsames Ergebnis aus einem veralteten Cache stammt.
Ein Binary statt hunderter npm-Pakete
Parcel 2 war modular aufgebaut: Fast jede Funktion kam als eigenes npm-Paket. Das war sauber getrennt, führte aber zu hunderten Abhängigkeiten, die gepflegt und aktualisiert werden mussten. Parcel 3 packt die gängigen Webspezifikationen in ein einziges Binary: HTML, CSS, JavaScript, TypeScript, SVG, Bildkonvertierung und -optimierung, RSS- und Atom-Feeds, Web-Manifeste und mehr. Neu hinzu kommen unter anderem Tailwind ohne PostCSS, der React Compiler, MDX, SVG-nach-JSX und Glob-Imports. Die gängigen Funktionen sind ohne Zusatzpakete verfügbar.
Auch die Entwicklungserfahrung bekommt konkrete Verbesserungen. Parcel 3 unterstützt vertrauenswürdiges HTTPS über eine lokale Zertifizierungsstelle, die sich in das Betriebssystem integriert. Die Option –open kann auf macOS einen bereits geöffneten Browser-Tab wiederverwenden. Ein eingebauter Bundle-Analyzer zeigt, warum ein Modul enthalten ist und welche Bundles andere laden. Der neue Befehl parcel run baut und startet einen Node-Eintrag mit Hot Module Replacement und startet den Prozess nur neu, wenn es nötig ist. Das ist besonders für React Server Components und andere Node-Server interessant.
Trotz eingebauter JavaScript-Runtime und all dieser Funktionen bleibt das Parcel-3-Binary unter 30 MB und hat null npm-Abhängigkeiten. Parcel 2 kam inklusive Abhängigkeiten auf etwa 120 MB, das neue Binary ist also rund viermal kleiner. Die Größe ist nicht das wichtigste Kriterium für einen Bundler. Sie zeigt aber, wie viel Ballast durch die konsolidierte Architektur verschwindet. Weniger Pakete bedeuten weniger Installationszeit, weniger Versionskonflikte und weniger Angriffsfläche in der Lieferkette.
Parcel 3 Native Plugins: C-ABI, SDKs und QuickJS
Für Erweiterungen setzt Parcel 3 auf native Plugins. Sie werden als dynamische Bibliotheken zur Laufzeit in den Parcel-Prozess geladen und können in Rust, Go, Swift oder jeder Sprache geschrieben werden, die die C-ABI unterstützt. Parcel stellt eine stabile C-Schnittstelle bereit, über die Plugins Inhalte lesen und setzen, den Bundle-Graphen auslesen und weitere Aufgaben erledigen können. C ist hier die gemeinsame Sprache, weil es niedrig genug liegt und eine stabile ABI bietet, mit der viele höhere Sprachen zusammenarbeiten können. Für Rust, Go und Swift gibt es SDKs, dazu einen wiederverwendbaren GitHub-Actions-Workflow für Cross-Kompilierung und Veröffentlichung auf npm.
Nicht jedes Plugin muss nativ sein. Parcel 3 unterstützt weiterhin JavaScript- und TypeScript-Plugins, was mit fehlendem Node-Kern nicht selbstverständlich ist. Statt Node einzubetten, nutzt Parcel eine eigene JavaScript-Runtime auf Basis von QuickJS. Sie bietet partielle Node-Kompatibilität für die Funktionen, die Build-Plugins typischerweise brauchen, verzichtet aber bewusst auf Dinge wie Netzwerkzugriff. QuickJS erreicht nicht die Spitzenleistung von V8, startet dafür sehr schnell, braucht wenig Speicher und lässt sich auf mehreren Threads parallel betreiben.
Die Empfehlung ist pragmatisch: Für maximale Performance schreibst du native Plugins. Für einfache oder selten aufgerufene Plugins, die nur wenige Dateien verarbeiten, reicht QuickJS. JavaScript-Plugins sind weitgehend mit Parcel 2 kompatibel, es gibt aber kleinere API-Unterschiede, die im Migrationsleitfaden beschrieben sind. Wer eigene Parcel-2-Plugins pflegt, sollte diesen Leitfaden lesen, bevor er die Alpha in einem größeren Projekt einsetzt. Parcel schließt JavaScript-Plugins nicht aus, bietet aber für native Erweiterungen den schnelleren Weg.
Zentrale Konfiguration und besseres Parcel-3-Code-Splitting
Die Konfiguration wird in Parcel 3 zentraler. Schon Parcel 2 kannte die Datei .parcelrc, um festzulegen, welche Plugins laufen. Die Konfiguration der Plugins selbst lag jedoch verstreut in Dateien wie .babelrc, .postcssrc oder package.json. Parcel 3 zieht auch diese Einstellungen in .parcelrc. Das macht Projekte leichter lesbar und verbessert die Performance, weil alle Konfigurationen zu Beginn eines Builds einmal aufgelöst werden, statt während des Builds immer wieder das Dateisystem zu durchsuchen. Für Teams mit vielen kleinen Konfigurationsdateien über ein Monorepo verteilt, ist das eine spürbare Vereinfachung.
Auch die Art, wie Parcel 3 Code aufteilt, wurde überarbeitet. Auf einer Website mit 450 Seiten nennt die Ankündigung 64 Prozent weniger HTTP-Anfragen pro Seite und 10 Prozent weniger übertragene Bytes pro Seite als bei Parcel 2. Dahinter steht ein verbessertes Kostenmodell, das die Anzahl paralleler Anfragen, die Brotli-komprimierte Größe und die Cache-Wiederverwendung sowohl innerhalb einer Sitzung als auch zwischen Builds gegeneinander abwägt. Diese Parameter sollen sich an die Bedürfnisse einer Anwendung anpassen lassen. Statt jede Datei einzeln oder alles in einem großen Bundle auszuliefern, sucht Parcel 3 einen Mittelweg.
Beim Code-Splitting achtet das Team außerdem stärker auf die Korrektheit von CSS. Eine gemeinsame CSS-Datei herauszulösen, verändert die Kaskadenreihenfolge, und das kann Styles kaputt machen. Parcel 3 tut das nur noch, wenn eine Analyse der gesamten Anwendung es nachweislich als sicher einstuft. Werden Stylesheets in widersprüchlicher Reihenfolge importiert, erscheint eine Warnung. Das ist weniger spektakulär als ein neuer Benchmark, aber im Alltag oft wichtiger, weil stille CSS-Fehler viel Zeit kosten können.
Auch das Tree Shaking wurde erweitert: Neben ESM, CommonJS und CSS-Modulen entfernt Parcel nun ungenutzte Elemente aus SVG-Sprites, indem es Verweise wie use href auf eine Sprite-Datei verfolgt. Bei JavaScript wurde das Scope Hoisting entfernt, was die Fehlerfläche verkleinert und Funktionen wie Top-Level-Await ermöglicht, während ein Großteil des Tree-Shaking-Vorteils erhalten bleibt. Für bestehende Projekte ist das eine Entlastung, weil weniger aggressive Optimierungen auch weniger überraschende Randfälle erzeugen. Wer auf jedes letzte Byte optimiert, sollte die Ergebnisse trotzdem selbst messen.
Library Mode, fehlende Bausteine und der Einstieg in die Alpha
Für Bibliotheken ist Parcel schon lange ein bequemer Weg, und Version 3 baut das aus. Parcel liest das Feld package.json#exports automatisch, einschließlich verschachtelter und Multi-Entry-Pakete, und baut alle Ziele parallel. Ein Haupt-Einstiegspunkt und ein Ordner mit Hilfsfunktionen lassen sich so mit einem einzigen parcel build sowohl als ESM- als auch als CJS-Variante erzeugen. Zusätzlich gibt Parcel in Bibliotheken jedes Modul als eigene Ausgabedatei aus, statt alles zu bündeln. Konsumierende Anwendungen können dadurch besser tree shaken und Code aufteilen. TypeScript-.d.ts-Dateien werden in der Alpha noch nicht erzeugt, sollen aber in einer späteren Version zurückkehren.
Der Einstieg ist niedrigschwellig. Du installierst parcel@next, um die Alpha auszuprobieren, oder installierst @parcel/parcel3 und nutzt den Befehl parcel3, um Parcel 3 parallel zu Version 2 zu testen. Der Migrationsleitfaden beschreibt, welche Änderungen im Projekt nötig sind. Noch fehlen einige Bausteine: Compressor-Plugins, die .d.ts-Generierung, eigene Bundler-Plugins und eine programmatische JavaScript-API. Auch bekannte Probleme sind dokumentiert, und Feedback sammelt das Team auf GitHub. Eine Alpha ist kein Release Candidate; das sollte man bei der Planung berücksichtigen.
Für Teams mit großen TypeScript-Monorepos, langsamen CI-Builds und vielen abhängigen npm-Paketen ist Parcel 3 einen ernsthaften Test wert, am besten auf einem separaten Branch mit realen Kaltstart-Messungen. Wer auf ausgefeilte Cache-Invalidierung, eine stabile JavaScript-API oder .d.ts-Generierung angewiesen ist, sollte die Alpha beobachten, aber noch nicht als Fundament für kritische Produktionspipelines einsetzen. Parcel 3 startet schneller, braucht weniger Speicher und erlaubt Erweiterungen über native Schnittstellen. Als TypeScript-Build-Tool ist es interessanter geworden. Die Alpha bleibt ein Zwischenstand: messen, nicht blind übernehmen.
Quelle: v3.parceljs.org
