Yeah, it's a fun time capsule. The policy was written in July 2024 [1]. There's a contentious discussion in 2025 [2] where they discussed it and reaffirmed the ban. Then in June 2026 they reiterated the ban and added CI checks to reject AI coauthors [3]
[1] github.com/servo/book/commit/5afb80d5b08b259ca359…
[2] servo#36379
[3] servo.org
Part of this, as others have noted, is due to: book.servo.org
> Can I submit a PR that includes code generated by AI tools?
> No. This includes (but is not limited to) all generative AI tools like Claude, Codex, ChatGPT, Cursor, Gemini, and Windsurf.
For something like a browser, this de facto limits the set of people who can contribute to something that touches the layout engine (e.g. the ineffable but brilliant github.com/servo/servo/blob/main/components/layou…) to just those already familiar with the code.
A much better middle ground IMO would be to quarantine first-time committers behind an AI-generated-PRs-will-not-be-reviewed policy, but to allow those who understand and respect the cycle enough to get PRs accepted, to begin using AI to give the team leverage. Without some kind of policy like that, Servo's sadly going to fall behind literally any other open-source project that people could dedicate their time towards.
Currently they do not: book.servo.org
> Contributions must not include content generated by large language models or other probabilistic tools, including but not limited to Copilot or ChatGPT. This policy covers code, documentation, pull requests, issues, comments, and any other contributions to the Servo project.
> For now, we’re taking a cautious approach to these tools due to their effects — both unknown and observed — on project health and maintenance burden. This field is evolving quickly, so we are open to revising this policy at a later date, given proposals for particular tools that mitigate these effects.
The references to ChatGPT and Copilot suggest it was authored before the Codex and Claude Code revolution. I wonder if they'll revise it at some point soon.
Update: looks like that language was originally added in July 2024: github.com/servo/book/commit/5afb80d5b08b259ca359…
I found a discussion about changing it in April 2025, but they decided to keep it the same at that point: servo#36379
Formal Web: a modular Web engine written in Rust and using formal methods
Reposting; this time with a focus on why it is not a code dump.
The project I would like present is a web engine written in Rust. It does not break new grounds in the sense of being the first Web engine in Rust, because we have had a Web engine for a long time, where I am myself involved as a maintainer and Technical Steering Committee member: Servo.
However, this is not a code dump either, because:
- Myself, and others, have been working on this since March of this year.
- This post is a "full fledged post", which is supported by a linked-to longer essay (see below)
- I will below explain the relevance for the Rust community
- I will compare it with other Web engines written in Rust.
----
Ok so now that this is out of the way, here is the actual post:
gterzian/formal-web is a new prototype of a Web engine written in Rust.
It is relevant for the Rust community, because it provides us with something new:
- a multi-process graphics stack based on modern Rust components, like Vello and Wgpu, paired with a modular design allowing deeper platform integration, for example integrating with Core Animation and using IOSurface on Apple platforms.
- A modular approach to integrating a Javascript engine, so that you can "bring your own engine". Currently V8 and the all Rust Boa are supported out of the box, and other engines, Like the also all Rust Nova, could be integrated through the implementation of various traits.
- Use of Blitz components, blitz-dom and blitz-paint, as a kind of DOM engine inside the Web engine.
- Use of formal methods to model check multi-process Rust code, based on the approach described at Validating Traces of Distributed Programs Against TLA+ Specifications
- Modularity of various other layers, such as: networking, media, and the starting of and communication with process-like sub-components.
- An embedder API that makes it easy to do various platform specific integrations, such as using a display link on Mac.
- An explicit goal of eventually being able to Ship on IOS in the EU as per Apple's guidelines.
How is this different from other Web engines in the Rust ecosystem?
Difference with Servo: the graphics stack of Servo does not isolate GPU operations in a dedicated process and it is based on an OpenGL stack.
Difference with Blitz: while Blitz does integrate well with Vello/Wgpu, it is not designed around process isolation of either GPU operations or the running of Javascript, making it less suitable for the Web use-case where you essentially run untrusted code downloaded over the internet. While it does use Anyrender as modular render target, it does not offer modularity at the lower-level end of the graphics pipeline.
Neither engines allow swapping out JS engines, and neither allow for deep platform graphics integration like Core Animation based compositing on Mac (which can make a large difference in terms of battery life).
For a walk-through of the entire flow involved in rendering a frame of Web content, see the introduction essay: How I am building a Web engine.
The essay also contains a gif showing the benefits of Core Animation on Mac, where only relevant parts of the screen are re-rendered.
Please let me know what you think. I can also use help implementing countless Web standards.
20 points · 8 comments
@houzhongji89090 你可能在找：
servo/servo
1 like · 53 views
Mentions
Yeah, it's a fun time capsule. The policy was written in July 2024 [1]. There's a contentious discussion in 2025 [2] where they discussed it and reaffirmed the ban. Then in June 2026 they reiterated the ban and added CI checks to reject AI coauthors [3] [1] github.com/servo/book/commit/5afb80d5b08b259ca359… [2] servo#36379 [3] servo.org
Part of this, as others have noted, is due to: book.servo.org > Can I submit a PR that includes code generated by AI tools? > No. This includes (but is not limited to) all generative AI tools like Claude, Codex, ChatGPT, Cursor, Gemini, and Windsurf. For something like a browser, this de facto limits the set of people who can contribute to something that touches the layout engine (e.g. the ineffable but brilliant github.com/servo/servo/blob/main/components/layou…) to just those already familiar with the code. A much better middle ground IMO would be to quarantine first-time committers behind an AI-generated-PRs-will-not-be-reviewed policy, but to allow those who understand and respect the cycle enough to get PRs accepted, to begin using AI to give the team leverage. Without some kind of policy like that, Servo's sadly going to fall behind literally any other open-source project that people could dedicate their time towards.
Currently they do not: book.servo.org > Contributions must not include content generated by large language models or other probabilistic tools, including but not limited to Copilot or ChatGPT. This policy covers code, documentation, pull requests, issues, comments, and any other contributions to the Servo project. > For now, we’re taking a cautious approach to these tools due to their effects — both unknown and observed — on project health and maintenance burden. This field is evolving quickly, so we are open to revising this policy at a later date, given proposals for particular tools that mitigate these effects. The references to ChatGPT and Copilot suggest it was authored before the Codex and Claude Code revolution. I wonder if they'll revise it at some point soon. Update: looks like that language was originally added in July 2024: github.com/servo/book/commit/5afb80d5b08b259ca359… I found a discussion about changing it in April 2025, but they decided to keep it the same at that point: servo#36379
Formal Web: a modular Web engine written in Rust and using formal methods Reposting; this time with a focus on why it is not a code dump. The project I would like present is a web engine written in Rust. It does not break new grounds in the sense of being the first Web engine in Rust, because we have had a Web engine for a long time, where I am myself involved as a maintainer and Technical Steering Committee member: Servo. However, this is not a code dump either, because: - Myself, and others, have been working on this since March of this year. - This post is a "full fledged post", which is supported by a linked-to longer essay (see below) - I will below explain the relevance for the Rust community - I will compare it with other Web engines written in Rust. ---- Ok so now that this is out of the way, here is the actual post: gterzian/formal-web is a new prototype of a Web engine written in Rust. It is relevant for the Rust community, because it provides us with something new: - a multi-process graphics stack based on modern Rust components, like Vello and Wgpu, paired with a modular design allowing deeper platform integration, for example integrating with Core Animation and using IOSurface on Apple platforms. - A modular approach to integrating a Javascript engine, so that you can "bring your own engine". Currently V8 and the all Rust Boa are supported out of the box, and other engines, Like the also all Rust Nova, could be integrated through the implementation of various traits. - Use of Blitz components, blitz-dom and blitz-paint, as a kind of DOM engine inside the Web engine. - Use of formal methods to model check multi-process Rust code, based on the approach described at Validating Traces of Distributed Programs Against TLA+ Specifications - Modularity of various other layers, such as: networking, media, and the starting of and communication with process-like sub-components. - An embedder API that makes it easy to do various platform specific integrations, such as using a display link on Mac. - An explicit goal of eventually being able to Ship on IOS in the EU as per Apple's guidelines. How is this different from other Web engines in the Rust ecosystem? Difference with Servo: the graphics stack of Servo does not isolate GPU operations in a dedicated process and it is based on an OpenGL stack. Difference with Blitz: while Blitz does integrate well with Vello/Wgpu, it is not designed around process isolation of either GPU operations or the running of Javascript, making it less suitable for the Web use-case where you essentially run untrusted code downloaded over the internet. While it does use Anyrender as modular render target, it does not offer modularity at the lower-level end of the graphics pipeline. Neither engines allow swapping out JS engines, and neither allow for deep platform graphics integration like Core Animation based compositing on Mac (which can make a large difference in terms of battery life). For a walk-through of the entire flow involved in rendering a frame of Web content, see the introduction essay: How I am building a Web engine. The essay also contains a gif showing the benefits of Core Animation on Mac, where only relevant parts of the screen are re-rendered. Please let me know what you think. I can also use help implementing countless Web standards.
@houzhongji89090 你可能在找： servo/servo