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.
Still an amazing feat of development from the entire team.
Why are the tests so disconnected from the usability? My assumption is the tests are closer to a unit test, while browsing a page is essentially an E2E test, and if anything in the pipeline goes wrong (especially given that we use complex JS everywhere) the result is essentially useless.
As such, 90% test pass rate but low usability simply means that 10% of the tests cover a lot of very visible usability features that ladybird hasn't addressed yet.
There’s still a very long way before they can compete with Chrome, of course. And I’m not sure I ever understood the value proposition compared to forking an existing engine.
Another example is around ad blockers -- if Blink is the only option, they can make it hard for ad blockers to function whereas having other engines allows different choices to be made.
It’s that Chrome and V8’s implementation has grown to match resourcing. You probably can’t maintain a fork of their engine long-term without Google level funding.
there by definition is no vendor lock-in by forking an open-source engine. The worst case is the original maintainers going evil tomorrow and you being on your own, which is no worse than starting from scratch, except you saved yourself some ten million odd lines of mindless spec implementation in the case of a browser.
If you fork that monopolist’s engine, you’re not making any immediate difference to the market. You’ll adopt all their existing behavior, whether or whether not it conforms to spec (and I would guess you would continue to pull in many of their changes down the road).
A brand new implementation is much more difficult, but if it works it’s much more meaningful in preventing a monopoly.
It's like projects trying to keep Firefox XUL alive, or GTK+ 2 or 3.
The project has now moved from just updating the external dependency to working on that and possibly actively fighting against the tide. That is a lot harder and requires more work each time you update the dependency.
So in effect you have vendor lock-in. And if the vendor controls or affects downstream products like plugin developers (targeting manifest V3) or application developers (targeting GTK+ 3 or 4) then its even harder to maintain support for the other functionality.
Though, I suppose even if true, it would still be a pretty good timeframe.
To quote Rich Harris, the author of Svelte: https://x.com/Rich_Harris/status/1841605646128460111
--- start quote ---
saying 'no' is the key to good software design, but in standards you can only 'champion' proposals — you can't champion the _lack_ of a proposal. the best you can hope for is inertia.
in my experience the only feedback that is welcome is around the details of an idea, never around whether the idea has merit in the first place, and you should expect to be reminded that implementers are the only people whose opinions actually matter.
--- end quote ---
and someone else in the same conversation:
--- start quote ---
You can't practically anti-champion standards that are small improvements to features that ought to have been abandoned, like Shadow DOM. Shadow DOM sucks, but it sucked a little less when they added CSS Module Scripts, Selection.getComposedRanges(), ElementInternals.shadowRoot…
https://x.com/dfabu/status/1841936377350652391
---
It's doable, but not easy especially when the train engine is being stuffed with high-octane fuel by Google's resources.
They are decades of work away from having a browser that would be competitive with Chrome or Firefox.
It’s a valuable, ambitious project, but it is going to take a while before it can be used for anything real.
At least now the cynical pessimistic takes changed from "impossible, not even MS with their giant teams can do it" to "it may take decades for this small team to do it".
They changed course.