[HN Gopher] Servo Revival: 2023-2024
___________________________________________________________________
Servo Revival: 2023-2024
Author : panic
Score : 281 points
Date : 2025-01-07 22:25 UTC (1 days ago)
(HTM) web link (blogs.igalia.com)
(TXT) w3m dump (blogs.igalia.com)
| int0x29 wrote:
| They haven't abandoned it but that title makes it sound like they
| have.
| benatkin wrote:
| I think that's intended. This indicates that there's a
| possibility it's _default dead_.
|
| > Servo is a huge project. To keep it alive and making
| progress, we need continuous funding on a bigger scale than
| crowdfunding can generally accomplish. If you're interested in
| contributing to the project or sponsoring the development of
| specific functionality, please contact us at join@servo.org or
| igalia.com/contact.
|
| > Let's hope we can walk this path together and keep working on
| Servo for many years ahead.
|
| https://paulgraham.com/aord.html
| Brian_K_White wrote:
| s/default/defacto
| cbarrick wrote:
| s/defacto/de facto/
| benatkin wrote:
| s/$/\//
| Brian_K_White wrote:
| admitted
| tux3 wrote:
| or, s@$@/@, I don't know whether that's more or less
| cryptic :)
| mappu wrote:
| No, "default dead" is VC-speak for a business that relies
| on runway to operate rather than being profitable.
| Brian_K_White wrote:
| Is Servo a business? I thought it was an open source
| software library?
| orf wrote:
| It's obviously not a business.
| leoc wrote:
| I assume that they're hoping that the EU or an EU member-
| state steps up; or failing that, maybe a (probably-US)
| nonprofit or billionaire donor, perhaps a Laurene Powell Jobs
| or MacKenzie Scott type. To be clear, something like this
| very probably _should_ happen. I 'm heading to social media
| to shout into the void about this: dear reader, you should
| probably do this too, and use any other means you might have
| to steer the attention of decision-makers towards this.
|
| That said, in the longer term the solution to the WWW"'s Too
| Big To Fork problem surely has to involve getting much more
| of the "specification" expressed precisely in declarative
| specification languages, so as to greatly reduce the handwork
| involved in generating a half-decent implementation.
| alex_duf wrote:
| I don't think a single big donation is a good idea. We're
| so used to seeing extreme wealth we don't event question
| it.
|
| Once a big donation is given, you get to wonder what sort
| of influence that person (willingly or not) has had on the
| project. A much better model is a large amount of small
| donations, the incentive becomes to serve the maximum
| amount of these people.
| leoc wrote:
| I too would prefer that the funding come from a
| relatively hands-off source, like some EU pot, if
| possible. But I think that nearly any (reasonably likely)
| funding source would be preferable to letting Servo
| development fail.
| LeFantome wrote:
| What we need are multiple implementations, all giving
| feedback on the spec:
|
| https://github.com/LadybirdBrowser/ladybird
| striking wrote:
| A lot of private funding at these consultancies actually
| comes from pet features. Some company says "hmm, we sure do
| rely on XYZ feature a lot, would be nice if it were
| faster", they throw some money at a consultancy like
| Igalia, and then it becomes faster for everyone. No need
| for a big pot all at once, though I'm sure that'd be really
| nice.
| nar001 wrote:
| Hopefully they don't! I wanna see where this goes, we need more
| browser engines
| Vinnl wrote:
| The article was first posted in 2024, which made it feel less
| so at the time :)
|
| Should probably have a "(2024)" appended to the title.
| mdaniel wrote:
| Interesting, they also claim that they are the 2nd biggest
| contributors to Chromium after Google:
| https://bsky.app/profile/igalia.com/post/3lasylsguzs2f
| jitl wrote:
| Igalia is the real deal. Many companies that want bugs fixed or
| features added to web browsers hire Igalia to make those
| changes. They also maintain WebKit on Linux (gtk and wpe)
| https://planet.igalia.com/webkit/
| mmastrac wrote:
| Yeah. I got to see Andy Wingo's work on a V8 feature and it
| was an impressive piece of work.
| topspin wrote:
| That's interesting. One wonders what their future looks like
| after Google divests Chrome. Good to see that the knowledge
| base isn't entirely confined within Google.
| qingcharles wrote:
| Chrome will still be the #1 browser, and corps will still
| want features added, so they'll be good for a while I
| think.
| topspin wrote:
| Sure. My thinking is this is a big opportunity.
| barkingcat wrote:
| Igalia is self directed and one of the few organizations I
| can see taking on technical leadership of the entire
| chromium project if/when Google divests Chrome.
|
| The technical talent at Igalia runs deep.
| lawik wrote:
| Yeah, been seeing their site a lot when setting up cog and
| weston for an embedded kiosk thing. Also met a bunch of them
| at the OpennSource Summit in Vienna.
|
| Every now and then you run into these small-ish expert
| consultancies that actually are the force behind a lot of
| open source.
|
| They seem awesome.
| LeFantome wrote:
| They also employ the main dev for Chimera Linux:
|
| https://chimera-linux.org/
| barkingcat wrote:
| Igalia is a huge force in open source
|
| They are self directed contractors.
|
| They are also responsible for huge portions of chromium and
| fundimental/base opensource libraries.
|
| If you can think of an open source library, it's highly likely
| Igalia had funded some development or bug fixes.
| shmerl wrote:
| Any plans to move WebRender to using Vulkan instead of OpenGL?
| The latter is really not well suited for proper parallelism.
|
| I hope Servo will eventually replace Chromium in QtWebEngine and
| other similar cases.
| benatkin wrote:
| There's an active attempt to make a DOM rendering engine in
| Rust using these APIs. https://github.com/DioxusLabs/blitz
| shmerl wrote:
| That looks like its own thing, so not going to benefit Servo
| and Firefox if I understand correctly? Since they are using
| WebRender.
| nicoburns wrote:
| Correct. There are some shared components (notably Stylo,
| the style system), but Webrender is not one of them.
| Webrender is still maintained primarily by Mozilla as part
| of Firefox. If they have any plans to move to
| Vulkan/Metal/DX10/wgpu then I haven't heard of them.
|
| It might be possible for Servo to go down the same route as
| Blitz and have pluggable rendering backends. If so then the
| wgpu-based renderering library we are using (Vello [0] -
| which is an exciting project in it's own right) could be an
| option. Servo is actively looking at potentially using this
| library to implement Canvas2D.
|
| [0]: https://github.com/linebender/vello
| norman784 wrote:
| Wouldn't be better for them to use wgpu instead?
| pjmlp wrote:
| Given that wgpu is based on WebGPU, it is kind of limited by
| a graphics API designed for the Web sandbox and managed
| languages.
| shmerl wrote:
| Not sure, I don't see an issue with using Vulkan directly,
| but I think WebRender developers did plan to use wgpu at some
| point.
| WD-42 wrote:
| Of all projects for Mozilla, the supposed champions of the web,
| to abandon, it still blows my mind that they chose Servo to be
| the one to lay off the entire team for.
| torginus wrote:
| This. Especially since it's pretty much supposed to be Rust's
| flagship project.
| IshKebab wrote:
| To be fair, it wasn't really by the time they abandoned it.
| torginus wrote:
| Still, I think Rust was designed for the style and scale of
| application that a Web Browser is. Foundational, but not
| kernel level, highly complex, with a wide feature set,
| performance is important (but not the most important) and
| high reliability/maintainability and quality is expected.
|
| Building these kinds of apps was commonplace in the
| 90s/early 2000s: photo editing apps, word processors, IDEs,
| 3D modeling software etc. Maybe RDBMS count as well.
|
| In practice Rust is mostly used by web people to gain clout
| - rewriting microservices, which are usually <10k, but very
| rarely above 100k LOC, and were originally written in a
| very slow language, such as Python or Ruby.
|
| Had these projects started out in an uncool, but performant
| language, like Java, there'd have been very little
| reasonable justification for these Rust rewrites.
| IshKebab wrote:
| > In practice Rust is mostly used by web people to gain
| clout
|
| Complete hogwash.
| IshKebab wrote:
| I agree. Pretty much the main distinguishing feature of Firefox
| is that it doesn't use WebKit/Blink. Crazy of them to
| discontinue working on their own engine's future, especially
| when it was already yielding results.
|
| I'm trying Firefox on Android at the moment and it's noticeably
| less snappy than Chrome. I wonder if Servo would have changed
| that.
| soganess wrote:
| I am always in bizarro world when I read comments like this.
| I swear I perceive firefox for android to feel snappier and
| smoother than chrome.
|
| To be clear, I am not trying to claim you are wrong! It is
| the common wisdom that chrome is faster on android. But I
| swear, scrolling and page loading just feels faster on
| firefox. My only guess is the adblocker, but I think firefox
| is faster than brave, so who knows.
|
| I wonder if other have a similar experience and can shed some
| light on the situation?
| IshKebab wrote:
| I just double checked by closing all tabs, killing the
| browser and then loading Hacker News. It's about 0.5s on
| Chrome and 1s on Firefox (roughly). That's a big
| difference.
|
| Firefox is probably faster for ad-heavy sites, but it
| definitely isn't for sites without obtrusive ads.
| soganess wrote:
| That is the kind of results I would expect! Plus V8 (if
| that is still the JS engine in chrome) has always been
| faster. And android is probably the priority target for
| chrome at this point.
|
| But on the occasional times I launch it (chrome), it just
| feels like it bogus down more often doing basic things.
| Someone once suggested that, paradoxically, it is slower
| because I don't use it very often. Something to do with
| ART and how the AOT compilation work on android
| Zardoz84 wrote:
| Using uBlock Origin makes wonders. Chrome could be faster,
| but isn't fast enough to render all the ads shit stuff that
| are on many webs.
| throwaway48476 wrote:
| Firefox on android is a million times faster than chrome
| because it has an ad blocker.
| IshKebab wrote:
| Not all sites have egregious ads. Chrome is faster for
| those.
| usrnm wrote:
| Why? They already have their own browser engine, what would
| they gain by creating another one? It's a browser company, not
| a Rust promotion company, from this point of view the decision
| was completely logical.
| bpye wrote:
| Many components from Servo (like WebRender) ended up being
| useful in Firefox. That alone seems like a pretty reasonable
| motivation to continue?
| usrnm wrote:
| No, it doesn't? It shows that Gecko can be updated and
| modernised without the need for a complete rewrite.
| ptman wrote:
| But a rewrite may allow for an overall better
| architecture.
| usrnm wrote:
| Is there anything wrong with Gecko architecture? So wrong
| that it's a major obstacle and cannot be changed? I don't
| know anything about its internals or browser engines in
| general, so I can't really comment on that, but what I do
| know from practice is that a complete rewrite is a very
| expensive and a very risky project, that will fail more
| often than not. There should be very serious arguments
| behind it, something a lot more serious than the age of
| the codebase or a new and shiny programming language.
| cassepipe wrote:
| It is a very big project and has a big potential for the
| classic double-free, use-after-free, null-dereferencing,
| one-off index errors etc. which they designed Rust to get
| rid of in the first place. I believe they had such a bug
| some months ago and that it was quite serious.
| dralley wrote:
| It's a lot easier to swap out the renderer or the CSS
| engine for a new one than it is the whole core of the
| browser engine.
|
| Mozilla decided that replacing Gecko as-is was not
| reasonably likely to actually happen, and that further
| efforts towards Servo would be better made by continuing to
| evolve Gecko.
| Certhas wrote:
| Honestly though: Why? Large chunks of the most important servo
| work is in Firefox now. Nobody else maintains even one web
| engine. What is the importance for the open web of Moz
| developing two?
| conradfr wrote:
| Doesn't that mean that those parts they integrated are now
| maintained and improved twice in separate wasteful efforts?
| nicoburns wrote:
| No. Mozilla maintains those parts as part of Firefox
| (Gecko). Servo imports and syncs back changes.
| cabirum wrote:
| Mozilla could run out of money in the middle of engine rewrite,
| see also: Netscape[1]. I think they just decided to play safe.
|
| [1]: https://www.joelonsoftware.com/2000/04/06/things-you-
| should-...
| LeFantome wrote:
| Yes, since Firefox IS Netscape, they have some experience
| with this.
| dralley wrote:
| HN: "Mozilla has too many side projects that don't make the
| browser better"
|
| Also HN: "Mozilla should spend more than a decade and tens of
| millions of dollars on a brand new browser engine that has no
| hope of replacing Gecko before it reaches 100% compatibility
| with a spec thousands (tens of thousands?) of lines long, not
| to mention the kind of "quirks" you see with websites in the
| wild, while they already lag behind Google with the browser
| engine they already have."
|
| People like cool R&D projects, and that's understandable - I
| like Servo too. But the fact that it was really cool doesn't
| compensate for the fact that it was not going to be production-
| ready any time soon and in that light it's understandable why
| it was cancelled. While some parts of Servo ended up being so
| successful that they were merged into Firefox, a lot of what
| remained only in Servo (and not in Firefox) was nowhere close.
|
| The layout component was by far the least mature of any part of
| Servo at the time (unlike Stylo and WebRender, I mean) and in
| fact it was going through the early stages of a brand-new
| rewrite of that component at the time the project was
| cancelled, partly because the experimental architecture ended
| up not being very suitable.
|
| https://servo.org/blog/2023/04/13/layout-2013-vs-2020/
| demurgos wrote:
| > that has no hope of replacing Gecko before it reaches 100%
| compatibility with a spec thousands (tens of thousands?) of
| lines long
|
| When Servo was still managed by Mozilla, they were able to
| merge some components incrementally into the Firefox. Most
| famously, Stylo and WebRender were first developed in Servo.
| They could have kept Servo for experimentation and merge
| parts incrementally.
|
| It may also have enabled better embedding supporting which is
| a weak point of Firefox compared to Chrome; which is a long-
| term solution to remain relevant.
| dralley wrote:
| I covered that. Sure, Stylo and WebRender were successful
| enough that they made it into Firefox, but the Layout
| component was very much not. Servo was in the middle of a
| clean-slate rewrite of the layout component because the
| initial architecture chosen in 2013 wasn't very good.
|
| The CSS engine and rendering engine are a lot easier to
| swap out than the remaining parts.
|
| Again, I get why people like Servo, but "in 10 years, maybe
| we'll be able to take on Electron" isn't that great of a
| value proposition for a huge R&D project by a company
| already struggling to remain relevant with their core
| projects.
| timschmidt wrote:
| > "in 10 years, maybe we'll be able to take on Electron"
| isn't that great of a value proposition
|
| Perhaps not, but "in 10 years, we'll have a browser
| that's significantly faster and safer than the
| competition" is how you plan to still be relevant 10
| years from now.
| dralley wrote:
| The browser engine is not what makes Firefox "relevant"
| or not. Their competitors are Apple, Google and
| Microsoft. The marketing budget for Chrome is larger than
| Mozilla's entire budget. "Google" is synonymous with the
| entire internet for a large fraction of the non-technical
| population. Every device you could buy on the market
| whether a PC, a tablet or a phone has one of their
| competitors browsers already pre-installed.
|
| Their primary leverage is unique features and functional
| adblockers, neither of which is impacted by the layout
| engine.
|
| And again, you're taking away resources from something
| that is already behind right now. The canonical example
| of massive long-term rewrites being a bad idea for the
| business is literally the precursor to Firefox. Gecko can
| be refactored in-place, including into Rust if they
| decided to do so.
| timschmidt wrote:
| > Their primary leverage is unique features and
| functional adblockers, neither of which is impacted by
| the layout engine.
|
| Yes, unique features like being written in a memory safe
| language and depending on memory safe implementations of
| image and video decode libraries are exactly what I care
| about in an all-knowing sandbox which touches network
| services and runs untrusted code on my computer.
|
| > And again, you're taking away resources from something
| that is already behind right now.
|
| Disagree. You're talking about every Mozilla project
| that's not Servo. Firefox/Servo development is Mozilla's
| core competency. One which they've abandoned.
| dralley wrote:
| >depending on memory safe implementations of image and
| video decode libraries are exactly what I care about in
| an all-knowing sandbox which touches network services and
| runs untrusted code on my computer.
|
| What does that have to do with Servo? Firefox has already
| been doing those things and continues to do them [0],
| they don't need to do them in Servo first.
|
| We are specifically talking about the utility of
| rewriting a layout engine from scratch, rather than
| putting more resources into evolving Gecko - including
| rewriting small parts of Gecko in Rust incrementally.
|
| >Disagree. You're talking about every Mozilla project
| that's not Servo. Firefox/Servo development is Mozilla's
| core competency. One which they've abandoned.
|
| They obviously haven't abandoned it. It's not like they
| cancelled Gecko development too and are rebasing on top
| of Blink. Again, this is all just a philosophical debate
| over whether rewrites or refactors are more effective
| when it comes to the most core component of the browser.
|
| [0] https://github.com/mozilla/standards-
| positions/pull/1064
| timschmidt wrote:
| https://4e6.github.io/firefox-lang-stats/
|
| Do you see those red and orange and green pie slices? 40%
| of the code. There, be memory errors. Approximately 70%
| of all errors in that code will be memory safety related
| and exploitable.
|
| Fixing it looks like developing Servo.
|
| Don't want to take my word for it? How about the US
| Department of Defense: https://media.defense.gov/2022/Nov
| /10/2003112742/-1/-1/0/CSI...
| dralley wrote:
| Mozilla continues to add new Rust to Firefox, despite
| discontinuing the Servo project. A big parallel rewrite
| is not the only possible approach to writing Rust.
| "Fixing it" does not have to look like Servo. In fact
| doing more incremental rewrites will improve the
| situation shown in that chart much faster than waiting 10
| years for parity before doing the replacement.
|
| I'm not responding further until you actually read and
| understand what I'm saying instead of flailing at a
| strawman.
| timschmidt wrote:
| > A big parallel rewrite is not the only possible
| approach to writing Rust.
|
| A rewrite _is_ the only way to convert the codebase to
| Rust or any other memory safe language. Whether that
| happens in parallel, piecemeal, or both at the same time
| is down to how well you use a version control system and
| structure your code. As has already been shown by sharing
| Servo code with Firefox.
|
| A full rewrite is particularly useful with Rust, as the
| language wants you to structure your code differently
| than most C/C++ is structured. Doesn't make sense not to
| have one going if that's the plan. If you're going to
| rewrite the whole thing anyway, might as well do it in an
| idiomatic way.
| bogeholm wrote:
| > A full rewrite
|
| Things You Should Never Do, Part I [0]
|
| [0]: https://www.joelonsoftware.com/2000/04/06/things-
| you-should-...
| timschmidt wrote:
| Things Mozilla have done a few times.[0] All with valid
| reason. 30 years without a rewrite is pretty rare for any
| piece of software.
|
| 0: https://en.wikipedia.org/wiki/Netscape_Navigator
| steveklabnik wrote:
| Google has demonstrated that writing _new_ code in a
| memory safe language still significantly improves the
| safety story of a codebase, even while keeping around the
| old code. Full scale rewrites are not the only option.
| timschmidt wrote:
| Yes, every line of C/C++ you can replace with a memory
| safe language in a critical codebase like a browser
| improves it's safety story. Which is exactly the reason
| replacing all of it is so attractive.
|
| But just to offer another point, I also still run into
| memory leaks and other performance issues in long-lived
| Firefox processes which, based on my experience with
| Rust, would be unlikely to be a problem in a functional
| Servo. It'd be nice to have a browser I don't have to
| occasionally kill and restart just to keep Youtube
| working.
| WD-42 wrote:
| I'm pretty sure if Firefox started beating chrome in
| speed benchmarks (because of a newer, more modern engine)
| they would be able to claw back some of their lost market
| share. Even normal people care about speed.
| mook wrote:
| That would be hard to do with Google intentionally
| sandbagging things like YouTube (I'm thinking about them
| using a nonstandard version of web components, plus a
| super slow shim for Firefox, instead of using the
| standardized version that Chrome also supported).
| WD-42 wrote:
| True, I guess investing in the future viability of your core
| product doesn't fit with how modern corporations are run.
|
| They should just keep launching bookmarking and vpn services
| that might make money RIGHT NOW.
| dralley wrote:
| Does anybody argue that Google is negligent for not doing a
| complete rewrite of Blink, rather than doing the same
| incremental software development as everyone else? Did they
| suffer from their choice to use WebKit in the very
| beginning rather than do their own thing?
| WD-42 wrote:
| Why would they need a rewrite? Blink is the market
| leader.
|
| Meanwhile daily driving gecko becomes a worse experience
| by the hour.
| aorth wrote:
| Oh this is nice to hear. It's always pleasant to read updates
| about Servo. I didn't know they started accepting donations on
| Open Collective and GitHub sponsors last year
| https://servo.org/blog/2024/03/12/sponsoring-servo/. I'm happy to
| contribute something.
| jszymborski wrote:
| FYI: I think their website indicates they pay the fewest fees
| on GitHub, so you may want to set up your donations there if
| anyone is still deciding between the two.
|
| Sponsoring them was a no brainer for me :)
| diggan wrote:
| > I think their website indicates they pay the fewest fees on
| GitHub
|
| The difference (https://servo.org/sponsorship/#donation-fees)
| between the donation going via GitHub/Microsoft and Open
| Collective (independent) is so small (96% VS ~91%) that I'd
| rather not centralize funding FOSS with someone who has kind
| of a shitty track record with it, like Microsoft.
|
| Made more sense in the beginning of GitHub Sponsors when
| Microsoft was matching donations 2x, or whatever it was. But
| now? I don't feel like it makes much sense anymore.
|
| Open Collective is a fully public organization, who lives and
| breathes FOSS.
| jszymborski wrote:
| Note that the fee for Open Collective depends on the amount
| you are donating, what card you use, and where you are
| from.
|
| Servo would only see 85.6% of my 5 USD/mo donation as I'm
| from Canada. If I used PayPal, that number would go down to
| 81.2%.
|
| I do agree that I'd prefer Open Collective, fees being
| equal/comparable.
| cies wrote:
| All this discussion (hate) on the effort to "rewrite in Rust"...
|
| At the same time these projects are soooo promissing (to me -- it
| may be purely subjective).
|
| By _these_ projects I mean:
|
| Servo and Verso
|
| Redox OS
|
| System76's COSMIC Desktop's EPOCH
|
| RipGrep
|
| Deno
|
| Zig
|
| tree-sitter
|
| And lots of web dev libs and frameworks: Actix, Leptos, Dioxus...
|
| Currently a web dev stack can run on Redox OS and use
| significantly less resources than Alpine! (and this stack has not
| even had the years of tuning Alpine had)
| alraj wrote:
| Why is Zig here?
| cies wrote:
| Shit, should have been Zed. The editor.
| actionfromafar wrote:
| It would have been funny to suggest rewriting Zig in Rust.
| :)
| edoceo wrote:
| Rewrite Rust in Zig.
| nasretdinov wrote:
| Honestly either should be more than possible to do,
| although not sure how beneficial. It would certainly be
| very funny if Zig compiler would be implemented in Rust
| and, simultaneously, Rust compiler would be written in
| Zig
| throwawaymaths wrote:
| zig compiler does lots of things for speed that would
| push it well into unsafe rust, or unchecked rust (like
| using u32 index tags in arrays instead of pointers)
| nasretdinov wrote:
| Even better! It would be a great opportunity for the
| author(s) to rewrite it in idiomatic Rust!
| actionfromafar wrote:
| Or idiomatic COBOL!
| ivolimmen wrote:
| I took a look at COSMIC and it really looks nice. I am not
| interest in it because it is written in Rust but it simply
| looks nice and the window management also looks promising. I
| hope to run it on my main machine soon.
| LeFantome wrote:
| I have been running COSMIC on my laptop and really enjoying
| it. It is only going to get better from Here.
| kragen wrote:
| Polars, a Rust replacement for Pandas.
|
| Rewriting things in Rust is a reasonable thing to do. I think
| the hate is for people who criticize existing software for
| being written in C on the grounds that hypothetically someone
| could rewrite them in Rust.
|
| " _I_ rewrote SQLite in Rust " would be praiseworthy (assuming
| it's true). "Why don't _you_ rewrite SQLite in Rust? " is
| trolling.
| geodel wrote:
| Exactly. The problem is _You_ do the rewrite because _I_ like
| Rust.
| kragen wrote:
| To be fair, this is a deal I would totally take, at my
| normal consulting rates. I'll be slower than Rust
| superfans, but I'm probably cheaper too.
___________________________________________________________________
(page generated 2025-01-08 23:00 UTC)