Skip to content(if available)orjump to list(if available)

Servo's progress in 2024

Servo's progress in 2024

190 comments

·February 5, 2025

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.

lukan

I am not excited, because HTML is not a great UI framework at all.

It just happens to be the most widespread by accident, because hyperlinked documents - HTML - became huge and then more and more UI elements were bolted on top of it. And suddenly it became the goto, because the plattform run everywhere.

But it is still a ugly mess underneath and you might be right, that it is the future, but it is not a great one. I hope a great one will surface one day and then we can start new with something sane.

"I'm excited for the new crop of browser engines because they could fix those deficiencies"

And I cannot see what fixing those deficiencies could mean other, than throwing most of the standard away. It doesn't mean all of it needs to be thrown away. WebAudio API, WebGPU, etc. all became great standards. But simple UI elements, like a slider or color picker are still just ugly and impossible to make beautiful and behave sane, besides making a new one by hand, or using a libary from someone who did that. But - with WebGPU especially - I am excited for the possibility to build a sane framework on top of some subsets of the browsers capabilities.

codingbot3000

That's really a good point. If you're building a native app or similar, why constrain yourself to HTML?

iudqnolq

Because flexbox & grid are amazing. And you'll probably need it anyway if you ever have to render arbitrary rich text.

AnonC

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

In my observation, Electron's deficiencies go beyond these two. One glaring issue is the UX not conforming to the native OS guidelines/conventions, including things like keyboard based navigation and OS feature integration.

Give me a native app and an Electron (or similar app, including the abominations that are Catalyst apps on macOS), and I'll choose native apps every time.

diath

Numerous video games have been doing precisely that for the past decade using CEF: https://en.wikipedia.org/wiki/Chromium_Embedded_Framework

petabyt

BeamNG does it, and their UI responsiveness is the worst I've ever seen. It runs at most 20fps and using it is straight up painful.

ChocolateGod

FiveM uses CEF and let's you replace much of the built in GTA V scaleform with it.

It's incredible what can be done but can be far less responsive than the scaleform it replaces, but this may partially be due to it being a third party mod to the game.

null

[deleted]

promiseofbeans

Minecraft Bedrock uses React + a "web-like platform" (I assume this means they've just implemented the bits they needed) for their UI: https://github.com/Mojang/ore-ui

samtheDamned

Bedrock's interface also feels slightly more sluggish than Java's, Though its definitely faster than the other examples here.

ZeWaka

s/o to CefGlue, the C# bindings: https://github.com/space-wizards/cefglue

zeroq

and before that Scaleform!

apaprocki

The Bloomberg Terminal is rendered using Chromium and has been for many years. You don’t need to wait for new browser engines to use the existing ones, but you do need resources to contribute, maintain, bugfix, etc. because there is no such thing as a free lunch.

cjpearson

Props to Bloomberg for contributing too. I've noticed that they have sponsored the development of CSS Grid and other features in Chromium.

petabyt

> I'm convinced that using an embedded browser engine to render app UI is the future.

I think Facebook had the same thoughts at some point and they invested heavily in web tech. Later when that backfired (because of performance issues) they started the React Native project.

kylecazar

Yes, they prioritized just straight up mobile web for a while, citing things like HTML5 as the future of apps.

I think that an embedded web rendering strategy for UI within the context of a framework that provides other native interfaces may indeed become a bigger thing

whywhywhywhy

Apple purposefully limits what web tech can achieve on their platform so web vs native discussion needs to be heavily caveated on iOS what should be possible just isn’t.

We also know it’s not a case of just Apples native tech being better because MacOS has truly lost to webtech, hard to even name an app built in the last 5-10 years by a 3rd party in Apples own tech. Everything is just Electron or cross frameworks.

Personally I love truly native Mac apps but it’s certainly clear no one else cares and electron is enough.

andelink

> hard to even name an app built in the last 5-10 years by a 3rd party in Apples own tech. Everything is just Electron or cross frameworks

Was 5-10 years ago was the last time you used MacOS? Or do I live in a bubble? Because your statement sits opposite of my perception of things. Maybe I don't use enough apps to say for sure. I don't use most of these, but here are some that I can think of off-hand. You can tell me if these are too old, some of them may be I don't know.

Starting with ones recently seen on HN:

- pISSStream

- Ice

- Ghostty

- Stats

- NetNewsWire

- Wealthfolio

- Orion Browser

- Iina

- Dato, Velja + most others from Sindre Sorhus

- Proxyman

- Transmission

- SwiftBar

- AppLite

- MonitorControl

- BetterDisplay

- Maccy

- CodeEdit

- Does HandBrake count?

- Zed?

There's also a number of sites/lists dedicated to these types of apps. Sometimes it feels like there are too many apps even.

lostmsu

Wait, I understand Apple limits competitor browsers, but non-browser apps should have no issue embedding Chromium or Gecko, right?

weinzierl

"It has no native DOM API bindings"

I wish we'd get direct DOM access from WASM anytime but I have little hope.

infogulch

Actually, building WASM direct DOM api first, then building the native DOM api as an extension of that sounds like a great idea.

yencabulator

My understanding is that "the DOM API" is specced very much in terms of Javascript, so WASM component stuff might see a "DOM2 API" that's similar but not really the same API. Lots of work in speccing that out, I bet. But yes, please!

tcfhgj

why? it doesn't matter in any non-trivial app

weinzierl

In other contexts people complain about every byte shipped too much but whenever WASM comes up kilobytes of useless JavaScript shims don't matter. And it is one unnecessary extra request we should not need. It is one extra build step to generate the bindings.

cakealert

Unfortunately, the best GUI in existence atm is a proprietary middleware and the language for it is XAML.

NoesisGUI: https://www.noesisengine.com/xamltoy/0e2a866b60bc2b9a724b4c6...

And it even has a studio for paying clients which makes designing a GUI trivial. https://www.noesisengine.com/studio/

The studio is made using their own GUI library and its sleek af. Not even QT holds a candle to it. Would have been nice to have such a project in the open source world.

pjmlp

Qt certainly holds several candles, what happens is that people always complain about having to pay for tools, while expecting to be payed themselves.

https://www.qt.io/product/ui-design-tools

mcintyre1994

Is that desktop only, or does their demo just not work on mobile but other stuff can? I don’t get a keyboard when I focus their password input on iOS Safari.

lofaszvanitt

we need something like this but with a css-html-js output

andyjohnson0

https://platform.uno/ is an option for building web apps with xaml

taurknaut

> Browser rendering engines are so powerful and versatile and universal I don't see how they can lose.

Well browsers are pretty damn heavy for an app that won't use 99% of its functionality. Maybe some of this can be amortized with clever distro work so apps don't have to ship the whole runtime but that hasn't happened yet.

(In fact, it's a little odd to me electron is based on chrome rather than the WebKit that actually ships with macos.... you should be able to ship that sort of app with a few megabytes)

I'd also rather eat glass than be stuck with javascript, easily the most frustrating ecosystem I've ever worked with by a very wide margin. Just the language is ok, but the build pipelines/bundling/transpilation/polyfillls is absolutely miserable to work with and lack of a decent standard library really hurts. It's crazy how we've basically lifted up the concepts of compilation and linking c objects to the world of javascript, just to ship code in a language the browser already fully supports.

Maybe WASM will help but my understanding its use of the DOM is quite awkward and still requires javascript usage.

jampekka

How does WASM help with the concepts of compilation and linking c objects?

esad

I think Servo's killer application would be a mobile-first browser for postmarketOS/Mobian/other mobile Linux distros. It's a weird vacuum because Firefox has its Android port, but when you run Firefox on small linux (touch)screen, the experience is very suboptimal. I'd call it unbearable if it wasn't for bunch of tweaks in form of https://gitlab.postmarketos.org/postmarketOS/mobile-config-f...

Chrome is no better, as it has a very weird hardcoded minimum window width of 500px.

spankalee

I've long thought its killer feature would be embeddable cross-platform UI and native-wrapped web apps like Electron and Capacitor. For these cases it doesn't need to render the entire public web, but the subset used by the application developers. It's a much more tractable problem.

Chrome had a project a long time ago called Razor whose goal was to make a 120fps streamlined subset of the web platform for those types of use cases. They tried to throw away warts of the web that slowed down parsing and rendering like quirks modes, floats, negative margins, infinite entity expansion, element adoption, and probably most built-in elements, leaving a few core built-ins and custom elements.

Razor apps could have run on the web, and in a Razor runtime. Unfortunately, IMO, they kept removing things until they removed the document, and swapped in Dart for JS and the project became Flutter which is not very web-like at all.

I thought Razor was a neat idea, and Servo could really fill that space well.

elcritch

Fascinating, and I’ve been working on a native UI project I call Figuro for a couple of years now (1) that’s built on the idea of simple nodes.

It’s surprising how similar to HTML it’s becoming. I feel like it's sorta an inverse of the Flutter story. Lately I’m working on adding a subset of CSS. Adding padding and margins too seems like a good idea too, etc. Part of me wonders how much of a webpage I could render with it.

1: https://github.com/elcritch/figuro

rafaelmn

Yes this is the ideal space for a performance minded web rendering engine rewrite.

And if you do it well enough as a subset it can become the next standard where the modern web is just the subset, you can even integrate it with a legacy render where you fall back to legacy when you detect you cant handle it, and have the fast path for the subset.

pests

Didn’t realize that was the backstory of Flutter, I thought this was headed in a different direction.

I heard the YouTube team did something similar for their embedded / resource-constrained environments where the client just renders barebones HTML/JS and only what is needed is implemented in the engine.

spankalee

Yeah, YouTube has minimal engine called Cobalt: https://developers.google.com/youtube/cobalt

That's also an unfortunate story, because they've really lagged on adding features in the past because they generally have no way to update the engine on TVs. So any new feature would take 5-10 years to be usable.

So almost 10 years ago they didn't invest in some core things like web components, and they could have used them by now if they did.

nulld3v

Another similar project (alpha stage): https://github.com/DioxusLabs/blitz

And another (mature but proprietary): https://sciter.com/

kevingadd

The minimum window width is a funny thing, Chrome has been steadily raising the minimum every time they make changes to the UI. It used to have a minimum around 320px and now on some configurations it's nearly 800px. There's an old open bug about it where people periodically comment to complain that it was raised again.

pipeline_peak

> I think Servo's killer application would be a mobile-first browser for postmarketOS/Mobian/other mobile Linux distros

Are you suggesting that such an app would get people to go out of their way and use mobile Linux?

PartiallyTyped

Huawei is doing that, with their own OS.

culi

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:

  Chrome: 96.82%
  Firefox: 95.41%
  Safari: 94.97%
  Ladybird: 89.30%
  Servo: 78.61%

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.

culi

That's interesting and it explains why the wpt.fyi website doesn't show a percentage but instead the number of tests.

There are tons of other examples of these easy points in the test suite. Ofc text encoding tests are important if we want the internet to truly be global

I guess these percentages are kinda useless by themselves but still useful to track progress when you put them together in a historical graph

IshKebab

Yeah it's crazy that they don't weight the tests. AVIF support is 1 test, whereas WebCryptoAPI is 50k.

Release0381

AVIF support is irrelevant. JPEG, PNG and soon JPEG XL is all you need.

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.

https://mozilla.github.io/standards-positions/#webusb

ironhaven

It may seem like a lot but there are 1.7 million web platform tests. Controversial chrome only web apis are few and far between the common features

IshKebab

At this point the web is a de facto standard platform. The whatwg doesn't decide what makes it up any more than w3c did.

As well as browsers supporting features not endorsed by whatwg, there are plenty of features that they have endorsed that browser vendors didn't bother with.

JimDabell

> At this point the web is a de facto standard platform.

Yes, the web is a standard platform, Blink is not. Google can’t just spit out any old privacy-violating, insecure garbage specification and call it a web standard just because it’s what they want to build. Google don’t unilaterally decide what the web is.

> there are plenty of features that they have endorsed that browser vendors didn't bother with.

Something can’t become a web standard unless there are two independent implementations. It’s part of the standardisation process. It also disqualifies things like Web NFC and WebUSB from being web standards because Google couldn’t convince anybody outside of Google to implement them.

saghm

It's a standard platform, but the platform itself is not standardized, which is the point I think GP was making. The problem isn't that people don't think the web is a standard platform, but that it's hard to quantify what it means to support the web as a platform because of conflicting implementations. Standardization is ostensibly supposed to help with that, but it obviously doesn't perfectly reflect what browsers will actually support. Ultimately it the question comes down to whether people can actually use the browser with the websites they want to connect to, but that's not something that can be quantified easily due to it depending on what features websites are using and which features a browser has implemented, and network effects can make it hard to pin down what's expected at any given time, which is where all of these "imperfect" metrics like calculating some score based on the standards is coming from.

upcoming-sesame

I'm guessing that the "last 5% = 90% of the work" rule applies to browser engines as well ?

wobfan

Idiot here: How long will it approximately take until we see a real Ladybird or Servo browser in production, that is actually usable and e.g. has addons?

Like, will it be 6-12 months, or more like 2-3 years?

brodo

I think Andreas Kling said they aim for their first release in 2026.

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

madeofpalk

Basically became webkit. Which google forked for Blink/Chrome

yonatan8070

Damn

I was entirely unaware that both Chrome and Safari can trace their roots back to KDE of all projects. I always just assumed big corpos like Google and Apple would just roll their own from scratch.

loeg

It eventually forked into Webkit / Chrome.

yonatan8070

These are interesting stats, but it makes me wonder what those tests exactly are. Are there 3.18% of tests that no browser passes? How applicable are most of these tests to real world websites?

culi

No, likely much less than 3.18%. Chrome passes the most but there are plenty of tests that only Chrome passes or only Chrome doesn't pass

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)

culi

As another comment pointed out, some of them will never be implemented on purpose. These tests aren't all backed by web standards. E.g. one test suite is for compatibility with non-standard Blink APIs

Also there are new tests being added all the time

polyaniline

Hasn't Servo been around much longer than Ladybird? Has it stagnated?

kibwen

Servo was on a multi-year development hiatus, which is the reason this is news (see the graph in the article). In addition the original priority of Servo was not to broadly implement web standards, it was as a proving ground for Rust components to be uplifted into Firefox (I'm unclear whether or not those components, which have surely been continually developed since then, have been backported into Servo).

KwanEsq

>(I'm unclear whether or not those components, which have surely been continually developed since then, have been backported into Servo)

I believe the article makes clear that they have.

>Servo main dependencies (SpiderMonkey, Stylo and WebRender) have been upgraded

zarzavat

Whisper it but C++ is probably a better language for building a FOSS web browser engine than Rust.

There’s simply more C++ programmers around, and you need as many bodies as possible for such a large project. There’s also precious few Rust developers with experience with large projects since Servo is the largest project.

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.

jillesvangurp

Servo was of course based on the servo project in Mozilla. But that was discontinued years ago before that project was completed. I'm sure Mozilla still uses some of those components. But is servo actively contributing back to Mozilla at this point or is it more of a fork?

0x457

> But that was discontinued years ago before that project was completed.

IIRC purpose of Servo when it was Mozilla project was:

- Develop large scale project in rust to see pain points

- Have a test bed for pieces that would later be integrated in Firefox

In both cases project succeeded: Quantum CSS (Stylo), WebRender, and some smaller components that I don't recall. I don't think there was ever a goal of building a full consumer-grade browser, at least not within Mozilla.

nicoburns

There is two-way syncing of the shared components (primarily Stylo and Webrender). They are primarily maintained by Mozilla, but Servo has been contributing some changes.

monroewalker

If servo (or something like it) succeeds, would that mean potentially being able to swap out chromium in Electron? Would that help with performance / application size?

kibwen

Long ago it was a goal of Servo to adhere to the Chromium embedding framework, and differentiate itself from Gecko by having a good embedding story. I'm unclear whether that is still a goal of the modern project, however.

ramon156

Why the big dip in PRs over the years? Was that the year it got discontinued?

pilaf

I would guess so. Their blog also has a big gap between 2020 [1] (when the Servo team was laid off from Mozilla) and 2023 [2] when they found new funding and restarted development, with nothing else posted in between.

1: https://servo.org/blog/2020/11/17/servo-home/

2: https://servo.org/blog/2023/01/16/servo-2023/

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

fbouvier

Yes, argentic workflows are one of our use cases for Lightpanda.

We skip the graphical rendering of the web page for instant startup, fast execution and low resources usage.

infogulch

Can skipping rendering affect website behavior? What happens when JS tries to get layout/color information? How often does this break a website?

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

PartiallyTyped

Minor typo:

    from over an our to under 30 minutes.
s/our/hour/

null

[deleted]

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.

fbouvier

And some lightweight alternatives like Bellard's QuickJS (https://bellard.org/quickjs/) in C and Kiesel (https://kiesel.dev/) in Zig.

nicoburns

Also, Hermes which React Native uses.

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]