Just yesterday I was thinking about Ladybird, and I claimed that it was a fool’s errand, for reasons I’ll explain in a bit. What I didn’t know is if Kling recognized what he was doing, and was just not taking it very seriously, or if he was way over his head and was kind of oblivious.
I enjoyed reading this interview because it makes it very clear that Kling has a lot of experience doing this, and understands that’s it’s difficult, and is doing it because he enjoys it.
The reason I don’t think Ladybird will ever really get to the point where it can render an arbitrary site perfectly, is based on my experience as a web developer. I haven’t been doing web development for very long, but there have been a couple times in the last couple of years where I’ve stumbled upon browser layout bugs where Chrome/Firefox/Safari render something different. These are normally not issues where a browser completely misses something (ie, every browser supports flexbox these days). Rather, there are edge-case bugs that appear just by combining simple web components in simple ways. Chrome and Firefox handle a table with percentage height differently. Or a margin on a child which is larger than the parent’s width. And these are bugs that have existed for years. And for every edge-case like that where Chrome and Firefox differ, there are 10 more where the behavior is unintuitive or not defined by the spec but Firefox and Chrome have standardized.
But maybe, since Ladybird doesn’t have an existing buggy implementation, they’ll be able to implement the spec properly quickly the first time. I think that’s an interesting perspective that Kling brings up in this interview.
The other thing I want to comment on is that it’s really hard to tell how much progress they’re making.
> We've taken a very vertical slice approach to adding functionality to the browser… We tend to find a webpage that we want to improve for whatever reason. Maybe it's cool to get the New York Times to render, and then we just spend a bunch of time fixing as many issues as we can for that site… And that might not be the most structured approach to it, but it has been very, very good at keeping people motivated and excited and engaged in the work
This means that Ladybird “supports” a ton of features. They support flexbox! They support grid! But pretty much all of these features are only partial implementations. Kling says in the interview they support svg, and then later explains that they’re going to have to re-write the text-rendering system to get text-on-curves working. Well, to me, “supports svg” means “we have implemented the entire svg specification.” When Kling is using it to mean “we have some portion of svg’s work. We don’t crash when we see an svg element.” I’m not saying Kling’s definition is wrong, but it’s another factor that makes it difficult to judge where the project is.
To start to wrap up this (long) comment, let me restate the four claims I’m making. (This is not the conclusion, this is the summary before the conclusion, hang on.)
* Ladybird is developed differently in two ways: vertical slices, and being implemented from scratch in modern times.
* there are people who are misled by the vertical-slices and Kling’s use of “support” to believe that Ladybird development is a lot farther along than it is.
* There are people like me who think that Ladybird will never complete with existing browser engines (we also have a hard time judging Ladybird’s progress for the reasons stated above).
* These same reasons may allow Ladybird to reach compatibility with other browsers.
I have a lot of respect for Kling, and I think it’s cool that they’ve been able to accomplish so much “for the fun of it”. As mentioned in the interview, this will have short-term positive impact even if it never matches Chrome. If it wasn’t clear from how long this was, I’m actually really enthusiastic about the project, and I’ll be looking at ways to contribute in the future.
> The reason I don’t think Ladybird will ever really get to the point where it can render an arbitrary site perfectly, is based on my experience as a web developer. I haven’t been doing web development for very long, but there have been a couple times in the last couple of years where I’ve stumbled upon browser layout bugs where Chrome/Firefox/Safari render something different.
So what does perfect even mean in this context? Who's right, Chrome, Firefox, or Safari?
I 100% believe Ladybird will eventually be able to render arbitrary sites in an acceptable format at some point (potentially within the next year or two). It's pretty remarkable how many sites look very close to acceptable already. Any weird edge cases where Ladybird renders stuff differently from a big browser won't mean it's rendering the site "imperfectly"; just like how when Firefox and Chrome do different things, it doesn't mean either one is "correct".
You should check out his browser hacking videos. It's pretty shocking how much they have already and how fast it's improving. I have no doubt they will eventually be able render the vast majority of websites correctly. The real question is whether they will ever be able to make it performant enough that people who don't care about browser hacking will choose to use it. That's where a lot of the engineering hours in browsers goes.
> It's pretty shocking how much they have already and how fast it's improving.
My experience with large software projects is that there is an 80/20 effect where the first 80% happens really fast and easy and then the last 20% gets harder and harder and harder.
Most of the challenge of software engineering is dealing with the scale and complexity of the codebase itself. So greenfield development is always going to be faster at first because there's simply less code to go around. But as you keep pouring code in, you are creating the complexity that makes software development hard.
I definitely wouldn't do a linear projection of their current velocity and assume the whole project will keep moving that fast.
I suspect that the momentum behind the project is having a group of core developers (Kling foremost) that have complete knowledge of all the moving parts. This allows a small team to make changes quickly while keeping the whole cohesive and without the slowdown of deliberative bureaucracy. Maybe it’s like the human organizational equivalent of L1 cache. It’s like riding a wave, a situation that can’t last forever. I have been part of teams that did the work of much larger teams. It’s great when that happens. The last mile might be less fun, but this entire OS is a labor of love.
I say something similar to my friends and colleagues all the time regarding my “professional” software projects. It takes 20% of the time to do 80% of the work. But that last 20% of the work takes 80% of the time.
Essentially the core functionality doesn’t take very long to build out. But the final polishing, details, edge cases, and bug fixes soak up a huge amount of time.
> we also have a hard time judging Ladybird’s progress for the reasons stated above
There are plenty of available test for web browser stack, allowing to compare browsers and their implementation of standards, including Ladybird.
* Acid3: http://wpt.live/acid/acid3/test.html
* All browsers score 100/100
* HTML5test: https://html5test.com/index.html
* Chrome: 528
* Firefox: 491
* Safari: 471
* Ladybird: 266 (in december 2022, I couldn't find more recent figures, but I wouldn't be surprised if it were significantly higher today)
* Test262 (JS engines): https://test262.report
* Chrome (V8): 86%
* Firefox: 85%
* Safari: 85%
* Ladybird: 87% (behind on language syntax, significantly ahead on built-ins, internationalization, and AnnexB)
* Web Platform Tests: https://web-platform-tests.org/
* I don't have figures for this, but this is integrated in Ladybird's CI pipeline
* Probably others
The point is: it is quite possible to judge and measure overall progress, and the vertical slice approach they use lead to constant overall improvement.
Well, that's the thing when we're talking about hobbyist FOSS development. There's no bosses and no money involved to get a developer, point them at specifications, and say "implement this top to bottom." Instead you're going to get people implementing the parts important to them and/or fun to implement and/or relatively easy. Can a new browser engine compete with the big boys when it's developed like that? No, but maybe it can get good enough for casual use, and since it was mentioned in another thread here that Kling actually has hired a dev to work on Ladybird/LibWeb, maybe the whole thing's moot anyway and we'll start seeing things like text on an SVG path and other stuff which I imagine is not so fun to implement get done in the near future.
I enjoyed reading this interview because it makes it very clear that Kling has a lot of experience doing this, and understands that’s it’s difficult, and is doing it because he enjoys it.
The reason I don’t think Ladybird will ever really get to the point where it can render an arbitrary site perfectly, is based on my experience as a web developer. I haven’t been doing web development for very long, but there have been a couple times in the last couple of years where I’ve stumbled upon browser layout bugs where Chrome/Firefox/Safari render something different. These are normally not issues where a browser completely misses something (ie, every browser supports flexbox these days). Rather, there are edge-case bugs that appear just by combining simple web components in simple ways. Chrome and Firefox handle a table with percentage height differently. Or a margin on a child which is larger than the parent’s width. And these are bugs that have existed for years. And for every edge-case like that where Chrome and Firefox differ, there are 10 more where the behavior is unintuitive or not defined by the spec but Firefox and Chrome have standardized.
But maybe, since Ladybird doesn’t have an existing buggy implementation, they’ll be able to implement the spec properly quickly the first time. I think that’s an interesting perspective that Kling brings up in this interview.
The other thing I want to comment on is that it’s really hard to tell how much progress they’re making.
> We've taken a very vertical slice approach to adding functionality to the browser… We tend to find a webpage that we want to improve for whatever reason. Maybe it's cool to get the New York Times to render, and then we just spend a bunch of time fixing as many issues as we can for that site… And that might not be the most structured approach to it, but it has been very, very good at keeping people motivated and excited and engaged in the work
This means that Ladybird “supports” a ton of features. They support flexbox! They support grid! But pretty much all of these features are only partial implementations. Kling says in the interview they support svg, and then later explains that they’re going to have to re-write the text-rendering system to get text-on-curves working. Well, to me, “supports svg” means “we have implemented the entire svg specification.” When Kling is using it to mean “we have some portion of svg’s work. We don’t crash when we see an svg element.” I’m not saying Kling’s definition is wrong, but it’s another factor that makes it difficult to judge where the project is.
To start to wrap up this (long) comment, let me restate the four claims I’m making. (This is not the conclusion, this is the summary before the conclusion, hang on.)
* Ladybird is developed differently in two ways: vertical slices, and being implemented from scratch in modern times.
* there are people who are misled by the vertical-slices and Kling’s use of “support” to believe that Ladybird development is a lot farther along than it is.
* There are people like me who think that Ladybird will never complete with existing browser engines (we also have a hard time judging Ladybird’s progress for the reasons stated above).
* These same reasons may allow Ladybird to reach compatibility with other browsers.
I have a lot of respect for Kling, and I think it’s cool that they’ve been able to accomplish so much “for the fun of it”. As mentioned in the interview, this will have short-term positive impact even if it never matches Chrome. If it wasn’t clear from how long this was, I’m actually really enthusiastic about the project, and I’ll be looking at ways to contribute in the future.