201 karma · joined April 11, 2020
TLDR; the code is not a valid POC but throw-away level quality that could never support a functioning web engine. It's actually very clear hallucinated AI BS, which is what you get when you don't have a human expert in the loop.
I actually like using AI, but only to save me the typing.
That is true in a way, although even for agents readability matters.
But the code here does not actually do the right thing, and the way it is written also means it never could.
Web devs do care whether the engine runs their code according to Web standards(otherwise it's early IE all over), and end-users do care that websites work as their devs intended to.
Current state is throw-away level quality.
I've critiqued it at length in the other post, see https://news.ycombinator.com/item?id=46705625
A well-architected POC built in a week with a clear path to scaling it to a full implementation down the line would be impressive, but that's not what this is.
The current code output is basically throw-away level quality AI hallucinated BS.
In various comments in https://news.ycombinator.com/item?id=46624541 I have explained at length why your fleet of autonomous agents failed miserably at building something that could be seen as a valid POC.
One example: your rendering loop does not follow the web specs and makes no sense.
https://github.com/wilsonzlin/fastrender/blob/19bf1036105d4e...
The above design document is simply nonsense; typical AI hallucinated BS. Detailed critique at https://news.ycombinator.com/item?id=46705625
The actual code is worse; I can only describe it as a tangle of spaghetti. As a Browser expert I can't make much, if anything, out of it. In comparison, when I look at code in Ladybird, a project I am not involved in, I can instantly find my way around the code because I know the web specs.
So I agree this isn't just wiring up of dependencies, and neither is it copied from existing implementations: it's a uniquely bad design that could never support anything resembling a real-world web engine.
Now don't get me wrong, I do think AI could be leveraged to build a web engine, but not by unleashing autonomous agents. You need humans in the loop at all levels of abstractions; the agents should only be used to bang out features re-using patterns established or vetted by human experts.
If you want to do this the right way, get in touch: https://github.com/gterzian
Whether it is the best case scenario in terms of benchmark, I am not so sure.
The Web is indeed standardized and there are many open-source implementations out there. But how to implement the Web in a novel way by definition means you are trying to solve some perceived problem with existing implementations.
So I would rephrase your statement as such: rewriting an existing engine in another language without any novelty might be the best case scenario for autonomous coding agents.
As an example of approaching the problem in a novel way: the Fastrender code seems obsessed with metering of resources. Implementing the Web with that constraint in mind would be an interesting problem and not obvious at all. That's not what the project is doing so far by the way, since the code is quite frankly a bunch of spaghetti that does not follow Web standards at all(in a way that is unrelated to the metering story, so the divergence from specs is not novel, it's just wrong).
To leverage AI to build a working browser you would imo need the following:
- A team of humans with some good ideas on how to improve on existing web engines.
- A clear architectural story written not by agents but by humans. Architecture does not mean high-level diagrams only. At each level of abstraction, you need humans to decide what makes sense and only use the agent to bang out slight variations.
- A modular and human-overseen agentic loop approach: one agent can keep running to try to fix a specific CSS feature(like grid), with a human expert reviewing the work at some interval(not sure how fine-grained it should be). This is actually very similar to running an open-source project: you have code owners and a modular review process, not just an army of contributor committing whatever they want. And a "judge agent" is not the same thing as a human code owner as reviewer.
Example on how not to do it: https://github.com/wilsonzlin/fastrender/blob/19bf1036105d4e...
This rendering loop architecture makes zero sense, and it does not implement web standards.
> in the HTML Standard, requestAnimationFrame is part of the frame rendering steps (“update the rendering”), which occur after running a task and performing a microtask checkpoint
> requestAnimationFrame callbacks run on the frame schedule, not as normal tasks.
This is BS: "update the rendering" is specified as just another task, which means it needs to be followed by a microtask checkpoint. See https://html.spec.whatwg.org/multipage/#event-loop-processin...
Following the spec doesn't mean you cannot optimize rendering tasks in some way vs other tasks in your implementation, but the above is not that, it's classic AI bs.
Understanding Web standards and translating them into an implementation requires human judgement.
Don't use an agent to draft your architecture; an expert in web standards with a interest in agentic coding is what is required.
Message to Cursor CEO: next time, instead of lighting up those millions on fire, reach out to me first: https://github.com/gterzian
This isn't a POC web engine; it's throw-away code that can never scale to a full web engine.
So instead of wasting millions on this autonomous run, they should have put together a small team of people with some ideas on how to improve on existing web engines, and then give that team a large token development budget. You could get a nice POC after a couple of weeks, and after a year or two of further iterations you might have something really interesting.
So this is a great example of how AI fails when left unsupervised; a more interesting experiment would be about how a small team can leverage AI to leapfrog Chromium; not in one week but in a year or two.
Just made some last edits above so not sure which version you saw. I toned it down a bit and clarified some stuff...
You're right that lots of code appears only used in unit-tests, of which there is an enormous amount(making it hard to tell whether what is being tested makes sense). In Servo we don't have a single line of unit-tests in the script component, because all of it is covered by the WPT integration test suite shared with all other engines...
Although I dissented on the decision, we banned the use of AI. Outside of the project I've been enjoying agentic coding and I do think it can be used already today to build production-grade software of browser-like complexity.
But this project shows that autonomous agents without human oversight is not the way forward.
Why? Because the generated code makes little sense from a conceptual perspective and does not provide a foundation on which to eventually build an entire web engine.
For example, I've just looked into the IndexedDB implementation, which happens to be what I am working on at the moment in Servo.
Now, my work in Servo is incomplete, but conceptually the code that is in place makes sense and there is a clear path towards eventually implementing the thing as a whole.
In Fastrender, you see an Arc<Mutex<Database>> which is never going to work, because by definition a production browser engine will have to involve multiple processes. That doesn't mean you need the IPC in a prototype, but you certainly should not have shared state--some simple messaging between threads or tasks would do.
The above is an easy coding fix for the AI, but it requires input from a human with a pretty good idea of what the architecture should look like.
For comparison, when I look at the code in Ladybird, yet another browser project, I can immediately find my way around what for me is a stranger codebase: not just a single file but across large swaths of the project and understand things like how their rendering loop works. With Fastrender I find it hard to find my way around, despite all the architectural diagrams in the README.
So what do I propose instead of long-running autonomous agents? The focus should shift towards demonstrating how AI can effectively assist humans in building well-architected software. The AI is great at coding, but you eventually run into what I call conceptual bottlenecks, which can be overcome with human oversight. I've written about this elsewhere: https://medium.com/@polyglot_factotum/on-writing-with-ai-87c...
There is one very good idea in the project: adding the web standards directly in the repo so it can be used as context by the AI and humans alike. Any project can apply this by adding specs and other artifacts right next to the code. I've been doing this myself with TLA+, see https://medium.com/@polyglot_factotum/tla-in-support-of-ai-c...
To further ground the AI code output, I suggest telling it to document the code with the corresponding lines from the spec.
Back in early 2025 when we had those discussions in Servo about whether to allow some use of AI, I wrote this guide https://gist.github.com/gterzian/26d07e24d7fc59f5c713ecff35d... which I think is also the kind of context you want to give the AI. Note that this was back in the days of accepting edits with tabs...
The article is an example of "task parallelism", where you have different threads doing different things on different (local) data. Having those threads communicate via message-passing is a nice way to model workflows crossing thread boundaries, and in that setup you usually want some sort of deterministic behavior related to the ordering of operations(for a given workflow).
On the other hand, I think the Rayon example is a good case of "data parallelism", where you have workers doing "the same thing" on "the same (shared-)data".
In such a case, perhaps locks and shared-data are a better fit than message-passing, and indeed what you're after is not necessarily some sort of sequential ordering of worker operations. However you still probably want the ability to make other deterministic assertions about the behavior of the workers.
I wrote another article highlighting some of these "different determinism" at https://medium.com/@polyglot_factotum/rust-concurrency-five-...
On the other hand, sending a message would allow for only a single thread of execution owning that object, and calling methods on the object in response to incoming messages.
So I'd say it's not really "sending a message to an object", it's rather "sending a message to some kind of thread of execution, which owns that object uniquely".
Result: there is a "single writer" with regards to the internal state of that object.
I actually wrote an article on this for Rust, perhaps it could help rewiring your mental model: https://medium.com/@polyglot_factotum/rust-concurrency-the-s...
On the other points, I would still stick to my suggestion of using WebIDL, at least for Spidermonkey, since you'd have to otherwise write all the glue code yourself. The bindings generation is worth it I think.
Re using Tokio to run the event-loop of the VM, I would probably just use a native thread, like I suggested in the article.
Tokio is really like a runtime for Rust, meaning that if you use it to implement a runtime for say Wasm, then you're trying to run your own runtime within someone else's runtime. Not saying it can't be done, just not how I would do it.
I think Tokio on the other hand could really shine if used in a separate "networking component" that, in a Deno-like server-side runtime, would handle all incoming requests/connections, and then have the "runtime" run in a separate component(and process, if you want some isolation). Let's say you wanted to run different VM's, isolated from each other, you could run each in it's own process, and the networking would also be done in its own, or the "main", process of the overall engine.
Incoming networking requets could then be translated into events or other kind of calls into the user-code running on an isolated VM, which itself is probably best run using a simple event-loop running on a single-thread.
It's similar to what Servo does actually, where there is a "net" component to do the networking(although it's client-side networking off-course), then there is the "constellation" component that is like "one ring to rule them all" main component, and you have the "script" component actually running Spidermonkey VMs each on their own event-loop(let's say roughly one per "tab", plus one per worker).
So the JS/Wasm running on Spidermonkey is "async", like you can await a promise and so on, however it's actually driven by a single-thread, with other components, like "net", running "in-parallel" of "script", in their own process, and using whatever threading or async runtime they need.
So for example, if you do a fetch in JS, then the script component can keep running other stuff in it's task-queues in the meantime(in a single-threaded, one task at a time, fashion), while the net component will do the fetch over the network, and as "stuff happens" related to this fetch, net will enqueue tasks back on the event-loop where the fetch originated, resulting in events/promise resolving on the VM, and executing of handlers in JS.
So not only do "net" and "script" have to run in separate processes for security(spectre) and robustness, they also have to run in parallel of each other, and according to a very specific specification(see for the event-loop of script for example: https://html.spec.whatwg.org/multipage/#event-loop-processin...)
So I guess you could run a tokio runtime in both processes, but it would actually be kinda overkill(Servo does uses Tokio in the "net" component, and that's obviously a good fit since it's doing the networking).
So I'd say the trick would be clearly separating the networking, from the VM(s), probably use something like Tokio in the networking component, and to implement the event-loop driving the VM, I'd just use a native thread, one per VM.
This article is part of a collection of articles going into the architecture of Servo, if you're interested: https://medium.com/programming-servo
The embedding API used can be found at https://github.com/servo/servo/tree/master/ports/libsimplese...
I think it's a pretty low-level embedding API, so perhaps not comparable with embedding Webkit(I have no experience with that either), it does seem to do the trick.