Servo in 2024: stats, features and donations
31 comments
·February 5, 2025culi
materielle
One interesting thing covered in the Ladybird monthly update videos, is that most of the web platform tests are text encoding tests for Asian languages.
If you remove them, Ladybird is closer to 60% and Servo to 50%.
Still good, and the point still stands that they are making amazing progress. But probably more accurate because that last 10%-20% are going to get harder to chip away at.
JimDabell
Be careful you don’t mistake that for web standards compatibility.
There are many tests in there for non-standard Blink-only APIs that Google implemented unilaterally, which both Mozilla and Apple rejected on security and privacy grounds.
For instance WebUSB accounts for 845 tests, and WebNFC accounts for 173 tests. Neither of these are web standards, they are Blink-only Google APIs.
LeFantome
While I don’t doubt that there are bogus tests in there, looking at how many of them Safari and Firefox pass does not indicate that they have rejected many of them.
JimDabell
Web NFC:
> Status of This Document
> This specification was published by the . It is not a W3C Standard nor is it on the W3C Standards Track.
— https://w3c.github.io/web-nfc/
> We oppose this feature and will not implement it.
> We do not believe a permission prompt is a sufficient mitigation for the serious security and privacy risks raised by this specification. In addition, we think exposing direct hardware access to the web is a bad idea and compromises the device-independence of the web platform.
— https://lists.webkit.org/pipermail/webkit-dev/2020-January/0...
> We believe Web NFC poses risks to users security and privacy because of the wide range of functionality of the existing NFC devices on which it would be supported, because there is no system for ensuring that private information is not accidentally exposed other than relying on user consent, and because of the difficulty of meaningfully asking the user for permission to share or write data when the browser cannot explain to the user what is being shared or written.
— https://mozilla.github.io/standards-positions/#web-nfc
WebUSB:
> This specification was published by the Web Platform Incubator Community Group. It is not a W3C Standard nor is it on the W3C Standards Track.
— https://wicg.github.io/webusb/
> WebKit declined to implement several APIs, including WebUSB, due to concerns over fingerprinting
> We have previously stated privacy concerns, thus the concerns: privacy label. We agree with Mozilla's security concerns raised in their standards position issue, thus the concerns: security label.
— https://github.com/WebKit/standards-positions/issues/68
> Because many USB devices are not designed to handle potentially-malicious interactions over the USB protocols and because those devices can have significant effects on the computer they're connected to, we believe that the security risks of exposing USB devices to the Web are too broad to risk exposing users to them or to explain properly to end users to obtain meaningful informed consent. It also poses risks that sites could use USB device identity or data stored on USB devices as tracking identifiers.
a-dub
what ever became of khtml? i remember back in the day it had the nicest codebase of all of the browser layout engines.
xnorswap
Webkit was forked from khtml, but the original died along with Konqueror, which couldn't keep up with javascript API changes & performance.
a-dub
lots of relevant interesting reading on the webkit wikipedia page: https://en.wikipedia.org/wiki/WebKit
seems it was a quite complicated matter that included clashes between open source and commercial concerns.
https://web.archive.org/web/20090210230809/http://www.kdedev...
loeg
It eventually forked into Webkit / Chrome.
madeofpalk
Basically became webkit. Which google forked for Blink/Chrome
wiz21c
Are the last percents harder to complete ? (law of diminishing returns)
igrunert
For Ladybird - Andreas Kling called out that the vast majority of "easy tests" are passing and each additional test is going to be more difficult to come by going forward.
https://www.youtube.com/watch?v=-l8epGysffQ (1 minute - 4 minute)
infogulch
I'm convinced that using an embedded browser engine to render app UI is the future. Browser rendering engines are so powerful and versatile and universal I don't see how they can lose.
"But Electron!" Yes, Electron hasn't taken the world by storm because it has two huge deficiencies: 1. It takes an enormous amount of resources including ram and disk. 2. It has no native DOM API bindings so it takes even more ram and cpu to compile and run JS quickly.
I'm excited for the new crop of browser engines because they could fix those deficiencies, opening up browser tech to app developers without hugely compromising the experience.
horsawlarway
I mean... Just to be clear, Electron has pretty much taken the world by storm.
Huge number of Enterprise/productivity apps are shipped on Electron.
It's hard to beat the value proposition on the business side if you need a website for the product.
jillesvangurp
Are there browsers that use servo; or plans to build one? If not, who is actually using servo and what for?
dblohm7
Firefox has used Servo's rendering and styling components for years now.
Tsarp
Wondering how useful this would be for the agentic workflows that need browsing. The open deep research tread from yesterday mentioned using a pure text based browser sort of thing to quickly get info.
infogulch
Like the recently discussed Lightpanda?
Show HN: Lightpanda, an open-source headless browser in Zig | 318 points | 11 days ago | 137 comments | https://news.ycombinator.com/item?id=42817439
petesergeant
I have to imagine that the vast majority of those workflows are going to want to blend into real traffic as much as possible, which just means driving Chrome
qwertox
That's great news! I thought the project had died and that this meant that V8 was the only serious JavaScript engine for the future.
For those who don't know: "Servo is a web browser rendering engine written in Rust, with WebGL and WebGPU support, and adaptable to desktop, mobile, and embedded applications."
vanderZwan
I'm confused: why would the existence of a browser engine affect a JavaScript engine? Don't you mean WebKit/Blink instead of V8?
Either way I'm glad that there's a challenge to the browser monopoly and its various technical components of course.
gkbrk
Servo just uses SpiderMonkey instead of their own JS engine in Rust.
Even without SpiderMonkey, we'd still have JavascriptCore from Safari and LibJS from Ladybird.
wslh
I don't see the relevancy of the JS engine in the context of a web rendering engine and its independent complexity. The homepage of Servo (basically, a portion of the Wikipedia entry snapshot) doesn't even mention it.
kjeetgill
Because the parent-most post from quertox was:
> That's great news! I thought the project had died and that this meant that V8 was the only serious JavaScript engine for the future.
The person you're responding to was basically clarifying what you want to too.
madeofpalk
> V8 was the only serious JavaScript engine for the future.
Firefox's SpiderMonkey? Webkit's JSC?
bdhcuidbebe
spidermoneky has been around since before V8
diggan
Bit of an understatement. SpiderMonkey was the first JavaScript engine (out of all of them), born in 1996, made by refactoring the scraps of Mocha that was the initial prototype made by Eich.
ai-christianson
I thought it had died too. Great to see it make a comeback.
oguz-ismail
[flagged]
kuringganteng
[dead]
Ladybird and Servo are exciting and much needed projects since Microsoft abandoned their own independent browser engine to use Chromium.
If you didn't know you could see the massive progress both projects have made in web compatibility here: https://wpt.fyi/results/?label=master&product=chrome&product...
As of today, browsers pass this percent of tests: