[HN Gopher] Servo v0.0.1
___________________________________________________________________
Servo v0.0.1
Author : undeveloper
Score : 441 points
Date : 2025-10-20 12:55 UTC (10 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| adzm wrote:
| From the blog at
| https://servo.org/blog/2025/10/20/servo-0.0.1-release/
|
| > Today, the Servo team has released new versions of the
| servoshell binaries for all our supported platforms, tagged
| v0.0.1. These binaries are essentially the same nightly builds
| that were already available from the download page with
| additional manual testing, now tagging them explicitly as
| releases for future reference.
|
| > We plan to publish such a tagged release every month. For now,
| we are adopting a simple release process where we will use a
| recent nightly build and perform additional manual testing to
| identify issues and regressions before tagging and publishing the
| binaries.
|
| > There are currently no plans to publish these releases on
| crates.io or platform-specific app stores. The goal is just to
| publish tagged releases on GitHub.
| bastawhiz wrote:
| 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?
| sebsebmc wrote:
| That's roughly correct. The other side of this is figuring
| out a release process and thinking about versioning.
| swiftcoder wrote:
| I think it's also that they finally got Mac/Arm releases
| sorted, so now they have the full platform support matrix for
| nightlies?
| zwnow wrote:
| Is there a remind me bot once a relevant version number releases?
| Like 1.0 for example
| bdcravens wrote:
| That might be a while. It's taken 5 years from being
| transferred to the Linux Foundation to get to 0.0.1.
| someplaceguy wrote:
| All the more reason for asking the question?
| 01HNNWZ0MV43FF wrote:
| 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.
| nicoburns wrote:
| The release announcement doesn't contain much information, but
| Servo does publish regular "This month in Servo" updates on their
| blog which contain lots of details:
|
| - Blog: https://servo.org/blog/
|
| - Most recent TMIS post https://servo.org/blog/2025/09/25/this-
| month-in-servo/
|
| Check them out if you're interested in what's going on with
| Servo.
| Y_Y wrote:
| When Google Reader died, so did a large part of me, and the
| web.
|
| That said, I'm recently back on RSS and this is another good
| feed:
|
| https://servo.org/blog/feed.xml
| srott wrote:
| I wish I had a RSS reader to feed this to...
| skyfaller wrote:
| One of my favorite RSS readers is https://vore.website -
| river of news, no unread indicators, simple. It's a
| website, as the domain suggests, so no need to install
| anything.
| zymhan wrote:
| > as the domain suggests
|
| It suggests a couple of things...
| Millennium wrote:
| 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.
| heavyset_go wrote:
| I'm happy with FreshRSS
| CaptainOfCoit wrote:
| 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?
| ryukoposting wrote:
| 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.
| lastontheboat wrote:
| Link? I'm a Servo maintainer and I appreciate test cases like
| that.
| Imustaskforhelp wrote:
| I tried my simple html css website and it kinda worked
| actually. Even the dark mode/light mode worked but it was
| also minimalist pure html css website
| sebsebmc wrote:
| 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.
| fschuett wrote:
| You would end up simply with Electron 2.0. I tried de-
| entangling the Servo CSS / JS / Layout engine some years ago,
| to see if it would be more lightweight, it wasn't:
| https://github.com/fschutt/servo_gui_test (62 MB binary size,
| several hundred MB RAM usage IIRC)
|
| I am currently working on getting https://azul.rs/reftest
| ready, which uses some of the underlying technologies as Servo
| (taffy-layout, webrender) but uses no JavaScript and also has a
| C / Python API. Azul is basically that, except it's not usable
| yet.
| nicoburns wrote:
| See my comment
| (https://news.ycombinator.com/item?id=45644277) about Blitz.
| Perhaps you might be interested in collaborating :)
|
| Also, we're not using it in Blitz (although it could be added
| as a backend) but a note that WebRender is maintained. See
| Servo's most recent 0.68 branch
| (https://github.com/servo/webrender/tree/0.68) and also
| ongoing upstream development in the Firefox repository
| https://github.com/mozilla-firefox/firefox/tree/main/gfx/wr
| fschuett wrote:
| 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_Ap
| p...
|
| Dioxus however repeats this exact same pattern again, and
| even the Elm architecture doesn't really fix it. I didn't
| finish the document but basically there is a (1) "hierarchy
| of DOM elements" and a (2) "graph of UI data" and those two
| are not always the same - they can overlap, but the core
| assumption of many GUI toolkits is that (2) is a tree (it's
| a graph, really) and (2) is always in the same hierarchy as
| (1), which is why GUI programming is a pain, no matter what
| language / framework. Electron just makes the visual part
| easier, but then you still need React to deal with the pain
| of data model / view sync.
|
| I can collaborate on the flex / grid solver ofc, but it's
| very hard to collaborate on anything else because the
| technologies used, the goals, the architecture, etc. are
| very different between Dioxus / Azul. Azul is more
| "monorepo-NIH integrated solution" (because I often got bug
| reports in 2019 that I couldn't fix because I didn't own
| the underlying crate, so I had to wait for the maintainers
| to do another release, etc. - I learned from that).
|
| As a note, the layout engine is also now heavily vibe-coded
| (sorry not sorry), so I don't take credit - but feel free
| to take inspiration or copy code. Gemini says the solver3
| code is a "textbook implementation", take that as you will.
| My idea was to build a "AI feedback loop" to semi-
| automatically put the HTML input, the debug messages (to
| see what code paths are hit), the source code and the final
| display list into a loop to let the AI auto-debug the
| layout engine. So that part of writing the HTML engine
| isn't really hard, assuming the plan works out. The hardest
| part is caching, scrolling, performance debugging,
| interactions between different systems, and especially
| supporting the C API. Layout is comparably simple.
| nicoburns wrote:
| 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!
| nicoburns wrote:
| If you don't need JavaScript, then you might be interested in
| https://github.com/DioxusLabs/blitz.
|
| It pulls in Servo/Firefox's CSS engine Stylo (and Servo's HTML
| parser html5ever) and pairs it with our own layout engine
| (which we are implementing mostly as libraries: Taffy [0] for
| box-level layout and Parley [1] for text/inline layout) and DOM
| implementation. Rendering and networking are abstracted behind
| traits (with default implementations available) and you can
| drive it using your own event loop.
|
| Minimal binary sizes are around 5mb (although more typical
| build would be more like 10-15mb).
|
| [0]: https://github.com/DioxusLabs/taffy [1]:
| https://github.com/linebender/parley
| enzyme1234 wrote:
| would this be a good fit for rendering a game UI? showing
| various stat/dialogue displays, an inventory/equip screen
| with draggable items, menus, etc. All I really want is
| html+css to do styling and layout and I'd rather have the
| interaction logic in the game code than javascript anyway
| nicoburns wrote:
| 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://git
| hub.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".
| Vinnl wrote:
| 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...
| natemcintosh wrote:
| Tried it out on Linux. Worked better than I expected. Sites that
| are text heavy render well, and quickly. Sites with more
| "customization" sometimes struggled with rendering; stuff all
| over the place. Memory usage seemed a bit higher than Firefox
| with the same tabs, but not out of this world higher.
|
| All in all, an impressive release.
| brokencode wrote:
| It's still a ways off, but I'm excited for the possibility of
| something like Tauri using Servo natively instead of needing
| host browsers. A pure Rust desktop app stack with only a single
| browser to target sounds fantastic.
| qzw wrote:
| But then we have the same complaint against Electron, namely
| large deployment sizes and no shared memory, no?
| Octoth0rpe wrote:
| this part is important: > A pure Rust desktop app stack
|
| I think the parent is imagining a desktop with servo
| available as a standard lib, in which case you're left with
| the same complaints as Tauri, not electron; that the system
| version of Servo might be out of date.
| brokencode wrote:
| 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?
| Aissen wrote:
| A few hours ago, just a few comments:
| https://news.ycombinator.com/item?id=45642051
| altairprime wrote:
| If you email the mods they'll merge the duplicate discussions.
| Footer contact link.
| clot27 wrote:
| I am sooo ready to ditch chrome and firefox duopoly
| lambdaone wrote:
| 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.
| whizzter wrote:
| 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.
| throwaway48476 wrote:
| They chose c++ because the web spec implies object oriented
| design.
| IshKebab wrote:
| 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%20languag
| e%2...
| throwaway48476 wrote:
| That was the answer I remember Andreas give in a update
| video to answer the "why not rust" question.
| IshKebab wrote:
| That doesn't really make sense to me either. Even if
| WebIDL is inheritance based, that is going to be
| processed automatically so you can easily use codegen to
| make the resulting interface nice in Rust, in a way that
| would be relatively difficult if you were hand-writing
| it.
| lawn wrote:
| They're announced they want to move to Swift to combat some
| of this.
| whizzter wrote:
| 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.
| tredre3 wrote:
| Their choice is actually Swift and by the time there's a
| stable release all the C++ code is intended to have been
| replaced.
|
| Time will tell if _that_ will be a big problem or if more
| mainstream ways of doing things are better for a project
| intended to run everywhere!
| norman784 wrote:
| I remember they mentioning Swift a few months ago, but
| currently I don't see any swift in their github repo,
| didn't checked other branches besides main.
| hypeatei wrote:
| > all the C++ code is intended to have been replaced.
|
| That is not their goal at all, I don't where you heard
| that. Swift is currently stalled due to some blockers
| listed on their issue tracker, but any usage of it will
| be in safety-critical areas first and not a complete
| rewrite of existing code.
| glenstein wrote:
| 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.
| bastawhiz wrote:
| Don't forget that pretty much 100% of iOS users and a
| nontrivial percentage of Mac users are on Webkit/Safari.
| That's not to say Safari is really leading the pack on
| anything at all, but Google also hasn't led Apple by the nose
| on pretty much anything on the web in recent years.
| jorvi wrote:
| Yup, the split is really Blink+WebKit. Gecko marketshare is
| tiny these days.
|
| What's interesting is seeing a few non-Apple WebKit
| browsers pop up, like Orion (Kagi) and Epiphany.
|
| Call me cynical, but I don't see Ladybird or Servo do much
| beyond making a splash. Browser engines take an incredible
| amount of dev hours to maintain. Ladybird is hot now, but
| what about in a decade? Hype doesn't last that long and at
| that point the money and a chunk of the dev interest will
| have dried up.
|
| Blink and WebKit both have massive corporations championing
| them, so those engines do not run that risk.
| nicoburns wrote:
| > 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.
| The_Rob wrote:
| Firefox market share is so low, it really seems more like a
| Chrome and Safari duopoly.
| oblio wrote:
| It's all Konqueror's fault, really.
| smt88 wrote:
| The duopoly is Chrome and Safari. Firefox barely registers,
| especially because all browsers on iOS are Safari.
|
| Also, what's your issue with Firefox?
| kelnos wrote:
| 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.)
| glenstein wrote:
| I've seen a lot of criticism of Mozilla in these parts, some
| more fair than others. (Adtech = bad, regardless of whether you
| call it privacy preserving. CEO pay, not as bad as people say
| but don't love it.) But the notion that a trillion dollar
| platform company dictating web standards and Firefox are two
| sides of the same coin is, by my lights, the singularly most
| spectacular failure of comprehension that's been wrought by
| this era of Mozilla skepticism. It's not exactly a big lie
| because the people saying it seem to sincerely believe it but
| it's comparably disastrous as a test of information literacy.
| tracker1 wrote:
| Mozilla was sitting on a chest of cash that could have funded
| engineering efforts for decades. Instead they decided to
| inflate managers and marketers in an effort to expand
| market/mindshare and follow that with needs for ever
| increasing funding drives to fund lavish parties and events
| on the marketing side, while shuttering engineering efforts
| and even laying off swaths of engineering talent.
|
| That doesn't even touch some of the more salient political
| movements or failure after failure to spin the brands off
| into something more/different for profit motives.
|
| Mozilla needs to restructure as an engineering focused
| organization where business operations, marketting and brand
| management are not steering the ship.
| roryirvine wrote:
| Are non-profits in the US allowed to hoard cash long-term?
|
| In the UK, spending on furthering their charitable purpose
| is expected to roughly match income over the medium term.
| There are carve-outs for specific types of "permanent
| endowment" (and even there, spending is meant to match the
| investment income) but it wouldn't cover anything like
| Mozilla's commercial agreement with Google.
| yencabulator wrote:
| Mozilla has already hoarded well over a billion. A
| billion would pay a sizable development team of experts
| for quite a while.
|
| https://assets.mozilla.net/annualreport/2024/mozilla-
| fdn-202...
| roryirvine wrote:
| But the Mozilla Foundation's purpose is "protect and
| improve the Internet as a public resource, open and
| accessible to all".
|
| It's not clear to me why that requires a sizeable team of
| developers - surely they'd be better off working for MoCo
| (the commercial subsidiary who make the browser and who
| provide a large portion of the MoFo's income)?
|
| MoFo's activities are centred on philanthropy and
| advocacy. You'd expect most of their staff to be experts
| in things like community engagement, policy research and
| development, grant-making, campaign strategy, volunteer
| welfare, reporting & transparency, and management of
| investments.
|
| Sure, there'll be some engineering needed to support
| that, but it shouldn't be their core focus.
| yencabulator wrote:
| You're arguing the stated purpose of the current system,
| I'm arguing we'd actually benefit more from refocusing it
| into software (like it used to be).
|
| And that's the _stated_ purpose. The observed current
| purpose of the system is to make a small handful of
| people more rich.
| roryirvine wrote:
| The MoCo/MoFo split happened for a reason: a non-profit
| couldn't do the big commercial deals that became
| available to MoCo.
|
| If you went back to the pre-2005 situation, in which MoFo
| was all there was, it would have _at most_ low single-
| digit millions in the bank rather than a billion. The AOL
| dowry was only intended to last a couple of years, and
| there 's simply no way it could have sustained
| development of the browser beyond that. The Phoenix would
| have been consumed by the flames, and we'd be left with a
| stagnant IE/Chrome duopoly.
| yencabulator wrote:
| Let's try this:
|
| 1. most of the money comes from Google Search placement
| in the browser
|
| 2. most of the money is NOT used on the browser
| glenstein wrote:
| On the linked report above I'm seeing software
| development as about 52% of their expenses. And many of
| the other expenses, eg "General and administrative", I
| understand to be support infrastructure for software
| development. This would seem to fit the meaning of "most"
| on my read.
| yencabulator wrote:
| It's really telling that Mozilla does not want to itemize
| those costs to say how little the actually use on
| Firefox.
| ptx wrote:
| 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/
| glenstein wrote:
| Having worked for a non-profit many years ago as an
| office monkey who, among other things, took notes on
| finance committee meetings, it's typical to have some
| operating reserves that you can measure in terms of how
| many months or years of your operating expenses they
| could cover. This is a common financial stress test used
| to assess the financial health of organizations. Given
| Mozilla's singular dependence on Google search and
| pressure to diversify income streams, it's their firewall
| in case of emergency. And frankly the simple return on
| investment from their endowment year to year is one of
| the strongest non-Google revenue streams at their
| disposal right now.
|
| If armageddon came and they no longer had their search
| revenue, they could cover 2 years of their operational
| costs. Many organizations have endowments that cover them
| for anywhere from 5 to 20 years. What I understand off
| the top of my head is that their major spending
| categories are software development, "operations" which
| is largely infrastructure to support that development,
| legal, and marketing.
|
| I could see the case for not spending so much on
| marketing, but it would be organizational suicide to
| deficit spend away their endowment, their one firewall
| against existential threats, on "engineering" without a
| credible road map to long-term sustainable income that's
| better than what they're already doing. In fact if you
| catch the HN comment section on the right say, such
| behavior would probably be pointed to as yet another
| example of wasting money on unfocused side bets, because
| at the end of the day the mob truly can't decide what it
| wants.
|
| And who knows maybe this "spend it all down on
| engineering + ??? + profit" plan could work, but that
| would be extremely risky and would hinge on the details
| of a plan. But I don't feel like I'm hearing a plan so
| much as vibes. I would actually turn the tables on this
| whole entire interpretation and say what they spend
| relative to their market share, they're actually punching
| above their weight compared to Google, and that this
| criticism of "hoarding" is not grounded in financial
| literacy.
| yencabulator wrote:
| The whole argument is that Mozilla is using their money
| incredibly inefficiently, and a good chunk of that is
| putting money into the pockets of the people managing it.
|
| They claim to be putting $220 M/year into software
| development, but can't sponsor Servo even at $1 M/year? I
| call bullshit.
| glenstein wrote:
| Well I did just give you four paragraphs extensively
| elaborating on the strategic value of having an
| endowment, and how strategically fundamental it is to the
| long-term health, health of any organization and how it's
| consistent with financial management you see at typical
| Western non-profit institutions.
|
| I actually think you're right that they should have kept
| Servo, but that doesn't sustain the charge that is smart
| to not have an endowment or spend down their endowment
| for no reason. Most of your questions are financial
| literacy issues in response to standard non-profit
| disclosures rather than legitimate critique of strategy.
| yencabulator wrote:
| 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?
| nicoburns wrote:
| 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.
| glenstein wrote:
| 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.
| beardsciences wrote:
| Whether it's something like this, or ladybird's engine, I'm happy
| there is work being made in this space.
| DerSaidin wrote:
| +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.
| ricardobeat wrote:
| 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.
| 01HNNWZ0MV43FF wrote:
| 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
| nerdponx wrote:
| Is some kind of a browser microkernel possible? Could you
| ship, say, JS Canvas support in a separate optional
| module?
| nicoburns wrote:
| 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.
| shiomiru wrote:
| I've done something like that in my TUI browser:
|
| https://codeberg.org/bptato/chawan/src/commit/3f2fffd882f
| f47...
|
| It just spins up a background process when a canvas
| context is created and sends drawing commands through
| IPC. As a result, you can rm the 970k canvas binary (most
| of it is just Unifont) and with some luck you will only
| break canvas rendering.
|
| Of course this only works for things that are relatively
| self-contained. So you can add/remove image decoders or
| protocol handlers without recompiling (the main binary
| has zero networking code), but the JS API is still baked
| in.
|
| (I imagine you could also implement some less
| performance-sensitive APIs in JS and load the bytecode on
| demand, but I haven't tried.)
| nicoburns wrote:
| 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.
| cardanome wrote:
| Meanwhile Lua is under 200kb. Imagine if you could use it
| as a browser language, no more bloat and churn.
| ricardobeat wrote:
| 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.
| johannes1234321 wrote:
| That however would limit the browser to small audiences.
| Many users won't accept movies not playing and many sites
| require a JavaScript engine with all those optimisations,
| even SpiderMonkey loses too much in that space.
|
| Binary size however is less of an issue for most users.
| nicoburns wrote:
| 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.
| Y_Y wrote:
| > binary is 100MB+ on Mac
|
| If you're worrying about that size then Mac OS is not the
| platform for you.
| ricardobeat wrote:
| 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.
| evolve2k wrote:
| "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...
| Hemospectrum wrote:
| > 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.
| nicoburns wrote:
| > 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.
| ionelaipatioaei wrote:
| 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.
| tracker1 wrote:
| Agreed. Servo is emphatically not anything resembling a
| priority at Mozilla and hasn't been for a long while.
| lawn wrote:
| 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.
| zargon wrote:
| Servo is not part of Mozilla any more.
| echelon wrote:
| Servo's value is that it's written in Rust.
|
| Ladybird is C++ and that still has the same issues as every
| other engine.
|
| I suspect Ladybird will/has already leapfrogged Servo in
| performance and usage due to the Ladybird team and its
| momentum. Mozilla isn't doing anything with Servo anymore.
|
| But I also don't really see a compelling reason for
| Ladybird's existence - we already have Chromium, Blink,
| Gecko, etc. It's hard for me to imagine a world where
| Ladybird is a healthy contender for marketshare.
|
| The only real novel thing to do in this space is "rewrite
| it in Rust".
| nicoburns wrote:
| > The only real novel thing to do in this space is
| "rewrite it in Rust".
|
| Ironically Chromium is now starting to include quite a
| bit of Rust. And of course Firefox has for some time.
| mnmalst wrote:
| They are planning to use swift in the future. Last point:
| https://ladybird.org/#faq
| heavyset_go wrote:
| 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.
| oblio wrote:
| Aren't Chromium and Blink basically the same thing? And
| Gecko isn't embeddable.
| heavyset_go wrote:
| > _And Gecko isn 't embeddable._
|
| This is "In Review"[1], whatever that means.
|
| [1] https://connect.mozilla.org/t5/ideas/ability-to-
| embed-gecko-...
| nicoburns wrote:
| > 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.
| F3nd0 wrote:
| I'm more hopeful about Servo because it's released under a
| copyleft licence, whereas Ladybird chose a pushover one.
| Imustaskforhelp wrote:
| Can you elaborate what you mean by pushover license?
|
| Ladybird uses bsd-2 license which is OSI, I mean its not
| fsf/copyleft but permissive which should be better
| sometimes for things like embedding etc. no?
|
| It looks like servo uses mozilla public license 2, can you
| please explain me the difference and why you think one is
| pushover and other is not?
| F3nd0 wrote:
| '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.
| darkwater wrote:
| I'm so going to try this, and I hope it will end up as when I
| tried and used Phoenix, and then Firebird.
| wduquette wrote:
| I'd like to see this succeed, but I'm skeptical that a small team
| can keep up with the major players in this area. Many years ago
| Dan Kennedy (of the SQLite team) wrote a lovely HTML widget for
| TCL/TK. It rendered CSS 1.0 quite nicely, and was a pleasure to
| use, modulo a few font-related bugs; but was soon rendered
| obsolete and out of date. Not blaming Dan, here; it simply wasn't
| a one-person job. Meanwhile, I'd rewritten an app to make use of
| it. Got burned once, don't want to get burned again.
| nicoburns wrote:
| I feel like part of the solution here is to build the browser
| as reusable modular components. For some parts of browsers
| that's been common for years: JS engines (V8, SpiderMonkey,
| etc) are typically reusable, as are rendering backends
| (WebRender, Skia, etc), and lower-level components like
| Freetype/Harfbuzz/icu.
|
| Servo's CSS engine Stylo is also modular, and is shared by
| Firefox which is part of how they've managed to not completely
| fall behind in web standards support despite the project being
| all but abandoned for several years.
|
| I'm building another browser engine Blitz [0] which also uses
| Stylo, and we're building our layout/text engine in such a way
| that it can be reused so future browser engines (at least ones
| written in Rust) shouldn't need to build either Style or Layout
| if they don't want to.
|
| A few more infrastructure pieces like this and browser engine
| development starts to look more approachable.
|
| [0]: https://github.com/DioxusLabs/blitz
| norman784 wrote:
| Thanks for you hard work, I already saw taffy being used by
| other prominent projects like Cosmic desktop environment,
| bevy, etc
| bryanlarsen wrote:
| It's several small teams. Servo is modular, and parts of it are
| useful outside of Servo. Other projects are using and
| maintaining and enhancing those modules. For example, IIRC
| dioxus uses many of the modules.
|
| Edit: see sister comment by the actual Dioxus guy, which is
| more accurate than mine!
| Yoric wrote:
| I seem to recall that MMM was based on this widget.
|
| For context, MMM was a browser that supported both browser
| addons and sandboxed applets, around 1995.
| shmerl wrote:
| Mozilla can always return to backing the project.
| robin_reala wrote:
| Ah nice, they're finally generating native ARM Mac binaries.
| esafak wrote:
| They just issued their first release, 0.0.1, after 50,000
| commits. I've never seen that before.
| samus wrote:
| It would be a pleasure to check out the open source web engine
| you have been a major contributor to :)
| kelnos wrote:
| 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.
| timvisee wrote:
| I'm seriously impressed on how far this has come. Tried a few
| websites in the experimental mode, it renders quite well.
| amiljkovic wrote:
| Does it support kiosk mode or is it configurable to run "locked
| down" to a single page and full-screen?
| 01HNNWZ0MV43FF wrote:
| If servoshell doesn't, Tauri will, the Tauri project seemed
| open to collaborating with Servo as an alternative to OS-
| provided WebViews
| CharlesW wrote:
| 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.
| brson wrote:
| Congrats to the servo team. It's been a long road and it's
| amazing they kept it alive.
| nonethewiser wrote:
| 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.
| duped wrote:
| > Servo is a prototype web browser engine
| nonethewiser wrote:
| Yes, those words are also in the repo.
| nicoburns wrote:
| To many people involved in browser development there is a
| distinction between the "browser" (Chrome and Firefox, but also
| Opera, Brave, Arc that don't develop their own engine) and the
| "web engine" (Blink, WebKit, Gecko).
|
| Servo is currently more of the latter than the former as it's
| UI is a pretty minimal one that is mostly useful for testing
| and doesn't much of the niceties that users expect of a modern
| browser (bookmarks, history, password manager, etc).
|
| I do agree that it's confusing for most people though.
| nonethewiser wrote:
| OK, that is a fair distinction I guess. A browser engine
| would be more clear then, I think. That is what it says in
| the readme.
| Philpax wrote:
| 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.
| butz wrote:
| I wonder if it is deliberate choice to not include scrollbar? Is
| it due to limitations of UI widgets, or nowadays scrollbars are
| part of website, as some websites are very happy to set scrollbar
| size to "too narrow for comfortable use" or even remove it
| altogether. To end on positive note: is there a way for an
| average developer to try and fix this issue, thus doing my own
| share of contributing? Where should one start?
| fabrice_d wrote:
| Related: https://github.com/servo/servo/issues/21817
|
| You should likely join https://servo.zulipchat.com and ask
| questions to know where to start.
| xnorswap wrote:
| I am confused, I remember downloading and trying an early Servo
| release out a very long time (decade?) ago.
|
| I've not been following the space, is this a different project
| with the same name?
| nicoburns wrote:
| If the other project was a web browser then it's the same
| project. It got abandoned ~5 years ago, but has since been
| picked up again.
| edoceo wrote:
| Same, reborn
| adaml_623 wrote:
| 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
| alex_duf wrote:
| 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
| 1vuio0pswjnm7 wrote:
| Mozilla/5.0 (Android; Mobile; rv:128.0) Servo/0.0.1 Firefox/128.0
___________________________________________________________________
(page generated 2025-10-20 23:01 UTC)