Hacker News

points by porphyra 2 days ago | 0 comments

Servo is really great: Rust seems like a no brainer choice for a modern web engine, and its clean, performance-focused design from the ground up is wonderful.

But it seems really hard for it to get anywhere just based on occasional contributions from volunteers. I was actually quite surprised that basic functionality like <progress> and the :checked attribute were not even supported prior to this release.

Servo got 527 commits, while Chromium has over 20,000 commits.

[–] btown 2 days ago

Part of this, as others have noted, is due to: https://book.servo.org/policy/ai-usage.html

> 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 https://github.com/servo/servo/blob/main/components/layout/f...) 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.

[–] fabrice_d 2 days ago

Servo is already lacking reviewers. How would accepting AI contributions help?

[–] alfiedotwtf 2 days ago

I was excited in 2014 when I discovered Rust, because it just totally made sense that it was where the future of coding was moving to.

Now, in 2026 I’m excited by LLMs because the combo of Rust+AI is literally an unstoppable force..

It’s a shame they’re building the Lamborghini of rendering engines but refuse to source parts unless it’s delivered on horseback

[–] scratcheee 1 day ago

I get what you’re saying, but LLMs really aren’t great at writing code for use in “key” codebases where every line needs to be clear and clear easy to review, not adding to the maintenance burden any more heavily than necessary.

Now reviewing code, finding flaws? They’re great at that. Prototyping new ideas, and suggesting potential solutions? Amazingly useful. Writing lots of code solving problems in projects focused on having the features not on being long term secure and easy to extend? They seem to do this very well.

But the actual code going into a web browser engine needs to be very carefully produced.

So I’d compare it more to how c++ going into safety critical systems cannot use any of the “cool” features of c++. Code going into a web browser cannot be generated without a human hand tightly on the tiller.

[–] matkoniecz 1 day ago

Servo is already lacking reviewers. How would accepting AI contributions help?

[–] gspr 1 day ago

You are in a cult.

[–] cowlevel 2 days ago

Why not use AI to help familiarize yourself with it?

By the time you understand it you shouldn't need AI to write changes. First-time committers are the ones most likely to use AI.

[–] cleansy 2 days ago

This is covered in the FAQ. AI may help you, but oftentimes the assumptions about the code are either noisy or simply wrong.

[–] darkamaul 2 days ago

> > No. This includes (but is not limited to) all generative AI tools like Claude, Codex, ChatGPT, Cursor, Gemini, and Windsurf

Based on the tool listed here, you can probably know when this policy was first written. For instance, Windsurf is long gone and Cursor is not tier 1 anymore.

Crazy to think how much the space of AI coding agent has evolved in less than 2 years.

[–] porphyra 2 days ago

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] https://github.com/servo/book/commit/5afb80d5b08b259ca359cfe...

[2] https://github.com/servo/servo/discussions/36379

[3] https://servo.org/blog/2026/06/30/may-in-servo/

[–] nextaccountic 2 days ago

They were right at each time for different reasons

In 2024 the tools were severely lacking. Today they work better (if subpar and verbose), but put an undue burden on reviewers (which are already in short supply)

[–] Hendrikto 2 days ago

We have got enough AI slop, and it is very easy to produce more. I am happy somebody is trying a different route.

[–] worldsavior 2 days ago

You can see how Ladybird is "progressing" right now because of AI. I think it's a shame because now AI would just be using parts from chromium or Firefox, and they're going to encouter eventually an unmaintainable codebase. How a new browser engine helps here then?

[–] LeFantome 1 day ago

It is not like they are fully vibe coding the browser. And Ladybird was not built with a prompt. They already had a more or less fully functioning browser before they introduced the use of AI.

The design of Ladybird follows the web standards closely as well. It is going to be quite different from older engines. And the code is quite organized, if your concern is AI slop from layers and layers of AI added features. I do not think that is how they are using it at all.

My biggest gripe with Ladybird is that they adopted some pretty large components written by Google. You cannot really use Skia and say that you do not rely on Google as an example.

Not relying on Google was their big selling point, since every other browser is Google-dependent.

[–] vrighter 1 day ago

why would the middle ground be betterf itqs not as if that code needs to be reviewed any less. a coder reviewing their own code is pretty useless, so this would still occupy revewers on ai slop

[–] zarzavat 2 days ago

The solution is to fork. An indie browser engine needs LLMs to have any hope of ever catching up with the big 3.

[–] eyjafjallajokul 2 days ago

> Rust seems like a no brainer choice for a modern web engine

Well, I mean Servo was the original catalyst and production use-case for Rust back in 2012. Both are products of the work of various folks at Mozilla around the time.

[–] throwup238 2 days ago

And large parts of the project replaced parts of Firefox like the renderer and CSS engine nearly a decade ago.

[–] fabrice_d 2 days ago

There are not just volunteer contributions, but also people working full time on Servo: some at Igalia, and some at Huawei at least.

[–] jpfr 1 day ago

Even with that many commits, the WPT pass percentage increases at a good rate: https://servo.org/wpt/

Maybe, hopefully, Rust allows to maintain a more safe browser at less than 20,000 commits per month.

We will see the maintenance effort after achieving 100% WPT. And whether they can close the performance gap by Rust-enabled safe concurrency...

[–] dnautics 1 day ago

> Rust seems like a no brainer choice for a modern web engine,

Why? Beacuse of memory safety?

It's a shame that there aren't other memory safe low-level options that don't come with the rest of the baggage of rust, or try out different paradigms, for example: not defaulting to malloc (and having other allocator options that aren't painful), not using trait-based shared behavior, not using macros, no turbofish, object orientation (for those who partake), etc.

[–] ivell 1 day ago

Sounds like you would like to look into Mojo.

https://mojolang.org/

[–] dnautics 1 day ago

I don't like OOP. We should have more than one memory safe low level options.

[–] jeffbee 2 days ago

Language choice has next to nothing to do with browser performance. Servo's "performance-focused" design currently suffers from a 10x gap between it and Chrome on the same platform.

[–] nicoburns 2 days ago

For Style and Layout, Servo is now competitive (and in many cases faster) than Chrome / Firefox according to my benchmarks https://nicoburns.github.io/browser-layout-bench/

[–] fabrice_d 2 days ago

10x gap on which benchmark?

[–] jeffbee 2 days ago

Speedometer 3.1

[–] fabrice_d 2 days ago

Your numbers seem very outdated. Testing on a MacBook Air M4, here's what I get:

- Servo b88af263d11e12288ff3eca0848aaa675d6a52f0: 21.4

- Chrome 157: 60.9

- Safari 27.2: 59.2

- Firefox 159: 41.0

So between 2x and 3x slower than the current "big 3".

[–] jeffbee 1 day ago

OK. The fact that these figures are rapidly changing only underlines my point: language platform has virtually nothing to do with browser performance.

[–] orangeboats 2 days ago

If you are determined enough you can even write V8 in assembly. But how many man-hours would that take?

[–] MobiusHorizons 2 days ago

I think the benchmark is for layout performance not JavaScript execution, but v8 is fast because it emits assembly more so than because of the language it is implemented in. That said, I would be very surprised if there is not hand tuned assembly routines for performance critical routines.

[–] orangeboats 2 days ago

My point was that while you can implement any performant program (be it V8 or Spidermonkey, Blink or Servo) in any language, the effort required to reach a certain performance level differs between the languages.

>v8 is fast because it emits assembly

It emits machine code afaik. And secondly, do you _really_ want to implement the intermediate layers of a JIT in assembly?

[–] MobiusHorizons 1 day ago

I take your point that code organization in assembly is hard, and not worth the performance gains over higher level languages. It’s true, we don’t write much complex software completely in assembly.

However the point I was trying to make is still relevant I think, which is that machine instruction abstraction layer (whether it is serialized as binary machine code or as assembly text) remains a critical piece of what makes high performance software fast even today.

There is a recurring myth I see on HN that suggests abstraction layers are progressive, as though humanity had evolved past the assembly/machine instructions abstraction layer to C to higher level languages leaving lower abstraction layers behind completely. That is simply untrue, and a project like V8 is actually a great example of this, since it not only will have hand tuned assembly routines, but also needs to ship a bespoke compiler which will emit machine instructions.

So even though it’s true we don’t organize our software with assembly language, it remains a key to performance. It could be a custom JIT compiler, hand tuned SIMD code (eg to handle string parsing), or even just checking what the compiler emitted (eg in compiler explorer). Machine instructions remain key to high performance.

[–] orangeboats 1 day ago

You don't seem to know where the machine code are generated from. A big part of a compiler is optimizing intermediate representations of the source code.

I am not going to waste my time with you.