Servo v0.0.1

466 pointsposted 13 hours ago
by undeveloper

141 Comments

adzm

12 hours ago

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.

bastawhiz

11 hours ago

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

10 hours ago

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

11 hours ago

That's roughly correct. The other side of this is figuring out a release process and thinking about versioning.

nicoburns

12 hours ago

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

10 hours ago

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:

https://servo.org/blog/feed.xml

srott

6 hours ago

I wish I had a RSS reader to feed this to...

skyfaller

5 hours ago

One of my favorite RSS readers is https://vore.website - river of news, no unread indicators, simple. It's a website, as the domain suggests, so no need to install anything.

zymhan

5 hours ago

> as the domain suggests

It suggests a couple of things...

Millennium

3 hours ago

Yeah, after the appropriate layers of VPN/Incognito/Tor/muted phone/etc I braved the link, and it turns out it's actually real, but that is still not a hostname I want connected to me in anyone's access logs more than once.

natemcintosh

12 hours ago

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.

brokencode

8 hours ago

It’s still a ways off, but I’m excited for the possibility of something like Tauri using Servo natively instead of needing host browsers. A pure Rust desktop app stack with only a single browser to target sounds fantastic.

qzw

7 hours ago

But then we have the same complaint against Electron, namely large deployment sizes and no shared memory, no?

Octoth0rpe

6 hours ago

this part is important: > A pure Rust desktop app stack

I think the parent is imagining a desktop with servo available as a standard lib, in which case you're left with the same complaints as Tauri, not electron; that the system version of Servo might be out of date.

brokencode

4 hours ago

Yeah, multiple Tauri apps could theoretically share a Servo library.

Though I’d also be interested to see how slim it could be with static linking.

Presumably a lot of code could be compiled out with dead code analysis? Or compile flags could remove old compatibility cruft and unneeded features?

beardsciences

11 hours ago

Whether it's something like this, or ladybird's engine, I'm happy there is work being made in this space.

DerSaidin

11 hours ago

+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

10 hours ago

> 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

10 hours ago

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.

Hemospectrum

6 hours ago

> Servo has been in development for a decade

I was curious how you arrived at that figure so I checked the dates. Servo began in 2012 as a Mozilla skunkworks project, died off in 2020, and was revived in late 2023. If you simply subtract the "dead" period, sure, it doesn't look like it was going anywhere fast, but that's ignoring the multiple major changes in direction and the 5+ years during which Servo development was fully subordinate to Firefox development. It only became a fully independent browser development effort after the project was revived by Igalia.

Y_Y

9 hours ago

> binary is 100MB+ on Mac

If you're worrying about that size then Mac OS is not the platform for you.

ricardobeat

3 hours ago

Not sure what your point is? Chrome for example is much smaller on Mac than other platforms.

And it's not about absolute size, but compared to Chrome/Electron you'd expect a fresh modern codebase to be somewhat slimmer and faster.

01HNNWZ0MV43FF

10 hours ago

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

nicoburns

9 hours ago

There are ways to slim it down, but WebRTC and video playback would probably be one of the first things I'd remove if I were looking to do that!

The other obvious target is the JS engine. IIRC V8 is 90mb just by itself. I don't think SpiderMonkey is quite so large but definitely still in the 10s of megabytes. A slower simpler JS engine (QuickJS, hermes, etc) could be quite a bit smaller.

johannes1234321

7 hours ago

That however would limit the browser to small audiences. Many users won't accept movies not playing and many sites require a JavaScript engine with all those optimisations, even SpiderMonkey loses too much in that space.

Binary size however is less of an issue for most users.

nicoburns

6 hours ago

Yeah, I think these kind of setups don't make much sense for the main "browser application that end-users use" use case. They can make a lot of sense in the Electron "I'm wrapping a browser to use as an app framework" use case though.

cardanome

7 hours ago

Meanwhile Lua is under 200kb. Imagine if you could use it as a browser language, no more bloat and churn.

ricardobeat

3 hours ago

QuickJS is about 200kb as well and has similar performance to Lua, it's not about the language itself. V8 performance is closer to C in some areas.

nerdponx

9 hours ago

Is some kind of a browser microkernel possible? Could you ship, say, JS Canvas support in a separate optional module?

shiomiru

5 hours ago

I've done something like that in my TUI browser:

https://codeberg.org/bptato/chawan/src/commit/3f2fffd882ff47...

It just spins up a background process when a canvas context is created and sends drawing commands through IPC. As a result, you can rm the 970k canvas binary (most of it is just Unifont) and with some luck you will only break canvas rendering.

Of course this only works for things that are relatively self-contained. So you can add/remove image decoders or protocol handlers without recompiling (the main binary has zero networking code), but the JS API is still baked in.

(I imagine you could also implement some less performance-sensitive APIs in JS and load the bytecode on demand, but I haven't tried.)

nicoburns

6 hours ago

A separate module that is configurable at build time would probably be doable. A separate module that is loaded at runtime probably isn't feasible.

F3nd0

7 hours ago

I’m more hopeful about Servo because it’s released under a copyleft licence, whereas Ladybird chose a pushover one.

Imustaskforhelp

6 hours ago

Can you elaborate what you mean by pushover license?

Ladybird uses bsd-2 license which is OSI, I mean its not fsf/copyleft but permissive which should be better sometimes for things like embedding etc. no?

It looks like servo uses mozilla public license 2, can you please explain me the difference and why you think one is pushover and other is not?

F3nd0

4 hours ago

‘Pushover’ is another term for ‘permissive’. It emphasises the fact that, unlike copyleft licences, pushover licences don’t make an attempt to protect the freedoms they grant their users. In other words, they allow anyone to make and distribute derivative works without preserving any of the freedoms which came with the original work.

As far as I can see, for an author of derivative work, permissive licences are only really preferable when you either can’t or don’t want to grant or preserve the freedoms which a copyleft licence would require you to grant and preserve. (Which, to be fair, may often be the case.) From a different point of view, copyleft can be seen as better for embedding, since it means that Free Software in question will only be used to make more Free Software.

The MPL is a copyleft licence, but it’s known as a ‘weak copyleft’ licence. That means it preserves only the freedom of the program it initially covers; any changes made directly to that program can only be distributed as Free Software, but the program itself may be used and distributed as part of a larger work, which as a whole does not have to be Free. (This is in contrast to ‘strong copyleft’ licences like the GPL, which require the entire larger work to be Free.)

Weak copyleft is a kind of compromise which lets you e.g. embed a piece of software without having to grant all your users freedom to use, share and modify your entire work, but you're still required to grant them those freedoms in regard to the piece you’re embedding.

ionelaipatioaei

10 hours ago

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

9 hours ago

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

echelon

9 hours ago

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

nicoburns

9 hours ago

> The only real novel thing to do in this space is "rewrite it in Rust".

Ironically Chromium is now starting to include quite a bit of Rust. And of course Firefox has for some time.

mnmalst

8 hours ago

They are planning to use swift in the future. Last point: https://ladybird.org/#faq

heavyset_go

3 hours ago

I think that was being blocked by Swift features/libraries not being consistent across platforms, in that Swift for Linux/etc is missing stuff you'd get in macOS.

I don't see that changing any time soon. If Apple truly wanted Swift adoption to be cross platform, they have the resources to do it, but they didn't do it.

stephen_g

2 hours ago

No, pretty sure that's all basically fixed in Swift 6 (Sep 2024), I think it's more just the immaturity of the C++ interop in being able to bridge Swift to complex C++ code.

That's a key feature of what Apple want Swift for (to gradually replace their C++ projects with Swift) but it's still pretty new. It'll take a while to mature.

echelon

2 hours ago

That feels like the wrong language to bet the farm on.

Swift is horrible to develop in cross-platform. The language ergonomics are great, but the support just isn't there.

Also - swift is great for lots of applications, but a browser? Why use a garbage collected language for something that needs to be smooth? Unpredictable GC pause jitter is not something you want when smooth scrolling and rendering. Granted Javascript already negates that experience a little bit, but why introduce even more unpredictability?

I get the feeling the leadership loves Mac/Apple, which makes sense in light of their recent iOS announcement. Maybe they're prioritizing that world.

tracker1

9 hours ago

Agreed. Servo is emphatically not anything resembling a priority at Mozilla and hasn't been for a long while.

zargon

4 hours ago

Servo is not part of Mozilla any more.

lawn

8 hours ago

Mozilla gave up on it a while ago.

It somehow survived after years with little progress and has relatively recently gathered speed again under new stewardship.

clot27

11 hours ago

I am sooo ready to ditch chrome and firefox duopoly

lambdaone

11 hours ago

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

11 hours ago

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

10 hours ago

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.

nicoburns

3 hours ago

> Blink and WebKit both have massive corporations championing them, so those engines do not run that risk.

There's always risk. IE/Edge also had a massive corporation championing it, until it didn't. The US DOJ also appears to be considering actively prevent Google from backing Chrome. Which could also do for Firefox given that it's revenue comes from the same source.

No doubt that wouldn't completely kill those engine given our reliance on them, but in those kind of circumstances we might welcome the existence of some simpler engines that are cheaper/easier to maintain.

whizzter

11 hours ago

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

11 hours ago

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!

norman784

10 hours ago

I remember they mentioning Swift a few months ago, but currently I don’t see any swift in their github repo, didn’t checked other branches besides main.

hypeatei

10 hours ago

> all the C++ code is intended to have been replaced.

That is not their goal at all, I don't where you heard that. Swift is currently stalled due to some blockers listed on their issue tracker, but any usage of it will be in safety-critical areas first and not a complete rewrite of existing code.

glenstein

10 hours ago

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

11 hours ago

They chose c++ because the web spec implies object oriented design.

IshKebab

11 hours ago

No they didn't. It's C++ because the primary author was most familiar with C++ and only allowed C++ in SerenityOS.

https://ladybird.org/#:~:text=The%20choice%20of%20language%2...

throwaway48476

11 hours ago

That was the answer I remember Andreas give in a update video to answer the "why not rust" question.

IshKebab

7 hours ago

That doesn't really make sense to me either. Even if WebIDL is inheritance based, that is going to be processed automatically so you can easily use codegen to make the resulting interface nice in Rust, in a way that would be relatively difficult if you were hand-writing it.

lawn

11 hours ago

They're announced they want to move to Swift to combat some of this.

whizzter

10 hours ago

Yep, but there was another post mentioning half a million lines of C++ code so far.

While the C++ interop in Swift seems sane with Clang being embedded I wonder how much time/energy they will have to actually move significant parts if it's so large already.

glenstein

10 hours ago

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

9 hours ago

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.

glenstein

5 hours ago

Are you sure that you have your numbers right? It seems pretty common in the hn comment section for people to come in and randomly claim that Mozilla either spent all of their money or are losing all of their money. But the last figure I saw for their cash and investments was around $1.2 billion from late 2022, and everything I can find on their data spanning from the 2010s through the 2020s through today is that it's been a steady trend line up.

They had $91 million in 2009. 105 million and 2010, $193 million by the end of 2011, $372 million by the end of 2015, and I don't have every number for every year, but it all seems to indicate a steady upward trend.

I'm not sure how to look at those data and interpret them as squandering of cash and those are pretty specific claims that I would hope could be articulated in a clear cause and effect way if they were true.

roryirvine

8 hours ago

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.

yencabulator

7 hours ago

Mozilla has already hoarded well over a billion. A billion would pay a sizable development team of experts for quite a while.

https://assets.mozilla.net/annualreport/2024/mozilla-fdn-202...

roryirvine

6 hours ago

But the Mozilla Foundation's purpose is "protect and improve the Internet as a public resource, open and accessible to all".

It's not clear to me why that requires a sizeable team of developers - surely they'd be better off working for MoCo (the commercial subsidiary who make the browser and who provide a large portion of the MoFo's income)?

MoFo's activities are centred on philanthropy and advocacy. You'd expect most of their staff to be experts in things like community engagement, policy research and development, grant-making, campaign strategy, volunteer welfare, reporting & transparency, and management of investments.

Sure, there'll be some engineering needed to support that, but it shouldn't be their core focus.

yencabulator

6 hours ago

You're arguing the stated purpose of the current system, I'm arguing we'd actually benefit more from refocusing it into software (like it used to be).

And that's the stated purpose. The observed current purpose of the system is to make a small handful of people more rich.

roryirvine

5 hours ago

The MoCo/MoFo split happened for a reason: a non-profit couldn't do the big commercial deals that became available to MoCo.

If you went back to the pre-2005 situation, in which MoFo was all there was, it would have at most low single-digit millions in the bank rather than a billion. The AOL dowry was only intended to last a couple of years, and there's simply no way it could have sustained development of the browser beyond that. The Phoenix would have been consumed by the flames, and we'd be left with a stagnant IE/Chrome duopoly.

yencabulator

5 hours ago

Let's try this:

1. most of the money comes from Google Search placement in the browser

2. most of the money is NOT used on the browser

glenstein

3 hours ago

On the linked report above I'm seeing software development as about 52% of their expenses. And many of the other expenses, eg "General and administrative", I understand to be support infrastructure for software development. This would seem to fit the meaning of "most" on my read.

yencabulator

3 hours ago

It's really telling that Mozilla does not want to itemize those costs to say how little the actually use on Firefox.

glenstein

4 hours ago

Having worked for a non-profit many years ago as an office monkey who, among other things, took notes on finance committee meetings, it's typical to have some operating reserves that you can measure in terms of how many months or years of your operating expenses they could cover. This is a common financial stress test used to assess the financial health of organizations. Given Mozilla's singular dependence on Google search and pressure to diversify income streams, it's their firewall in case of emergency. And frankly the simple return on investment from their endowment year to year is one of the strongest non-Google revenue streams at their disposal right now.

If armageddon came and they no longer had their search revenue, they could cover 2 years of their operational costs. Many organizations have endowments that cover them for anywhere from 5 to 20 years. What I understand off the top of my head is that their major spending categories are software development, "operations" which is largely infrastructure to support that development, legal, and marketing.

I could see the case for not spending so much on marketing, but it would be organizational suicide to deficit spend away their endowment, their one firewall against existential threats, on "engineering" without a credible road map to long-term sustainable income that's better than what they're already doing. In fact if you catch the HN comment section on the right say, such behavior would probably be pointed to as yet another example of wasting money on unfocused side bets, because at the end of the day the mob truly can't decide what it wants.

And who knows maybe this "spend it all down on engineering + ??? + profit" plan could work, but that would be extremely risky and would hinge on the details of a plan. But I don't feel like I'm hearing a plan so much as vibes. I would actually turn the tables on this whole entire interpretation and say what they spend relative to their market share, they're actually punching above their weight compared to Google, and that this criticism of "hoarding" is not grounded in financial literacy.

yencabulator

4 hours ago

The whole argument is that Mozilla is using their money incredibly inefficiently, and a good chunk of that is putting money into the pockets of the people managing it.

They claim to be putting $220 M/year into software development, but can't sponsor Servo even at $1 M/year? I call bullshit.

glenstein

3 hours ago

Well I did just give you four paragraphs extensively elaborating on the strategic value of having an endowment, and how strategically fundamental it is to the long-term health, health of any organization and how it's consistent with financial management you see at typical Western non-profit institutions.

I actually think you're right that they should have kept Servo, but that doesn't sustain the charge that is smart to not have an endowment or spend down their endowment for no reason. Most of your questions are financial literacy issues in response to standard non-profit disclosures rather than legitimate critique of strategy.

yencabulator

3 hours ago

Sure, let them hold on to that cool $1B, and live off the interest.

Now, how come they burn $220+ M/year into software development and $0 on Servo?

glenstein

2 hours ago

They're maintaining 32 million lines of code, same as Chrome, on dramatically less resources. So if the question is how they manage to be so much more efficient in terms of ratio of resources invested to production capability (or insert preferred metric, LoC, market share, code line commits, security updates etc), I think it likely comes down to the breakthrough efficiencies of Rust, which they developed.

Rust was the backbone of Quantum, their monumental overhaul and modernization of the Gecko engine. Mozilla is way ahead of competitors in shipping production Rust code. Google is in C++, but taking baby steps toward also implementing Rust in bits and parts but with lots of security containering and interfacing with C++.

yencabulator

2 hours ago

You seem to be describing a project that was abandoned by Mozilla and what resulted in what is today known as Servo.

Firefox contains not-so-much Rust and Servo would have been the road there.

Mozilla is specifically not developing Servo, and thus mostly not getting the benefits you state. (The major exception being Stylo.)

nicoburns

7 hours ago

Worth noting that Mozilla Corporation (which I believe is the entity that has the contract with Google) is a for-profit organisation wholely owned by Mozilla Foundation which is the non-profit.

In theory, it feels like that ought not to change anything regarding the legal situation, but I bet it does.

heavyset_go

3 hours ago

There's some serious Mozilla Derangement Syndrome in online spaces, I see it on Reddit, too. A lot of people seem to want to hold them to standards they hold no other company to, some discontents seem to be driven into a frothing rage by some of CEOs uh.. traits? too.

The_Rob

11 hours ago

Firefox market share is so low, it really seems more like a Chrome and Safari duopoly.

oblio

6 hours ago

It's all Konqueror's fault, really.

kelnos

11 hours ago

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

11 hours ago

The duopoly is Chrome and Safari. Firefox barely registers, especially because all browsers on iOS are Safari.

Also, what's your issue with Firefox?

brson

10 hours ago

Congrats to the servo team. It's been a long road and it's amazing they kept it alive.

butz

9 hours ago

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?

darkwater

11 hours ago

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

9 hours ago

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

9 hours ago

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

9 hours ago

Same, reborn

adaml_623

8 hours ago

I hope they give it a new name with the rebirth. I know it means something to some people but there are a lot of different things with that name

emmelaich

an hour ago

Agree, 'servo' suggests serving whereas this is oriented to being a web client?

alex_duf

7 hours ago

I hope they don't, Servo is a technology

If someone wants to put marketing veneer on top of a new project that uses servo, great! But servo is servo: a rendering engine

wduquette

11 hours ago

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

11 hours ago

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.

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

norman784

10 hours ago

Thanks for you hard work, I already saw taffy being used by other prominent projects like Cosmic desktop environment, bevy, etc

bryanlarsen

11 hours ago

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

11 hours ago

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.

shmerl

3 hours ago

Mozilla can always return to backing the project.

CaptainOfCoit

12 hours ago

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?

nicoburns

11 hours ago

If you don't need JavaScript, then you might be interested in https://github.com/DioxusLabs/blitz.

It pulls in Servo/Firefox's CSS engine Stylo (and Servo's HTML parser html5ever) and pairs it with our own layout engine (which we are implementing mostly as libraries: Taffy [0] for box-level layout and Parley [1] for text/inline layout) and DOM implementation. Rendering and networking are abstracted behind traits (with default implementations available) and you can drive it using your own event loop.

Minimal binary sizes are around 5mb (although more typical build would be more like 10-15mb).

[0]: https://github.com/DioxusLabs/taffy [1]: https://github.com/linebender/parley

enzyme1234

10 hours ago

would this be a good fit for rendering a game UI? showing various stat/dialogue displays, an inventory/equip screen with draggable items, menus, etc. All I really want is html+css to do styling and layout and I'd rather have the interaction logic in the game code than javascript anyway

nicoburns

10 hours ago

I think it would, modulo that it's not really "ready" yet.

We do have a couple of PoC examples of integrating with the Bevy game engine. Both of these use Dioxus Native, which wraps Blitz with Dioxus (which is a React-like framework but in Rust rather than JavaScript - https://github.com/DioxusLabs/dioxus), but you could do DOM tree creation and event handling manually if you wanted to.

- This first one includes Bevy inside a window setup by Dioxus Native (using a `<canvas>` element similar to how you might on the web). Here the event loop is controled by Dioxus Native and the Bevy game is rendered to a texture which is then included in Blitz's scene. https://github.com/DioxusLabs/dioxus/tree/main/examples/10-i...

- This second one does it the other way around and embeds a Dioxus Native document inside a window setup by Bevy. Here the event loop is controlled by Bevy and the Blitz document is rendered to a texture with which Bevy can then do whatever it likes (generally you might just render it on top of the games, but someone tried mapping it into 3d space https://github.com/rectalogic/bevy_blitz) https://github.com/DioxusLabs/dioxus/tree/main/examples/10-i...

The latter is probably what I would recommended for game UI.

Both approaches probably need more work (and Blitz could do with more complete event handling support) before I would consider them "production ready".

fschuett

11 hours ago

You would end up simply with Electron 2.0. I tried de-entangling the Servo CSS / JS / Layout engine some years ago, to see if it would be more lightweight, it wasn't: https://github.com/fschutt/servo_gui_test (62 MB binary size, several hundred MB RAM usage IIRC)

I am currently working on getting https://azul.rs/reftest ready, which uses some of the underlying technologies as Servo (taffy-layout, webrender) but uses no JavaScript and also has a C / Python API. Azul is basically that, except it's not usable yet.

nicoburns

11 hours ago

See my comment (https://news.ycombinator.com/item?id=45644277) about Blitz. Perhaps you might be interested in collaborating :)

Also, we're not using it in Blitz (although it could be added as a backend) but a note that WebRender is maintained. See Servo's most recent 0.68 branch (https://github.com/servo/webrender/tree/0.68) and also ongoing upstream development in the Firefox repository https://github.com/mozilla-firefox/firefox/tree/main/gfx/wr

fschuett

10 hours ago

I know about Dioxus / Blitz, but it's a very, very different project. The only common part is that both Azul and Blitz use taffy for flexbox / grid, but both the technologies, architecture, funding and goals are extremely different:

Blitz:

- Custom renderer (Skia?) vs Azuls WebRender fork (to get rid of any C dependencies)

- Stylo (CSS parser) vs azul-css (to support compilation of CSS to const items)

- HarfRust (font shaping) - vs allsorts (I used allsorts also in printpdf, so it fits)

- Skrifa (font parsing) - vs allsorts again (simplifies things)

- Fontique (font selection) - vs rust-fontconfig (custom pure-Rust rewrite of fontconfig)

- Parley (line breaking) - vs Azuls text3 engine

- All as separate projects vs Azuls monorepo-style

Dioxus:

- RSX macros, data + function coupled together vs Azuls "C function callbacks + HTML dataset" model

- Binary hot-patching vs Azuls dynamic linking model

- Macros vs Azuls HTML/CSS to Rust/C compiler build tool (no macros)

- Funded by YC (not sure about upsell?) vs funded by donations (once it's stable enough) and my Maps4Print cartography startup (dogfooding)

These things matter, even for small decisions. For example, Azul uses a custom CSS parser because the CSSProperty is a C-compatible enum, so that later on you can compile your entire CSS to a const fn and use CSS strings without even doing any allocations. So even on that level, there's a technological-architectural difference between Azul and Stylo.

But the core point is more architecturally: Azuls architecture is built for de-coupling the user data from the function callbacks, because I see this as the Archilles heel that all GUI systems so far have failed at:

https://github.com/fschutt/azul/blob/master/doc/guide/02_App...

Dioxus however repeats this exact same pattern again, and even the Elm architecture doesn't really fix it. I didn't finish the document but basically there is a (1) "hierarchy of DOM elements" and a (2) "graph of UI data" and those two are not always the same - they can overlap, but the core assumption of many GUI toolkits is that (2) is a tree (it's a graph, really) and (2) is always in the same hierarchy as (1), which is why GUI programming is a pain, no matter what language / framework. Electron just makes the visual part easier, but then you still need React to deal with the pain of data model / view sync.

I can collaborate on the flex / grid solver ofc, but it's very hard to collaborate on anything else because the technologies used, the goals, the architecture, etc. are very different between Dioxus / Azul. Azul is more "monorepo-NIH integrated solution" (because I often got bug reports in 2019 that I couldn't fix because I didn't own the underlying crate, so I had to wait for the maintainers to do another release, etc. - I learned from that).

As a note, the layout engine is also now heavily vibe-coded (sorry not sorry), so I don't take credit - but feel free to take inspiration or copy code. Gemini says the solver3 code is a "textbook implementation", take that as you will. My idea was to build a "AI feedback loop" to semi-automatically put the HTML input, the debug messages (to see what code paths are hit), the source code and the final display list into a loop to let the AI auto-debug the layout engine. So that part of writing the HTML engine isn't really hard, assuming the plan works out. The hardest part is caching, scrolling, performance debugging, interactions between different systems, and especially supporting the C API. Layout is comparably simple.

nicoburns

6 hours ago

It's worth noting that:

- You don't have use Dioxus to use Blitz: you can do your own DOM construction and event handling with imperative Rust APIs.

- You don't have use any of the provided renderers to use blitz-dom (although our default renderer is Vello which is also pure Rust), and it would be possible to hook it up to WebRender.

- We have a lot of the tricky incremental layout and caching logic implemented (although there are still bugs).

- Blitz has grant funding through NLnet as well as funding from DioxusLabs, and is fully open source under permissive licenses (MIT/Apache 2.0) that don't really allow for "rug pulling".

---

That being said, the designs around CSS do sound quite different: we have chosen to take on a relatively heavy dependency in Stylo; we don't support non-tree-like structures; and in general, if you wish to do your own thing then that it what you ought to do!

Not sure that I agree that layout is simple (I have spent many long hours debugging the nuances of CSS layout over the past months), and I'm a little skeptical that an AI-based approach will work out. But I wish you luck!

ryukoposting

12 hours ago

I tried it as a little preview window for writing my blog, which is (in my opinion) very basic HTML and CSS. Whole page rendered wrong, though I admit I didn't bother to find out why. Give it a shot, but keep your expectations low.

Imustaskforhelp

11 hours ago

I tried my simple html css website and it kinda worked actually. Even the dark mode/light mode worked but it was also minimalist pure html css website

sebsebmc

11 hours ago

If you have a basic site that doesn't work you can open an issue on the repo. If you have some relatively simple site, its useful for the team to know what features that people are using are broken.

lastontheboat

11 hours ago

Link? I'm a Servo maintainer and I appreciate test cases like that.

timvisee

10 hours ago

I'm seriously impressed on how far this has come. Tried a few websites in the experimental mode, it renders quite well.

amiljkovic

10 hours ago

Does it support kiosk mode or is it configurable to run “locked down” to a single page and full-screen?

CharlesW

9 hours ago

This is an incomplete browser engine, suitable mostly for technical contributors. If you're looking for a solution for kiosks, there are good for-purpose products/projects. Examples include: OpenKiosk, Porteus Kiosk, SiteKiosk.

01HNNWZ0MV43FF

10 hours ago

If servoshell doesn't, Tauri will, the Tauri project seemed open to collaborating with Servo as an alternative to OS-provided WebViews

1vuio0pswjnm7

9 hours ago

Mozilla/5.0 (Android; Mobile; rv:128.0) Servo/0.0.1 Firefox/128.0

nonethewiser

9 hours ago

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.

nicoburns

9 hours ago

To many people involved in browser development there is a distinction between the "browser" (Chrome and Firefox, but also Opera, Brave, Arc that don't develop their own engine) and the "web engine" (Blink, WebKit, Gecko).

Servo is currently more of the latter than the former as it's UI is a pretty minimal one that is mostly useful for testing and doesn't much of the niceties that users expect of a modern browser (bookmarks, history, password manager, etc).

I do agree that it's confusing for most people though.

nonethewiser

9 hours ago

OK, that is a fair distinction I guess. A browser engine would be more clear then, I think. That is what it says in the readme.

Philpax

9 hours ago

Servo is to a browser what Chromium Embedded Framework is to Chromium. It is the vast majority of what is necessary for a browser, but it is not a browser in itself: it renders websites, but all of the user-facing browser functionality around that is a separate concern.

duped

9 hours ago

> Servo is a prototype web browser engine

nonethewiser

9 hours ago

Yes, those words are also in the repo.

robin_reala

11 hours ago

Ah nice, they’re finally generating native ARM Mac binaries.

zwnow

12 hours ago

Is there a remind me bot once a relevant version number releases? Like 1.0 for example

bdcravens

12 hours ago

That might be a while. It's taken 5 years from being transferred to the Linux Foundation to get to 0.0.1.

someplaceguy

10 hours ago

All the more reason for asking the question?

esafak

11 hours ago

They just issued their first release, 0.0.1, after 50,000 commits. I've never seen that before.

kelnos

11 hours ago

Version numbers don't really mean much, especially for a project that was initially supposed to just be a proving ground for new Firefox technologies, some of which are indeed used in Firefox today.

Only more recently has the plan emerged to release a full browser engine based on servo.

samus

11 hours ago

It would be a pleasure to check out the open source web engine you have been a major contributor to :)