Ladybird passes the Apple 90% threshold on web-platform-tests

Original Article ↗ Hacker News Discussion ↗

Significance of the 90% WPT Milestone / Apple & iOS

  • The 90% Web Platform Tests (WPT) threshold matters mainly because Apple uses it as a bar for giving third‑party engines JIT access on iOS, which is required for a viable browser.
  • This is currently only meaningful in the EU under the DMA; elsewhere Apple is expected to continue requiring WebKit.
  • Some see Apple’s WPT requirement as reasonable risk‑control for granting rwx/JIT; others frame it as “malicious compliance” that keeps alternative engines practically marginal.

WebKit on iOS: Pain Points vs Defenses

  • Critics say WebKit on iOS “sucks” for:
    • Lack of full uBlock Origin and powerful extension APIs; some argue Safari content blockers (e.g. Wipr, uBO Lite) are “good enough”.
    • Numerous layout/animation/rendering bugs, especially with transforms, opacity, border‑radius, fixed positioning, video playback (playsInline, fullscreen hijacks, broken events).
    • Slow bugfix propagation and poor dev tooling (e.g. service worker debugging).
  • Others counter that Safari largely follows specs, WebKit is not uniquely worse than Gecko, and Safari is a critical counterweight against a full Chrome monopoly.

Ladybird’s Progress, Viability, and Funding

  • Commenters are impressed that a small, funded non‑profit team (about 8 full‑time engineers, with multiple corporate sponsors) has reached this level of conformance so fast.
  • Several have tried builds: many sites work; major ones like YouTube, Reddit comments, or Vimeo still crash or misbehave. Performance is not yet competitive.
  • Many expect the “last 10%” of compatibility to be the hardest and never fully done, as the web keeps growing. Some think Ladybird is still “years/decades” from Chrome‑level parity; others see a credible path to a “usable” release in the near term.
  • There’s debate over why fund Ladybird instead of Firefox/Gecko; one argument is that a clean, spec‑driven engine without legacy baggage can better resist Blink‑centric de facto behavior.

WPT as a Metric (and Its Limits)

  • WPT was designed as an engineering tool, not a balanced scorecard. Encoding tests dominate the count, so raw pass percentage overweights that area.
  • The visible “jump” in Ladybird’s graph is tied to implementing large feature clusters (e.g. CSS Typed OM, bulk encoding fixes), illustrating Goodhart’s Law once Apple made WPT a gate.
  • Still, there is broad agreement that, despite flaws, WPT is one of the few objective and automatable measures available for new engines.

Standards, Chrome, and Browser Monoculture

  • One side argues Chrome has the best formal standards compliance and does much work in the open with W3C/WHATWG/ECMA; pre‑standard shipping is seen as necessary experimentation.
  • The opposing view is that Chrome repeatedly ships half‑baked specs (WebUSB, WebHID, Constructable Stylesheets, Manifest V3, etc.), then uses market share and developer inertia to turn them into de facto standards, “IE6 in reverse”.
  • Concerns include Chrome’s leverage over ad blocking and the difficulty for small engines to “keep up with a moving train” of new APIs. Some call for stronger government or consortium constraints; others doubt regulators’ competence and fear stifled innovation.

Implementation Choices, JS Engine, and Security

  • Ladybird uses its own C++ engine and LibJS; Test262 shows LibJS already close to major engines in spec coverage, though definitely slower and less optimized.
  • C++ is seen as pragmatic (matching Chrome/Firefox internals and the team’s expertise) but raises concerns about memory‑safety; some commenters prefer Rust/Swift for security‑critical code.
  • The project has expressed interest in eventually moving toward Swift when cross‑platform support is mature enough, but progress there appears slow/blocked.
  • Sandbox strategy and hardening details are largely unclear in the thread; security‑conscious users suggest relying on OS‑level isolation (e.g., compartmentalized OSes) for now.

User Impact, Regulation, and Market Power

  • Some users appreciate Apple’s quality bar and API restrictions; others emphasize concrete harms: slow updates, constrained engines on iOS, and weakened competition.
  • There is extended debate about consumer ignorance, the need for antitrust intervention against Apple/Google’s mobile control, and the economic cost of entrenched browser/OS gatekeepers.
  • Many see Ladybird’s mere existence as positive: any credible non‑Blink engine reduces monoculture risk, even if market success is uncertain and “pay‑to‑play” distribution still dominates.