> Today, the Servo team has released new versions of the servoshell binaries for all our supported platforms, tagged v0.0.1. These binaries are essentially the same nightly builds that were already available from the download page with additional manual testing, now tagging them explicitly as releases for future reference.
> We plan to publish such a tagged release every month. For now, we are adopting a simple release process where we will use a recent nightly build and perform additional manual testing to identify issues and regressions before tagging and publishing the binaries.
> There are currently no plans to publish these releases on crates.io or platform-specific app stores. The goal is just to publish tagged releases on GitHub.
The release announcement doesn't contain much information, but Servo does publish regular "This month in Servo" updates on their blog which contain lots of details:
I have similar emotions about google.com no longer working in w3m and other no-JS browsers, something that happened this year seemingly to very little fanfare, or whatever the antonym to fanfare is.
(Oh! I wonder if Servo will bring about a new, JS enabled, TUI browser?)
This is something I want to make possible! There was an early experiment in https://github.com/mcclure/cuervo/ which helped identify some ways that our embedding APIs would need to change to support that use case.
yeah very sad, had a tmux shortcut for quickly "googling" things.. However, https://www.startpage.com/ does not complain and supposedly sports the same search index..
For modern sites and if your terminal toolchain does not support sixel, https://github.com/fathyb/carbonyl is a neat hack that gives you a text-rendered blink engine, i.e. supporting all the same sites as those pesky GUI browsers. With sixel/kitty graphics, there was another option which slipped my mind.. [edit: maybe chawan as in sibling comment, but that also is "not supported" by google with the default user agent.]
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.
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.
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.
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.
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.
One nice thing about targeting a web engine is that your application could potentially run in browsers too. Lots of Electron applications do this.
Also you get to take advantage of the massive amount of effort that goes into web engines for accessibility, cross-platform consistency, and performance.
Electron is a memory hog, but actually very powerful and productive. There’s a reason why VSCode, Discord, and many others use it.
But yeah, I wouldn’t say no to a native Rust desktop stack similar to Qt. I know there are options at various levels of sophistication that I’m curious about but haven’t explored in depth.
If it runs in a web browser, why bother Electron if you can just install a standalone web app in Chromium-based browsers (or Firefox with PWA extension)? I do this with Slack, Teams, Discord, Gmail and they use less RAM since they reuse a shared web engine.
Some applications benefit from the host integration. VSCode in particular, since it interacts with the terminal and other applications. I'm also assuming 1Password benefits from it as well for full OS integration.
But then they don't need to be made as Electron apps, but rather native apps, which use a fraction of resources. Compare e.g. Sublime Text or Notepad++ with VS Code.
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.
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.
“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.“
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.
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
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.
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.
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.
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.)
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?
‘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.
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.
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".
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.
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.
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.
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.
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.
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.
> 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.
I don't see the current US DoJ doing anything that harms Big Business and doesn't cater to the petulant whims of the current Presidential Administration.
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.
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.
> 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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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++.
This is not correct. Servo predated Quantum. Quantum was never abandoned, it was completed and integrated into Firefox. Quoting from their page on Quantum:
>Firefox Quantum was a revolution in Firefox development. In 2017, we created a new, lightning fast browser that constantly improves. Firefox Quantum is the Firefox Browser.
Quantum took modernizations that were started as part of Servo but integrated them into Gecko, where they continue to live today. They include Stylo as you noted, but also WebRender, Quantum DOM, Quantum Compositor, Quantum Flow, as well as a host of rust libraries and tooling.
Firefox’s responsiveness, GPU acceleration, and memory-safety improvements are directly attributable to Servo's research being folded in.
So it is in fact getting the benefits I stated. In fact it demonstrates that Servo succeeded after all: the fruits of it were harvested, brought into Firefox and are a key demonstration of Mozilla punching above its weight with smart investments allowing them to be more efficient than Google.
Edit: The reply below is largely unresponsive, not acknowledging factual inaccuracies, and repeating points that have already been addressed. As I already explained, Firefox benefits from Servo to this day. The end of its support is regrettable but not a scandal nor even a demonstration of inefficient use of resources. Its benefits were rolled into the core browser which is maintained at a fraction of the cost of its competition.
There was a time when Mozilla worked on what is being now pushed forward under the Servo umbrella. 2017 was 8 years ago. Then in 2020 Mozilla laid off 250 employees, including pretty much all of the developers of Servo/Quantum and their security team.
And now Mozilla is sitting on that cool $1.3 B, burning $220-500 M/year on "software development" without telling anyone what it actually is doing with that money, and putting $0 into Servo.
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.
Why is it that the Mozilla Foundation was set up in such a way that it cannot fund the core browser development activity? Other foundations do fund software development for their respective projects, e.g. the FreeBSD Foundation [1] and the Python Software Foundation [2].
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.
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.
Saying "Mozilla doesn’t itemize expenses" is like saying a university's annual financial report is hiding cafeteria costs because it doesn’t list fruit cups separately.
Large nonprofits publish consolidated, high-level statements that group expenses by broad function, not by department or line item because that's the correct level of financial reporting for external audiences.
If they misrepresented their spending that would be flagged by the independent auditor. It's deeply responsible to accuse them of hiding something when you have no baseline concept of standard disclosures.
>we'd actually benefit more from refocusing it into software (like it used to be).
Firefox was spending $40MM on software and development in 2009. Adjusted for inflation that would be ~ $60MM today. They're spending upwards of $262MM today. So they're spending more than quadruple what they used, to directly on software + development.
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.
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.
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.
I think a lot of the people who remember Phoenix and were part of the push to install Firefox and unseat IE are very sour about what the Mozilla Corporation is currently doing.
>about what the Mozilla Corporation is currently doing.
I don't know if you ever saw the movie Dark City, but one aspect of the plot was that everyone thought they knew the way to Shell Beach, but could never actually tell you how to get there if you asked [0]:
>Murdoch learns that he came from a coastal town called Shell Beach, which everyone knows, though no one remembers how to get there and Murdoch's attempts to visit fail.
And, look at this thread! 90% of the time it's young adults with no financial literacy misinterpreting non-profit filings.
Which, again, it's not to say there's no issues. Adtech is bad. CEO pay is bad-ish. But most of the time the best anyone can manage is sweet nothings like "you know... all the... stuff they're doing!" It's filed away in the Shell Beach part of their brains.
I feel like I just want to keep a running list of the most egregious criticisms, or alternatively write an article along the lines of "Mozilla Criticisms, Ranked by Sanity".
Some are fair! But many aren't. But it may help temper MDS to put it all in one place.
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.)
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?
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?
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).
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
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".
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.
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:
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.
- 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!
Coming from someone who mainly does Vanilla JS, CSS, HTML (no frameworks) for their apps, your API looks very approachable. I like that you have Python bindings too. (Only thing better would be to take JavaScript, HTML and CSS.) I'll have to try it out sometime.
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.
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.
I've been testing web software that I work on with Servo and Ladybird. I'm pretty impressed!
Servo has some areas where it performs very well, though support for things like CSS Grid are still experimental and off by default (but working pretty well), and it's missing a few important APIs still. (I haven't checked in a while but last I looked it was missing AbortController. That's pretty unfortunate and probably breaks a lot of random stuff across the web.
I think Ladybird in Nixpkgs still doesn't have fully working hardware acceleration, so I'm probably not seeing the full smoothness Ladybird can offer in an optimal setup. Still! It runs pretty well, and it supports a vast majority of the web platform. Right now for my own development, the only major two omissions I've noticed are Origin Private File System, which is pretty new, and OffscreenCanvas, which actually is "implemented" but only as a stub. Throwing Web Workers and heavy WebAssembly workloads at Ladybird seems like no problem at all, and it renders a very reasonable subset of modern CSS almost perfectly.
(Tangent: Ladybird Web Workers are actually separate processes, which is kind of funny. If one runs out of control, you can literally SIGKILL it. The browser copes with this seemingly fine!)
Unfortunately, a lot of the web uses libraries and frameworks that are happy to eagerly adopt web standards and technologies that are not supported by browsers from a year or two ago. While I realize a lot of these standards were created specifically to solve problems that real developers have, I've been unimpressed watching this play out. Often new technologies increase complexity to solve relatively minor already-manageable issues with the web platform, and I feel like it is counterproductive to fatten up the web platform just for that. I mean really. There eventually has to be a point where we all agree that there is simply too much CSS technology and there is little justification to add more, but yet it just continues to grow uncontrollably. (I'm not saying it's all bad, though. Personally, I think the text-wrap additions were actually pretty nice things that really do need to be part of the layout engine.)
I'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.
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.
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!
A Cloudflare turnstile caused Servo to crash during my testing, just like with Pale Moon earlier this year. They are becoming the new gatekeepers of the Web.
>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.
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.
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.
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.
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.
I shipped my first commercial website in 2001. I have PTSD from times when you had to basically do at least twice the work to ensure that your page worked - not just looked, but worked - on multiple browsers over multiple systems.
I recall a postmortem from a project of a major telecom website which took its pride in being accessible "everywhere". They had a matrix of systems and browsers, like 10x10, and they described how painful it was to check all the boxes.
I remember a tiny JS library I wrote at Wikia in 2006 for deep linking. It started with ~10 lines implementing documentation. But by the time I had all major browsers covered it grew to 500 lines.
I also have very fond memories of Flash. Apart from resolution - when I had my project working on my machine I had 100% certainty that it would work exactly the same on every client. Including mobile, kiosks, and desktop deployments.
Times were different, BigCos lived in siloes, ES4 went to shit and we needed another 15 years to reinvent the wheel with TS, but today everyone seems to be on the same team and browsers are shockingly compatible.
We don't. But we could use a memory safe one, so that a random website can't steal your credit card info. Unfortunately Servo is the only one that's actively developed and is written in a memory safe language; the rest are all C++.
Because its probably not a good idea to have one company essentially control the internet through their browser. Firefox is practically irrelevant and Safari only matters if you're on an Apple device.
what do you mean "control the internet"? Microsoft for all intents and purposes controls all documents across the globe with their Office suite and it doesn't mean you can't write "hitler" in your document. I mean, c'mon.
That analog doesn't fit at all. The internet is public infrastructure, akin to roads or utilities. Not just document writing software.
Your web browser is your primary gateway to the Internet, which is a fundamental part of our daily lives now With Google dominating the vast majority of the market (not just through Chrome but also Chromium) they dictate the mechanisms used to access it.
Google Chrome is already the defacto standard. Web developers design sites with it in mind first, everything else is an after thought. If Chrome decides to implement a feature that impacts user access or website design, everyone just has to go along with it.
Look at the "Web Integrity API" fiasco from a while back. Google was basically proposing that websites be able to block access if they don't like something about the clients environment. That is entirely antithetical to a free and open Internet, and had they decided to move forward with it the rest of the web community would have had no choice but to go along.
because otherwise google will control the web standards via chrome implementation. Whatever pains you deal with cross-browser compatibility, it's nothing like the pain of web development when IE was dominant. Like the IE era, we are heading towards an environment where whatever google says, goes.
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.
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?
I think it's also that they finally got Mac/Arm releases sorted, so now they have the full platform support matrix for nightlies?
That's roughly correct. The other side of this is figuring out a release process and thinking about versioning.
I think the motivation is Ladybird [1] coming on the scene with lots of awareness and sponsorship
[1] https://ladybird.org/#about
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.
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
I have similar emotions about google.com no longer working in w3m and other no-JS browsers, something that happened this year seemingly to very little fanfare, or whatever the antonym to fanfare is.
(Oh! I wonder if Servo will bring about a new, JS enabled, TUI browser?)
This is something I want to make possible! There was an early experiment in https://github.com/mcclure/cuervo/ which helped identify some ways that our embedding APIs would need to change to support that use case.
yeah very sad, had a tmux shortcut for quickly "googling" things.. However, https://www.startpage.com/ does not complain and supposedly sports the same search index..
For modern sites and if your terminal toolchain does not support sixel, https://github.com/fathyb/carbonyl is a neat hack that gives you a text-rendered blink engine, i.e. supporting all the same sites as those pesky GUI browsers. With sixel/kitty graphics, there was another option which slipped my mind.. [edit: maybe chawan as in sibling comment, but that also is "not supported" by google with the default user agent.]
As for modern TUI browsers, there are already: Chawan, Browsh, Carbonyl.
I wish I had a RSS reader to feed this to...
Miniflux is pretty good and easy to self-host:
https://github.com/miniflux/v2
https://miniflux.app/docs/docker.html
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.
> as the domain suggests
It suggests a couple of things...
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.
If you're on iOS/MacOS, try https://netnewswire.com. Old-school high-quality free macOS app.
I'm happy with FreshRSS
Servo also publishes weekly reports on Mastodon: https://floss.social/@servo
Tried it out on Linux. Worked better than I expected. Sites that are text heavy render well, and quickly. Sites with more "customization" sometimes struggled with rendering; stuff all over the place. Memory usage seemed a bit higher than Firefox with the same tabs, but not out of this world higher.
All in all, an impressive release.
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.
But then we have the same complaint against Electron, namely large deployment sizes and no shared memory, no?
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.
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?
For rust desktop apps, why target a web engine, when we have much more lightweight native GUI frameworks? We don't need yet another bloated Electron.
One nice thing about targeting a web engine is that your application could potentially run in browsers too. Lots of Electron applications do this.
Also you get to take advantage of the massive amount of effort that goes into web engines for accessibility, cross-platform consistency, and performance.
Electron is a memory hog, but actually very powerful and productive. There’s a reason why VSCode, Discord, and many others use it.
But yeah, I wouldn’t say no to a native Rust desktop stack similar to Qt. I know there are options at various levels of sophistication that I’m curious about but haven’t explored in depth.
If it runs in a web browser, why bother Electron if you can just install a standalone web app in Chromium-based browsers (or Firefox with PWA extension)? I do this with Slack, Teams, Discord, Gmail and they use less RAM since they reuse a shared web engine.
Some applications benefit from the host integration. VSCode in particular, since it interacts with the terminal and other applications. I'm also assuming 1Password benefits from it as well for full OS integration.
But then they don't need to be made as Electron apps, but rather native apps, which use a fraction of resources. Compare e.g. Sublime Text or Notepad++ with VS Code.
Whether it's something like this, or ladybird's engine, I'm happy there is work being made in this space.
+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.
> 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.
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.
“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...
> 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.
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
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.
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.
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.
Meanwhile Lua is under 200kb. Imagine if you could use it as a browser language, no more bloat and churn.
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.
It's not minimum. Custom WebKit builds could weight less, depending on features. Also Sciter is more lightweight.
Is some kind of a browser microkernel possible? Could you ship, say, JS Canvas support in a separate optional module?
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.)
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.
> binary is 100MB+ on Mac
If you're worrying about that size then Mac OS is not the platform for you.
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.
Chrome is still bigger than Servo. For a really small size, go for Sciter, Netsurf or Dillo.
I’m more hopeful about Servo because it’s released under a copyleft licence, whereas Ladybird chose a pushover one.
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?
‘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.
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.
> 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.
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".
They are planning to use swift in the future. Last point: https://ladybird.org/#faq
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.
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.
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.
> 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.
I've compared Servo with Ladybird and the latter uses 3x more RAM for the same website: https://fosstodon.org/@niutech/114139305720083599
So Servo is more lightweight than Ladybird.
Aren't Chromium and Blink basically the same thing? And Gecko isn't embeddable.
> And Gecko isn't embeddable.
This is "In Review"[1], whatever that means.
[1] https://connect.mozilla.org/t5/ideas/ability-to-embed-gecko-...
Mozilla has been working on embedding Gecko since 2005. In practical terms, it can't be done.
I'd be glad to be proven wrong.
There are: GeckoView and Gecko Embedded, so it's doable.
Blink is the backing engine of Chromium.
And therefore Chromium isn't a browser engine and shouldn't be listed there.
Agreed. Servo is emphatically not anything resembling a priority at Mozilla and hasn't been for a long while.
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.
Servo is not part of Mozilla any more.
I am sooo ready to ditch chrome and firefox duopoly
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.
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.
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.
> 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.
I don't see the current US DoJ doing anything that harms Big Business and doesn't cater to the petulant whims of the current Presidential Administration.
Plenty of the petulant whims of the current Presidential Administration are harmful to big business.
Safari leads in many, many ways and is a fantastic browser. No one’s updated their priors from 5 years ago unfortunately.
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.
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!
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.
> 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.
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.
They're announced they want to move to Swift to combat some of this.
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.
They chose c++ because the web spec implies object oriented design.
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...
That was the answer I remember Andreas give in a update video to answer the "why not rust" question.
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.
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.
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.
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.
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...
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.
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.
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.
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?
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++.
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.)
This is not correct. Servo predated Quantum. Quantum was never abandoned, it was completed and integrated into Firefox. Quoting from their page on Quantum:
https://www.mozilla.org/en-US/firefox/browsers/quantum/
>Firefox Quantum was a revolution in Firefox development. In 2017, we created a new, lightning fast browser that constantly improves. Firefox Quantum is the Firefox Browser.
Quantum took modernizations that were started as part of Servo but integrated them into Gecko, where they continue to live today. They include Stylo as you noted, but also WebRender, Quantum DOM, Quantum Compositor, Quantum Flow, as well as a host of rust libraries and tooling.
Firefox’s responsiveness, GPU acceleration, and memory-safety improvements are directly attributable to Servo's research being folded in.
So it is in fact getting the benefits I stated. In fact it demonstrates that Servo succeeded after all: the fruits of it were harvested, brought into Firefox and are a key demonstration of Mozilla punching above its weight with smart investments allowing them to be more efficient than Google.
Edit: The reply below is largely unresponsive, not acknowledging factual inaccuracies, and repeating points that have already been addressed. As I already explained, Firefox benefits from Servo to this day. The end of its support is regrettable but not a scandal nor even a demonstration of inefficient use of resources. Its benefits were rolled into the core browser which is maintained at a fraction of the cost of its competition.
There was a time when Mozilla worked on what is being now pushed forward under the Servo umbrella. 2017 was 8 years ago. Then in 2020 Mozilla laid off 250 employees, including pretty much all of the developers of Servo/Quantum and their security team.
And now Mozilla is sitting on that cool $1.3 B, burning $220-500 M/year on "software development" without telling anyone what it actually is doing with that money, and putting $0 into Servo.
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.
Why is it that the Mozilla Foundation was set up in such a way that it cannot fund the core browser development activity? Other foundations do fund software development for their respective projects, e.g. the FreeBSD Foundation [1] and the Python Software Foundation [2].
[1] https://freebsdfoundation.org/about-us/about-the-foundation/
[2] https://www.python.org/psf/developersinresidence/
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.
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.
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
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.
It's really telling that Mozilla does not want to itemize those costs to say how little the actually use on Firefox.
Saying "Mozilla doesn’t itemize expenses" is like saying a university's annual financial report is hiding cafeteria costs because it doesn’t list fruit cups separately.
Large nonprofits publish consolidated, high-level statements that group expenses by broad function, not by department or line item because that's the correct level of financial reporting for external audiences.
If they misrepresented their spending that would be flagged by the independent auditor. It's deeply responsible to accuse them of hiding something when you have no baseline concept of standard disclosures.
They're not hiding anything they're legally required to disclose, but that's a very low bar.
>we'd actually benefit more from refocusing it into software (like it used to be).
Firefox was spending $40MM on software and development in 2009. Adjusted for inflation that would be ~ $60MM today. They're spending upwards of $262MM today. So they're spending more than quadruple what they used, to directly on software + development.
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.
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.
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.
I think a lot of the people who remember Phoenix and were part of the push to install Firefox and unseat IE are very sour about what the Mozilla Corporation is currently doing.
That and the whole Eich debacle.
>about what the Mozilla Corporation is currently doing.
I don't know if you ever saw the movie Dark City, but one aspect of the plot was that everyone thought they knew the way to Shell Beach, but could never actually tell you how to get there if you asked [0]:
>Murdoch learns that he came from a coastal town called Shell Beach, which everyone knows, though no one remembers how to get there and Murdoch's attempts to visit fail.
And, look at this thread! 90% of the time it's young adults with no financial literacy misinterpreting non-profit filings.
Which, again, it's not to say there's no issues. Adtech is bad. CEO pay is bad-ish. But most of the time the best anyone can manage is sweet nothings like "you know... all the... stuff they're doing!" It's filed away in the Shell Beach part of their brains.
0. https://en.wikipedia.org/wiki/Dark_City_(1998_film)
I feel like I just want to keep a running list of the most egregious criticisms, or alternatively write an article along the lines of "Mozilla Criticisms, Ranked by Sanity".
Some are fair! But many aren't. But it may help temper MDS to put it all in one place.
I'd do it myself, but I don't want to put a target on my back that will attract the internet's most tedious pedants.
Firefox market share is so low, it really seems more like a Chrome and Safari duopoly.
It's all Konqueror's fault, really.
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.)
The duopoly is Chrome and Safari. Firefox barely registers, especially because all browsers on iOS are Safari.
Also, what's your issue with Firefox?
It's not duopoly, there is also WebKit, e.g. in Epiphany Browser.
[dead]
A few hours ago, just a few comments: https://news.ycombinator.com/item?id=45642051
If you email the mods they’ll merge the duplicate discussions. Footer contact link.
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?
Related: https://github.com/servo/servo/issues/21817
You should likely join https://servo.zulipchat.com and ask questions to know where to start.
Congrats to the servo team. It's been a long road and it's amazing they kept it alive.
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?
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
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
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".
Igalia (who are heading Servo nowadays), say:
> Embedding Servo into applications requires a stable and complete WebView API. While early work exists, it’s not yet ready for general use.
(While announcing that they got funded to fix that.)
https://www.igalia.com/2025/10/09/Igalia,-Servo,-and-the-Sov...
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.
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
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.
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!
Coming from someone who mainly does Vanilla JS, CSS, HTML (no frameworks) for their apps, your API looks very approachable. I like that you have Python bindings too. (Only thing better would be to take JavaScript, HTML and CSS.) I'll have to try it out sometime.
Thanks, it's not really ready yet though, the screenshots were from 2019.
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.
I found your blog and this behaviour is extremely mysterious! Thanks for pointing this out, I've got a new puzzle to dig into now.
Edit: https://github.com/servo/servo/issues/40047
Shoot, am I forgetting to send Content-Type on stylesheets? Wow, uh, oops.
I guess I'll leave it that way for now, in hopes that a production example is useful?
Link? I'm a Servo maintainer and I appreciate test cases like that.
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
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.
I've been testing web software that I work on with Servo and Ladybird. I'm pretty impressed!
Servo has some areas where it performs very well, though support for things like CSS Grid are still experimental and off by default (but working pretty well), and it's missing a few important APIs still. (I haven't checked in a while but last I looked it was missing AbortController. That's pretty unfortunate and probably breaks a lot of random stuff across the web.
I think Ladybird in Nixpkgs still doesn't have fully working hardware acceleration, so I'm probably not seeing the full smoothness Ladybird can offer in an optimal setup. Still! It runs pretty well, and it supports a vast majority of the web platform. Right now for my own development, the only major two omissions I've noticed are Origin Private File System, which is pretty new, and OffscreenCanvas, which actually is "implemented" but only as a stub. Throwing Web Workers and heavy WebAssembly workloads at Ladybird seems like no problem at all, and it renders a very reasonable subset of modern CSS almost perfectly.
(Tangent: Ladybird Web Workers are actually separate processes, which is kind of funny. If one runs out of control, you can literally SIGKILL it. The browser copes with this seemingly fine!)
Unfortunately, a lot of the web uses libraries and frameworks that are happy to eagerly adopt web standards and technologies that are not supported by browsers from a year or two ago. While I realize a lot of these standards were created specifically to solve problems that real developers have, I've been unimpressed watching this play out. Often new technologies increase complexity to solve relatively minor already-manageable issues with the web platform, and I feel like it is counterproductive to fatten up the web platform just for that. I mean really. There eventually has to be a point where we all agree that there is simply too much CSS technology and there is little justification to add more, but yet it just continues to grow uncontrollably. (I'm not saying it's all bad, though. Personally, I think the text-wrap additions were actually pretty nice things that really do need to be part of the layout engine.)
Ladybird is a memory hog compared to Servo: https://fosstodon.org/@niutech/114139305720083599
I'm seriously impressed on how far this has come. Tried a few websites in the experimental mode, it renders quite well.
I'm so going to try this, and I hope it will end up as when I tried and used Phoenix, and then Firebird.
I'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.
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
Thanks for you hard work, I already saw taffy being used by other prominent projects like Cosmic desktop environment, bevy, etc
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!
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.
Mozilla can always return to backing the project.
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?
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.
Same, reborn
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
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
I think there's a Verso project which uses it. Named servo in reverse.
Agree, 'servo' suggests serving whereas this is oriented to being a web client?
A Cloudflare turnstile caused Servo to crash during my testing, just like with Pale Moon earlier this year. They are becoming the new gatekeepers of the Web.
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.
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.
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.
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.
> Servo is a prototype web browser engine
Yes, those words are also in the repo.
Wow ive never seen such a low version number
Ah nice, they’re finally generating native ARM Mac binaries.
It actually renders way more than it did a couple months ago. Very good progress!
Does it support kiosk mode or is it configurable to run “locked down” to a single page and full-screen?
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.
If servoshell doesn't, Tauri will, the Tauri project seemed open to collaborating with Servo as an alternative to OS-provided WebViews
Mozilla/5.0 (Android; Mobile; rv:128.0) Servo/0.0.1 Firefox/128.0
Is there a remind me bot once a relevant version number releases? Like 1.0 for example
Adding context on a tangent
"The Missing Protocol: Let Me Know" https://news.ycombinator.com/item?id=44881287
Such a thing could be implemented with RSS on a long scale or ntfy.sh on a short scale, but afaik most projects don't.
That might be a while. It's taken 5 years from being transferred to the Linux Foundation to get to 0.0.1.
All the more reason for asking the question?
They just issued their first release, 0.0.1, after 50,000 commits. I've never seen that before.
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.
It would be a pleasure to check out the open source web engine you have been a major contributor to :)
ELI5 why we need more engines?
I shipped my first commercial website in 2001. I have PTSD from times when you had to basically do at least twice the work to ensure that your page worked - not just looked, but worked - on multiple browsers over multiple systems.
I recall a postmortem from a project of a major telecom website which took its pride in being accessible "everywhere". They had a matrix of systems and browsers, like 10x10, and they described how painful it was to check all the boxes.
I remember a tiny JS library I wrote at Wikia in 2006 for deep linking. It started with ~10 lines implementing documentation. But by the time I had all major browsers covered it grew to 500 lines.
I also have very fond memories of Flash. Apart from resolution - when I had my project working on my machine I had 100% certainty that it would work exactly the same on every client. Including mobile, kiosks, and desktop deployments.
Times were different, BigCos lived in siloes, ES4 went to shit and we needed another 15 years to reinvent the wheel with TS, but today everyone seems to be on the same team and browsers are shockingly compatible.
> ELI5 why we need more engines?
We don't. But we could use a memory safe one, so that a random website can't steal your credit card info. Unfortunately Servo is the only one that's actively developed and is written in a memory safe language; the rest are all C++.
SQLite is C, do you think we need Rust reimplementation?
Eventually? Yes.
Because its probably not a good idea to have one company essentially control the internet through their browser. Firefox is practically irrelevant and Safari only matters if you're on an Apple device.
what do you mean "control the internet"? Microsoft for all intents and purposes controls all documents across the globe with their Office suite and it doesn't mean you can't write "hitler" in your document. I mean, c'mon.
That analog doesn't fit at all. The internet is public infrastructure, akin to roads or utilities. Not just document writing software.
Your web browser is your primary gateway to the Internet, which is a fundamental part of our daily lives now With Google dominating the vast majority of the market (not just through Chrome but also Chromium) they dictate the mechanisms used to access it.
Google Chrome is already the defacto standard. Web developers design sites with it in mind first, everything else is an after thought. If Chrome decides to implement a feature that impacts user access or website design, everyone just has to go along with it.
Look at the "Web Integrity API" fiasco from a while back. Google was basically proposing that websites be able to block access if they don't like something about the clients environment. That is entirely antithetical to a free and open Internet, and had they decided to move forward with it the rest of the web community would have had no choice but to go along.
Sure that is fine with Microsoft. Now imagine you are ICC judge using Microsoft service.
because otherwise google will control the web standards via chrome implementation. Whatever pains you deal with cross-browser compatibility, it's nothing like the pain of web development when IE was dominant. Like the IE era, we are heading towards an environment where whatever google says, goes.
WDYM "pain when IE was dominant"?
It was anything but. For a decade macromedia had monopoly on web standards with their player and it was marvelous.
Can you imagine a simple straight implementation and knowing it will work across all of your clients today?
flash was total aids
and so was your comment ¯\_(ヅ)_/¯