This Month in Ladybird – August 2026

I'm still very interested in the project and look forward to each monthly update, and I can empathize (though not agree) with the reasoning, but something is off ever since they announced the decision to close the project to outside contributions. It's still Open Source, but only a self-selected group of maintainers gets to write and merge code, at least for the time being.

Somehow that's not the "a new independent Open Source browser" future I thought we had signed up for with our attention.

Again, I understand all the arguments for why at this particular time they feel that they cannot afford the energy expense required need to run a community. First-hand, actually, because I am involved with running a very large one myself.

But it makes me think a lot about the value proposition of the product. Re-creating Firefox/Chrome can still be a useful exercise, but from an end-user POV another exchangable web browser will not rock their world. Wouldn't the real product be healthy governance?

Separately I wonder if the compatibility job is easier now that you can just give the HTML5 spec to Fable and Bob's your uncle.

Then something unexpected happened: Apple adopted KHTML for Safari's WebKit. WebKit was then adopted as the render for Chrome

Could a niche browser still become mainstream /today/? I think so.

Ladybird can afford to be a beloved hobby browser that simply hasn't solved all the edge cases but works well 97% of the time

I understand that your argument still stands in big picture, but in this big world there is plenty of room for Firefox and Ladybird and there is more than enough room to grow. Firefox mostly is being held back with their organization. I'm not convinced that it is technical problem.

But then again, I'm still believing that there will be a year of desktop Linux coming. Maybe even sooner than we expect.

I think it is still a bit too early to say that. The most difficult part is to ensure the security of the implementation, and not just the checkbox compliance against standards. So when this survives the swarm of pentesters, it will be a absolute titanic work. Otherwise it might be too risky to use.

> - how many people in a team do you need and how long would it take to write a browser engine from scratch

The boring not-really-an-answer is "it depends on which sites you want to render properly": a browser capable of rendering Hacker News is a perfectly fine one-person project (which the book would get you to), supporting things like banking and online mail requires not just developers but also people willing to "dogfood" test it as their daily browser

I second https://browser.engineering as a resource on that. Also consider dropping into the Servo Zulip.

> how is an actual html, css and javascript specification implemented at the code level? are we painting an empty canvas or is it more complicated

It's more complicated, but conceptually it's painting into an empty canvas

> how is backward compatibility implemented? > what test cases do you consider for making something like this? how do you determine if you have handled all the outliers or not?

The ~2 million Web Platform Tests https://github.com/web-platform-tests/wpt. They also handle most of the backwards compatibility. The rest is engine developers manually comparing against each other's engines.

> is all the code written in c++ or is it rust these days?

There's still a lot of C++, but new code is increasingly Rust. To what degree varies by engine: Servo (and Blitz) are almost entirely Rust. Ladybird was 100% C++ in February, but is now 25% Rust. Firefox has significant and actively developed core components in Rust, but isn't actively converting more core modules. Chromium doesn't have any core components in Rust yet, but has invested heavily in converting foundational dependencies like FreeType and HarfBuzz to Rust. Safari is the outlier, I believe it doesn't use any Rust yet.

> how many people in a team do you need and how long would it take to write a browser engine from scratch

I've heard estimates that Chrome has a team of >1000, Firefox 500-800, Safari 100-200, Servo / Ladybird are more like 5-10. I've been building Blitz by myself for ~3 years. Something like 3-5 years is probably a minimum if you're truly building from scratch unless you have a really large team backing it, and depending on your success criteria.

> how is mobile vs desktop handled at the browser engine code level?

There are actually surprisingly few differences beyond touch input and screen size handling.

Going above 5%, OTOH, I would be shocked to ever see happen, for two reasons. 1) Mass-market adoption requires working well on an enormous long tail, which is difficult without a large team. 2) The primary driver of playing at that size is mass marketing/distribution, which requires $$$. Engineering a great product is necessary, but not sufficient.

My perspective on this is informed by being on Google Chrome from inception to 2025. Chrome from near the beginning was well-engineered and had three compelling-according-to-user-research advantages over the IE of 2008 (speed, security, and not being made by Microsoft), but mass adoption depended on a large number of non-engineering factors, of which marketing/distribution was (to a then-mid-20s software engineer) the most surprising one. I didn't believe that was what made the difference in which browser most people used; I was very wrong. Techies are not the leading-edge trendsetters for the masses we sometimes believe we are.

IMO, taking mass market share in the future will require either a compelling-to-users product coupled with at least a couple hundred million dollars in marketing and distribution budget, or else something that is completely unlike web browsers of the past (maybe there's something that replaces the web entirely). No one has done the former since Chrome launched; the closest people have come to the latter thus far is things like Dia/Atlas that try to reimagine workflows in an AI context, and I think the market has not found those to be sufficiently different+compelling.

In some situations it's the only way to get a decent download speed.

As far as fragmentation goes, I think both Firefox and Chrome derivatives figure out the final file size in advance, pre-allocate a temporary file that long and put data in it as it arrives. Completing the download is a rename operation or a no-op.