Servo v0.0.1
91 comments
·October 20, 2025adzm
bastawhiz
Is it as simple as "now is as good a time as any to start tagging releases"? There's no special motivating factor that drove this to happen now?
swiftcoder
I think it's also that they finally got Mac/Arm releases sorted, so now they have the full platform support matrix for nightlies?
sebsebmc
That's roughly correct. The other side of this is figuring out a release process and thinking about versioning.
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:
- 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.
Y_Y
When Google Reader died, so did a large part of me, and the web.
That said, I'm recently back on RSS and this is another good feed:
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.
beardsciences
Whether it's something like this, or ladybird's engine, I'm happy there is work being made in this space.
DerSaidin
+1
Personally I'm more optimistic about Servo - because originating at Mozilla, I imagine more web browser experience and expertise went into its architecture, and also because Rust.
nicoburns
> originating at Mozilla, I imagine more web browser experience and expertise went into its architecture
Andreas Kling who created Ladybird had prior experience working on KHTML/WebKit so there is expertise there too.
ricardobeat
I don't know.. Servo has been in development for a decade and still has quite underwhelming performance and UX. The binary is 100MB+ on Mac, scrolling is janky, a google image search takes 10+ seconds to render and goes through very buggy states. Meanwhile Ladybird renders a legacy UI, but feels really fast and stable.
evolve2k
“Servo is more than a browser engine—it’s a collection of crates used widely across the Rust ecosystem. Maintaining these libraries benefits not just Servo, but the broader web platform.“
Per: https://www.igalia.com/2025/10/09/Igalia,-Servo,-and-the-Sov...
01HNNWZ0MV43FF
Seeing Servo and full-fat Electron [1] both at 100 MB made me wonder if that's the minimum for an "Everything bagel" browser engine that does WebRTC, video playback, etc., etc.
How big is Ladybird?
[1] I believe you can make Electron smaller by cutting parts of Chromium out, but the default is around 100 MB
Y_Y
> binary is 100MB+ on Mac
If you're worrying about that size then Mac OS is not the platform for you.
ionelaipatioaei
I think Ladybird will beat Servo at making an usable and good product, Mozilla might have more resources but that's not the only thing that you need if you want to build great software.
nicoburns
> Mozilla might have more resources but that's not the only thing that you need if you want to build great software.
Servo is no longer a Mozilla project, and hasn't been since 2020. It's now developed by Igalia, Huawei, and a collection of volunteers.
tracker1
Agreed. Servo is emphatically not anything resembling a priority at Mozilla and hasn't been for a long while.
echelon
Servo's value is that it's written in Rust.
Ladybird is C++ and that still has the same issues as every other engine.
I suspect Ladybird will/has already leapfrogged Servo in performance and usage due to the Ladybird team and its momentum. Mozilla isn't doing anything with Servo anymore.
But I also don't really see a compelling reason for Ladybird's existence - we already have Chromium, Blink, Gecko, etc. It's hard for me to imagine a world where Ladybird is a healthy contender for marketshare.
The only real novel thing to do in this space is "rewrite it in Rust".
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?
nicoburns
If the other project was a web browser then it's the same project. It got abandoned ~5 years ago, but has since been picked up again.
edoceo
Same, reborn
brson
Congrats to the servo team. It's been a long road and it's amazing they kept it alive.
Aissen
A few hours ago, just a few comments: https://news.ycombinator.com/item?id=45642051
altairprime
If you email the mods they’ll merge the duplicate discussions. Footer contact link.
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?
fabrice_d
Related: https://github.com/servo/servo/issues/21817
You should likely join https://servo.zulipchat.com and ask questions to know where to start.
clot27
I am sooo ready to ditch chrome and firefox duopoly
lambdaone
We are lucky it's even a duopoly. All it would take is the demise of Firefox, and the entire web would be defined entirely by the implementation of Chrome/Chromium.
Servo is very welcome; a third leg to the stool makes real diversity possible again.
bastawhiz
Don't forget that pretty much 100% of iOS users and a nontrivial percentage of Mac users are on Webkit/Safari. That's not to say Safari is really leading the pack on anything at all, but Google also hasn't led Apple by the nose on pretty much anything on the web in recent years.
jorvi
Yup, the split is really Blink+WebKit. Gecko marketshare is tiny these days.
What's interesting is seeing a few non-Apple WebKit browsers pop up, like Orion (Kagi) and Epiphany.
Call me cynical, but I don't see Ladybird or Servo do much beyond making a splash. Browser engines take an incredible amount of dev hours to maintain. Ladybird is hot now, but what about in a decade? Hype doesn't last that long and at that point the money and a chunk of the dev interest will have dried up.
Blink and WebKit both have massive corporations championing them, so those engines do not run that risk.
whizzter
Ladybird seems to be progressing at an impressive pace also, time will tell however if their choice of C++ will be a big problem or if modern ways of doing things are safe enough.
tredre3
Their choice is actually Swift and by the time there's a stable release all the C++ code is intended to have been replaced.
Time will tell if that will be a big problem or if more mainstream ways of doing things are better for a project intended to run everywhere!
glenstein
Very excited for Ladybird and Servo. I wonder if a good thing that may emerge from this era of LLM code-support capabilities is that its more feasible to support alternative browser codebases even as they get into the multi-million lines of code.
throwaway48476
They chose c++ because the web spec implies object oriented design.
lawn
They're announced they want to move to Swift to combat some of this.
glenstein
I've seen a lot of criticism of Mozilla in these parts, some more fair than others. (Adtech = bad, regardless of whether you call it privacy preserving. CEO pay, not as bad as people say but don't love it.) But the notion that a trillion dollar platform company dictating web standards and Firefox are two sides of the same coin is, by my lights, the singularly most spectacular failure of comprehension that's been wrought by this era of Mozilla skepticism. It's not exactly a big lie because the people saying it seem to sincerely believe it but it's comparably disastrous as a test of information literacy.
tracker1
Mozilla was sitting on a chest of cash that could have funded engineering efforts for decades. Instead they decided to inflate managers and marketers in an effort to expand market/mindshare and follow that with needs for ever increasing funding drives to fund lavish parties and events on the marketing side, while shuttering engineering efforts and even laying off swaths of engineering talent.
That doesn't even touch some of the more salient political movements or failure after failure to spin the brands off into something more/different for profit motives.
Mozilla needs to restructure as an engineering focused organization where business operations, marketting and brand management are not steering the ship.
roryirvine
Are non-profits in the US allowed to hoard cash long-term?
In the UK, spending on furthering their charitable purpose is expected to roughly match income over the medium term. There are carve-outs for specific types of "permanent endowment" (and even there, spending is meant to match the investment income) but it wouldn't cover anything like Mozilla's commercial agreement with Google.
The_Rob
Firefox market share is so low, it really seems more like a Chrome and Safari duopoly.
kelnos
Firefox isn't a part of any duopoly, with market share numbers as low as they are these days. Chrome + Safari, perhaps? (Or Chrome + Edge if you exclude mobile, though Edge of course uses the same rendering engine as Chome.)
smt88
The duopoly is Chrome and Safari. Firefox barely registers, especially because all browsers on iOS are Safari.
Also, what's your issue with Firefox?
1vuio0pswjnm7
Mozilla/5.0 (Android; Mobile; rv:128.0) Servo/0.0.1 Firefox/128.0
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.
nicoburns
I feel like part of the solution here is to build the browser as reusable modular components. For some parts of browsers that's been common for years: JS engines (V8, SpiderMonkey, etc) are typically reusable, as are rendering backends (WebRender, Skia, etc), and lower-level components like Freetype/Harfbuzz/icu.
Servo's CSS engine Stylo is also modular, and is shared by Firefox which is part of how they've managed to not completely fall behind in web standards support despite the project being all but abandoned for several years.
I'm building another browser engine Blitz [0] which also uses Stylo, and we're building our layout/text engine in such a way that it can be reused so future browser engines (at least ones written in Rust) shouldn't need to build either Style or Layout if they don't want to.
A few more infrastructure pieces like this and browser engine development starts to look more approachable.
norman784
Thanks for you hard work, I already saw taffy being used by other prominent projects like Cosmic desktop environment, bevy, etc
bryanlarsen
It's several small teams. Servo is modular, and parts of it are useful outside of Servo. Other projects are using and maintaining and enhancing those modules. For example, IIRC dioxus uses many of the modules.
Edit: see sister comment by the actual Dioxus guy, which is more accurate than mine!
Yoric
I seem to recall that MMM was based on this widget.
For context, MMM was a browser that supported both browser addons and sandboxed applets, around 1995.
null
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.
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.