September in Servo: <progress>, rounded rectangles, and more

Posted by iamnothere 1 day ago

Counter265Comment74OpenOriginal

Comments

Comment by porphyra 20 hours ago

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.

Comment by jpfr 9 minutes 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...

Comment by btown 20 hours 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.

Comment by fabrice_d 19 hours ago

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

Comment by alfiedotwtf 9 hours 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

Comment by matkoniecz 2 hours ago

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

Comment by gspr 3 hours ago

You are in a cult.

Comment by cowlevel 12 hours 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.

Comment by cleansy 5 hours ago

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

Comment by vrighter 50 minutes 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

Comment by darkamaul 19 hours 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.

Comment by porphyra 19 hours 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/

Comment by nextaccountic 5 hours 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)

Comment by worldsavior 5 hours 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?

Comment by LeFantome 2 hours 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.

Comment by Hendrikto 8 hours ago

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

Comment by zarzavat 6 hours ago

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

Comment by eyjafjallajokul 13 hours 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.

Comment by throwup238 13 hours ago

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

Comment by dnautics 3 hours 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.

Comment by ivell 2 hours ago

Sounds like you would like to look into Mojo.

https://mojolang.org/

Comment by fabrice_d 19 hours ago

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

Comment by jeffbee 17 hours 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.

Comment by nicoburns 3 hours 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/

Comment by fabrice_d 15 hours ago

10x gap on which benchmark?

Comment by jeffbee 15 hours ago

Speedometer 3.1

Comment by fabrice_d 10 hours 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".

Comment by jeffbee 1 hour ago

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

Comment by orangeboats 11 hours ago

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

Comment by MobiusHorizons 10 hours 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.

Comment by orangeboats 9 hours 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?

Comment by robin_reala 23 hours ago

Remember that if you value Servo you can sponsor them, details at https://servo.org/sponsorship/

Comment by shakna 22 hours ago

Progress got my attention.

As an on-again off-again project, I've been building an incremental game that is pretty much just hundreds of progress bars - a little bit out of the norm for the browser.

Firefox everything renders smoothly and gently.

Chrome chugs, skips paints, delays animation frames, skips some events, and batches others.

Game uses a few features that aren't in Servo yet... But maybe I can tweak it...

Comment by ericyd 1 day ago

It's heartening to see a large group of people working (mostly) for free on a passion project. Makes me optimistic about the resilience of intrinsic human drive.

Comment by caminanteblanco 1 day ago

One of the things I find really helpful about servo (as a casual user) is the breadth of pre-built releases they have. It makes it much more feasible to actually use on a day-to-day basis, especially on android

Comment by npodbielski 1 day ago

wow! they already have android apk? Awesome!

Comment by npodbielski 1 day ago

login form on HN does not work, but servo is working! :D

Comment by caminanteblanco 1 day ago

It was working a second ago (I made the parent comment from servo) but it looks like you get logged out pretty quickly. YMMV, plus probably best not to log into anything too important yet

Comment by npodbielski 22 hours ago

I do not think HN is important :) But thanks for warning.

Comment by moderation 1 day ago

The progress on Servo is impressive. UI polish is required in order to be more usable. Things like keyboard shortcuts to focus the address bar are required to make it feasible for more daily driving use

Comment by jszymborski 1 day ago

My understanding is that the main focus is on the engine and building a good embedding API so that folks can build browsers (and apps and web drivers etc...) with it.

Comment by moderation 1 day ago

That is my understanding too. In contrast Ladybird has really improved in the UI area and the recent addition of session restore, content blocking and performance makes it a very capable daily driver browser

Comment by nerdypepper 1 day ago

i've been hacking on my own browser using servo as a library! its lovely to interface with.

Comment by nerdypepper 20 hours ago

i have been hacking on my own servo-based browser using gpui for macos: https://tangled.org/oppi.li/meridian/

Comment by hn_submit 12 hours ago

Although Servo is great I believe Ladybird is already much further along and they're currently porting their codebase to Rust (it's currently in C++).

Comment by Weryj 1 day ago

I want servo the succeed

Comment by walski 9 hours ago

Is there a maintained fork that allows AI based or assisted contributions?

Comment by wild_pointer 19 hours ago

Great progress

Comment by amelius 1 day ago

With the advances in AI, I'd expect the Servo project to go a lot faster ...

Do they allow vibe-coded contributions?

Comment by simonw 1 day ago

Currently they do not: https://book.servo.org/policy/ai-usage.html

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

I found a discussion about changing it in April 2025, but they decided to keep it the same at that point: https://github.com/servo/servo/discussions/36379

Comment by kykat 1 day ago

Ladybird seems to be embracing vibe coding, so I think there's a great opportunity to compare them. After a couple of months of vibe coding what do you people here think about Ladybird's progress?

Comment by fabrice_d 15 hours ago

You should rather check the tech debt after a few years.

Comment by tcdent 1 day ago

About ready to switch to Servo as my daily driver on desktop.

Have been using it as the render backend on an experimental tablet OS and its quite capable once you fix the font rendering.

Would gladly upstream contributions but I dont type anymore.

Comment by phkahler 1 day ago

>> With the advances in AI, I'd expect the Servo project to go a lot faster ... >> Do they allow vibe-coded contributions?

With an official automated test suite that they aim to pass, someone could probably set Claude loose on closing out those bugs and feature gaps. Assuming AI can figure out why tests fail (it probably can) I'd give it about a day to finish. Actually maybe a week since it'd be compiling RUST. Would the resulting code be of the same quality? Probably not. Would it be good? Maybe.

Comment by nicoburns 1 day ago

IME, agents are generally capable of passing the tests autonomously. But not with code you'd actually ever want to use. Both because of the quality, and because it will have awful performance/memory/security issues.

Comment by pkulak 1 day ago

I think the sweet spot is not allowing vibe-coded contributions past a certain line count. At least, that's my policy. If you use an LLM to track down some bug that's a few lines to fix; that's fine. But if it's a new feature that needs 100s of lines; just make a feature request and if I agree, I can spin up my own clanker.

Comment by matkoniecz 1 day ago

> Do they allow vibe-coded contributions?

are there serious projects welcoming vibe-coded PRs?

Comment by tormeh 1 day ago

That was my thought as well. You'd imagine a known quantity like a browser should be easy to make now. I know it sounds ridiculous to anyone who hasn't tried the new models, but idk what to tell you. Photoshop used to be impossible to clone, too. I asked Opus 5.5 to add SSGI to an open source game and it did it in an afternoon. I don't know anything about graphics programming. This is nuts.

Comment by samus 18 hours ago

Photoshop was never impossible to clone, and people have written browser engines before. The issue was never implementation complexity, but rather the things that are actually hard: going past the 99% of required features, hunting down corner cases, and at the same time ensuring high test coverage and maintainability.

Comment by matkoniecz 7 hours ago

> You'd imagine a known quantity like a browser should be easy to make now.

feel free to make one

Comment by EigenFluxAI 14 hours ago

[flagged]

Comment by simplyetchedsit 17 hours ago

[flagged]

Comment by z3ratul163071 21 hours ago

Comment by matkoniecz 7 hours ago

it is great that different projects take different approaches

Comment by domenkozar 1 day ago

Sad to see Servo ban AI contributions.

Feels like a missed opportunity where we could take a giant leap forward.

Comment by porphyra 20 hours ago

The AI policy for Servo, which prohibits AI contributed code (but allows you to use AI to inspect and learn about the codebase), was written in mid-2024, which seems like an eternity ago.

But even in June 2026 they reiterated this ban and added CI checks to automatically reject AI-coauthored patches [1].

> For developers of Servo itself, please note that per project policy, you must not use the output of large language models or other generative AI tools in your contributions. To help us enforce that, we now have CI checks that reject AI agents as coauthors (@SimonSapin, @delan, #44723).

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

Comment by nerdypepper 1 day ago

my read is that with the right guidance, implementing the vast amount of the CSS spec for example, could be done easily with some AI assistance, the spec is incredibly well defined. just comparing the layouting and styling in blitz[0] (which does use agents), servo is lacking quite a bit, and the implementation of various features don't follow the spec exactly.

that being said, i entirely respect their decision of course, perhaps they will revisit at a later point in time!

[0]: https://github.com/dioxuslabs/blitz

Comment by nicoburns 1 day ago

(I'm the maintainer of Blitz)

My experience is that it varies greatly by feature.

Something like border styles, the agent was able to do pretty effectively. Although it still took a few hours iterating on it to get the performance characteristics and edge cases right.

More complex features like hoisting position absolute nodes and other layout features still take days to weeks of iterating to get something usable that isn't so fragile it'll blow up the next time you touch something.

Comment by fschuett 20 hours ago

Yes, this was how I did it in Azul[1], which is „reverse engineered from the W3C spec“. But it still took a lot of „agentic debugging“ to get the same visual layout as Chrome[2]. It wasn‘t „easily“ done however and it‘s not yet stable.

[1] https://azul.rs/ui

[2] https://azul.rs/ui/reftest

Comment by 8NNTt8z3QvLT8tp 18 hours ago

CSS isn't super well defined actually, at least not compared with HTML or JavaScript.

Comment by Y_Y 1 day ago

Giant leaps aren't typically the way to steady progress

Comment by matkoniecz 1 day ago

> 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.

seems entirely reasonable reason and approach, and I see no reason to force everyone approach LLM in the same way

Comment by iknowstuff 23 hours ago

It’s kind of a wink wink situation. Language like this simply encourages developers to vet code written by AI thoroughly to avoid being caught with obvious slop.

But as maintainers we (I don’t work on servo, but other projects) know that obviously people use AI anyway.

Comment by samus 18 hours ago

That's good enough and would prove that one put effort into the PR. Which is exactly what that policy actually wants to achieve.

Comment by lanyard-textile 20 hours ago

+1. If you submit code that was drafted by AI but vetted well by a human to not be obvious... Good :)

Comment by ravenstine 23 hours ago

If you believe AI isn't still involved in contributions to Servo, I have a bridge in Brooklyn to sell you.