Ladybird überschreitet in den web-platform-tests Apples 90-%-Schwelle

• Ladybird hat in den automatisierten Webstandard-Tests web-platform-tests die 90-%-Bestehensschwelle von Apple erreicht
• Diese Tests messen umfassend die Kompatibilität eines Browsers mit Webstandards wie HTML, CSS und JavaScript
• Durch eine hohe Erfolgsquote in den Tests auf dem Niveau von Apple-Browsern (vor allem Safari) hat Ladybird gezeigt, dass seine Kernalgorithmen und die Implementierung von Webstandards eine Zuverlässigkeit ähnlich der von führenden Browsern der Branche erreicht haben
• Das ist ein wichtiger Meilenstein, der zeigt, dass ein neuer Open-Source-Browser tatsächlich mit den etablierten Marktführern konkurrieren kann

[shakespeares]

Ich hoffe, dass es bald auf Augenhöhe mit Blink und WebKit stehen wird.

[GN⁺]

Hacker-News-Kommentare

• Ich habe viel Erfahrung mit der Arbeit an den web-platform-tests, daher sollte man vorsichtig sein, die Bestehensquote von Tests als Metrik zu verwenden. Das soll Ladybirds Leistung nicht schmälern; die schnelle Entwicklung von Ladybird ist wirklich beeindruckend, und wenn die web-platform-tests diesem Team helfen, ist das an sich schon etwas Gutes. Neue Implementierungen der Webplattform wie Ladybird, Servo und Flow zu sehen, ist sehr erfreulich. Allerdings sind die web-platform-tests ursprünglich als Engineering-Werkzeug optimiert worden, nicht als objektive Metrik. Zum Beispiel ist der Anteil an Decoding-bezogenen Tests an der Gesamtzahl der Tests übermäßig hoch. Der Grund ist nicht, dass das in der Browserentwicklung besonders schwierig wäre, sondern dass sie leicht zu erzeugen sind. Außerdem versuchen wir, technische und soziale Hürden zu senken, damit man frei nützliche Tests beitragen kann. Das eignet sich nicht gut für eine gute Metrik, aber sehr wohl für eine gute Engineering-Ressource. Das Interop Project löst dieses Problem teilweise durch andere Trade-offs und ausgewählte Testmengen, aber das derzeitige System ist bereits darauf ausgelegt, nur auf Projekte zu zielen, die fast vollständige Webbrowser-Engines implementiert haben
  • Im Tweet wird erwähnt, dass diese Metrik ein willkürlicher Maßstab ist, den Apple dem Ladybird-Team auferlegt hat. In den monatlichen Updates von Ladybird wird auch die Zahl der bestandenen Tests veröffentlicht, bei der Encoding-Tests ausgeschlossen sind, weil sie die Erfolgsquote übermäßig erhöhen
  • Ich frage mich, ob es unmöglich ist, eine ausgewählte Teilmenge von Tests als Metrik zu verwenden
  • Dann muss man direkt mit Apple sprechen. Apple ist die Partei, die diese Kriterien erstellt hat
  • Ich verstehe nicht, warum das hier angesprochen wird. Das ist keine Ladybird-Metrik, sondern eine Anforderung von Apple für iOS
• Dass der Ladybird-Browser schon bald in einen praktisch nutzbaren Zustand kommen könnte, ist wirklich großartig. Ich dachte, das würde noch ein paar Jahre dauern, aber ich hätte nicht erwartet, dass er so schnell konkurrenzfähig wird
  • Ich habe ihn zwar nicht selbst benutzt, aber ich habe einige der monatlichen Zusammenfassungsvideos gesehen. Tests zu bestehen und im Alltag schnell genug zu sein, sind völlig verschiedene Dinge. Im Moment scheint Ladybird noch nicht so schnell zu sein. Trotzdem ist die Entwicklungsleistung des gesamten Teams beeindruckend
  • Ich frage mich, ob das Sprichwort „90 % der Zeit gehen für die ersten 90 % der Fertigstellung drauf, und für die restlichen 10 % noch einmal 90 %“ auch auf Ladybird zutrifft. Selbst wenn das so ist, wäre es insgesamt immer noch eine ziemlich gute Entwicklungszeit
  • Ich würde empfehlen, die Erwartungen nicht zu hoch zu schrauben. Nach dem Entwicklungsbericht für September gibt es noch extrem viel zu beheben. Es ist eindeutig ein enormer Fortschritt, aber bis Ladybird fertig ist, werden voraussichtlich noch einige Jahre vergehen
  • Vor drei Jahren war ich bei Ladybird noch skeptisch. Aber erstens ist die Zahl der Vollzeitingenieure auf acht gestiegen, was ich nicht erwartet hatte, und zweitens sind tatsächlich drei Jahre vergangen. Deshalb bin ich jetzt viel optimistischer. Natürlich ist es bis zur Konkurrenzfähigkeit mit Chrome noch ein weiter Weg, und ich frage mich weiterhin, welchen Wert es hat, eine eigene Engine zu bauen, statt eine bestehende zu forken
  • Früher dachte ich, dass es Jahrzehnte dauern würde, eine komplett neue Browser-Engine zu bauen, aber es überrascht mich, wenn ich sehe, wie engagierte Leute wie das Ladybird-Team tatsächlich etwas zustande bringen
• In dem dazugehörigen Tweet wird erwähnt, dass dies ein wichtiger Meilenstein dafür ist, dass Ladybird unter iOS als alternative Browser-Engine in Betracht gezogen werden kann
  • Daher verstehe ich den Kontext, warum Apple im Titel des Artikels vorkommt
  • Aber das gilt zumindest nur innerhalb der EU, und außerhalb davon wird Apple es nicht erlauben, egal wie gut die Engine ist
• Es ist wirklich beeindruckend, wie schnell das unabhängige, nicht von Konzernen getragene Projekt Ladybird gewachsen ist
  • Ich verstehe den Ausdruck „non-corpo“, aber tatsächlich ist die Ladybird-Organisation selbst eine juristische Person. Siehe zugehörige Unterlagen
  • Wenn man bedenkt, wie viele Aufgaben ein Browser übernimmt, ist ein Projekt in dieser Größenordnung wirklich enorm. Schon einen großartigen HTML/CSS-Renderer und eine JS-Engine zu bauen, ist eine beachtliche Leistung, aber sobald man im Ökosystem angekommen ist, muss man auch mit künftigen Änderungen Schritt halten. Chrome kann sich neuen Vorschlägen widersetzen, während kleinere Browser eher das Gefühl vermitteln, nur hinterherzulaufen
  • Ich bezweifle, dass Ladybird wirklich nicht von Unternehmen getragen ist. Soweit ich mich erinnere, gab es einige Unternehmenssponsoren. In dieser Hinsicht würde ich nicht sagen, dass es besser dasteht als Gecko als Non-Profit-Projekt hinter Firefox
  • Wenn Ladybird dieses Tempo beibehält, erwarte ich, dass es Ende 2027 ein wirklich ernstzunehmender Konkurrent sein könnte. Persönlich finde ich allerdings, dass auch die Servo-Engine, die als Nächstes am meisten Funktionalität hat, eine ähnlich konzentrierte Anstrengung braucht. FF/Mozilla scheint daran kaum Interesse zu haben, daher braucht es unbedingt ein separates Browserprojekt
  • Tests zu bestehen und sicher zu sein, sind völlig verschiedene Dinge. Das hier sind Konformitätstests, keine Sicherheitstests. Trotzdem ist es extrem beeindruckend
• Ich frage mich, wie schwierig die letzten 10 % sein werden. Bei einem typischen Softwareprojekt würden für die letzten 10 % mehr als 90 % zusätzlichen Aufwands anfallen
  • Und das letzte 1 % wird sich ständig ändern und wohl nie wirklich abgeschlossen sein. Die 90 % sind Apples Maßstab. Aber ich frage mich, welches Niveau normale Nutzer eigentlich verlangen
  • Browser waren historisch gesehen eines der größten und schwierigsten Projekte überhaupt. Ich sehe nicht, warum man erwarten sollte, dass das einfacher wird. Vielleicht ist man erst dann wirklich in der Endphase, wenn auf das Finden eines Segfaults ein Kopfgeld von 20.000 Dollar ausgesetzt ist
• Ich habe Ladybird selbst gebaut und ausgeführt. Überraschenderweise öffnen sich schon ziemlich viele Websites gut. YouTube funktioniert allerdings noch nicht, und bei Vimeo oder dem Reddit-Kommentarfeld kommt es zu Abstürzen. Trotzdem ist das ein sehr ermutigendes Ergebnis. Für den Build werden etwa 6 GB Festplattenspeicher benötigt
• Im Diagramm ist ein großer Sprung zu sehen! Ich frage mich, welche Änderung diese Verbesserung verursacht hat
  • Im Twitter-Thread hat tatsächlich jemand Andreas danach gefragt, und die Ursache war die Zusammenführung der Spezifikation der CSS Typed Object Model API
  • Mit diesem Pull Request wurden etwa 6400 zusätzliche CSS-bezogene Tests bestanden. Das erklärt aber vermutlich nicht den gesamten Ausschlag im Diagramm, auch wenn es sicher geholfen hat. PR-Details
  • Das Diagramm hat keine Achsen, daher weiß man nicht, ob es wirklich ein großer Sprung ist. Es könnte zum Beispiel auch nur von 89 % auf 90,2 % gegangen sein. Vielleicht war diese Veränderung gar nicht größer als frühere Anstiege, die auf der linken Seite des Diagramms nicht angezeigt werden
• Ich frage mich, wie es mit der GTK-bezogenen Entwicklung von Ladybird vorangeht
• Ich frage mich, welche JS-Engine Ladybird verwendet
  • Es verwendet die eigene Engine LibJS LibJS auf GitHub
  • Der gesamte Source Code ist original
• Aus Ingenieurssicht überrascht es mich, dass ein Großkonzern Qualitätsstandards festlegt und den API-Zugriff von 3rd-party-Software einschränkt. Aus Kundensicht ist es erfreulich, dass strenge Qualitätsstandards und API-Beschränkungen auf OS-Ebene für überprüfte Sicherheit sorgen
  • Aus Verbrauchersicht führt das dazu, dass Updates des Browsers, auch bei Bugs oder Sicherheitsproblemen, langsamer kommen, weil der Browser Apples Prüfung bestehen muss. Auf dem Mac oder anderen Plattformen ist das nicht nötig. Apple sorgt außerdem dafür, dass Browser, die nicht Safari sind, nicht richtig funktionieren, und auf dem Mac oder anderen Betriebssystemen gibt es so ein Umfeld nicht. Und obwohl Apple in der EU so tut, als würde es alternative Engines erlauben, gibt es in Wirklichkeit nur mehr böswillige Regelbefolgung (malicious compliance), sodass alternative Engines praktisch nur theoretisch existieren. Am Ende ist das auch für Verbraucher ein Nachteil
  • Aus Verbrauchersicht ist es bereits ein Problem, überhaupt Dienste wie GitHub oder Threads im offiziellen Browser des OS zu nutzen
  • Aus Ingenieurssicht frage ich mich, ob Apples Browser selbst diese eigenen Standards einhält. Gerade Safari hat bestimmte Bugs erstaunlich häufig. Darunter sind viele ganz gewöhnliche Fehler, die vermutlich jeder schon einmal beim Erstellen einer Webseite erlebt hat
  • Ich frage mich, ob man überhaupt die Wahl hat, keinen kaputten Browser zu verwenden
  • Das ist keine Überraschung, sondern wirkt auf mich wie der Versuch, die Kontrolle auf wettbewerbswidrige und unfaire Weise zu behalten