I suspect in a year or so, an entire browser can be prompted by AI and then it won’t feel all that cool anymore. Unless AI hits a wall soon (unlikely).

afaik the decision to run animations on or off the main thread is a recurring point of debate not just in web browsers. On iOS for example SwiftUI runs them on the main thread while UIKit w/ CoreAnimation runs them off it. I don’t remember the specific reasons for these decisions but the point is, as with many things there are pros and cons to both approaches.

Opera's old engine (Presto) was able to do this too, before Opera switched to Blink. This is a perfect example of why browser diversity is important.

It's very easy to build it yourself if you want to try it right now.

https://github.com/LadybirdBrowser/ladybird/blob/master/Docu...

Once I spent a month debugging a UAF bug, in a messy C++ codebase.

With rust, those class of errors are very difficult to arrive at, unless you specifically make it so.

with rust, the "risk" gets moved from runtime to compiletime. I'll take a 1TB build bloat over code crashing in prod. any day.

I have the same problem and am regularly `cargo clean`ing hundreds of gigabytes of build artifacts. It is a real problem. I feel like I need minimum 4TB of SSD space just to comfortably work at the scale I'm working now in Rust. That's just for the working space of the target folders across worktrees.

I just think agents benefit a lot from having unavoidable feedback in the dev loop, and Rust affords that through its strictness. It's easier for agents to fall into the pit of success with Rust. I do think it's somewhat lacking in compile-time features, though.

It's expected. Cargo has very conservative cache cleanup (once per month IIRC).

There's incremental compilation cache that generates lots of churn (although Rust's compilation unit is a crate, "queries" in the compiler are cached individually, creating many cache entries per function per type).

The other half of the disk space is debug info, because abstractions that optimize down to zero runtime code still carry all of their source-level debug info.

These can be adjusted in build profiles if you're ok with coarser debug info or less fine-grained caching.

It's normal. But you can somewhat mitigate by:

- Making sure you compile with as few profiles as possible.

- Disabling debug info (or setting it to "line-table-only") for the default profile.

It's normal, but they're working on it:

https://blog.rust-lang.org/inside-rust/2026/08/18/reducing-t...

Shared libraries (i.e. not building every damn dependency) would fix this problem real quick in many situations, but of course, Rust people don't want to commit to an ABI in order to keep their options open. I don't think it makes sense much longer - at this point "can't do shared libraries" seems more like cultural inertia.

Two or so ABI breaks with a few years between them also seem quite survivable.

90gb? i've ran cargo clean on a single project and reclaimed over 700gb before.

but i still love rust ofc

Isn't the advantage memory safety?

When I mentioned, after C++26 failed its vote, that maybe they should use this extra time to focus more on memory safety, I got downvoted instead.

Surely that attitude isn't helping their situation.

[dead]

Because it IS futile. Occam's Razor shaped hobby project, that what it is. Where is the market share? Nowhere, because existing browsers are good enough and no corporation pushes Ladybird.

Showing how far one can go with modern AI tooling does matter only a little when all you do is looking at Chromium/Firefox code and recompiling the logic of it in another language.

I'll stick with Firefox.