Erfahrungen mit dem in Rust entwickelten Servo-Webbrowser
(spacebar.news)- Der weltweite Marktanteil Chromium (Chromium)-basierter Browser steigt, wodurch die Sorge wächst, dass die Vielfalt der Webstandards und die Zukunft des Open Web leiden könnten.
- Die in Rust entwickelte Servo-Engine besitzt zwei große Stärken: Multithreading-Performance und Speichersicherheit, und gewinnt im Bereich der Web-Rendering-Engines als neue Alternative an Aufmerksamkeit.
- Da sich Servo noch in einem frühen Stadium befindet, existieren auf den meisten Websites Rendering-Bugs. Auf einigen Demoseiten oder einfachen Seiten wie Wikipedia funktioniert es jedoch ordnungsgemäß.
- Das Servo-Projekt wurde zwar ursprünglich von Mozilla initiiert, wird aber heute von der Linux Foundation Europe verwaltet und folgt einer Struktur mit technologischer Unabhängigkeit sowie gemeinschaftsorientierter Entscheidungsfindung.
- Vor dem Hintergrund der Konzentration auf wenige Browser-Engines ist die kontinuierliche Weiterentwicklung alternativer Engines wie Gecko und Servo ein Hinweis darauf, wie wichtig die Wahrung der Vielfalt in der Web-Ökosphäre ist.
Die Monopolisierung von Web-Engines und deren Risiken
- In den 1990er Jahren bis Anfang der 2000er Jahre existierten verschiedene Browser-Engines wie Internet Explorers Trident, Operas Presto, Netscapes Gecko und Konquerors KHTML nebeneinander.
- Im Laufe der Zeit wurden KHTML in WebKit sowie Presto und Tasman in Blink, die Engine von Chromium, integriert oder ersetzt.
- Da moderne Hauptbrowser (Chrome, Edge, Opera usw.) fast vollständig auf Chromium/Blink basieren, entsteht zunehmend die Situation, dass ein Implementierer faktisch zum Standard wird.
- Sicherheitslücken, eingeschränkte Erweiterbarkeit und ähnliche Probleme fallen auf und zeigen, dass bei Abhängigkeit von einer Engine der gesamte Web-Ökosystem-Umfang betroffen ist.
Das Auftauchen der Servo-Engine
- Servo ist eine von Grund auf neu in Rust entwickelte Browser-Rendering-Engine.
- Basierend auf den Stärken von Rust wie Multithreading und Speichersicherheit soll sie strukturell die Schwächen bestehender C/C++-Engines (z. B. Speicherfehler) reduzieren.
- Das Hauptziel von Servo ist ein eingebetteter Web-Rendering-Engine, sodass sie neben einem eigenständigen Browser auch als Alternative zu Electron oder Android WebView eingesetzt werden kann.
- Unter dem Dach der Linux Foundation Europe werden technische Entscheidungen nicht von einem einzelnen Großkonzern, sondern durch ein technisches Komitee getroffen.
- Als vollständig neue Browser-Engine nach rund zehn Jahren baut Servo bei der Reifung auf den Erfahrungen der etablierten Haupt-Engines auf.
Erfahrungen mit der Nutzung von Servo und aktueller Stand
- Auf der offiziellen Website steht ein Nightly Build (für Windows, macOS, Android und Linux) für das Ausprobieren von Servo bereit.
- Funktionen wie Lesezeichen, Erweiterungen oder Datensynchronisierung werden derzeit nicht unterstützt.
- Auf den meisten Websites treten Rendering-Bugs auf; bei Google-Suche oder einigen Seiten kommt es zu Layoutproblemen oder Abstürzen.
- Einfach strukturierte Seiten wie Wikipedia oder CNN Lite funktionieren hingegen normal.
- Auf der Servo-Demoseite können grafische Leistungsdemonstrationen gezeigt werden; im Benchmark „Particle Physics“ wurde auf einem aktuellen MacBook Pro (x86-Emulation) ein Ergebnis von 55–60 FPS gemessen.
- Im Acid3-Test erreichte Servo 83/100 Punkte, also weniger als die etwa 95 Punkte der Mainstream-Browser.
- Für die Zukunft sind zentrale Webstandards wie Shadow DOM und CSS Grid auf der Roadmap enthalten, mit Fokus auf bessere Web-Kompatibilität.
Geschichte von Servo und wichtige Wendepunkte
- Servo wurde 2012 bei Mozilla gestartet; 2013 stieß Samsung zur Entwicklung hinzu.
- Ursprünglich war ein Austausch von Gecko nach der Stabilisierung geplant, doch realistisch wurde die Strategie auf eine schrittweise Ersetzung einzelner Gecko-Komponenten durch Servo-Code umgestellt.
- Mit dem Firefox-57-Update (Quantum) wurde die CSS-Engine (Quantum CSS, Stylo) durch Servo-Code ersetzt und brachte deutliche Verbesserungen bei Leistung und Speichereffizienz.
- Nach Mozillas umfangreicher Restrukturierung 2020 (einschließlich der Servo-Entwickler) wurde Servo unter die Linux Foundation überführt und die Fördermittel gesichert; derzeit wird die community-zentrierte Entwicklung unter anderem mit Unterstützung von Open-Source-Unternehmen wie Igalia fortgeführt.
Zukunftsperspektiven für die Browserlandschaft
- Nachdem das US-Justizministerium in dem Verfahren gegen Googles Monopolstellung (Chrome, Android) obsiegte, wird über den Verkauf von Chrome und das Verbot von Suchverträgen mit Drittbrowsern diskutiert.
- Mozilla ist stark von den Einnahmen aus der Standard-Suchplatzierung in Firefox abhängig (wichtig für die Aufrechterhaltung der Gecko-Entwicklung), und hat gegen diese Maßnahme Bedenken geäußert.
- Falls Mozilla diese Google-Einnahmen verliert, könnte Firefox, um Entwicklungskosten zu senken, auf WebKit oder Chromium/Blink umsteigen.
- In diesem Fall wären Szenarien wie ein Fork von Gecko mit Community-Betrieb oder ein allmähliches Ausfransen von Gecko denkbar.
- Die Existenz von Alternativen wie Servo und Gecko rückt damit erneut in den Mittelpunkt als wichtiger Faktor für Vielfalt und Balance des Web-Plattform-Ökosystems.
Abschluss und Implikationen
- Auch bei fortschreitender Vereinheitlichung der Hauptbrowser-Engines spielt das Erscheinen innovativer Alternativen wie Servo eine entscheidende Rolle für die Vielfalt und Gesundheit des Web-Ökosystems.
- Zwar ist Servo kurzfristig kaum als vollwertiger Alltagsbrowser einsatzbereit, doch technische Experimente und Weiterentwicklungen gehen kontinuierlich voran.
- Es besteht große Erwartung hinsichtlich Servo's weiterer Entwicklung und der möglichen Auswirkungen auf die Branche.
4 Kommentare
Soll man etwas herunterladen und benutzen, das nicht einmal richtig funktioniert? Woher kommt eigentlich diese Arroganz?
Ich habe gehört, dass Rust entwickelt wurde, um Servo zu entwickeln … Hoffentlich wird Servo ein Erfolg.
Muss ich da nur ich ständig an das Hurd-Projekt denken … oder täusche ich mich?
Hacker-News-Kommentare
Auf der aktuellen Roadmap haben Shadow DOM und CSS Grid Priorität. Ich arbeite am CSS-Grid-Support, und bald soll Unterstützung für "named grid lines and areas" hinzukommen. Ich erwarte, dass dadurch mehr Website-Layouts korrekt funktionieren werden. Vielleicht bin ich voreingenommen, weil es mein Projekt ist, aber ich finde die Art, wie Servo CSS Grid implementiert, ziemlich cool. Die Kernimplementierung ist in eine externe Bibliothek ausgelagert, Taffy (GitHub-Link), und diese Bibliothek wird im Rust-UI-Ökosystem breit eingesetzt. Beispiele sind die Web-Engine Blitz(Link), der Texteditor Zed(Link) und die Game-Engine Bevy(Link), wo sie für Flexbox, Block-Layout und andere Aufgaben genutzt wird. Ich hoffe, dass Servos Ansatz, eine Web-Engine auf Basis der Erfahrungen mit modularen Bibliotheken wie Stylo und html5ever in unabhängige Module mit öffentlichen APIs zu zerlegen, künftig die Einstiegshürde für Web-Engine-Entwickler senkt und neuen Entwicklern stark helfen wird.
Von Blitz höre ich zum ersten Mal. Es wirkt wie ein ziemlich interessantes und ambitioniertes Projekt, fast wie eine echte "versteckte" Web-Engine. Servo ist seit den Anfängen von Rust weithin bekannt, aber Blitz ist nicht weniger beeindruckend.
Ich frage mich, ob die Erfahrung, Browser-Engine-Funktionalität selbst implementiert zu haben, beeinflusst, wie man HTML oder CSS schreibt. Suchst du immer noch dreimal pro Woche nach "css grid cheatsheet"?
Ich mache mir Sorgen, dass dieser Ansatz, Funktionen aufzuteilen und zu modularisieren, am Ende eher zu Feature-Bloat oder Fragmentierung führt. Um gegen Google bestehen zu können, ist eine fokussierte Strategie wichtig, und genau das bereitet mir Sorgen.
Ich nutze taffy für das Layout meines kleinen Rust-basierten E-Ink-Kalenders, deshalb finde ich solche Neuigkeiten sehr spannend.
Ich mag den Ansatz wirklich, Web-Engines in öffentlich verfügbare API-Module aufzuteilen, die man unabhängig verwenden kann. Als ich mir früher WebRTC angesehen habe, habe ich mich gefragt, warum die Wahl zwischen einem billigen Skype-Klon in 50 Zeilen JavaScript und einem einwöchigen Chromium-C++-Build-Albtraum bestehen muss. Zum Glück gibt es jetzt auch ein WebRTC-Rust-Crate, sodass nicht nur Web-Apps von solchen Investitionen profitieren.
Mozilla wirkt auf mich wie ein Kandidat für die Ruhmeshalle der Unternehmen, die wie Xerox "Technologien der Zukunft geschaffen und dann ahnungslos an die Konkurrenz verloren" haben. Mit Rust und Servo waren sie bei der Browser-Entwicklung zeitweise Google voraus, deshalb verstehe ich wirklich nicht, warum sie es nicht weiterverfolgt haben.
Mozilla ist nicht wie Xerox. Wenn überhaupt jemand das neue Xerox ist, dann eher Google. Google investiert mit enormen Mitteln in Forschung und Entwicklung ohne klaren Geschäftsplan. Ein typisches Beispiel sind Transformer-Modelle — im Grunde hat Google LLMs zuerst gebaut und wurde am Ende trotzdem von OpenAI abgehängt. Mozillas Erfolg war immer auf Webbrowser wie Netscape und Firefox konzentriert. Auch Rust ist im Kern eine Sprache, die für Browser geschaffen wurde. Dass sie andernorts nützlich ist, ist nur ein willkommener Nebeneffekt.
Google war seit 2006 Mozillas wichtigste Einnahmequelle. Damit Mozilla fortbestehen konnte, musste man Google zufriedenstellen. Das birgt Konfliktpotenzial, ist aus Mozillas Sicht aber ein ziemlich guter Deal.
Ich glaube, Mozilla ist jetzt am Ende. Sie waren zu abhängig von Google und stehen nun davor, selbst das zu verlieren. Servo und Ladybird werden die Zukunft sein, und ich bin wirklich beeindruckt, wie schnell sich Ladybird mit so wenigen Leuten entwickelt.
Falls Mozilla Gecko aufgibt, wäre das der Zeitpunkt für einen Hard Fork und die Flucht aus Mozilla. Mit dem Aufgeben von Gecko meine ich übrigens nicht einen Wechsel zu Servo, sondern zu Chromium.
Ich habe das Gefühl, dass es schwer ist, Menschen dazu zu bringen, für Browser zu bezahlen. Für ein 10-Euro-Bier geben sie problemlos Geld aus, aber in meinem Umfeld gab es viele Leute, die selbst einer lebenslangen WhatsApp-Lizenz für 0,99 Euro aus dem Weg gehen wollten.
Ich verstehe immer noch nicht, warum Mozilla die technische Zukunft von Firefox aufgegeben hat. Wenn man sich Mozilla aber unter dem Aspekt der Geldströme ansieht, wird einiges verständlicher.
Auch die Einstellung des Pocket-Dienstes ist ein trauriges Beispiel. Ich stelle mir als Aprilscherz vor, dass Mozilla ankündigt, Firefox einzustellen und sich auf das Kerngeschäft zu konzentrieren. Ein bitterer Witz darüber, dass die "platonische Idee" des schönen Einstellens beliebter Produkte inzwischen wohl ihr eigentliches Kerngeschäft ist.
Wenn man sich verschiedene Abgänge und die Kommunikationsweise ansieht, scheint Mozilla damals ein extrem politisches Unternehmen gewesen zu sein. Servo hatte unglaublich aktive Kommunikation, und auch bei Rust war die Atmosphäre gut, also könnte gerade das oben für Unruhe gesorgt haben. Mozilla wird immer noch stark von alten Leuten geführt, und ich denke, die Fehler des Top-Managements wiegen schwer.
Ich glaube immer noch fest daran, dass Servo zu einer echten Gegenkraft gegen das Chrome/Chromium-Monopol werden kann. Ich verstehe nicht, warum Mozilla das aufgegeben hat und warum die Linux Foundation es kaum unterstützt.
Wenn man Mozillas Strategie langfristig als Weg zu Unabhängigkeit von Google-Geldern betrachtet, ergibt sie durchaus Sinn. Die tatsächlichen Nicht-Google-Einnahmen stiegen von 80 Millionen Dollar im Jahr 2022 auf 150 Millionen Dollar im Jahr 2023. Auch das Gesamtvermögen wuchs jedes Jahr um 100 Millionen Dollar und erreichte 2023 eine Milliarde Dollar. Der Anteil der Google-Gelder sank von 90 % im Jahr 2020 auf 75 % im Jahr 2023. Völlig unabhängig sind sie also nicht, aber es gibt eine Richtung. Anders als oft behauptet, kann man allein anhand der Geldflüsse zu anderen Schlüssen kommen. Viele kritisieren, dass Servo hätte weitergeführt werden müssen, aber ich denke, dass Servo nach Quantum für Firefox tatsächlich keine große Rolle mehr gespielt hat.
Ist es richtig, dass der Großteil von Mozillas Einnahmen von Firefox kommt?
Es gibt auch Ladybird(offizielle Website) als Herausforderer des Blink-Monopols. Ich weiß nicht sicher, wie es weitergehen wird, aber ich bin gespannt.
Ich verstehe nicht ganz, was das Ziel von Ladybird ist. Es gibt ehemalige Ingenieure und es werden Spenden gesammelt, also ist es offensichtlich mehr als ein reines Hobbyprojekt. Trotzdem kann ich mir schwer vorstellen, wie es bei Funktionen, Sicherheit und Performance mit Blink, WebKit und Gecko konkurrieren soll. Das sind ohnehin keine kleinen Teams, und ohne breite Akzeptanz bringt allein eine Engine nicht viel. Das gilt auch für Servo, aber bei Servo wirken die technischen Ziele überzeugender. Bei Ladybird sehe ich diese Klarheit nicht.
Rein technisch sehe ich den Reiz von Ladybird nicht so recht. Es ist im Grunde in C++ geschrieben und wirkt deshalb nicht anders als Gecko oder Blink. Servo hat dagegen klare technische Design-Unterschiede bei Sicherheit, Parallelität und anderem, was es attraktiv macht.
Ich hoffe, dass Ladybird erfolgreich wird. Man kann es jetzt direkt unterstützen, und das finde ich sinnvoll. Anders als bei Mozilla bin ich sicher, dass die eingesammelten Spenden vollständig in die Browser-Entwicklung fließen werden.
Ich frage mich, ob Ladybird versucht, auf Swift umzusteigen. Wenn man eine Browser-Engine in C++ entwickelt, gefällt mir das zwar nicht besonders, aber es wirkt realistisch und ergebnisorientiert. Bei Rust hätte ich das Gefühl von Zukunftsorientierung, und das würde ich anerkennen. Aber eine Engine in einer anderen Sprache wie Swift zu bauen, wirkt auf mich wie eine interne politische Entscheidung eines Unternehmens. Ich frage mich, warum man absichtlich eine Sprache mit noch schwachem Support-Ökosystem wählen würde (bezogener Tweet).
Der Dogemania-Test lief auf einem M4 Pro MacBook Pro mit bis zu 400 Bildern flüssig bei 60 FPS. In Chrome wurden dagegen bis zu 1400 Bilder mit 60 FPS gehalten; danach wurde es mir zu lästig und ich habe es geschlossen.
Ich habe dasselbe Experiment gemacht, und der Unterschied zwischen Firefox und Chromium war enttäuschend groß. In Chromium blieb es selbst jenseits von 1000 Bildern noch bei 100 FPS, während Firefox direkt nach 500 Bildern unter 60 FPS fiel. Es war vielleicht kein vollständig fairer Test — Chromium ist mein kaum genutzter Browser und ohne Add-ons — aber beim Leistungsvergleich hat mich das einiges spüren lassen.
Wenn die Bilder in dogemania nach der Animation stillstehen, frage ich mich, ob das nicht ein Fall ist, der sich wirklich leicht optimieren lassen müsste. Sogar alte Computer wie ein Amiga müssten so etwas doch praktisch unbegrenzt bewältigen können.
Es ist etwas gewagt, Servo als "neue" Engine zu bezeichnen.
Ich dachte, Rust sei für den Webbrowser Servo gemacht worden.
Zur Aussage "Wenn von einem Standard nur noch eine einzige Implementierung übrig bleibt, wird diese am Ende selbst zum Standard" verstehe ich nicht ganz, warum das ein Problem sein soll. Wenn die Implementierung Open Source ist und ein Komitee mit mehreren Beteiligten die Spezifikation festlegt, scheint mir das in Ordnung. Die aktuelle Situation, in der enorme Ressourcen in mehrere Engines fließen, wirkt eher verschwenderisch. Ich denke, es wäre effizienter, bei Browser-Engines wie beim Linux-Kernel nur eine zu haben und nur die Distributionen unterschiedlich zu gestalten.
So gut die Absichten auch sind: Implementierungen enthalten immer Bugs und kleine Unsauberkeiten. Ohne eine zweite unabhängige Implementierung wird am Ende jeder sagen "funktioniert doch", und der Bug selbst wird zum Standard. Wenn Webseiten anfangen, sich auf solche Bugs zu verlassen, orientiert sich am Ende alles nicht mehr an der Spezifikation, sondern an den konkreten Fehlern einer bestimmten Implementierung. Deshalb ist auf MS Windows alte UI über viele Schichten gewachsen und Kompatibilität wurde zum Albtraum. Mit mehreren unabhängigen Implementierungen lassen sich Standards tatsächlich erhalten und weiterentwickeln, und Optimierungen werden einfacher.
In der Theorie klingt das gut, aber in der Praxis haben die Interessen eines einzelnen Entwicklers nicht immer mit denen der Nutzer überein, deshalb halte ich ein Monopol nicht für wünschenswert. Besonders die jüngste Abschaffung von Manifest v2 in Blink-basierten Browsern kam bei den Nutzern schlecht an.
Je mehr Browser-Engines es gibt, desto geringer ist das Risiko, dass sich eine Sicherheitslücke überall gleichzeitig auswirkt. Selbst bei speichersicheren Sprachen können logische Fehler Schaden anrichten, daher ist Vielfalt wichtig.
Du hast von einer Strategie mit "einer Engine und mehreren Distributionen" gesprochen, aber für Leute, die an BSD-Umgebungen oder ZFS gewöhnt sind, fühlt sich gerade dann, wenn man alte Wege verlässt, Stabilität und Ausgereiftheit deutlich besser an.
Schon jetzt haben Google oder Leute aus diesem Umfeld starken Einfluss auf die Standardisierung. Wenn alles von Chromium bestimmt wird, wird die Lage noch schlimmer. Vielleicht muss es wirklich erst zum großen Zusammenbruch kommen, damit alle die Grenzen von W3C, WHATWG und ähnlichen Gremien anerkennen.
Als ich die Beobachtung gelesen habe — "Die meisten Websites haben leichte Rendering-Bugs, und einige funktionieren gar nicht; in den Google-Suchergebnissen gibt es viele überlappende Elemente, und die Startseite von MacRumors stürzt nach dem Scrollen ab. Wikipedia, CNN Lite, persönliche Websites und NPR-Text funktionieren dagegen perfekt" — ist mir aufgefallen, dass ich fast nie Beispiele sehe, in denen gesagt wird, Google oder MacRumors sollten für Servo angepasst werden. Stattdessen lautet das Fazit fast immer, dass Servo sich wie Chrome/Chromium verhalten müsse. Das finde ich sehr bedauerlich, denn dann würden (a) am Ende Werbeunternehmen die Standards festlegen und (b) die Leute, die Webseiten bauen, die falschen Anreize bekommen. Sich an einfachen Dingen wie Wikipedia oder CNN Lite zu orientieren, ist doch eigentlich viel unkomplizierter. Ich finde, ein "Standard"-Browser sollte sich nicht an Beliebtheit orientieren, sondern daran, dem tatsächlichen Standard möglichst nahe zu kommen. Wirklich standardkonform ist etwas erst dann, wenn es sowohl in unpopulären als auch in populären Browsern funktioniert. Letztlich liegt die Antwort meiner Meinung nach nicht darin, den Webbrowser zu reparieren, sondern die Webseiten. Ich experimentiere immer noch mit der ursprünglichen libwww-Bibliothek und den Tools des W3C. Mit nur kleinen Anpassungen funktionieren sie auch heute noch, über 30 Jahre später, gut für die Optimierung textbasierter Webseiten. Das Internet ist ein öffentliches Gut, aber heutige Browser und Webseiten sind zu stark auf Werbeoptimierung und Datensammlung ausgerichtet. Erst wenn Seiten und Browser wirklich für WWW-Nutzer Priorität haben, hat das Bedeutung. Unten ist ein einfaches Skript, um mit libwww ein statisches Binary zu bauen.
Ich finde es wirklich traurig, wie Mozilla sich von einem wettbewerbsfähigen Browser-Unternehmen immer mehr zu einer aktivistisch wirkenden Organisation entwickelt hat. Deshalb scheint auch das Kernprodukt immer schwächer geworden zu sein, und das macht mich bitter.