> Today, the Servo team has released new versions of the servoshell binaries for all our supported platforms, tagged v0.0.1. These binaries are essentially the same nightly builds that were already available from the download page with additional manual testing, now tagging them explicitly as releases for future reference.
> We plan to publish such a tagged release every month. For now, we are adopting a simple release process where we will use a recent nightly build and perform additional manual testing to identify issues and regressions before tagging and publishing the binaries.
> There are currently no plans to publish these releases on crates.io or platform-specific app stores. The goal is just to publish tagged releases on GitHub.
show comments
nicoburns
The release announcement doesn't contain much information, but Servo does publish regular "This month in Servo" updates on their blog which contain lots of details:
Check them out if you're interested in what's going on with Servo.
show comments
natemcintosh
Tried it out on Linux. Worked better than I expected. Sites that are text heavy render well, and quickly. Sites with more "customization" sometimes struggled with rendering; stuff all over the place. Memory usage seemed a bit higher than Firefox with the same tabs, but not out of this world higher.
All in all, an impressive release.
show comments
beardsciences
Whether it's something like this, or ladybird's engine, I'm happy there is work being made in this space.
show comments
jchw
I've been testing web software that I work on with Servo and Ladybird. I'm pretty impressed!
Servo has some areas where it performs very well, though support for things like CSS Grid are still experimental and off by default (but working pretty well), and it's missing a few important APIs still. (I haven't checked in a while but last I looked it was missing AbortController. That's pretty unfortunate and probably breaks a lot of random stuff across the web.
I think Ladybird in Nixpkgs still doesn't have fully working hardware acceleration, so I'm probably not seeing the full smoothness Ladybird can offer in an optimal setup. Still! It runs pretty well, and it supports a vast majority of the web platform. Right now for my own development, the only major two omissions I've noticed are Origin Private File System, which is pretty new, and OffscreenCanvas, which actually is "implemented" but only as a stub. Throwing Web Workers and heavy WebAssembly workloads at Ladybird seems like no problem at all, and it renders a very reasonable subset of modern CSS almost perfectly.
(Tangent: Ladybird Web Workers are actually separate processes, which is kind of funny. If one runs out of control, you can literally SIGKILL it. The browser copes with this seemingly fine!)
Unfortunately, a lot of the web uses libraries and frameworks that are happy to eagerly adopt web standards and technologies that are not supported by browsers from a year or two ago. While I realize a lot of these standards were created specifically to solve problems that real developers have, I've been unimpressed watching this play out. Often new technologies increase complexity to solve relatively minor already-manageable issues with the web platform, and I feel like it is counterproductive to fatten up the web platform just for that. I mean really. There eventually has to be a point where we all agree that there is simply too much CSS technology and there is little justification to add more, but yet it just continues to grow uncontrollably. (I'm not saying it's all bad, though. Personally, I think the text-wrap additions were actually pretty nice things that really do need to be part of the layout engine.)
show comments
clot27
I am sooo ready to ditch chrome and firefox duopoly
show comments
butz
I wonder if it is deliberate choice to not include scrollbar? Is it due to limitations of UI widgets, or nowadays scrollbars are part of website, as some websites are very happy to set scrollbar size to "too narrow for comfortable use" or even remove it altogether. To end on positive note: is there a way for an average developer to try and fix this issue, thus doing my own share of contributing? Where should one start?
Congrats to the servo team. It's been a long road and it's amazing they kept it alive.
nullbyte808
It actually renders way more than it did a couple months ago. Very good progress!
timvisee
I'm seriously impressed on how far this has come. Tried a few websites in the experimental mode, it renders quite well.
darkwater
I'm so going to try this, and I hope it will end up as when I tried and used Phoenix, and then Firebird.
xnorswap
I am confused, I remember downloading and trying an early Servo release out a very long time (decade?) ago.
I've not been following the space, is this a different project with the same name?
show comments
wduquette
I'd like to see this succeed, but I'm skeptical that a small team can keep up with the major players in this area. Many years ago Dan Kennedy (of the SQLite team) wrote a lovely HTML widget for TCL/TK. It rendered CSS 1.0 quite nicely, and was a pleasure to use, modulo a few font-related bugs; but was soon rendered obsolete and out of date. Not blaming Dan, here; it simply wasn't a one-person job. Meanwhile, I'd rewritten an app to make use of it. Got burned once, don't want to get burned again.
show comments
CaptainOfCoit
Is Servo ready if I want to play around with it in a embedded-browser capacity? Say I wanted to have some basic HTML+CSS UI, can I create a Rust binary that embeds Servo+those resources and it kind of works?
show comments
nonethewiser
OK my understanding is that servo is a browser.
Then I read this on their repo:
>Servo aims to empower developers with a lightweight, high-performance alternative for embedding web technologies in applications.
Um... what? Are they just saying it's a browser in a verbose way or what? It just seems like you could replace literally all those words with "browser" and the clarity would skyrocket. Although perhaps it's not actually just a browser and I dont understand.
show comments
robin_reala
Ah nice, they’re finally generating native ARM Mac binaries.
amiljkovic
Does it support kiosk mode or is it configurable to run “locked down” to a single page and full-screen?
Is there a remind me bot once a relevant version number releases? Like 1.0 for example
show comments
esafak
They just issued their first release, 0.0.1, after 50,000 commits. I've never seen that before.
show comments
zeroq
ELI5 why we need more engines?
I shipped my first commercial website in 2001. I have PTSD from times when you had to basically do at least twice the work to ensure that your page worked - not just looked, but worked - on multiple browsers over multiple systems.
I recall a postmortem from a project of a major telecom website which took its pride in being accessible "everywhere". They had a matrix of systems and browsers, like 10x10, and they described how painful it was to check all the boxes.
I remember a tiny JS library I wrote at Wikia in 2006 for deep linking. It started with ~10 lines implementing documentation. But by the time I had all major browsers covered it grew to 500 lines.
I also have very fond memories of Flash. Apart from resolution - when I had my project working on my machine I had 100% certainty that it would work exactly the same on every client. Including mobile, kiosks, and desktop deployments.
Times were different, BigCos lived in siloes, ES4 went to shit and we needed another 15 years to reinvent the wheel with TS, but today everyone seems to be on the same team and browsers are shockingly compatible.
From the blog at https://servo.org/blog/2025/10/20/servo-0.0.1-release/
> Today, the Servo team has released new versions of the servoshell binaries for all our supported platforms, tagged v0.0.1. These binaries are essentially the same nightly builds that were already available from the download page with additional manual testing, now tagging them explicitly as releases for future reference.
> We plan to publish such a tagged release every month. For now, we are adopting a simple release process where we will use a recent nightly build and perform additional manual testing to identify issues and regressions before tagging and publishing the binaries.
> There are currently no plans to publish these releases on crates.io or platform-specific app stores. The goal is just to publish tagged releases on GitHub.
The release announcement doesn't contain much information, but Servo does publish regular "This month in Servo" updates on their blog which contain lots of details:
- Blog: https://servo.org/blog/
- Most recent TMIS post https://servo.org/blog/2025/09/25/this-month-in-servo/
Check them out if you're interested in what's going on with Servo.
Tried it out on Linux. Worked better than I expected. Sites that are text heavy render well, and quickly. Sites with more "customization" sometimes struggled with rendering; stuff all over the place. Memory usage seemed a bit higher than Firefox with the same tabs, but not out of this world higher.
All in all, an impressive release.
Whether it's something like this, or ladybird's engine, I'm happy there is work being made in this space.
I've been testing web software that I work on with Servo and Ladybird. I'm pretty impressed!
Servo has some areas where it performs very well, though support for things like CSS Grid are still experimental and off by default (but working pretty well), and it's missing a few important APIs still. (I haven't checked in a while but last I looked it was missing AbortController. That's pretty unfortunate and probably breaks a lot of random stuff across the web.
I think Ladybird in Nixpkgs still doesn't have fully working hardware acceleration, so I'm probably not seeing the full smoothness Ladybird can offer in an optimal setup. Still! It runs pretty well, and it supports a vast majority of the web platform. Right now for my own development, the only major two omissions I've noticed are Origin Private File System, which is pretty new, and OffscreenCanvas, which actually is "implemented" but only as a stub. Throwing Web Workers and heavy WebAssembly workloads at Ladybird seems like no problem at all, and it renders a very reasonable subset of modern CSS almost perfectly.
(Tangent: Ladybird Web Workers are actually separate processes, which is kind of funny. If one runs out of control, you can literally SIGKILL it. The browser copes with this seemingly fine!)
Unfortunately, a lot of the web uses libraries and frameworks that are happy to eagerly adopt web standards and technologies that are not supported by browsers from a year or two ago. While I realize a lot of these standards were created specifically to solve problems that real developers have, I've been unimpressed watching this play out. Often new technologies increase complexity to solve relatively minor already-manageable issues with the web platform, and I feel like it is counterproductive to fatten up the web platform just for that. I mean really. There eventually has to be a point where we all agree that there is simply too much CSS technology and there is little justification to add more, but yet it just continues to grow uncontrollably. (I'm not saying it's all bad, though. Personally, I think the text-wrap additions were actually pretty nice things that really do need to be part of the layout engine.)
I am sooo ready to ditch chrome and firefox duopoly
I wonder if it is deliberate choice to not include scrollbar? Is it due to limitations of UI widgets, or nowadays scrollbars are part of website, as some websites are very happy to set scrollbar size to "too narrow for comfortable use" or even remove it altogether. To end on positive note: is there a way for an average developer to try and fix this issue, thus doing my own share of contributing? Where should one start?
A few hours ago, just a few comments: https://news.ycombinator.com/item?id=45642051
Wow ive never seen such a low version number
Congrats to the servo team. It's been a long road and it's amazing they kept it alive.
It actually renders way more than it did a couple months ago. Very good progress!
I'm seriously impressed on how far this has come. Tried a few websites in the experimental mode, it renders quite well.
I'm so going to try this, and I hope it will end up as when I tried and used Phoenix, and then Firebird.
I am confused, I remember downloading and trying an early Servo release out a very long time (decade?) ago.
I've not been following the space, is this a different project with the same name?
I'd like to see this succeed, but I'm skeptical that a small team can keep up with the major players in this area. Many years ago Dan Kennedy (of the SQLite team) wrote a lovely HTML widget for TCL/TK. It rendered CSS 1.0 quite nicely, and was a pleasure to use, modulo a few font-related bugs; but was soon rendered obsolete and out of date. Not blaming Dan, here; it simply wasn't a one-person job. Meanwhile, I'd rewritten an app to make use of it. Got burned once, don't want to get burned again.
Is Servo ready if I want to play around with it in a embedded-browser capacity? Say I wanted to have some basic HTML+CSS UI, can I create a Rust binary that embeds Servo+those resources and it kind of works?
OK my understanding is that servo is a browser.
Then I read this on their repo:
>Servo aims to empower developers with a lightweight, high-performance alternative for embedding web technologies in applications.
Um... what? Are they just saying it's a browser in a verbose way or what? It just seems like you could replace literally all those words with "browser" and the clarity would skyrocket. Although perhaps it's not actually just a browser and I dont understand.
Ah nice, they’re finally generating native ARM Mac binaries.
Does it support kiosk mode or is it configurable to run “locked down” to a single page and full-screen?
Mozilla/5.0 (Android; Mobile; rv:128.0) Servo/0.0.1 Firefox/128.0
Is there a remind me bot once a relevant version number releases? Like 1.0 for example
They just issued their first release, 0.0.1, after 50,000 commits. I've never seen that before.
ELI5 why we need more engines?
I shipped my first commercial website in 2001. I have PTSD from times when you had to basically do at least twice the work to ensure that your page worked - not just looked, but worked - on multiple browsers over multiple systems.
I recall a postmortem from a project of a major telecom website which took its pride in being accessible "everywhere". They had a matrix of systems and browsers, like 10x10, and they described how painful it was to check all the boxes.
I remember a tiny JS library I wrote at Wikia in 2006 for deep linking. It started with ~10 lines implementing documentation. But by the time I had all major browsers covered it grew to 500 lines.
I also have very fond memories of Flash. Apart from resolution - when I had my project working on my machine I had 100% certainty that it would work exactly the same on every client. Including mobile, kiosks, and desktop deployments.
Times were different, BigCos lived in siloes, ES4 went to shit and we needed another 15 years to reinvent the wheel with TS, but today everyone seems to be on the same team and browsers are shockingly compatible.