[flagged]
This Month in Ladybird – August 2026
41–50 of 86 posts
Re: This Month in Ladybird – August 2026
#42Earlier quoted context omitted.
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 ar…
> 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 :(
Re: This Month in Ladybird – August 2026
#43I 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…
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?
Re: This Month in Ladybird – August 2026
#44Earlier quoted context omitted.
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.
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.
Re: This Month in Ladybird – August 2026
#45> 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.
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).
Re: This Month in Ladybird – August 2026
#46Earlier quoted context omitted.
> 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 ext…
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.)
Re: This Month in Ladybird – August 2026
#47Earlier quoted context omitted.
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 C…
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.
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.
Re: This Month in Ladybird – August 2026
#48I 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…
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
Re: This Month in Ladybird – August 2026
#49So excited about this. Writing a real new web browser is a titanic project and Ladybird is making amazing progress
Re: This Month in Ladybird – August 2026
#50Earlier quoted context omitted.
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.