Ladybird erkunden: Das Nicht-Chromium-Browserprojekt

Ladybird ist eine von Grund auf neu entwickelte Webbrowser-Engine — ohne Chromium, ohne WebKit, ohne Gecko-Abstammung — entwickelt von der Ladybird Browser Initiative, einer gemeinnützigen Organisation nach 501(c)(3), gegründet von Andreas Kling und Chris Wanstrath. Es ist die erste wirklich neue, unabhängige Browser-Engine seit über einem Jahrzehnt, die ein Niveau der Standardkonformität erreicht hat, das die Aufmerksamkeit von Frontend-Entwicklern verdient. Dieser Artikel beantwortet die drei Fragen, die ein Entwickler tatsächlich hat, nachdem er „Ladybird” auf Hacker News oder X in den Trends gesehen hat: Ist es real, ist die Alpha-Version 2026 bedeutsam, und ändert es etwas an dem Web, das man ausliefert? Die Kurzfassung lautet: ja, möglicherweise und noch nicht — aber die Entwicklungstrajektorie ist das Interessante daran.

Was Ladybird ist und wer es entwickelt

Ladybird ist eine unabhängige Browser-Engine ohne gemeinsamen Code von Blink, WebKit oder Gecko, verwaltet von der Ladybird Browser Initiative — einer eingetragenen gemeinnützigen Organisation nach 501(c)(3). Laut der Organisationsseite des Projekts besteht die aktuelle Führung aus Andreas Kling als Präsident, Tim Flynn als Sekretär und Mike Shaver als Schatzmeister. Das Projekt begann als HTML-Viewer innerhalb von SerenityOS, Klings Hobby-Betriebssystem, bevor es sich zu einem eigenständigen, plattformübergreifenden Browser weiterentwickelte.

Die Governance-Struktur ist ein stärkeres Signal für die Ernsthaftigkeit des Projekts als jede Funktionsliste. Ladybird wird durch Sponsoring und Spenden finanziert, nicht durch Werbung oder Geräteverkäufe. Chris Wanstrath — Mitgründer von GitHub — ist Mitgründer der Initiative, und seine Familie hat eine Spende von 1 Million US-Dollar zugesagt, wie auf awesomekling.github.io bekannt gegeben wurde. Die Sponsorenliste des Projekts, aufgeführt auf ladybird.org (abgerufen April 2026), umfasst Platinum-Sponsoren wie FUTO, Shopify und Cloudflare sowie Gold-Sponsoren, darunter die Human Rights Foundation, Proton, Guillermo Rauch und Ohne Makler. Die aktuelle Einstufung sollte direkt auf der Website überprüft werden, da sie sich mit dem Wachstum des Projekts ändert.

Dies ist die entscheidende Antwort für Skeptiker: eine benannte juristische Person, benannte Führungskräfte, benannte Unternehmenssponsoren und eine nachweisbare Finanzierungszusage. Ladybird ist kein Wochenend-Prototyp.

Warum eine neue Browser-Engine selten ist

Das Web läuft auf drei Engines — Googles Blink, Apples WebKit und Mozillas Gecko — und eine wirklich neue ist selten, weil die Einstiegshürde enorm hoch ist. Das letzte Mal, als eine neue unabhängige Engine eine nennenswerte Verbreitung erreichte, lieferte Opera noch Presto aus; das endete 2013, als Opera zu einem Chromium-basierten Browser wechselte, und Microsofts Abkehr von EdgeHTML gipfelte 2020 in der stabilen Veröffentlichung des Chromium-basierten Edge. Heute ist das Web weitgehend von diesen drei Rendering-Engines abhängig, wobei Blink den dominanten Anteil an der Browsernutzung hält, laut StatCounter.

Eine neue Engine zu entwickeln ist außerordentlich schwierig, da sie zehntausende von Kompatibilitätstests bestehen und HTML, CSS, JavaScript, Grafik, Sicherheit, Barrierefreiheit und Performance im Web-Maßstab korrekt verarbeiten muss. Der Maßstab für diese Anforderungen ist die Web Platform Tests (WPT)-Suite, ein herstellerübergreifendes Konformitätsprojekt. WPT enthält Millionen einzelner Subtests; das Verhalten nachzubilden, auf das reale Websites angewiesen sind — einschließlich undokumentierter Eigenheiten, die etablierte Engines seit Jahrzehnten ausliefern — ist die Arbeit, die unabhängige Engines historisch gesehen zum Scheitern gebracht hat. Eine strikte Standardsimplementierung, die Websites beschädigt, die auf diesen Eigenheiten beruhen, besteht den einzigen Test nicht, der kommerziell wirklich zählt: das bestehende Web korrekt darzustellen.

Das ist der Kontext, der Ladybird bemerkenswert macht. Es konkurriert nicht über Funktionen. Es versucht, die Konformitätshürde zu überwinden, die die Konsolidierung des letzten Jahrzehnts nahezu unüberwindbar gemacht hat.

Ein Blick in die Ladybird-Architektur

Ladybirds Multi-Prozess-Architektur trennt Rendering, Bild-Dekodierung und Netzwerkanfragen in separate, sandboxed Prozesse, die über Inter-Prozess-Kommunikation koordiniert werden. Laut der Dokumentation und dem Quellcode-Layout des Projekts teilt sich die Engine in einen Haupt-UI-Prozess und eine Reihe von Hilfsprozessen auf: WebContent übernimmt Rendering und Script-Ausführung, ImageDecoder dekodiert Bilder, und RequestServer verarbeitet Netzwerkanfragen. Jeder Web-Content-Prozess läuft in einer Sandbox.

Der Zweck dieser Aufteilung ist die Kapselung an einer Prozessgrenze. Die Dekodierung nicht vertrauenswürdiger Bilddaten — eine historisch häufige Quelle von Memory-Corruption-Bugs — findet in ImageDecoder statt, isoliert vom Rendering-Prozess. Die Netzwerkverarbeitung liegt in RequestServer, isoliert vom Seiteninhalt. Die Prozesstrennung selbst ist der nachweisbare Design-Ansatz; die Grenzen sind der Ort, an dem Ladybirds Sicherheitsmodell angesiedelt ist, modelliert nach den Multi-Prozess-Designs, die Mainstream-Browser in den letzten fünfzehn Jahren übernommen haben.

Die Rendering- und Scripting-Arbeit ist auf eine Reihe von Bibliotheken aufgeteilt, die jeweils auf eine Schicht der Plattform ausgerichtet sind:

LibJS verdient besondere Erwähnung, da es sich nicht um einen dünnen Wrapper über eine bestehende JavaScript-Engine wie V8 oder JavaScriptCore handelt — es ist eine vollständige Implementierung mit eigenem Lexer, Parser, AST, Bytecode-Generator und Bytecode-Interpreter. Dieses Detail ist für den nächsten Abschnitt relevant, da das Frontend dieser Pipeline der Ort ist, an dem die bedeutendste jüngste Ingenieurarbeit des Projekts gelandet ist.

Sprachstrategie: C++-Kern, Rust in Entwicklung

Ladybirds Kern ist in modernem C++ geschrieben, aber das Team hat begonnen, performance- und sicherheitskritische Komponenten nach Rust zu migrieren. Im Februar 2026 landete das Projekt eine Rust-Reimplementierung der LibJS-Frontend-Pipeline — bestehend aus Lexer, Parser, AST, Scope Collector und Bytecode-Generator — mit standardmäßig aktivierter Rust-Pipeline, wie im Newsletter vom Februar 2026 berichtet. Dies ist die aktuellste und technisch bedeutsamste Entwicklung im Projekt und fehlt in früheren Berichten.

Die Motivation entspricht dem üblichen Grund für die Einführung von Rust in einer Browser-Engine: Memory Safety in Code-Pfaden, die nicht vertrauenswürdige Eingaben verarbeiten. Ein JavaScript-Parser verarbeitet bei jedem Seitenaufruf beliebigen, potenziell angreifer-kontrollierten Text, was ihn zu genau der Art von Komponente macht, bei der eine Memory-Safety-Garantie auf Sprachebene eine ganze Klasse von Sicherheitslücken eliminiert. Klar definierte Interop-Grenzen ermöglichen außerdem eine schrittweise Migration — das Rust-Frontend kann Bytecode an den bestehenden C++-Interpreter übergeben, ohne einen vollständigen Neuschrieb zu erfordern.

Dies war nicht das erste Experiment des Projekts jenseits von C++. Ladybird hatte zuvor Swift für Teile der Codebasis erprobt und später den gesamten Swift-Code entfernt, bevor man sich für Rust entschied. Der Wechsel von „wir probieren Swift aus” zu „die Rust-Frontend-Pipeline wird standardmäßig ausgeliefert” ist ein Zeichen technischer Reife: Das Projekt trifft und revidiert Sprachentscheidungen nun bewusst, anstatt C++ als dauerhaft gegeben zu betrachten.

Standardkonformität: Der aktuelle Stand von Ladybird

Stand April 2026 meldete Ladybird 2.067.263 bestandene Web Platform Test-Subtests — ein Anstieg gegenüber 2.003.537 im vorherigen Zeitraum — laut dem Newsletter vom April 2026, zusammen mit einer Bestehensquote von 97,8 % bei 52.045 von 53.207 importierten test262-JavaScript-Konformitäts-Subtests. Diese Zahlen sind der deutlichste Beweis dafür, dass Ladybird eine ernstzunehmende Engine und kein bloßes Demo ist.

Einige Vorbehalte sind notwendig, um diese Zahlen korrekt einzuordnen. Die WPT-Subtest-Anzahl ist eine absolute Zahl, kein Prozentsatz der Gesamtsuite; für ein gesamtheitliches WPT-Bestehensquoten-Ranking im Vergleich zu anderen Engines sollte man wpt.fyi direkt mit einem angegebenen Abrufdatum überprüfen, da sich Suitegröße und browserspezifische Ergebnisse kontinuierlich verändern. Die test262-Zahl bezieht sich auf importierte Subtests, nicht auf die gesamte Suite — Ladybird importiert eine Teilmenge und berichtet darüber. Mit diesen Einschränkungen ergibt sich folgendes Bild: eine JavaScript-Implementierung, die die überwältigende Mehrheit der ausgeführten Konformitätstests besteht, und eine Web-Plattform-Implementierung, die Millionen von WPT-Subtests besteht. Das liegt weit über der Schwelle, ab der eine Engine das reale Web überhaupt darstellen kann.

Roadmap und ehrliche Einschränkungen

Die offizielle Website plant eine öffentliche Alpha-Version im Jahr 2026 für Linux und macOS, laut der Ladybird-Homepage. Beta- und stabile Veröffentlichungsdaten wurden in sekundären Berichten als 2027 bzw. 2028 genannt, können jedoch derzeit nicht über ladybird.org verifiziert werden und sollten als Richtwerte und nicht als verbindliche Zusagen betrachtet werden. Pre-Alpha-Zeitpläne verschieben sich, und die Konformitätsarbeit einer Browser-Engine ist von Natur aus offen, daher ist jedes Datum nach der Alpha 2026 ein Ziel und kein Versprechen.

Die Plattformunterstützung ist enger als bei einem fertigen Browser, aber breiter als „nur Linux”. Die Alpha zielt auf Linux und macOS ab; die Windows-Unterstützung befindet sich in aktiver Entwicklung, und WSL2-basierte Build-Workflows existieren bereits für Entwickler unter Windows, die die Engine heute ausprobieren möchten. Der praktische Stand zum Zeitpunkt dieses Artikels ist Software, die gebaut wird und läuft, aber noch nicht für den täglichen Einsatz bereit ist — fehlende Funktionen und Unfertigkeiten sind zu erwarten.

Warum Ladybird für Frontend-Entwickler relevant ist

Eine vierte unabhängige Browser-Engine ist für Frontend-Entwickler als Konformitäts-Druckpunkt relevant, nicht als neuer Browser, auf den man ausliefert. Ein Projekt, das WPT strikt besteht und Spec-Issues einreicht, wenn reale Websites brechen, schafft eine Rechenschaftspflicht, die ein Zwei-oder-Drei-Engine-Oligopol nicht bietet. Der Wert ist struktureller Natur und hat nichts mit Marktanteilen zu tun.

Da Ladybirds gemeinnützige Struktur keine Werbeeinnahmen zu schützen und kein Geräte-Ökosystem zu verteidigen hat, ist es die einzige Engine, die auf einen vollständigen Endbenutzerbrowser abzielt, ohne strukturellen Anreiz, von den W3C-Spezifikationen zugunsten kommerzieller Interessen abzuweichen. Servo, ursprünglich von Mozilla und jetzt unter der Linux Foundation, teilt diese nicht-kommerzielle Haltung, wird aber derzeit als einbettbare Engine und nicht als vollständiges Browserprodukt entwickelt. Der Unterschied wird konkret, wenn man sich daran erinnert, dass FLoC ein Google Privacy Sandbox-Vorschlag war, der später durch Topics ersetzt wurde, und dass Intelligent Tracking Prevention ein WebKit-Feature ist, das Apples Plattformprioritäten widerspiegelt. Beides spiegelt den kommerziellen Kontext der jeweiligen Mutterorganisationen wider; eine Engine ohne solchen Kontext beseitigt diesen Druck vollständig.

Engine-spezifische Rendering- und Scripting-Eigenheiten — CSS-Layout-Randfälle, JavaScript-Verhaltensunterschiede an den Spec-Grenzen — sind die Art von Bug, die im Produktionsbetrieb bei einem heterogenen Browser-Publikum auftritt, nicht beim lokalen Testen gegen eine einzelne Engine. Session-Replays von Cross-Browser-Problemen zeigen häufig Fehler, die sich auf dem eigenen Rechner des Entwicklers nie reproduziert haben. Mehr unabhängige Implementierungen, die dieselbe Konformitätssuite bestehen, verengen den Raum, in dem sich diese Eigenheiten verstecken können.

Wie man Ladybird verfolgt und ausprobiert

Ladybird ist Pre-Alpha-Software, die auf Linux und macOS gebaut wird und läuft. Der zuverlässigste Weg, es zu verfolgen, sind die eigenen Kanäle des Projekts — sekundäre Berichte veralten innerhalb von Wochen. Der ladybird.org/news-Feed veröffentlicht regelmäßige Newsletter mit Konformitätszahlen, Architekturänderungen und Meilenstein-Updates — er ist die primäre Quelle für alle Statusangaben in diesem Artikel. Der Quellcode befindet sich im LadybirdBrowser/ladybird-Repository auf GitHub.

Um es zu bauen und auszuführen, sollte man den aktuellen Build-Anweisungen in der offiziellen Dokumentation folgen und nicht einer Drittanbieter-Anleitung — Abhängigkeitslisten und Build-Befehle ändern sich in einem so schnell voranschreitenden Projekt häufig. Nach dem Klonen und der Installation der Abhängigkeiten ist der Build-und-Run-Einstiegspunkt des Projekts sein Meta-Skript:

git clone https://github.com/LadybirdBrowser/ladybird.git
cd ladybird
./Meta/ladybird.py run

Die Form ./Meta/ladybird.py run ersetzt ältere ladybird.sh-Befehle, die in veralteten Tutorials zu finden sind. Spezifische Abhängigkeitsversionen, die außerhalb der offiziellen Dokumentation gefunden werden, sollten mit Vorsicht behandelt werden; vor dem Start sollten die Build-Anweisungen auf die aktuellen Toolchain-Anforderungen überprüft werden.

Ladybird ist eine echte, gut verwaltete, von Grund auf neu entwickelte Browser-Engine, die ernsthafte Konformitätshürden überwindet — heute noch keine praktikable Chrome-Alternative, aber der glaubwürdigste Versuch zur Engine-Diversifizierung, den das Web seit über einem Jahrzehnt gesehen hat. Die konkrete nächste Maßnahme ist, ladybird.org/news als Lesezeichen zu speichern und die Konformitätszahlen in jedem Newsletter zu verfolgen; die Entwicklung dieser Zahlen wird mehr darüber aussagen, ob dies das Web, das man ausliefert, verändert, als jede einzelne Momentaufnahme es kann.

FAQs

Understand every bug

Uncover frustrations, understand bugs and fix slowdowns like never before with OpenReplay — the open-source session replay tool for developers. Self-host it in minutes, and have complete control over your customer data. Check our GitHub repo and join the thousands of developers in our community.