Ladybird seems to have received a nice boost in momentum in the past two years. If you've ever watched one of Andreas videos on YouTube you'll find he's incredibly driven and knowledgeable in this area. I can imagine someone like him would go from being a "10x programmer" to a "100x programmer" with AI assistance. I am not entirely sure to what degree AI is being leveraged to speed up development, but I am indeed happier I might be able to ditch FF and begin using their browser soon.
> Ladybird seems to have received a nice boost in momentum in the past two years.
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?
The flood of low effort AI-contributions makes accepting anonymous contributions impractical nowadays. They'd waste hours reviewing things of no value. I know because it happened to several of my moderately successful projects. At some point I had to stop caring. I now only review the PR if the message is a single unformatted paragraph with few emojis, I find this to be a good signal that it was made by a human and not an agent (the code could still be LLM but a human cared enough to write their own message). I'm sure I will miss genuinely good and valuable contributions, but the signal-to-noise ratio is just too low.
It would be 100x worse for them because who wouldn't want to have a browser in their contribution portfolio when seeking a job?
A lot of folks might not want to hear it, but realistically some there's going to have to be a cultural realization that machine-generated low effort slop is not any more desired or helpful than human-generated low effort slop.
That's not an outright rejection of LLM-assisted code, it just means that a real person needs to be awake, at the wheel, and just as significant of a contributor. Literally anybody can point Claude at a repo and say "add X feature" or "fix Y bug" and so PRs that do that carry no value.
The value of a feature or a bugfix is not calculated from the effort required but from the need or desire for said feature or bugfix. So whether or not the barrier to entry has been lowered by llm's is irrelevant. What matters as to it's value is the result.
The important part is the quality of the code, how well-considered its design is, how well it gels with existing code, how readable it is to other humans, how well documented it is, how well its author understands it (and thus, can make surgical changes if needed), and how well it was tested.
A PR that implements a sought out feature or bug fix can be practically worthless if it doesn’t check some percentage of those boxes. The line differs per project naturally, but almost nobody wants a PR that is missing all of them.
That might be true of the raw, unknowable "true" value of the thing, but that's not the same as what people are willing to pay for a thing.
When one evaluates a purchase, implicit in that evaluation is the option to do the work one's self. If the price you are offering a thing is more than the cost of doing it myself, then I will not buy from you.
LLM coding proponents keep saying that it reduces the cost of development to near-zero. We keep hearing about all the "things we wouldn't have done before because it was just too expensive to get people to do it."
If this is true, any day now, the customers and clients and consumers are going to catch wise and start doing it for themselves. I mean, it's been almost a year since LLMs supposedly "10x'd" everyone's productivity. I'm still waiting to see where all this singularity is, so I doubt it actually is true. But it doesn't mean you're going to achieve ungodly margins on your software sales, especially when we're talking about open source software. Value absolutely does have a component that is the cost of the inputs.
> 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.
This is a problem brought on by AI, and does not seem fair to imply it's Ladybird's problem to solve.
Writing a browser/engine from scratch is a massively ambitious undertaking by itself. I don't expect them to also solve the tangential AI problem that every other open source project is contending with. Others can step up for that one.
I agree with your concerns but also think that a new viable browser engine will be such a benefit to the health of the open web that I'm willing to overlook such irregularities, at least for now. sqlite doesn't accept contributions either and it's done well for itself, and if Ladybird ends up going sour there's always the possibility of a fork. This is similar to my stance towards Firefox: despite the actions of Mozilla Corp, having at least one non-Blink engine is too important, and for friends and family that I care about, working ad-blockers are essential so there's no practical alternative.
Multiple browser engines reimplementing the same things fragments engineering resources and blink based browsers do have working as blockers. In fact ladybird uses the same adblocker as Brave, which is blink based.
Free and open-source software licenses never promised that any given project would absolutely accept code contributions from the general public. You're as free to exercise the Four Freedoms with Ladybird as you are with Firefox or Chromium, including the freedom to fork it; and your practical ability to get your own change merged into upstream Ladybird is probably about as good as it is for Firefox/Chromium, too.
Linux had an existing population of Unix engineers who had a strong incentive to build something that could replace the Unix systems they were paying for.
Ladybird doesn’t replace something developers are already paying for, so the incentive to make substantial, high-quality contributions is much weaker.
> 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.
That is the way the BSDs are developed and they're free software. If you want to you can pull the code and modify whatever you want. Let them get the thing up and running first, then see how the project handles external contributions. If they somehow fail to see the brilliance of some external contribution a fork will soon take over from where they dug themselves in, something which has happened many times over in free software land: Firefox (took over from the Mozilla Suite), Libreoffice (took over from Openoffice), Nextcloud (took over from Owncloud), egcs (took over from gcc, later became the main gcc branch), etc.
Ladybird [0]: "We will no longer accept public pull requests. From now on, code changes to the Ladybird codebase will only be introduced by project maintainers. [...] There will not be a separate process for submitting patches by other means."
FreeBSD [1]: "So you want to contribute to FreeBSD? That is great! FreeBSD relies on the contributions of its user base to survive. Your contributions are not only appreciated, they are vital to FreeBSD’s continued growth. [...] If you are submitting a simple patch to the src repo, please consider submitting it to the project’s GitHub mirror as a pull request."
Don't BSDs accept new contributors and patches tho? A long time ago I worked in the freebsd documentation project (translating th handbook) and it was pretty easy to join the core group. And ooenbsd pioneered anoncvs didn't it?
For ladybird it seems the group is closed to outsiders.
That's not really relevant. "anoncvs" was just the ability to retrieve source code from the project's repository without an account, as opposed to being forced to download a tarball. It didn't do anything more than ladybird's public github-hosted repository[1] to facilitate contributions.
Think of ladybird's github issues like the openbsd mailing lists. If you start submitting good issues with patches there, and you do it often enough that they would rather let you merge your patches yourself, there's a high likelihood you'll no longer be an outsider. (I don't know this from personal experience with ladybird, but it's the vibe I get from their posts about the matter.)
> 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.
> - 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
It's impressive that they're doing such titanic work. However, I'm highly skeptical that they can create a real rival to established browsers. I'm sorry for telling this, but Web standards are simply too complex and huge. Ladybird to Chrome / Firefox is almost like Wine / ReactOS to Windows, that last 3-5% of gap actually differentiates a normal browser from a browser that is a pain for web developers. And it's the most stubborn part to be fixed. Also, keep in mind that it hasn't much market, at least IE had a significant market that forced the developers to support it (with all the hate).
As of a week ago their pre-alpha version was capable of running my extremely heavy JS+ SVG + worker thread + SSE app, a bit slowly I admit but correctly in all major exercises I tried. So, I'm optimistic. They're doing great.
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.
But I agree, it's impressive. My blog uses a lot of modern CSS features (such as nested selectors), and this latest version rendered almost perfectly. Much better than Servo. Still, this small gap is often the difference between a normal browser and a browser that is a pain. Safari has much, much better compatibility, but even then this browser is hated for it's quirks, because even much smaller compatibility gaps are quite noticeable.
> Safari has much, much better compatibility, but even then this browser is hated for it's quirks
I think this meme has almost run its course.
Funnily enough I just had to fix a Safari layout quirk yesterday (for iOS 16 & 17 devices only). I was excited to pick it up because it had been _so long_ since I had to deal with a CSS-related browser incompatibility. I was nostalgic :')
I raced Claude to fix it. I knew which CSS had the issue, but I needed to set up an iOS simulator to verify my fix. So I had to download xcode, which download 10GB of data for a current simulator and Apple's embedded code-assist model. Then another 8GB for the iOS 16 simulator.
Claude took about 5min to find the right CSS file and then got stuck at the same point as me: needing to simulate it to verify. It just got the old webkit binaries and hacked together its own minimal browserstack clone.
It finished before me because of those downloads, but it only found half the fix. So... I won!
Except...I made a typo (`no-wrap` instead of `nowrap`) and had to do a fixup commit.
The browser might reach 95-97% compatibility eventually. But the last 3-5% gaps are the most stubborn. Many of these 3-5% are not trivial API calls. They might be some subtle legacy quirks, timing/rendering things, etc. There is a lot of poorly written historical code that might be illegal by web standards but browsers are forced to support. Established browsers have decades of patches and regression testing.
That sounds like a reasonable estimate for the gap between any pair of Chrome, Firefox, and Safari, just from varied depth of implementation of more recent standards.
The history of Chrome and Safari traces back to KTML, the renderer for Konqueror, a niche browser on Linux with so little market share there weren't real conversations about it ever seriously competing with Firefox or IE.
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.
The complexity of web standards isn't necessarily a bad thing. A lot of the "complexity" (as usually judged by the raw size of the spec) is just existing APIs evolving to be more rigorously defined. Before that level of specificity, browser implementations varied and engineers had to make certain decisions.
A more "complex" spec can sometimes make the job of the engineer simpler.
That's not the kind of complexity that is the problem though. The complexity you have to deal with is just more and more features being shoved into the spec at breakneck speed, or if they are not in the spec, it's just Google adding them to their engine and everyone starts using them anyway to the quasi-monopoly of Chromium-based browsers.
Are they? I feel like the real difference is an insistence on actually enforcing them. There were some really strong standards at the time of IE5, it was just the wild west in terms of what got built. And then you had Tantek Çelik quietly building all of them in IE5 on the Mac. Just a question of where to look.
May just be me being a romantic. Work shut off access to non-Chrome browsers an took away Incognito Mode. Which is fun for QA work.
Outside of the adoption of new standards, most of the work that goes into the big 3 browsers is more around edge cases and compat due to historical development reasons.
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
It is a nightmare scenario: you have a long tail of thousands of websites that are broken, a large complex codebase and you need hours of time per bug for a human to investigate and fix it. Some trickier bugs could take days to diagnose. It's not sustainable for a small team. Luckily, I think this is one of the cases where AI can be leveraged appropriately, and give them a fighting chance of catching up.
Just a small personal touch -- my coworker is constantly pushing me to use Chrome because it "just works", but I'm stubborn as hell. Used Firefox from early 2000s. Oh how I will love to twist his nerve even more once I will switch to Ladybird. Saying this because there has been more harder days to counter these pushes. And to be honest I think we are overthinking about how much this last 3-5 % actually matter for huge crowds.
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'm still believing that there will be a year of desktop Linux coming. Maybe even sooner than we expect.
It started 9 years ago.
That's the year ChromeBooks first outsold Macs in the USA. And note, that is by value, not units, meaning at least 4-5x as many Chromebooks were sold as all Mac hardware put together.
By 3-4y later this was worldwide.
So desktop Linux computers are now comprehensively outselling macOS machines and have been for nearly a decade… even with Apple's migration to Arm, which means better small machines but worse big machines.
But it's the wrong sort of Linux and so the Penguin taleban don't count it and are still arguing about... oh, systemd vs SysVinit, or glibc vs musl, or Emacs vs Vim, or something.
> It's impressive that they're doing such titanic work.
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.
This is probably an unpopular opinion but I think that if all this effort went in to improving Firefox, or a fork of Firefox if the goal is to totally de-Google it, then that wouldn't be such a problem and it would overall be healthier for the web. I don't really understand the purpose of this titanic software engineering effort just to avoid... a default search engine setting?
It doesn't have to chase it down, just keep plodding along implementing the new standards as they become accepted.
Google likes to make up its own "standards" and push them out on chrome, but Safari tends to be the late-comer to supporting impactful standards, not Firefox.
Do you have a particular use-case where Firefox's lack of support blocks you?
I'm honestly relieved to see that I'm not the only one to test optimized/newer implementations against less optimized/older implementations. It's what I came up with after thinking about it for quite a while and I've been wondering why so little other software seems to do that. In my case, it's about serialization code. My test compare self-reported reader / writer states and serialized data.
Ladybird goes further by also running the engines in parallel in debug builds during normal use. They have a way to extract test cases from any bugs found that way.
Feels like the old "browser wars" days again. Between AI productivity, and Google losing the grace to bloat the web specs, I wouldn't be surprised if it starts to take market share away from other browsers as soon as it's stable.
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.
Yeah basically everybody I know who's non-technical switched to Chrome when Google started advertising it on google.com (This was back when nontechnical users would start every search query by going to google.com). "Oh this says it's better and faster, let me download it". Google also paid shareware/freeware developers to bundle Chrome with their installers if you didn't uncheck some option in the "expert install" mode. Chrome would then launch and prompt the user to set it as the default browser. This is somewhat questionable, but this sort of developer usually pushes some sort of malware in their installers so I suppose Chrome was an improvement on that.
The distribution opt-outs really bugged me at the time, and I went and talked to the marketing team. Surprisingly, users who got Chrome via one of those opt-out deals used it at rates/in ways statistically indistinguishable from "organic" users (i.e. users who manually downloaded Chrome and installed it). This was a pretty strong counterargument to the idea that we were pushing something unhelpful on people who didn't want it -- they seemed to "want it" as much as the people who'd bothered to go find it manually.
I still didn't (and don't) love the practice, but it called in to question a lot of my assumptions about what people knew about software, why they used what they did, how they found it, etc.
Part of me wonders in a world with evergreen browsers if that long tail won’t simply shrink as time goes on.
I have yet to run into Java applets or Internet Explorer required situations in years. As far back as 2016 I’d occasionally find myself having to deal with both of these things. Still rare in 2016 but it was there.
Eventually I never saw it again.
That said, I’m not sure what gaps exist that I don’t perceive either, so I could be wrong and not know it
I agree, 1% is reasonable. That's still a huge number of people. And, not all users are created equal. If that 1% of everyone is skewed towards the more educated, IE if 5% of millionaires switch, that's 5% fewer eyeballs looking at a sports car ad.
I wonder if another path to “success” for ladybird could be rather than end users downloading it for the main browser, if it gains enough dev interest, we could get some kind of competitor to electron and it would end up getting bundled in that way as a lighter weight runtime to chromium for that use case.
People are all flawed. You can find faults in everyone. Overlooking these flaws is okay to a large number of folks as the product itself is amazing. The fact is that you're likely ignorant to the large number of products and services you use produced by folks with similar flaws.
My suggestion is to not try to idolize individuals. Products should be judged independent of the individuals involved in creating them, especially when many individuals participate in their creation.
On a serious note, it would be nice if in the far far future, once the browser is very stable, they release a windows binary since I do sometimes still use Windows 11 for moments when it is needed and it would be a shame to then temporarily still have to switch to Edge e.t.c. instead of being able to use Ladybird there too.
You never used a download manager like DownThemAll or GetBot back in the day?
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.
Speed Download on early OS X releases was a lifesaver back when I was still on 56k dialup. Its multiplexing was the only way I could get decent speeds half the time (browsers would often drift down to single digits) and being able to resume when connections were dropped (at least when servers supported it).
I didn't expect to see Twitch working so soon!
Ladybird seems to have received a nice boost in momentum in the past two years. If you've ever watched one of Andreas videos on YouTube you'll find he's incredibly driven and knowledgeable in this area. I can imagine someone like him would go from being a "10x programmer" to a "100x programmer" with AI assistance. I am not entirely sure to what degree AI is being leveraged to speed up development, but I am indeed happier I might be able to ditch FF and begin using their browser soon.
> Ladybird seems to have received a nice boost in momentum in the past two years.
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?
The flood of low effort AI-contributions makes accepting anonymous contributions impractical nowadays. They'd waste hours reviewing things of no value. I know because it happened to several of my moderately successful projects. At some point I had to stop caring. I now only review the PR if the message is a single unformatted paragraph with few emojis, I find this to be a good signal that it was made by a human and not an agent (the code could still be LLM but a human cared enough to write their own message). I'm sure I will miss genuinely good and valuable contributions, but the signal-to-noise ratio is just too low.
It would be 100x worse for them because who wouldn't want to have a browser in their contribution portfolio when seeking a job?
A lot of folks might not want to hear it, but realistically some there's going to have to be a cultural realization that machine-generated low effort slop is not any more desired or helpful than human-generated low effort slop.
That's not an outright rejection of LLM-assisted code, it just means that a real person needs to be awake, at the wheel, and just as significant of a contributor. Literally anybody can point Claude at a repo and say "add X feature" or "fix Y bug" and so PRs that do that carry no value.
The value of a feature or a bugfix is not calculated from the effort required but from the need or desire for said feature or bugfix. So whether or not the barrier to entry has been lowered by llm's is irrelevant. What matters as to it's value is the result.
The important part is the quality of the code, how well-considered its design is, how well it gels with existing code, how readable it is to other humans, how well documented it is, how well its author understands it (and thus, can make surgical changes if needed), and how well it was tested.
A PR that implements a sought out feature or bug fix can be practically worthless if it doesn’t check some percentage of those boxes. The line differs per project naturally, but almost nobody wants a PR that is missing all of them.
[flagged]
That might be true of the raw, unknowable "true" value of the thing, but that's not the same as what people are willing to pay for a thing.
When one evaluates a purchase, implicit in that evaluation is the option to do the work one's self. If the price you are offering a thing is more than the cost of doing it myself, then I will not buy from you.
LLM coding proponents keep saying that it reduces the cost of development to near-zero. We keep hearing about all the "things we wouldn't have done before because it was just too expensive to get people to do it."
If this is true, any day now, the customers and clients and consumers are going to catch wise and start doing it for themselves. I mean, it's been almost a year since LLMs supposedly "10x'd" everyone's productivity. I'm still waiting to see where all this singularity is, so I doubt it actually is true. But it doesn't mean you're going to achieve ungodly margins on your software sales, especially when we're talking about open source software. Value absolutely does have a component that is the cost of the inputs.
Looks like we need some kind of reputation mechanism for contributors.
https://github.com/mitchellh/vouch
> 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.
This is a problem brought on by AI, and does not seem fair to imply it's Ladybird's problem to solve.
Writing a browser/engine from scratch is a massively ambitious undertaking by itself. I don't expect them to also solve the tangential AI problem that every other open source project is contending with. Others can step up for that one.
I agree with your concerns but also think that a new viable browser engine will be such a benefit to the health of the open web that I'm willing to overlook such irregularities, at least for now. sqlite doesn't accept contributions either and it's done well for itself, and if Ladybird ends up going sour there's always the possibility of a fork. This is similar to my stance towards Firefox: despite the actions of Mozilla Corp, having at least one non-Blink engine is too important, and for friends and family that I care about, working ad-blockers are essential so there's no practical alternative.
Multiple browser engines reimplementing the same things fragments engineering resources and blink based browsers do have working as blockers. In fact ladybird uses the same adblocker as Brave, which is blink based.
It also fragments power, which makes it worth it.
Power is proportional to browser market share, not the engines the browsers use.
Free and open-source software licenses never promised that any given project would absolutely accept code contributions from the general public. You're as free to exercise the Four Freedoms with Ladybird as you are with Firefox or Chromium, including the freedom to fork it; and your practical ability to get your own change merged into upstream Ladybird is probably about as good as it is for Firefox/Chromium, too.
Said announcement: https://ladybird.org/posts/changing-how-we-develop-ladybird/
Linux had an existing population of Unix engineers who had a strong incentive to build something that could replace the Unix systems they were paying for.
Ladybird doesn’t replace something developers are already paying for, so the incentive to make substantial, high-quality contributions is much weaker.
> 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.
That is the way the BSDs are developed and they're free software. If you want to you can pull the code and modify whatever you want. Let them get the thing up and running first, then see how the project handles external contributions. If they somehow fail to see the brilliance of some external contribution a fork will soon take over from where they dug themselves in, something which has happened many times over in free software land: Firefox (took over from the Mozilla Suite), Libreoffice (took over from Openoffice), Nextcloud (took over from Owncloud), egcs (took over from gcc, later became the main gcc branch), etc.
No, it isn't.
Ladybird [0]: "We will no longer accept public pull requests. From now on, code changes to the Ladybird codebase will only be introduced by project maintainers. [...] There will not be a separate process for submitting patches by other means."
FreeBSD [1]: "So you want to contribute to FreeBSD? That is great! FreeBSD relies on the contributions of its user base to survive. Your contributions are not only appreciated, they are vital to FreeBSD’s continued growth. [...] If you are submitting a simple patch to the src repo, please consider submitting it to the project’s GitHub mirror as a pull request."
[0] https://ladybird.org/posts/changing-how-we-develop-ladybird/
[1] https://docs.freebsd.org/en/articles/contributing/
Don't BSDs accept new contributors and patches tho? A long time ago I worked in the freebsd documentation project (translating th handbook) and it was pretty easy to join the core group. And ooenbsd pioneered anoncvs didn't it?
For ladybird it seems the group is closed to outsiders.
> And ooenbsd pioneered anoncvs didn't it?
That's not really relevant. "anoncvs" was just the ability to retrieve source code from the project's repository without an account, as opposed to being forced to download a tarball. It didn't do anything more than ladybird's public github-hosted repository[1] to facilitate contributions.
Think of ladybird's github issues like the openbsd mailing lists. If you start submitting good issues with patches there, and you do it often enough that they would rather let you merge your patches yourself, there's a high likelihood you'll no longer be an outsider. (I don't know this from personal experience with ladybird, but it's the vibe I get from their posts about the matter.)
[1](https://github.com/LadybirdBrowser/ladybirdP)
few stupid questions as always so that i can become a smarter person
- what is the process of making a browser engine? what does the requirements look like
- how is an actual html, css and javascript speification implemented at the code level? are we painting an empty canvas or is it more complicated
- how is backward compatibility implemented?
- is all the code written in c++ or is it rust these days?
- how many people in a team do you need and how long would it take to write a browser engine from scratch
- what test cases do you consider for making something like this? how do you determine if you have handled all the outliers or not?
- how is mobile vs desktop handled at the browser engine code level?
> what is the process of making a browser engine? what does the requirements look like
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.
The book Web Browser Engineering may be interesting: https://browser.engineering/
> - 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
For the first two, I highly suggest you watch a few of their videos from about a year ago.
I am watching this project with interest.
It's impressive that they're doing such titanic work. However, I'm highly skeptical that they can create a real rival to established browsers. I'm sorry for telling this, but Web standards are simply too complex and huge. Ladybird to Chrome / Firefox is almost like Wine / ReactOS to Windows, that last 3-5% of gap actually differentiates a normal browser from a browser that is a pain for web developers. And it's the most stubborn part to be fixed. Also, keep in mind that it hasn't much market, at least IE had a significant market that forced the developers to support it (with all the hate).
https://waspdev.com/articles/2025-04-07/will-there-be-a-new-...
As of a week ago their pre-alpha version was capable of running my extremely heavy JS+ SVG + worker thread + SSE app, a bit slowly I admit but correctly in all major exercises I tried. So, I'm optimistic. They're doing great.
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.
But I agree, it's impressive. My blog uses a lot of modern CSS features (such as nested selectors), and this latest version rendered almost perfectly. Much better than Servo. Still, this small gap is often the difference between a normal browser and a browser that is a pain. Safari has much, much better compatibility, but even then this browser is hated for it's quirks, because even much smaller compatibility gaps are quite noticeable.
> Safari has much, much better compatibility, but even then this browser is hated for it's quirks
I think this meme has almost run its course.
Funnily enough I just had to fix a Safari layout quirk yesterday (for iOS 16 & 17 devices only). I was excited to pick it up because it had been _so long_ since I had to deal with a CSS-related browser incompatibility. I was nostalgic :')
I raced Claude to fix it. I knew which CSS had the issue, but I needed to set up an iOS simulator to verify my fix. So I had to download xcode, which download 10GB of data for a current simulator and Apple's embedded code-assist model. Then another 8GB for the iOS 16 simulator.
Claude took about 5min to find the right CSS file and then got stuck at the same point as me: needing to simulate it to verify. It just got the old webkit binaries and hacked together its own minimal browserstack clone.
It finished before me because of those downloads, but it only found half the fix. So... I won!
Except...I made a typo (`no-wrap` instead of `nowrap`) and had to do a fixup commit.
So I guess we'll call it a draw :(
The browser might reach 95-97% compatibility eventually. But the last 3-5% gaps are the most stubborn. Many of these 3-5% are not trivial API calls. They might be some subtle legacy quirks, timing/rendering things, etc. There is a lot of poorly written historical code that might be illegal by web standards but browsers are forced to support. Established browsers have decades of patches and regression testing.
That sounds like a reasonable estimate for the gap between any pair of Chrome, Firefox, and Safari, just from varied depth of implementation of more recent standards.
The history of Chrome and Safari traces back to KTML, the renderer for Konqueror, a niche browser on Linux with so little market share there weren't real conversations about it ever seriously competing with Firefox or IE.
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.
The web standards are enormously complex compared to that time. Not sure if today's tooling can compensate this.
The complexity of web standards isn't necessarily a bad thing. A lot of the "complexity" (as usually judged by the raw size of the spec) is just existing APIs evolving to be more rigorously defined. Before that level of specificity, browser implementations varied and engineers had to make certain decisions.
A more "complex" spec can sometimes make the job of the engineer simpler.
That's not the kind of complexity that is the problem though. The complexity you have to deal with is just more and more features being shoved into the spec at breakneck speed, or if they are not in the spec, it's just Google adding them to their engine and everyone starts using them anyway to the quasi-monopoly of Chromium-based browsers.
Are they? I feel like the real difference is an insistence on actually enforcing them. There were some really strong standards at the time of IE5, it was just the wild west in terms of what got built. And then you had Tantek Çelik quietly building all of them in IE5 on the Mac. Just a question of where to look.
May just be me being a romantic. Work shut off access to non-Chrome browsers an took away Incognito Mode. Which is fun for QA work.
Outside of the adoption of new standards, most of the work that goes into the big 3 browsers is more around edge cases and compat due to historical development reasons.
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
Yes, this is what I'm saying. It's unlikely to be a replacement for the majority of average users but can be popular among people like us.
It is a nightmare scenario: you have a long tail of thousands of websites that are broken, a large complex codebase and you need hours of time per bug for a human to investigate and fix it. Some trickier bugs could take days to diagnose. It's not sustainable for a small team. Luckily, I think this is one of the cases where AI can be leveraged appropriately, and give them a fighting chance of catching up.
Just a small personal touch -- my coworker is constantly pushing me to use Chrome because it "just works", but I'm stubborn as hell. Used Firefox from early 2000s. Oh how I will love to twist his nerve even more once I will switch to Ladybird. Saying this because there has been more harder days to counter these pushes. And to be honest I think we are overthinking about how much this last 3-5 % actually matter for huge crowds.
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'm still believing that there will be a year of desktop Linux coming. Maybe even sooner than we expect.
It started 9 years ago.
That's the year ChromeBooks first outsold Macs in the USA. And note, that is by value, not units, meaning at least 4-5x as many Chromebooks were sold as all Mac hardware put together.
By 3-4y later this was worldwide.
So desktop Linux computers are now comprehensively outselling macOS machines and have been for nearly a decade… even with Apple's migration to Arm, which means better small machines but worse big machines.
But it's the wrong sort of Linux and so the Penguin taleban don't count it and are still arguing about... oh, systemd vs SysVinit, or glibc vs musl, or Emacs vs Vim, or something.
Eh of course we don't count a totally locked down walled garden as Linux.
> It's impressive that they're doing such titanic work.
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.
Honestly, breaking on some advanced/esoteric features is a price I'd eagerly pay to get a browser that's cleaner, more lightweight, and user-focused.
This is probably an unpopular opinion but I think that if all this effort went in to improving Firefox, or a fork of Firefox if the goal is to totally de-Google it, then that wouldn't be such a problem and it would overall be healthier for the web. I don't really understand the purpose of this titanic software engineering effort just to avoid... a default search engine setting?
> if all this effort went in to improving Firefox, or a fork of Firefox
Someone tried to instigate that on Mastodon recently. It didn't work.
https://mastodon.social/@sarahjamielewis/116959309031485270
Spread the word. Contact the developers, ask them.
The forks I know about:
• Waterfox -- https://www.waterfox.com/
• Librewolf -- https://librewolf.net/
• Floorp -- https://floorp.app/
• Zen browser -- https://zen-browser.app/
• Mullvad -- https://mullvad.net/en/browser
• Konform -- https://codeberg.org/konform-browser
Others:
GNU IceCat – https://www.gnu.org/software/gnuzilla/
Mercury – https://thorium.rocks/mercury
I fear it would be hard to get some of the earlier forks on board... these are all based on much older codebases:
• Palemoon -- https://www.palemoon.org/
• Basilisk – https://www.basilisk-browser.org/
• Seamonkey – https://www.seamonkey-project.org/
Not even Firefox can keep up chasing down the chromium universe.
It doesn't have to chase it down, just keep plodding along implementing the new standards as they become accepted.
Google likes to make up its own "standards" and push them out on chrome, but Safari tends to be the late-comer to supporting impactful standards, not Firefox.
Do you have a particular use-case where Firefox's lack of support blocks you?
So excited about this. Writing a real new web browser is a titanic project and Ladybird is making amazing progress
Really excited for alpha. When it hits I plan on using it for my daily driver to help them with usage stats and crash reports.
I'm honestly relieved to see that I'm not the only one to test optimized/newer implementations against less optimized/older implementations. It's what I came up with after thinking about it for quite a while and I've been wondering why so little other software seems to do that. In my case, it's about serialization code. My test compare self-reported reader / writer states and serialized data.
Ladybird goes further by also running the engines in parallel in debug builds during normal use. They have a way to extract test cases from any bugs found that way.
Are there other sites that get through ad blockers as well as Twitch?
This is such a nerdy newsletter I love it
If you ever said you'd pay for a browser that doesn't exploit you nows the chance - donate to the project!
Feels like the old "browser wars" days again. Between AI productivity, and Google losing the grace to bloat the web specs, I wouldn't be surprised if it starts to take market share away from other browsers as soon as it's stable.
Sure, it could easily take 1%.
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.
Yeah basically everybody I know who's non-technical switched to Chrome when Google started advertising it on google.com (This was back when nontechnical users would start every search query by going to google.com). "Oh this says it's better and faster, let me download it". Google also paid shareware/freeware developers to bundle Chrome with their installers if you didn't uncheck some option in the "expert install" mode. Chrome would then launch and prompt the user to set it as the default browser. This is somewhat questionable, but this sort of developer usually pushes some sort of malware in their installers so I suppose Chrome was an improvement on that.
The distribution opt-outs really bugged me at the time, and I went and talked to the marketing team. Surprisingly, users who got Chrome via one of those opt-out deals used it at rates/in ways statistically indistinguishable from "organic" users (i.e. users who manually downloaded Chrome and installed it). This was a pretty strong counterargument to the idea that we were pushing something unhelpful on people who didn't want it -- they seemed to "want it" as much as the people who'd bothered to go find it manually.
I still didn't (and don't) love the practice, but it called in to question a lot of my assumptions about what people knew about software, why they used what they did, how they found it, etc.
Part of me wonders in a world with evergreen browsers if that long tail won’t simply shrink as time goes on.
I have yet to run into Java applets or Internet Explorer required situations in years. As far back as 2016 I’d occasionally find myself having to deal with both of these things. Still rare in 2016 but it was there.
Eventually I never saw it again.
That said, I’m not sure what gaps exist that I don’t perceive either, so I could be wrong and not know it
I agree, 1% is reasonable. That's still a huge number of people. And, not all users are created equal. If that 1% of everyone is skewed towards the more educated, IE if 5% of millionaires switch, that's 5% fewer eyeballs looking at a sports car ad.
I wonder if another path to “success” for ladybird could be rather than end users downloading it for the main browser, if it gains enough dev interest, we could get some kind of competitor to electron and it would end up getting bundled in that way as a lighter weight runtime to chromium for that use case.
Ugh, this guy again. I would stop using the web forever before I used Ladybird or anything made by Kling.
You praise DHH and Charlie Kirk, your moral compass is broken.
Context: https://kvibber.com/reviews/software/ladybird-inclusivity/
That's just the start of how many people came to learn about Kling. There was worse to come, apparently.
TLDR: pronoun drama
People are all flawed. You can find faults in everyone. Overlooking these flaws is okay to a large number of folks as the product itself is amazing. The fact is that you're likely ignorant to the large number of products and services you use produced by folks with similar flaws.
Is your suggestion that no one care?
My suggestion is to not try to idolize individuals. Products should be judged independent of the individuals involved in creating them, especially when many individuals participate in their creation.
[flagged]
[flagged]
what makes this a scam in your opinion, and how exactly do you reckon they are fooling investors?
snide vagueposting is a lot less cool than you think it is
It's probably the mozilla ceo
[flagged]
On a serious note, it would be nice if in the far far future, once the browser is very stable, they release a windows binary since I do sometimes still use Windows 11 for moments when it is needed and it would be a shame to then temporarily still have to switch to Edge e.t.c. instead of being able to use Ladybird there too.
You had me in the first half, not gonna lie.
> We also download over four parallel connections where possible.
I hope you can turn that off. It fragments the file and puts unnecessary load on the server.
You never used a download manager like DownThemAll or GetBot back in the day?
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.
GetRight was a fucking lifesaver when I was stuck on a 28.8k dial up connection that loved to drop at the worst possible time.
I haven't thought of that name in decades, but you're right, it really was. :-)
GetRight, then DownThemAll, and now, Multithreaded Download Manager:
https://addons.mozilla.org/en-GB/firefox/addon/multithreaded...
Speed Download on early OS X releases was a lifesaver back when I was still on 56k dialup. Its multiplexing was the only way I could get decent speeds half the time (browsers would often drift down to single digits) and being able to resume when connections were dropped (at least when servers supported it).
> unnecessary load
In some situations it's the only way to get a decent download speed.
Disk fragmentation isn't a thing for ssd's
It's still a thing.
https://www.usenix.org/conference/fast24/presentation/jun