Bez: Generating a browser engine from specs and tests
tangled.org
tangled.org
Edit: replies are making good points about AI capabilities and where the effort really goes. Let’s just say that I meant this in an aspirational sense, rather than where the rubber actually meets the road today.
No, not really. The absolute vast majority of those specs are human technical and technical-adjacent language, not machine-readable specs.
On top of that many web specs often invent new terminology because a lot of things are specced years or decades after something popular has taken over the term in userland.
Your second point makes a lot of sense to me too. I’m not sure how this could handle that facet of human nature, except possibly to indirectly contribute to speeding up the cycle of spec creation.
At that point it’s about optimizing and deciding trade offs, both of which might mean heavily directing the generation in some way. Over time, maybe LLMs or whatever succeeds them won’t go down so many bad architectural paths. We’ve certainly seen that already in the last year or two.
I also don’t think folks like you ever lose your value in these efforts, even if all of it came true tomorrow. At worst it would be you plus the AI, which would always be a more potent combination than say, me with an AI trying to make a browser engine.
I hear you brother. I, too, hope that one of the two or three companies will be able to improve and displace everything. Who needs Linux anyway.
Hope you are on the right side of the fence.
In the context of browsers the domination of one or two companies is already complete, and being able to generate new browsers with AI would hopefully allow people to escape the stranglehold of Chrome/Blink.
That said, I doubt a new,competitive browser could be created that way. The (possibly AI) developers of web apps won’t want to test on somebody’s bespoke AI-generated browser.
Do you really think LLMs will only belong to 2 or three companies in the future, when we already have fairly competitive open weights usable from home (or rented servers)? How would this be anything but the opposite of centralization amongst 2 or 3 companies, which is already the case now? Software has always been displacing things, especially itself.
Speed is probably not part of a web spec.
> wrong architecturally
Nor is software architecture (though web security specs may have some influence here).
"being a grandmother is not part of the bike frame spec so my grandmother with wheels is a bike"
Techniques, like the newly announced RL-XAR from Meta [1] are being developed that will likely improve reward models and guide RL training to optimize for metrics like software architecture that are hard to verify otherwise.
It's a matter of "bring the best non-conflicting wins together" at that point. The existing engines are too big to flip over their codebase without having seen competitors prove it too.
My estimate is that with the release of Opus 5.7, companies need to have their shit together because the work ecosystem will flip over at 6 at the current rate of progress. This generation is the first one that delivers local applications with a better toolset than a small scale SaaS in hours to days.
With luck all chromium/blink-based browsers will go the way of the dodo bird.
Also the specs are written to define observable behavior, and there's a fair bit of ambiguity that's UA defined, but to be actually compatible with the Web requires doing what Chrome does.
The good news is that you can look at the source of the 3 major engines (and Ladybird!) and your AI agent can do comparisons and figure out optimizations.
So far it's only HTML/CSS (and we have our Rust-based framework to write the apps in). But it has been designed for fast incremental rendering, so it could be extended with JavaScript support quite easily.
FWIW:
- Binary sizes start around 8mb if you're using GPU rendering (you can go smaller with CPU rendering, but you probably want the GPU). Our full browser app which pulls in things like sqlite, http cache libraries, etc is 20mb. Those usually compress to about half for distribution (.dmg, .appimage, etc).
- Base memory usage is something like 100mb (mostly from the graphics stack). I'm hoping to be able to bring that down a bit, but I think you can't realistically get much lower than 60mb with modern graphics. And to be perfectly honest we currently have an issue for RAM where it will often jump to more like 300-400mb after a little use. And I haven't fully gotten to the bottom of that yet.