OT, but I really like the name Ladybird for a silly reason - it's the name of Hank Hill's dog. Whenever I hear it I think of her and smile. That's right, the thought of a cartoon dog makes me happy. I told you it was silly.
I think it’s just fantastic that the Ladybird browser is close to being usable. I was under the impression this was going to take many years before it became competitive.
Don't worry. If the web browser ever becomes fast enough to be usable, even more javascript crap will be dumped on every website to slow it back down again
Thank you for the belly-laugh. It's Goodhart's Law in graph form.
"Oh, is this metric important? Let me get right on that."
No shade intended towards the Ladybird team. You were given the terms and you're behaving rationally in response to them. More power to you. It's just a fantastic demonstration of what it looks like to very suddenly be developing against a very specific metric.
If nothing else, having an alternative engine with any amount of viability at all that isn't Blink is great news. I'll be interested to see how this progresses.
It's always struct me as interesting that ladybird is built with C++. I like C++, and prefer it to languages like Rust, but it's not uncommon to see new OSS projects using weird languages and the newest tools. Lots of languages offer improvements in regards to threading models, development speed, or cross-platform support which we don't get in C++.
I suppose their success is likely directly related to the fact they made reasonable, practical development choices, but still.
As someone who's been quite heavily involved with web-platform-tests, I'd caution against any use of the test pass rate as a metric for anything.
That's not to belittle the considerable achievements of Ladybird; their progress is really impressive, and if web-platform-tests are helping their engineering efforts I consider that a win. New implementations of the web platform, including Ladybird, Servo, and Flow, are exciting to see.
However, web-platform-tests specifically decided to optimise for being a useful engineering tool rather than being a good metric. That means there's no real attempt to balance the testsuite across the platform; for example a surprising fraction of the overall test count is encoding tests because they're easy to generate, not because it's an especially hard problem in browser development.
We've also consciously wanted to ensure that contributing tests is low friction, both technically and socially, in order that people don't feel inclined to withhold useful tests. Again that's not the tradeoff you make for a good metric, but is the right one for a good engineering resource.
The Interop Project is designed with different tradeoffs in mind, and overcomes some of these problems by selecting a subsets of tests which are broadly agreed to represent a useful level of coverage of an important feature. But unfortunately the current setup is designed for engines that are already implementing enough feature to be usable as general purpose web-browsers.
As someone who's been quite heavily involved with having a brain, I'd advocate for using of the test pass rate as a metric for how many tests are passed.
What's the security story in Ladybird? Do they use sandboxes etc? I'm a bit concerned that hundreds of thousands of lines of C++ browser code written in just three years could be a minefield, but I hope I'm wrong.
Last I heard they were planning to move to Swift [1] partly because of the safety features. Apparently there are still some blockers [2] preventing that move though.
If you care about security, consider using Qubes OS, which runs everything in hardware-isolated virtual machines. My daily driver, can't recommend it enough. Ladybird can already be safely used on Qubes.
I just tried building and running it. Surprisingly many websites already load fine, though Youtube doesn't and Vimeo/Reddit comment section crashed it. Still, the results are quite encouraging! It takes ~6GB of HDD to build it.
Along the same lines, the State of Utopia will be building a free web browser for everyone, once AI is strong enough to do so. Please feel free to vote on feature ideas here: https://pollunit.com/polls/ahysed74t8gaktvqno100g
The WPT score is a flawed metric (encoding tests are overweighted), but it's one of the few objective yardsticks we have. What matters more is that Ladybird is finding spec ambiguities by implementing from scratch rather than cargo-culting Chrome's behavior.
The real test isn't passing 90%—it's whether they can keep pace as the web platform adds new APIs faster than any independent team can implement them. Browser engine development has become a regulatory moat, and breaking it requires either massive funding or accepting permanent incompatibility with the "modern web."
Still rooting for them. Browser monoculture is worse than metric gaming.
31 comments
[ 6.7 ms ] story [ 56.0 ms ] threadMe as customer: oh man I'm sure glad stuff is reviewed to some quality bar and the OS limits API access.
"Oh, is this metric important? Let me get right on that."
No shade intended towards the Ladybird team. You were given the terms and you're behaving rationally in response to them. More power to you. It's just a fantastic demonstration of what it looks like to very suddenly be developing against a very specific metric.
I suppose their success is likely directly related to the fact they made reasonable, practical development choices, but still.
That's not to belittle the considerable achievements of Ladybird; their progress is really impressive, and if web-platform-tests are helping their engineering efforts I consider that a win. New implementations of the web platform, including Ladybird, Servo, and Flow, are exciting to see.
However, web-platform-tests specifically decided to optimise for being a useful engineering tool rather than being a good metric. That means there's no real attempt to balance the testsuite across the platform; for example a surprising fraction of the overall test count is encoding tests because they're easy to generate, not because it's an especially hard problem in browser development.
We've also consciously wanted to ensure that contributing tests is low friction, both technically and socially, in order that people don't feel inclined to withhold useful tests. Again that's not the tradeoff you make for a good metric, but is the right one for a good engineering resource.
The Interop Project is designed with different tradeoffs in mind, and overcomes some of these problems by selecting a subsets of tests which are broadly agreed to represent a useful level of coverage of an important feature. But unfortunately the current setup is designed for engines that are already implementing enough feature to be usable as general purpose web-browsers.
1: https://x.com/awesomekling/status/1822236888188498031
2: https://github.com/LadybirdBrowser/ladybird/issues/933
The real test isn't passing 90%—it's whether they can keep pace as the web platform adds new APIs faster than any independent team can implement them. Browser engine development has become a regulatory moat, and breaking it requires either massive funding or accepting permanent incompatibility with the "modern web."
Still rooting for them. Browser monoculture is worse than metric gaming.