[HN Gopher] I tried Servo
___________________________________________________________________
I tried Servo
Author : robtherobber
Score : 295 points
Date : 2025-07-31 10:56 UTC (12 hours ago)
(HTM) web link (www.spacebar.news)
(TXT) w3m dump (www.spacebar.news)
| jqpabc123 wrote:
| _It 's still baffling to me that Mozilla threw out Firefox's
| technical future_
|
| Very little about Mozilla makes sense --- until you follow the
| money.
| olalonde wrote:
| What do you mean? Doesn't most of Mozilla's revenue come from
| Firefox?
| ObscureScience wrote:
| How do you think Firefox is making money, since it has no
| payed features? Hint: it has Google search as the default
| search engine.
| olalonde wrote:
| That's my point... The fewer people use Firefox, the less
| money they get from Google. If you follow the money, it
| doesn't make sense for them to neglect Firefox.
| jqpabc123 wrote:
| _The fewer people use Firefox, the less money they get
| from Google._
|
| You obviously haven't been following the money.
|
| The statistical global marketshare of Firefox is very
| close to that of Internet Explorer --- within a single
| rounding digit.
|
| https://www.bloomberg.com/news/newsletters/2023-05-05/why
| -go...
| GoblinSlayer wrote:
| Firefox users just block trackers, that's why you don't
| see them.
| thoroughburro wrote:
| No. Check Mozilla's own numbers if you don't believe
| tracking stats.
|
| https://data.firefox.com/dashboard/user-activity
| konart wrote:
| Tops make goods money as is. All they need to do is to
| keep Fx the way it is.
|
| And Google won't be paying more if Firefox becomes
| something bigger than Chrome. Google has no interest in
| it. All they need is a spoiler effect.
| olalonde wrote:
| But Google did pay Mozilla even when Firefox was bigger
| than Chrome.
| echelon wrote:
| Mozilla is simply an antitrust litigation sponge.
|
| Google knows it shouldn't be developing a browser. This
| paltry pocket change protects their pane of glass moat.
| 0x000xca0xfe wrote:
| > The fewer people use Firefox, the less money they get
| from Google
|
| This is not reflected in the numbers, at least from what
| I've found: 300m/year in 2011[1], 400+m/year in 2020[2],
| 485m/year in 2025[3].
|
| [1] https://www.computerworld.com/article/1543269/google-
| to-pay-...
|
| [2] https://www.pcmag.com/news/mozilla-signs-
| lucrative-3-year-go...
|
| [3] https://nerdschalk.com/85-of-mozillas-revenue-at-
| risk-firefo...
| DoctorOetker wrote:
| Is mozilla being rewarded if the user base provably
| falls?
| kaoD wrote:
| Google does not need Mozilla to have a sizable market
| share. They just need it as a semblance of competition in
| the browser space.
| thoroughburro wrote:
| You're the one who didn't follow the money: they've made
| _more_ from Google as their market share has decreased.
| Neat incentive, huh?
| atoav wrote:
| Nope it comes from Google.
| sirwhinesalot wrote:
| Mozilla is basically paid by Google to have a multi-platform
| non-Blink browser around they can point to when accused of
| being a monopoly.
|
| Having a quality browser is not required, merely it existing.
| So why waste money on novel web engine experiments when you
| can have AI conferences in Zambia?
| jqpabc123 wrote:
| Living large and loving life --- by selling out.
| nextaccountic wrote:
| I think people are implying that Google told Mozilla to drop
| Servo, to make sure Firefox wouldn't leapfrog Chrome. And
| since Google funds Mozilla almost entirely, Mozilla had to
| comply.
|
| Almost no technical aspect of Firefox have anything to do
| with how much money Google pays them.
| camdroidw wrote:
| It's wrong to name names without prood but after a point you
| start doubting your understanding of the world and at this
| point I'm beginning to suspect Mitchell Baker is a plant
| bobajeff wrote:
| I think without Mitchell Baker there would probably not have
| been a Mozilla. I'm fuzzy on the history but I believe she
| was the lawyer who originally set up the organization.
| badsectoracula wrote:
| AFAIK she also wrote the MPL, but the thing is, people
| change and doing good stuff 30 years ago doesn't mean
| they'd keep doing good stuff decades later.
|
| In any case it doesn't really matter much anymore since
| apparently she left Mozilla around February.
| Gualdrapo wrote:
| I still strongly believe Servo can be a real counterpoint to
| Chrome/Chromium's hegemony in the long haul. Not sure why
| Mozilla ditched it nor why The Linux Foundation gives little to
| no support at all to it.
| johnisgood wrote:
| Because Mozilla benefits from Google's donations (the
| majority comes from Google), and being a counterpoint to
| Google's Chrome is bad for Google, which means less or no
| donations to Mozilla. Google holds the key here. They have
| leverage over Mozilla.
| fhd2 wrote:
| They don't get donations from Google, but get paid to
| include Google as the default search engine, right?
|
| No important difference though. Mozilla tried to switch to
| Yahoo a few years back and backpedaled. In terms of what
| users expect, they don't have a lot of options. Google OTOH
| could do without the users Firefox has left. And I've
| personally observed Google strong arm "partners". Not sure
| I see a conspiracy here, but I'm pretty sure that if Google
| asks for concessions, Mozilla will see what they can do.
| johnisgood wrote:
| You are right, it is not a "donation", more like a
| business arrangement or something. I am not sure it is
| limited to "be the default search engine" though.
| LtdJorge wrote:
| It is
| f311a wrote:
| WebKit is a nice competitor, too. Look at Orion browser, it's
| a pretty decent competitor. Although they only target macOS,
| WebKit can be used on Windows and Linux, too.
| bobajeff wrote:
| Webkit on Linux is in terrible shape. Maybe in theory it
| could be a complete and useable engine but there clearly
| isn't enough interest to make it that way.
| johnisgood wrote:
| Orion does not target macOS only, well primarily yes, for
| now, but check out this thread:
| https://news.ycombinator.com/item?id=44708445.
|
| Someone said "It's coming on Linux (scheduled for March
| 2026). See https://kagi.com/changelog#6479".
| ac29 wrote:
| > nor why The Linux Foundation gives little to no support at
| all to it
|
| The Linux Foundation is mostly a dumping ground for dead and
| dying projects. Particularly they seem to specialize in
| abandoned commercial open source projects.
|
| I dont think the Foundation provides much, if any, developer
| funding for these projects. They list $193M in "project
| support" expenses but host over 1000 projects.
| bitwize wrote:
| I thought that was the Apache Foundation?
| k__ wrote:
| Many Apache projects are still well maintained.
| StopDisinfo910 wrote:
| The string of departures and how people communicated around
| them let me think it's something a lot less nefarious: Mozilla
| looked like an extremely political company at the time.
|
| Servo was extremely good at communication with their very
| frequent news letter and Rust had a lot of wind in its sails, I
| wouldn't be surprised if that ruffled the wrong feathers.
| Mozilla is very much still managed by what remains of its old
| guards - by that I mean what hasn't been poached - especially
| at the top.
|
| That would be pure incompetence from the top management but not
| malice.
| xpe wrote:
| A lot of things look like incompetence at a distance, but get
| really fascinating up close. Does anyone know care to share
| what they know about the particular personalities, drives,
| and visions?
| jqpabc123 wrote:
| _That would be pure incompetence from the top_
|
| For which they are compensated very well.
|
| It just doesn't make sense does it?
| nicoburns wrote:
| No, but it's not mozilla-specific. It's true of almost
| every large corporation.
| bornfreddy wrote:
| The way this world is going, you shouldn't attribute to
| incompetence what can be attributed to malice.
| xpe wrote:
| The end of Pocket is just another sad example.
|
| As an April fools joke, Mozilla should announce that they are
| discontinuing Firefox in order to focus on their core business,
| which is a beautiful abstraction: the Platonic ideal of
| discontinuing popular products.
| paulryanrogers wrote:
| Strange. I remember reading nothing but complaints about
| Pocket when they bought and integrated it. I guess it grew on
| people.
| Octoth0rpe wrote:
| Even if you dislike Pocket, its purchase/deprecation is an
| example of Mozilla failing to effectively use its capital.
| windsurfer wrote:
| They integrated Pocket as a proprietary service in their
| open source product 2 years before Mozilla acquired it.
| Removing the integration required editing about:config. The
| complaints were mostly during that time.
| chimeracoder wrote:
| > Strange. I remember reading nothing but complaints about
| Pocket when they bought and integrated it. I guess it grew
| on people.
|
| They bought Pocket to assuage complaints from people that
| they were "selling out" by including an optional button in
| Firefox (which never even loaded any code until it was
| clicked) that allowed you to set up an integration with
| your Pocket account and send articles there. They were
| clear that no data was sent to a third party unless you
| explicitly clicked it and went through the steps to set it
| up.
|
| Despite that, purists were unhappy that Firefox was doing
| literally anything at all with a third party, so Mozilla
| decided to buy Firefox in an attempt to put those
| complaints to rest, since it would no longer be a third
| party.
|
| In the end, those purists didn't stop complaining - they
| just moved on to different complaints. If you're curious to
| see for yourself, you can look up the conversations on HN
| and cross-reference the usernames against other topics
| involving OSS purism and Firefox.
|
| In the end, everyone lost: longtime Pocket users lost a
| product that they had enjoyed because it got acquired by a
| company that never really had an active interest in the
| product itself, Firefox lost because of the negative PR
| which contributes to their declining market share, and
| Mozilla lost because of the massive waste of money this
| was.
| wtallis wrote:
| > Despite that, purists were unhappy that Firefox was
| doing literally anything at all with a third party
|
| That's a horribly dishonest explanation. The _way_ that
| Pocket was integrated into the browser was obviously
| shady. Most clearly, there was no reason for it to be
| anything other than an extension. Mozilla _earned_ most
| of the complaints that they were shoving Pocket down user
| 's throats. The complaints weren't even primarily about
| "OSS purism"; Mozilla was simply being disrespectful to
| their users.
| 0points wrote:
| Not strange, satisfied people don't usually run around
| declaring how perfectly OK everything is.
| coredog64 wrote:
| That they're being bought by Google so that they can focus on
| the Platonic ideal of discontinuing popular products.
| Certhas wrote:
| I think Mozilla makes a lot of sense if you consider the
| following long term strategic goal: Become independent of
| Google money. None Google income has grown to 150M$ in 2023, up
| from 80M$ the year before. Mozilla has used dramatically more
| of the Google money to build up assets than it spends on
| advocacy or other projects that irl some people so. In 2023
| they had 1B$ in investments. Net assets have been going up by
| 100M+ per year.
|
| They are not yet in striking distance to truly become
| independent, but they are making significant steps in that
| direction. The share of Google money in their revenue went from
| 90% in 2020 to 75% in 2023.
|
| I don't think following the money actually shows what you think
| it does.
|
| As a postscript:
|
| Damned if they do, damned if they don't. There were plenty of
| people at the time arguing that Firefox maintaining one
| independent browser engine was idiotic and they should just
| switch to Chromium like everyone else. People like to lambast
| Mozilla over relatively minor advocacy spending stuff and cry
| that it should just focus on Firefox, but insist it should have
| obviously continued with Servo. Even though Servo probably
| wouldn't have made a substantial difference to Firefox post
| Quantum for a very long time.
| skinkestek wrote:
| The majority of Mozilla's revenue came through Firefox--their
| flagship product and by far their most recognized project.
|
| And yet, somehow, they still struggle to secure adequate
| funding _for Firefox itself_ , while millions are allocated
| to executive salaries and various advocacy initiatives.
| cozzyd wrote:
| Wait until you see executive salaries at other companies
| that make browsers.
| Certhas wrote:
| What do you even mean? They have adequate funding.
| Financially they are doing extremely well.
| lesuorac wrote:
| At what point could FireFox had just invested the money from
| Google into the SP500 and then just ran the company off of
| passive income?
|
| Like for 150M$ I bet you could fund browser development for
| at least a decade and that was just 1 year of income. (of
| course also burn the entire $150M).
| Certhas wrote:
| Not sure that's a realistic assessment of the cost of
| developing a browser. Mozilla gives Software Development
| exp names as by far the single largest expense at 260M$ in
| 2023. According to DuckAI 700 out of 750 Mozilla Co
| employees work on Firefox.
|
| I am sympathetic to the idea that a global remote team,
| that doesn't pay Silicon Valley salaries could get this
| done cheaper, and thus would be a better candidate for such
| an Invest and live on interests approach but 15M$ budget
| seems infeasible.
|
| Reading directly from the 2023 financial report: Revenues
| were 653M, Software Dev was 260M and change in net assets
| was 142M, so 402/653 is spent on the core activities you
| favour (and that is ignoring that you do need a legal and
| HR department, and some management, and some marketing if
| you don't want Firefox market share to fall further).
| cropcirclbureau wrote:
| Every day I login into Hacker News. Every day, I see Mozilla
| FUD.
| ObscureScience wrote:
| While it's hard to know what comes of it, there is also
| https://ladybird.org/ to challenge to monopoly of Blink.
| willi59549879 wrote:
| I hope it succeeds. Now they allow direct donations, so people
| who want it to succeed can help. I am sure these donations go
| directly into the development of the browser unlike with
| mozilla.
| robin_reala wrote:
| Worth pointing out that you can also sponsor Servo
| development: https://github.com/sponsors/servo
| YmiYugy wrote:
| I just don't get the point of ladybird. They have full time
| engineers and are soliciting donations, so it's clearly more
| than a hobby project. Maybe my assumptions are off, but I just
| can't imagine they could ever become competitive in terms of
| features, security and performance with the big engines. Blink
| is setting the pace, Webkit is barely able to keep up and Gecko
| is slowly falling behind. All of these teams are orders of
| magnitudes larger than the Ladybird team. If you think that
| Blinks dominance is a thread to the web it's not enough to have
| an alternative engine you need enough adoption of that engine
| so web devs make sure their site is compatible with that
| engine. Most of this also applies to Servo, but at least their
| technical project goals (embeddable, modular, parallel, memory
| safe) sound at least moderately compelling. Maybe Ladybird has
| similar goals, but at least their website doesn't really state
| any technical goals.
| f311a wrote:
| What's wrong with Webkit? It's super fast. I tested Orion
| browser recently.
| MrDrMcCoy wrote:
| Good implementations are hard to come by outside Apple's
| ecosystem.
| sirwhinesalot wrote:
| Not being funded by Google money is a pretty big deal. Some
| of the developers are former webkit devs so they have a good
| foundation to start from. It remains to be seen if they can
| pull it off.
|
| Orion adding Windows support (getting WebKit running on
| Windows again) would be pretty good too.
| badsectoracula wrote:
| Larger teams do not necessarily mean you get stuff faster. If
| anything after some point, a large team can be hard to get
| things moving and have tons of issues with communication.
| throw839340949r wrote:
| Ladybird has better results in web rendering tests than
| Servo, and slowly is gaining on Firefox.
|
| They are already quite competitive.
| fabrice_d wrote:
| Ladybird is extremely slow, it's far from being competitive
| at all.
| iotku wrote:
| They're prioritizing correctness to the spec over speed
| and are still 'officially' in pre-alpha. It's still to be
| determined how well they can bridge the gap there.
|
| For casual web browsing it's plenty fast enough already
| to do a lot of things, but they're a relatively small
| team fighting against decades of optimization.
| mrob wrote:
| All browsers are fast enough once you block all the
| useless web bloat.
| bowsamic wrote:
| But Ladybird's explicit goal is to work on the "real
| web", i.e. without blocking all that bloat
| ramon156 wrote:
| Very unfair to look at ladybird and call it slow, when
| its not even alpha and shouldn't be used yet
| paddim8 wrote:
| What? No one is expecting Ladybird to be fast at this
| stage. No one is claiming that it is. Ladybird is
| competitive because of the speed of which it is
| improving.
| YmiYugy wrote:
| In the update videos posted on the Ladybird YouTube channel
| it's said that they have exhausted most of the low hanging
| fruit in terms of correctness. Browsers and the web
| standard have a very long tail of odd behavior that you
| need to implement. I could be wrong, but if I had to guess
| they'll stall at a point where it's just good enough that
| some people will make it work, but it's not really useful
| for general use.
| 0x000xca0xfe wrote:
| True, but the longer the tail the less likely that you
| are affected by it.
|
| Since a couple weeks ago it became possible to view all
| major commercial news websites I use in my country.
|
| If it works for most websites and you only have to reach
| for Chrome sometimes it would still be perfectly usable.
| xdfgh1112 wrote:
| It is donation funded with no reliance on outside parties.
| They don't have to inject ads into pages like brave did or
| sell out to Google compromising their independence on web
| standards.
|
| They're ahead of Servo already anyway, and better funded.
| YmiYugy wrote:
| In the last 24h alone Chromium merged almost 900 CLs (their
| equivalent to a pull request) into the src/Chromium repo,
| Ladybird had 7. Yes a project that started fresh a couple
| of year ago with decades of hindsight can be more efficient
| than one started 16 year ago as the fork of a fork, but if
| I had to guess they'll sooner or later reach a point where
| they have implemented the low hanging fruit and chromium
| moves faster away than they can catch up.
| keysdev wrote:
| It was the similar sentiment with 0xide.
| materielle wrote:
| I think there are two things to keep in mind.
|
| 1) Apple and Firefox have enough resources to implement the
| most recent web standards. When you see a feature which goes
| un-implemented for too long, it's almost surely because
| nobody was even working on it because of internal resourcing
| fights.
|
| 2) Devs aren't created equal. It's possible for a team of 8
| people to be 10x more productive than another team of 8.
| bornfreddy wrote:
| > When you see a feature which goes un-implemented for too
| long, it's almost surely because nobody was even working on
| it because of internal resourcing fights.
|
| Or because they are reluctant to implement it for technical
| reasons? Not every "standard" that gets thrown on the table
| and implemented by Google is a brilliant idea.
| paddim8 wrote:
| Well Andreas Kling has worked on Safari and WebKit and
| (obviously) has talked to a lot of browser people. He knows
| what he is doing, and he frequently says that no one that has
| actually worked on a browser thinks it's impossible to create
| a new one, even with a small team (...of highly motivated and
| skilled people).
| Buttons840 wrote:
| Looks interesting, but they're going to try writing it in
| Swift?
|
| If you're writing a browser engine in C++, I may not like it,
| but I can see that you're pragmatic and are focused on the end
| result rather than the language. If you're writing it in Rust,
| okay, you maybe have your eyes on that pie in the sky, but
| you've chosen a language that, at least potentially, has the
| ability to replace C++ in creating bedrock software.
|
| Any other language and I feel like someone with a lot of
| political capital at the company just has a personal preference
| for the language and so, "yeah, we're going to rewrite it all
| in Swift"[0].
|
| I mean, you're writing a browser. Do you really want to build
| it in a language that is at the "it's improving" stage of
| support for the most popular operating systems?
|
| [0]: https://x.com/awesomekling/status/1822236888188498031
| jm4 wrote:
| You should look into why they chose it and what their
| implementation plan is. They evaluated multiple languages,
| including rust. There were some specific issues with rust
| that made it unsuitable for them. Swift was a bit of a dark
| horse candidate that the developers ended liking.
|
| There is no immediate plan to switch to anything so it's
| still C++. They may not ever switch. Swift's cross platform
| support isn't there yet and that's a prerequisite.
| Buttons840 wrote:
| I couldn't find any information beyond that Tweet I linked.
| jm4 wrote:
| I'll see if I can find it. I don't remember the specifics
| on rust, but it sounded like they gave it a fair shot. It
| was basically the one to beat until they figured out it
| wasn't going to work. The decision to adopt Swift wasn't
| made on a whim and, frankly, I'm skeptical it will happen
| any time soon, if ever. I think it's one of those
| situations where they want to make it more accessible to
| a next generation of developers the same way Linux is
| adopting rust. Swift is actually a really nice language,
| despite being associated primarily with Apple. It would
| be cool to see higher adoption.
|
| Ladybird has an interesting way of documenting web
| standards in code. They put a link to the reference doc
| at the top of a function and then each rule in a comment
| where it is implemented. It's very easy to follow and
| good quality code. Another project I recall having high
| quality code was KHTML. Not coincidentally, Andreas Kling
| worked on that one too.
|
| There are examples here: https://github.com/LadybirdBrows
| er/ladybird/tree/master/Libr...
|
| Anyway, the point is what they are doing is working well
| and Swift won't be ready for a while. If it ever happens,
| it won't be a rewrite. It'll more likely be a situation
| where it's written in both the same way Linux is both C
| and rust.
| Buttons840 wrote:
| > [Rust] was basically the one to beat until they figured
| out it wasn't going to work.
|
| I'd love to know more about this.
| jm4 wrote:
| Found it! It was on a podcast:
| https://changelog.com/podcast/604
|
| Here are some key quotes: "something that matters to us a
| lot is OO. Web specs & browser internals tend to be
| highly object-oriented, and life is easier when you can
| model specs closely in your code."
|
| "So what I've done is I've asked a bunch of people to
| "Please implement these things in a couple of different
| languages. And then we can talk about how that went, what
| you liked about each language, and which one you would
| like to work in every day." And what we ended up with was
| that people were initially excited to work in Rust,
| because there's a lot of hype, and it's like a popular
| language... And you would think that it's the greatest
| thing since sliced bread... And in many ways it is, if
| what you want is sliced bread. Or I don't know where I'm
| going with that. But it works well for a lot of things."
|
| "But it turns out it's not ideal for building a
| browser... Because the browser stack sits on top of this
| API that was designed in the '90s, inspired by Java and
| XML and stuff like that at the time. This '90s API, and
| it set the core of the web stack. And it's super object-
| oriented, and it's just hard to express all that stuff in
| Rust, because Rust doesn't lend itself to object-oriented
| programming. It doesn't have inheritance, for example,
| which is a very fundamental building block."
|
| "And so what happened was I asked people to write in
| Rust, and they were initially excited, and then they came
| back frustrated. And nobody had a good time working in
| Rust, as far as I understood, when doing anything but
| trivial programs that like take an input and transform it
| into something else. The moment you try to model
| something, sort of in a browser space, it just became
| tedious."
|
| "So we looked at some other languages, and the one that
| everybody has liked so far has been Swift. So it's a bit
| of an unlikely candidate, but we decided to look at it,
| because it is a safe, modern language, that has great
| object-oriented programming capabilities. I would say
| it's even better than C++ in many ways. And it's a little
| weird, because it feels like an Apple product almost, but
| they've been making great strides on Linux and Windows.
| Especially now, the upcoming Swift 6 is looking like it's
| going to be a really good release on other platforms as
| well... So that's sort of where the ship is pointing
| right now. We haven't committed to it, because we're
| still figuring out how to do some things, but it's been
| really positive, and everybody's enjoyed working in it,
| myself included. It's been fantastic. So that's sort of
| what we're looking at."
| zozbot234 wrote:
| > This '90s API, and it set the core of the web stack.
| And it's super object-oriented, and it's just hard to
| express all that stuff in Rust, because Rust doesn't lend
| itself to object-oriented programming. It doesn't have
| inheritance, for example, which is a very fundamental
| building block.
|
| That's a rather strange criticism, seeing as the only
| thing about objects that's slightly involved to express
| in Rust is _implementation_ inheritance; and even then,
| it can be phrased in a very reasonable way by using the
| generic typestate pattern. I.e. expressing a class that
| can be inherited from as a generic object MyBaseClass
| <T>, where T holds the "derived" object state (and can
| itself be generic in turn, thereby extending the type
| hierarchy) and methods can either be implemented for any
| MyBaseClass<T> or for some specific
| MyBaseClass<MyDerivedObject>.
|
| (This aims to do the right thing whenever a method on the
| base class relies on some method implementation that's
| defined deeper in the hierarchy, i.e. there is an
| indirection step, aka open recursion. That's the part
| that is missing when using simple composition.)
| Buttons840 wrote:
| I appreciate the details.
|
| Ultimately I'm not dissuaded from my original impression.
|
| I worked at a company doing web scraping, and our code
| sucked and we knew it, and the lead programmer kind of
| liked Elixir, and we were always going to rewrite in
| Elixir one day, and he would mention it in interviews and
| stuff, and put it on job requirements, but really there
| was almost no Elixir in the company. We came up with all
| sorts of reasons Elixir would make sense technically, I
| even offered some myself because I got positive social
| feedback when I spoke well of Elixir. But now that I'm
| out of the company, I can see that Elixir is not uniquely
| suited to solve the problems we had. It was just one guy
| liked Elixir and so ultimately we all did.
|
| I still predict the same for LadyBird. You can even see
| in the Tweet I linked that they choose C++ because of one
| person, so I'm guessing that one person also likes Swift.
| Time will tell.
| Perz1val wrote:
| Andreas has said that in some video I watched at some
| point, can't pinpoint it, but I can confirm jm4 didn't
| make it up
| jonkoops wrote:
| I have to be honest that I don't really understand the appeal
| of Ladybird from a purely technical perspective. It is written
| in C++, just like all the existing engines (yes there is some
| Swift, but it is negligible), so what benefit does it provide
| over Gecko or Blink? With Servo, I can see there is a distinct
| technical design around security and parallelism.
| BrawnyBadger53 wrote:
| There is more to a project this massive than its choice of
| language. For me though it's mostly about breaking from the
| monopoly and putting a check on Google's influence over
| browser space.
| mdaniel wrote:
| > There is more to a project this massive than its choice
| of language
|
| For writing a game, or Figma replacement, or some cutesy
| something that runs on your machine without requiring
| network access, probably. For one of the most impactful
| applications that downloads untrusted code from the
| Internet and executes it without any confirmation
| whatsoever, the language for sure does matter. "Chrome RCE"
| is a phrase that strikes fear, and it's not a rare
| occurrence. I'll point out that Google is not lacking some
| of the most skilled security researchers and tooling in the
| world, so I wish the Ladybird folks godspeed doing their
| own "does this build have vulns?" work
| paddim8 wrote:
| Well that's why they're going to rewrite parts of the
| code where those things are more likely in Swift
| rollcat wrote:
| Many many factors to consider. Simplistic take: KHTML was
| picked up by Apple because of its clean design and codebase;
| there's an extra 30 years of accumulated improvements in C++;
| you don't write stuff in Rust 1.0 either.
|
| Also: Andreas has worked on Webkit/Blink. He knew what he was
| doing when he started the project, even if it was "just for
| fun". Linux started under similar circumstances.
| Perz1val wrote:
| Rust does not produce magic in the assembly code. It does not
| even produce faster assembly code. Rust toolchain on it's own
| does not even produce assembly code. It just passes that to
| LLVM that does THE ENTIRE optimization. Without LLVM (written
| in C++) doing the heavy lifting, Rust is probably slower than
| V8 (written in C++) running JavaScript. There's no technical
| marver in Servo compared to Ladybird. I don't understand the
| yapping how a language makes projects good/bad, despite it
| being proven completely false again and again. The appeal is
| in independence and politics around the project.
| jcranmer wrote:
| The express purpose of building Servo in the first place
| was to experiment with ways to parallelize the layout
| algorithm. The advantage of Rust is that it is a language
| which enables the compiler to better enforce some of the
| rules that need to be followed to write correct thread-safe
| code. Note that Mozilla had previously tried--more than
| once--to do the same thing in C++ for Gecko, and both
| attempts had failed.
|
| As for the rest of your comment... I believe Rust now has
| MIR-based optimizations, so it's no longer the case that
| "THE ENTIRE optimization" is due to LLVM. But it's a non-
| sequitur to say that Rust would be slower without LLVM.
| Rust doesn't do many optimizations on its own, because it's
| quite frankly a lot of boring tedium to implement an entire
| optimizing compiler stack, and if you've got a library you
| can use to do that, why not? If no such library were
| available, Rust would merely be implementing all of those
| optimizations itself, much as V8 implements those
| optimizations itself.
| sdcoffey wrote:
| All-time opener
| kookamamie wrote:
| > The Dogemania test ran at a smooth 60 FPS on my M4 Pro MacBook
| Pro until reaching around 400 images
|
| I ran Dogemania on Chrome until 1400 images at steady 60 FPS at
| which point I got bored and closed the tab.
| specproc wrote:
| Wow, just did this myself. The difference between Firefox and
| Chromium was depressing.
|
| I'm getting >100 FPS almost consistently all the way up to
| 1,000 in Chromium, FF barely made it above 500 before dropping
| below 60.
|
| Probably not a completely fair test, I've no extensions etc. on
| Chromium and only use it for the odd stubborn website, but that
| was quite a lesson in their comparative performance.
| empath75 wrote:
| Chrome has thousands of developers working it. That is a lot
| of man hours for small optimizations.
| lvass wrote:
| For me it was stable 120fps on firefox at 2200 and 60fps at
| 3200, using 200W in my RX 6750XT.
|
| Chromium hit below 60fps at around 4000 and below 30fps at
| 6000 but used my integrated intel GPU all the time.
| bravesoul2 wrote:
| If dogemania keeps the images still after animation isn't it
| embarrassingly optimizable? Why cant an Amiga do infinity of
| these?
| kookamamie wrote:
| It did! Infinite bobs.
| nicoburns wrote:
| > The current roadmap lists Shadow DOM and CSS Grid as priorities
|
| I've been working on the CSS Grid support. About to land "named
| grid lines and areas" support which should make a bunch more
| websites layout correctly.
|
| I'm biased because it's my project, but IMO the approach Servo is
| using for CSS Grid is pretty cool in that the actual
| implementation is in an external library (Taffy [0]) that can be
| used standalone and is widely used accross the Rust UI ecosystem,
| including in the Blitz [1] web engine (which also uses Taffy for
| Flexbox and Block layout), the Zed [2] text editor, and the Bevy
| [3] game engine.
|
| I'm hopeful that this approach of breaking down a web engine into
| independently usable modules with public APIs (which builds upon
| Servo's earlier work on modular libraries such as Stylo and
| html5ever) will make it easier for people to get involved in web
| engine development (as they can understand each piece in
| isolation), and make it easier for people to create new web
| engines in future (as they won't have to start completely from
| scratch).
|
| [0]: https://github.com/DioxusLabs/taffy [1]:
| https://github.com/DioxusLabs/blitz [2]: https://zed.dev [3]:
| https://bevy.org/
| fouronnes3 wrote:
| Does having experience implementing a web browser engine
| feature change the way you write HTML or CSS in any way? Do you
| still google "css grid cheatsheet" three times a week like the
| rest of us?
| rockwotj wrote:
| To me, this is like asking if having built a sql engine if
| you write SQL differently.
|
| I think the answer is yes. Having a strong understanding of
| the underlying engine helps you debug and optimize more
| quickly
|
| Needing reference stuff never changes unless it's so
| frequently used.
| nicoburns wrote:
| > Does having experience implementing a web browser engine
| feature change the way you write HTML or CSS in any way?
|
| I think I'm more concious of what's performant in CSS. In
| particular, both Flexbox and CSS Grid like to remeasure
| things a lot by default, but this can be disabled with a
| couple of tricks:
|
| - For Flexbox, always set `flex-basis: 0` and `min-width:
| 0`/`min-height: 0` if you can without affecting the layout.
| This allows the algorithm to skip measuring the "intrisic"
| (content-based) size.
|
| - For CSS Grid, the analogous trick is to use `minmax(0,
| 1fr)` rather than just `1fr`.
|
| (I also have a proposal for a new unit that would make it
| easier to get this performance by default, but I haven't
| managed to get any traction from the standards people or
| mainstream browsers yet - probably I need to implement it and
| write it up first).
|
| > Do you still google "css grid cheatsheet" three times a
| week like the rest of us?
|
| Actually no. The process of reading the spec umpteen times
| because your implementation still doesn't pass the tests
| after the first N times really ingrains the precise meanings
| of the properties into your brain
| nashashmi wrote:
| How do you propose standards to the web groups?
|
| I want to propose CSS-inheritance--by-name (#box
| {inherit:$(#menu)})
|
| and the reintroduction of marquee tags for horizontal
| scrolling (a frequently used UI pattern on shopping sites).
| nicoburns wrote:
| > How do you propose standards to the web groups?
|
| I'm not sure. I tried opening an issue at
| https://github.com/w3c/csswg-drafts but that didn't get
| me very far. I suspect it's a case of making connections
| and then getting yourself an invite to present at a
| meeting.
| pxeger1 wrote:
| I succeeded with opening an issue and getting something
| to be supported in browsers (although I think it's not
| yet in the standard). It was a very small and fairly
| uncontraversial tweak which was easy to specify,
| implement, and test, though - bigger things are probably
| harder.
|
| https://github.com/w3c/csswg-drafts/issues/6203
| spankalee wrote:
| If you can socialize your idea to a few of the people
| that show up frequently in the issues, it can really
| help. See if there's someone with open DMs, tell them you
| work on CSS in Servo, and ask what they think.
| dleeftink wrote:
| (Just say yes, you have to look it up all the time so we
| don't feel as bad)
| nielsbot wrote:
| I wish there was a CSS analyzer that would give tips like
| this based on your CSS.
| fouronnes3 wrote:
| Or a straight up fork of CSS that removes the legacy
| stuff and fixes wrong defaults so that tips like this are
| unnecessary in the first place.
| mort96 wrote:
| I don't think it's necessarily a wrong default, just one
| which prioritizes usability/ease of programming over
| performance.
| nielsbot wrote:
| Or maybe a v2 syntax mode? Akin to `"use strict";` in JS.
| piker wrote:
| Do you not worry that instead it will lead to feature bloat and
| fragmentation? If you're going to strike at Google, you need
| laser focus.
| nicoburns wrote:
| Not really. Everything has a spec, so it's pretty clear
| what's in scope and what isn't. Also, we don't have time for
| bloat with our team size. We have to be laser focussed on
| what actually makes a difference to real websites. It's
| Chrome that has bloat!
|
| Also the specs don't change much (there are additions, but
| almost always backwards-compatible), so once written the code
| shouldn't need too much maintenance.
|
| I see it as writing a piece of foundational infrastructure.
| You can write your own HTTP library. But you don't need to:
| there are high-quality libraries readily available (e.g. curl
| or hyper). Similarly for HTML parsers or 2D graphics
| rendering. Nobody's done that for web layout yet (except
| arguably React Native's Yoga [0], but that's much less
| ambitious in terms of how much of the spec it attempts to
| support), so everybody has to write their own. But it's
| possible so we're doing it.
|
| [0]: github.com/facebook/yoga/
| afavour wrote:
| Shadow DOM and CSS Grid don't strike me as bloat or
| fragmentation in any way? CSS Grid in particular is table
| stakes that would be part of any laser focus.
| goku12 wrote:
| > (Taffy [0]) that can be used standalone and is widely used
| accross the Rust UI ecosystem, including in the Blitz [1] web
| engine (which also uses Taffy for Flexbox and Block layout)
|
| This is the first time I hear about Blitz. Looks equally
| interesting and ambitious. It is probably the real undercover
| web engine. Servo was widely known around when Rust debuted.
| echelon wrote:
| Questions for the Rust UX experts:
|
| Is Dioxus (or Leptos) much more performant than
| Tauri/Electron?
|
| I want to (1) build blindingly fast, low-latency, super
| performant UX for users, which precludes Tauri/Electron
| (something I'm currently using and unhappy about), but I also
| want to (2) maintain developer velocity, (3) have access to
| nice UX primitives and widgets, and (4) have it look nice and
| modern.
|
| Javascript/browser-oriented frameworks make requirements 2-4
| easy, and it has the side benefit of also making hiring easy
| (not a requirement per se). But the results feel so bloated
| and anti-Desktop/native. It gobbles up RAM and renders
| slowly, even when best practices are used. It's the very
| definition of a double-edged sword.
|
| Are these four requirements simply impossible to satisfy
| together for native Rust UX toolkits right now?
|
| Rust's egui looks amazing, but I doubt you'd be able to build
| a very complicated UX with it. Or if you could, it might take
| you half a year to deliver.
|
| Iced also looks cool, but looks less featureful.
|
| Are there any "non-browser" Rust UX toolkits that aren't
| dated GTK/KDE frameworks, but that can build graphically-
| oriented (not just text/button widget) programs?
|
| If I were building a "slimmed down photoshop", are there any
| Rust GUI toolkits to reach for? Or if I were incorporating a
| Bevy or 3D render pane?
| airstrike wrote:
| I'm super biased in favor of iced.
|
| Yes, there are missing features (it's not even version 1.0
| yet!) but I think the number is very small now and the
| solution is usually to fill in the gaps yourself--which is
| possible because iced is totally modular
|
| I've made a spreadsheet editor and a slideshow editor with
| it so "slimmed down photoshop" seems feasible although
| admittedly you will likely need to get deep into the
| renderer (possibly write your own renderer traits and
| there), but I suppose you're comfortable with that given
| your goal.
|
| If you're not allergic to Discord, come join us. It's a
| helpful, awesome tight community IMHO
|
| Link for the lazy: https://discord.gg/3xZJ65GAhd
|
| Project link: https://iced.rs
| Macha wrote:
| No support for RTL or CJK text, IMEs, or accessibility
| tools leaves it pretty firmly in the "toy" category for
| me for now, sadly.
|
| This isn't meant to bash on the project specifically,
| basically the only tools that meet that criteria are
| platform native UIs, the web stack (including Electron),
| Qt and Flutter.
|
| AccessKit is promising to change that but I haven't
| checked in a while how it's going. I did see GTK looking
| into it as a cross platform option as GTK's accessibility
| support only works on the Linux desktop currently
| airstrike wrote:
| In that case, I'm happy to let you know your info is
| outdated. CJK/IME support has landed.
|
| https://github.com/iced-rs/iced/pull/2777
| echelon wrote:
| sugoi!Japanese is one of our localization targets, so
| this is amazing!
|
| I'm building a graphically heavy app, so two more
| questions:
|
| 1) Is iced appropriate for building a canvas-type drawing
| app with image inclusions? Right now we're using Konva.js
| and we'd be losing a tremendous amount of out of the box
| flexibility in porting to iced, but the performance wins
| would be a major selling point.
|
| 2) Can you include Bevy panes? We're also doing some 3D
| visualization, and we currently use Three.js. But we have
| a lot of Bevy experience too.
| airstrike wrote:
| Awesome! Glad to hear that and I hope you do give it
| another try.
|
| 1. Yes but not necessarily a "resounding yes" because
| images right now are drawn on the top of each layer, so
| if you want to write on top of images you'll need to
| create different layers for each of them which is more
| expensive than not doing that. You may be OK with that
| for now (I am, for my slideshow editor), but there's
| pending work to be done there to remove the requirement
| of explicit layering and thus improve performance.
|
| 2. I'm not familiar enough with Bevy to opine. I know
| there's https://github.com/tasgon/bevy_iced but I think
| that might do the opposite of what you want. Having said
| that, iced lets you write custom shaders so you can go as
| deep in the stack as you'd like for any 3D visualization.
| The caveat then being that you're implementing all that
| logic yourself, but there's no stopping you.
|
| Importantly, I think it's worth joining the Discord and
| asking around, seeing what people are building, trying
| the library, and pointing out where you think you need
| help. This helps the core team understand use cases
| better and in some ways guides development IMHO. I'm not
| part of the core team, so I could be wrong, but that's my
| perception.
| goku12 wrote:
| > No support for RTL or CJK text, IMEs, or accessibility
| tools leaves it pretty firmly in the "toy" category for
| me for now, sadly.
|
| I18n, L10n and A11y tend to be very challenging features,
| making your wishlist a tall order. Solving that will
| require a larger developer mindshare. (I'm not sure how
| much of the existing frameworks can be reused here).
|
| > basically the only tools that meet that criteria are
| platform native UIs ...
|
| Here's the good news! Iced is already a platform native
| UI toolkit. It powers the Cosmic desktop and a few
| important applications are based on it. Iced is sure to
| receive a lot of attention once Cosmic stabilizes.
| Hopefully, you will get your wish sooner than later.
| daniel_sim wrote:
| Check out https://www.gpui.rs/ too
| nicoburns wrote:
| > Is Dioxus (or Leptos) much more performant than
| Tauri/Electron?
|
| For now it's largely the same. Both Dioxus and Leptos
| render using Tauri (or a web browser). For Dioxus, a Blitz-
| based renderer (Dioxus Native ) is in development which
| will change the story slightly.
|
| I would suggest Iced if you're looking for efficient (I
| don't think it's any less featureful than any other Rust-
| based GUI). With honourable mentions for Slint and Vizia.
| jpc0 wrote:
| > I want to (1) build blindingly fast, low-latency, super
| performant UX for users, ... (2) maintain developer
| velocity, (3) have access to nice UX primitives and widgets
| ... (4) have it look nice and modern.
|
| Find me when you find this, because I actually think it is
| impossible.
|
| I think there is fundamentally too much inherent complexity
| to abstract away to keep 2 and not sacrifice 1.
| Specifically for something properly cross platform.
|
| If you are only targeting MacOS or windows then I think
| it's absolutely possible but then you are using the wrong
| language, nothing against rust at all on that, the platform
| defaults are just swift / C# for those use cases.
|
| And I'm not sure but unless you are just using a gtk/Qt
| style framework you would absolutely run into a11y problems
| that you would need to build around yourself.
|
| Sounds like you probably want egui though... if your
| primary UI is a big canvas that needs to be hardware
| accelerated and interaction is just to assist that use case
| egui is probably a good bet for you. But you wouldn't be
| hiring web devs to do that.
| cosmic_cheese wrote:
| I believe it's possible, but it's going to take a little
| bit of outside of the box thinking in that it'd be most
| practical if the UI toolkit isn't bound strictly to a
| single paradigm.
|
| Both imperative and declarative UIs have serious
| problems. Imperative toolkits can get hairy with their
| boilerplate and can make staying in sync with data state
| a real challenge, while declarative toolkits have a
| strong tendency towards rigidity that makes for awkward
| DX and ugly code in all but the simplest todo app kind of
| examples and don't lend themselves to fine grained
| control.
|
| I think there's a happy medium to be found between the
| two in a well-designed hybrid. This hypothetical
| framework would allow full declarative in situations
| where that's highly suitable, but would also allow the
| dev to do widget configuration in a more traditional
| imperative style or if necessary fall back to full
| imperative. Support for reactivity on both sides of the
| coin would be robust so staying in lockstep with data is
| simplified.
|
| This would bring down boilerplate substantially since the
| broader layout of most screens could be done
| declaratively, but it wouldn't come at the cost of more
| advanced functionality, flexibility, and developer
| control on the individual widget level.
|
| I'd like to dig further into these ideas at some point if
| I get time.
| jpc0 wrote:
| I've been thinking about this myself and really UI
| development is mostly about design up front, many times
| with a well built design system UI changes can be
| trivial.
|
| But as you alluded to, data binding can be difficult. For
| some things, and even most web pages fall into this, you
| effectively load the data up front render something and
| then don't touch it again, on change you can absolutely
| just rerender everything because it is truly trivial to
| render.
|
| But for other things you need extremely complex data
| binding with constraint systems and things are extremely
| complex to render (CAD, Games, etc). For that you need
| cacheing and partial updates etc
|
| These is a spectrum between that and I just don't see the
| ability to abstract over it.
|
| And taking a11y into consideration no matter how you
| choose to render you also need to construct a tree or
| graph for screen readers, this also needs data binding.
| You will probably also be tying keyboard navigation to
| that graph (other than for a game but even then maybe)
|
| I feel like though a lot of performance problems on web
| is 1) people not understanding fundamentally how
| expensive certain operations are 2) lack of hardware
| acceleration for some vector operations in CEF / browsers
|
| For 1 just think about some UI element, a rounded button
| or something. A mesh had to be dynamically generated for
| that UI element and then drawn, if you for some reason
| are causing that mesh to be regenerated every frame that
| becomes expensive very quickly.
|
| Text is generally generated on the fly and cached as
| well, if its not software rendered.
|
| Once you get down to the nuts and bolts modern UI is a
| complex problem, and to build a framework for that, you
| need to get into the nuts and bolts.
|
| We're not even discussing rendering APIs yet...
| cosmic_cheese wrote:
| This is part of why I believe that smart hybridization is
| the key. In a complex application, you need qualities
| from all major schools of UI framework design, but
| broadly speaking we've been obsessed with trying to find
| a "silver bullet" one true paradigm that fits every use
| case, when no such thing exists.
|
| I also think that UI frameworks try to hard too be
| "magic" and unopinionated where they should instead be
| highly communicative and naturally guide developers into
| the happy path. So following your example of the
| excessively re-rendered button, the framework should
| really be detecting the unneeded redraws and complaining
| to the dev about them and potentially even presenting as
| compiler errors in production builds until they're fixed
| (which the compiler offers hints on how to do).
| spease wrote:
| Slint recently added Bevy support. I've been keeping an eye
| on it since I've used Qt and love working in Qml.
| echelon wrote:
| Slint cites Javascript. Is it another Electron/Tauri-
| like?
| jenadine wrote:
| Slint does not use a browser. Instead, it has its own
| runtime written in rust and uses a custom DSL to describe
| the UI.
|
| It has API for different programming language.
|
| For Javascript, it uses node or deno for the application
| logic, and then spawn the UI with its own runtime without
| the browser.
|
| In a way it is the opposite which took the JS runtime out
| of electron to replace it with a Rust API, while Slint
| keeps the JS runtime but swaps the browser for its own
| runtime (for the JS dev point of view)
| Narishma wrote:
| No, it's like Qt and QML.
| rollcat wrote:
| I'm no UX expert, but I regularly try out new (and old)
| toolkits to understand the problem space.
|
| It really sounds like you want an immediate mode toolkit.
| Retained mode will never be "super-snappy", there's an
| entire sandwich between your code and the pixels. Look at
| Blender or Reaper, this is the kind of "feel" you'd be
| getting.
|
| If you want retained mode + "true" native widgets on all
| platforms, investigate: Toga (Python), WxWidgets (C++), and
| Tk (Tcl). The native toolkits are often best in class on
| each platform, and these wrappers are about as thin as they
| can reasonably get (e.g. Toga uses pyobjc). Integration
| with Rust is left as an exercise to the reader ;)
|
| A rich widget library is nice, but consider the depth as
| well. Egui went to great lengths to integrate assistive
| technologies, which depending on your target audience may
| be impactful. (Also: accessibility is for everyone.
| https://shortcat.app/)
|
| If you want easy hiring, you have to go with mainstream.
| We've +/- named all of the options by now. Otherwise, hire
| a talent who's worked on the next closest thing to what
| you're building, and trust them to decide the direction.
|
| Looks and beauty are in the eye of the beholder. There are
| many apps that have a distinct, sometimes quirky, but
| appreciable style. Reaper looks out of place on every
| platform, but I prefer it over Logic or Ableton.
| explodingwaffle wrote:
| Certainly not a "Rust UX _expert_", but I do find GPUI
| interesting. Some nice examples here of not-"just
| text/button widget programs":
| https://github.com/longbridge/gpui-component
| usrusr wrote:
| Makepad is neither gtk generation nor browser based. Might
| check the "just text/button widget" box though, I'd
| certainly place it on the minimalistic end of the spectrum.
| (haven't worked with makepad, just enjoyed the demo)
| rapnie wrote:
| Makepad [0] is indeed quite impressive. You can directly
| try Makepad Studio in your browser [1]. Don't know if
| that's the latest or the demo version. Their demo vids
| are a good watch.
|
| [0] https://makepad.nl
|
| [1] https://makepad.dev
| nicoburns wrote:
| > this is the first time I hear about Blitz. Looks equally
| interesting and ambitious. It is probably the real undercover
| web engine
|
| It's certainly a newer and lesser-known engine. It's mostly
| been me working on it for the past year or so (with a couple
| of other occasional contributors). But I do have funding to
| work on it full time through DioxusLabs (who are building
| Dioxus Native - a Flutter / React Native competitor on top of
| it) and NLnet (who are a non-profit interested in the
| alternative web browser use case).
|
| We're trying to really push on the modular side of things to
| create a web engine that's flexible / hackable and can be
| moulded for a variety of use cases.
|
| We'd love more contributors, so if anyone is interested in
| getting involved then drop by our GitHub
| (https://github.com/DioxusLabs/blitz/) or Discord
| (https://discord.gg/AnNPqT95pu - #native channel)
| goku12 wrote:
| You have my admiration and support for this work! I guess
| it goes without saying how monumental and critical the work
| on alternative engines like servo and libweb are. We are
| genuinely tired of the current duopoly (I'm starting to
| lose hope with Firefox and gecko as well. They seem to have
| priorities different to our expectations.) But I guess we
| now have one more to look forward to, thanks to you and the
| rest of the team! Personally, I hope to pitch in as soon as
| I have some spare time available. Regards!
| dingi wrote:
| Just skimmed through the Blitz source. Really interesting.
| I don't have experience with UI rendering or Rust, but I
| couldn't help wondering: if you leave out things like local
| storage and websockets, why include networking at all?
| Feels like a separate concern. Genuinely curious. Great
| project. Wishing you all the best!
| jkelleyrtp wrote:
| Gotta fetch images and stylesheets from the network!
| 01HNNWZ0MV43FF wrote:
| > breaking down a web engine into independently usable modules
| with public APIs
|
| I love that. Years ago I looked at WebRTC and asked myself, why
| does it seem like making a crummy Skype knockoff is either 50
| lines of JavaScript or a nightmarish week of trying to get half
| of Chromium to compile in your C++ project?
|
| I think there is a WebRTC Rust crate finally, which is good.
| Web apps shouldn't be the only beneficiaries of all this
| investment
| gr__or wrote:
| That's so fun to hear, I've been using taffy for layouting my
| little rusty eink calendar
| zellyn wrote:
| > the MacRumors home page crashed after some scrolling
|
| I know there's a ton going on, with GPUs and rendering and all
| kinds of things, but I guess because Rust's memory safety and "no
| null pointers!" are so constantly hyped (especially in
| conversations about Go), that I'm always surprised when you fire
| up a Rust app and do something and it crashes out...
|
| [To be clear, I'm a big fan of modern sum types, and like to
| imagine an alternate reality where Go had them from the start...]
| IshKebab wrote:
| When they say "it crashed" they probably mean it panicked or
| just failed to render; not a segfault.
|
| Most languages have a way of saying "I haven't handled this
| case yet; just exit the program if you get here".
| jpc0 wrote:
| Rust also doesn't consider DOS a failure condition.
|
| Reading an invalid index, thats a panic.
| empath75 wrote:
| It can also get oomkilled
| oaiey wrote:
| Describing Servo as "new" is a stretch ;)
| timbit42 wrote:
| It started later than the other engines and it seems to have a
| number of great ideas the other engines haven't adopted yet.
| AdmiralAsshat wrote:
| I feel like Mozilla is going to join the annals of history with
| the likes of Xerox in the category of "Companies that created the
| technology of the future and casually tossed it to the wayside
| for competitors to scoop up" with Rust and Servo.
|
| It's mind-boggling that for a company so often seemingly playing
| catch-up with Google, Mozilla actually _leapfrogged_ Google in
| the browser development space for a time, and then...decided it
| wasn 't worth pursuing any further.
| nicce wrote:
| It is difficult to get people to pay for it. People happily pay
| for 10EUR beer but asked "friends" about how to bypass
| WhatsApp's 0,99 lifetime licenses.
| skinkestek wrote:
| Some did. Some like me lined up eagerly to pay the $1 yearly
| license and would have been happy to pay for my family too.
| yjftsjthsd-h wrote:
| And it's impossible to get people to pay for it when you give
| them no way to pay for it.
| CivBase wrote:
| You can donate, but who's going to pay $10 for beer when
| the same stuff is being given away for free?
| yjftsjthsd-h wrote:
| No, you can't. You can donate to the Mozilla Foundation,
| but you cannot donate to the Mozilla Corporation to
| actually fund Firefox development.
| LtdJorge wrote:
| Exactly. You can donate to a bunch of management people
| with multiple million dollars compensation that are
| running the company into the ground.
| argomo wrote:
| https://www.mozillafoundation.org/en/what-you-can-
| do/?form=d...
| yjftsjthsd-h wrote:
| https://www.mozillafoundation.org/en/donate/help/#frequen
| tly...
|
| > How will my donation be used?
|
| > These funds directly support advocacy campaigns (i.e.
| asking big tech companies to protect your privacy),
| research and publications like the *Privacy Not Included
| buyer's guide and Internet Health Report, and covers a
| portion of our annual MozFest gathering.
|
| Notice what donations aren't used for: Firefox.
| uncircle wrote:
| I've heard the same thing about monetising search engines.
| Kagi didn't get the memo, and last I've heard they're turning
| a profit.
|
| Sure, only nerds would pay for it, but not all products have
| to capture 100% market share.
| danelski wrote:
| But independent browsers need this metric. Good luck
| convincing website owners to test against your non-chromium
| browser with 0.3% market share.
| rollcat wrote:
| Twitch randomly blocks Chromium.
|
| (They don't even block the streams, only logins. I can
| watch, but not spend money. Perfectly reasonable.)
| tux3 wrote:
| Huh? That's crazy, I've never been blocked on Firefox,
| which is much smaller. And packed with privacy addons.
| WD-42 wrote:
| Okay but if everyone building the websites are using the
| browser with 0.3% market share it won't matter.
| nicce wrote:
| They don't. Most of the common web developers do what the
| managers and users require. Otherwise you are not
| providing value and using your time efficiently.
| drdaeman wrote:
| I'm not tracking what's currently going on with the
| underwater portion of frontend iceberg. Are things still
| like it was in late '00s and early '10s, where browsers
| still had plenty of their unique implementation quirks
| and non-standard features, and plenty of sites were
| relying on those?
|
| Back in the day, it was not entirely unheard of having
| two significantly different frontend implementations -
| one for IE, another for Netscape, with quite unhealthy
| amounts of parser hacks to hide code from the browsers.
|
| Possibly naively, but I think it's not that bad nowadays?
| (At least it wasn't so in late '10s.) Some things are
| Chrome-only, or Apple-only, but I rarely see "not
| supported in your browser" - the majority of features is
| generally standards compliant, and all those newcomer
| engine problems (like in the article) are mostly because
| there's a lot to implement.
| nicce wrote:
| It is not about what is supported now, but what will be
| supported in the future? Google is pushing most of the
| web standards and has a huge influence. Other, less used
| browsers must support them if they want to have any
| chance.
|
| You should ask that how many of the standard features are
| brought by someone else without huge influence of Google.
| If you cannot get anything new, when it is enough that
| Google says "no", then in reality there is only one
| browser.
| bowsamic wrote:
| > People happily pay for 10EUR beer
|
| I would not be happy to pay that much for a beer
| calibas wrote:
| > It's mind-boggling that for a company so often seemingly
| playing catch-up with Google, Mozilla actually leapfrogged
| Google in the browser development space for a time, and
| then...decided it wasn't worth pursuing any further.
|
| Google has been Mozilla's main source of revenue since around
| 2006. For Mozilla to exist, all they have to do is keep Google
| happy.
|
| It's kind of a nice deal for Mozilla, despite being a huge
| conflict of interest.
| rollcat wrote:
| And it's an even better deal for Google. "But look, Chrome is
| not a monopoly."
|
| If I was Google, I'd do something to set Mozilla back on that
| track. But oh well, Google these days is even more
| dysfunctional. They're about to lose search.
| AceJohnny2 wrote:
| Remember that time Microsoft bankrolled a floundering Apple
| to able to "But look, Windows is not a monopoly"
|
| https://thisdayintechhistory.com/08/06/apple-and-
| microsoft-c...
| godshatter wrote:
| If Mozilla decides to dump Gecko, then it's time for a hard
| fork and an abandonment of Mozilla. Maybe it's time now.
|
| edit: I mean dumping Gecko for Chromium, not Servo.
| goku12 wrote:
| Honestly, dumping gecko would be a suicide for Firefox. Much
| of Firefox's minuscule userbase consists of knowledgeable
| nerds who are holdouts from the Blink monoculture.
| dralley wrote:
| So start replacing bits of Blink with Rust, instead of bits
| of Gecko.
|
| Maybe their primary addressable market is nerds, but I
| guarantee more people quit using Firefox because of
| websites not working correctly or Google's marketing than
| because of any of the things that HN loves to complain
| about.
| criticalfault wrote:
| This is only fair.
|
| Mozilla doesn't deserve to survive. New players deserve our
| support, like servo and ladybird.
|
| Even with an enormous budget from Google (500M, I think per
| year) they managed to ruin everything, including Firefox, the
| thing bringing them those 500M.
|
| To me it looks as if Baker is an undercover person put there to
| sabotage Mozilla. Tldr: funded by Google, made absolutely
| everything in her power to run it into the ground
| mariusor wrote:
| Unlike historical examples like Stephen Elop that moved from
| Microsoft to Nokia and buried their mobile division only to
| return to Microsoft, Mitchell Baker was with Mozilla since
| the start.
| bornfreddy wrote:
| Yup, wouldn't be the first one [0].
|
| [0] https://en.m.wikipedia.org/wiki/Stephen_Elop
| jazzypants wrote:
| I'm not sure about that. Baker was one of the first Netscape
| employees, she literally helped found the Mozilla foundation,
| and she served as the first president of it.
|
| I'm not saying she has done a good job, but a lot of the
| early Netscape people like Brendan Eich have done nothing but
| sing her praises.
| dimal wrote:
| Mozilla is over. They put all their eggs in the Google basket,
| and soon they'll lose that. They have no viable path forward.
|
| Servo and Ladybird are the future. I'm astounded by how quickly
| Ladybird is proceeding, with far fewer people than Mozilla.
| It's been inspiring to see what that project is doing.
| GuB-42 wrote:
| Mozilla is nothing like Xerox, if anything Google is the new
| Xerox: they have way too much money so they throw it at R&D
| side projects without a business plan.
|
| The big one for Google is transformer models, they basically
| invented LLMs only to play catchup with OpenAI later.
|
| Mozilla successes have always been focused on the web browser,
| from the very beginning. Even the name reflects that: "Mozilla"
| stands for "Mosaic killer", Mosaic was the leading web browser
| at the time. They beat Mosaic with Netscape, they beat IE with
| Firefox, beating Chrome was their mission, and Rust and Servo
| were their weapons. It is sad that they dropped the ball.
|
| Like Xerox (and Google), Mozilla tried doing some side
| projects, but unlike Xerox, they didn't have money to burn from
| their quasi-monopolies, and I can't think of anything
| particularly innovative coming from Mozilla that isn't a
| browser. I don't consider Rust to be a side project, it is a
| programming language for writing a browser, that it is useful
| for projects other than a web browser is a happy side effect.
| bee_rider wrote:
| > [...] and I can't think of anything particularly innovative
| coming from Mozilla that isn't a browser. I don't consider
| Rust to be a side project, it is a programming language for
| writing a browser, that it is useful for projects other than
| a web browser is a happy side effect.
|
| I'm sure Rust started out as something intended to help with
| their browser work. But it became a general purpose
| programming language pretty early, right? I think it is...
| working pretty hard to find a reason to not include Rust as a
| innovative, non-browser piece of tech.
|
| Anyway, I don't really think it detracts from your broader
| point to count Rust as a separate thing from the browser.
| Already__Taken wrote:
| > But it became a general purpose programming language
| pretty early, right?
|
| IMO what we've seen learnt from ChromeOS and later their
| stab at firefox OS is the merit in treating the browser as
| the system. For that there was a lot of wisdom in making
| rust that capable. Seeing oxide make their stack is
| incredibly validating.
| dralley wrote:
| Servo would not have been some dramatic revolution in browser
| technology. It would have done the same thing browser engines
| currently do, but maybe a little faster and with a couple less
| security issues per year.
|
| It's dishonest to compare that to "the technology of the
| future", especially when nobody chooses their browser based on
| whether a page loads in 82ms or 70ms. They mostly choose
| browsers based on familiarity and marketing and what's
| preinstalled. Chrome is fast enough for most people that
| they're not gonna switch just because their dweeb nephew
| mentioned some other browser might be marginally faster.
|
| And they didn't toss Rust aside either. New bits of Firefox
| continue to be written in Rust to this day. That was actually
| the primary reason Servo was dropped - the bits of the browser
| engine that could be replaced with Servo bits easily had
| already been replaced. Rewriting Gecko slowly was deemed more
| practical than committing to 5+ years of parallel development
| and hoping that by the end it would be possible to replace
| millions of lines of Gecko code in one fell swoop.
| ninetyninenine wrote:
| I feel guis have taken a wrong turn. We need a simple composable
| language. I want entire theorems built from the least amount of
| axioms possible.
|
| HTML and css is not it. The sheer complexity is what causes all
| the bs.
| dmytrish wrote:
| Show us the way!
| bataleon wrote:
| Please bring this to iOS. WebKit is broken.
| samtheprogram wrote:
| If you think WebKit is broken, you should actually download a
| build of Servo and try it out.
| fHr wrote:
| I see Rust I upvote
| postalrat wrote:
| I thought it was more like: rust made for the web browser Servo.
| rrgok wrote:
| > This is a danger to the open web in more ways than one. If
| there is only one functioning implementation of a standard, the
| implementation becomes the standard.
|
| I still don't understand why this is a problem. As long as the
| engine implementing the spec - governed by committee formed by
| entities other than Google itself - is open source. The problem
| and the waste of resource is how we are behaving now.
|
| The browser engine should become as the Linux Kernel: one engine
| and different distros.
| mrob wrote:
| I disagree. The more browser engines in use the less damage any
| one security exploit can do. This matters even with memory safe
| languages, because logic errors can be just as damaging, e.g.
| the Log4j exploit.
| merelysounds wrote:
| In theory yes. In practice, only when the interests of the sole
| maintainer are aligned with the interests of the users; since
| these can change, it's best to avoid a monopoly.
|
| Case in point, recent manifest v2 deprecation is generally
| disliked by the community and no long term blink based
| alternative exists (that I know of).
| rollcat wrote:
| > The browser engine should become as the Linux Kernel: one
| engine and different distros.
|
| Try spending a month with a BSD - personally, I recommend
| OpenBSD, or (yes) macOS. Alternatively, try ZFS where you've
| previously used mdadm+lvm+luks+etc.
|
| The difference is like sitting in a chair that has all of its
| screws tightened. You only notice how bad was your previous
| chair once you feel there's no wobbling.
| RGBCube wrote:
| That's more of a distro thing than "Linux being a few screws
| loose".
|
| I vastly prefer the OpenBSD kernel too, but if you use a
| distro that does things properly such as NixOS, the BSDs are
| the ones that feel wonky.
| rollcat wrote:
| > That's more of a distro thing than "Linux being a few
| screws loose".
|
| That's what I mean. Every distro has plenty of loose
| screws, because they all package a kitchen sink, but miss
| the forest for the trees. Meanwhile Linus himself is upset,
| because he can publish a precompiled build of Subsurface
| for every platform, except Linux.
|
| A BSD is a vertically integrated base system. Design is how
| it _works_.
| uyzstvqs wrote:
| Google is killing Manifest V2, and AFAIK all downstream
| Chromium-based browsers (Brave, Edge, Vivaldi, Opera, etc) will
| eventually be affected. That should say enough about why having
| multiple browser engines is a good thing.
| notnullorvoid wrote:
| Standards already skew heavily to what Google or Google
| connected individuals want. If everything was Chromium based
| the situation would be even worse.
|
| Maybe worse is what we need to realize that many of the W3C and
| WHATWG standards are past the point of saving, and those
| organisation are no longer a good avenue for further
| advancement of the web.
| pornel wrote:
| Even with the best intentions, the implementation is going to
| have bugs and quirks that weren't meant to be the standard.
|
| When there's no second implementation to compare against, then
| everything "works". The implementation becomes the spec.
|
| This may seem wonderful at first, but in the long run it makes
| pages accidentally depend on the bugs, and the bugs become a
| part of the spec.
|
| This is why Microsoft has a dozen different button styles, and
| sediment layers of control panels all the way back to 1990.
| Eventually every bug became a feature, and they can't touch old
| code, only pile up new stuff around it.
|
| When you have multiple independent implementations, it's very
| unlikely that all of them will have the same exact bug. The
| spec is the subset that most implementations agree on, and
| that's much easier to maintain long term, plus you have a proof
| that the spec can be reimplemented.
|
| Bug-compatibility very often exposes unintended implementation
| details, and makes it hard even for the same browser to
| optimize its own code in the future (e.g. if pages rely on
| order of items you had in some hashmap, now you can't change
| the hashmap, can't change the hash function, can't store items
| in a different data structure without at least maintaining the
| old hashmap at the same time).
| Rakshith wrote:
| its really sad to see what mozilla turned into. a competitive
| browser company to activism. no wonder its core product started
| to wane
| Perz1val wrote:
| Why when a project is written in Rust it has to make the
| headline? Seems like the focus is proving that people behind a
| project can write Rust more than to just write good software.
| Does anybody outside Rust circle care? Servo to me is a prime
| example of that. Web standards are made around heavy use of OOP,
| often assuming garbage collection, so a browser is the final
| achievement, a holy grail and an ultimate flex for a Rust
| programmer. Even I think that it will be impressive.
| Realistically Servo will never be a real browser, probably will
| end up as a rendering engine for some Rusto-electronium, but
| that's still huge. Anyways, rant over, wish them luck
| qwertycrackers wrote:
| Things get Rust advertised in the title because the Rust
| community is somewhat on a quest to assert itself. There are
| certain things that the language will only be allowed to do if
| it becomes seen as one of the "big" languages, and advertising
| the language in a million small projects is a collective shove
| toward that aim.
| 1vuio0pswjnm7 wrote:
| "Most sites have at least a few rendering bugs, and a few are
| completely broken. Google search results have many overlapping
| elements, and the MacRumors home page crashed after some
| scrolling. Sites like Wikipedia, CNN Lite, my personal site, and
| text-only NPR worked perfectly."
|
| Like many HN readers, I have read countless accounts of web
| browsers and web browsing over the years.
|
| Unfortunately, I cannot recall even one that took an account such
| as this one and concluded something like, "We need to modify the
| Google and MacRumors pages so they work with Servo."
| Unfortunately, the conclusion is usually something like, "We need
| to fix Servo so it works like Chromium/Chrome."
|
| The reason I believe this is unfortunate is that (a) it
| ultimately places control in an ad services company and (b) it
| creates the wrong incentives for people who create web pages.
| Pages could be modified to conform to what Wikipedia, CNN Lite,
| the author's personal site and text-only NPR have done. This is
| not difficult. In fact, it is easier than modifying Servo to do
| what Chromium/Chrome is doing.
|
| IMO, the "standard" web browser should not be effectively defined
| by an ad services company (including its business partner,
| Mozilla) nor should the standard for a web page be defined by the
| "most popular" web browser, To me "popular" and "standard" are
| not necessarily the same. Web _pages_ (cf. web _browsers_) should
| work with unpopular browsers and popular browsers alike,
| According to OP, Wikipedia, CNN Lite, the author's personal site,
| and text-only NPR may meet the standard.
|
| In sum, fix web pages not web browsers.
|
| As a hobbyist, I still compile and experiment with w3c's original
| libww library and utilities. Below is short script I use to
| compile static binaries. With a TLS forward proxy these
| utilities, with few modifications, if any, can still work very
| well for me for retrieving web pages on today's web. (I am only
| interested in learning www history and optimising text retrieval,
| not graphics.) This library is generally "ancient" on the www
| timescale and yet it still works 30 years later. That's useful
| for www users like me, but maybe not for the online ad services
| companies and sponsored web browsers optimised for data
| collection and surveillance. Internet is supposed to be a public
| resource not a private one, i.e., highest priority of www pages
| and www browsers should be to serve www users not online ad
| service providers. # previous: download and
| compile w3c-libwww-5.4.2 pwd|grep "w3c-libwww-"||exec echo
| wrong directory export x=$(pwd) export
| examples=$x/Library/Examples export
| linemode=$x/LineMode/src export commandline=$x/ComLine/src
| export robot=$x/Robot/src y=" libwwwinit.a
| libwwwapp.a libwwwhtml.a libwwwtelnet.a libwwwnews.a
| libwwwhttp.a libwwwmime.a libwwwgopher.a libwwwftp.a
| libwwwdir.a libwwwcache.a libwwwstream.a libwwwfile.a
| libwwwmux.a libwwwtrans.a libwwwcore.a libwwwutils.a
| $x/modules/md5/.libs/libmd5.a -lm" cd $x/Library/src/.libs
| for z in head libapp_1 libapp_2 libapp_3 libapp_4 init
| chunk chunkbody LoadToFile postform multichunk put post
| trace range tzcheck mget isredirected listen eventloop
| memput getheaders showlinks showtags showtext tiny
| upgrade cookie do gcc -s -static -O2 -Wall -o
| $examples/$z $examples/$z.o $y done gcc -static -s
| -O2 -Wall -o $linemode/www $linemode/www-HTBrowse.o
| $linemode/www-GridText.o $linemode/www-ConView.o
| $linemode/www-GridStyle.o $linemode/www-DefaultStyles.o
| $x/PICS-client/src/.libs/libpics.a $y gcc -static -s -O2
| -Wall -o $robot/webbot $robot/webbot-HTRobot.o
| $robot/webbot-RobotMain.o $robot/webbot-RobotTxt.o
| $robot/webbot-HTQueue.o $y gcc -static -s -O2 -Wall -o
| $commandline/w3c $commandline/w3c-HTLine.o $y #
| next: symlink binaries to a folder in $PATH # or export
| PATH=$PATH:$examples:$commandline:$robot:$linemode
___________________________________________________________________
(page generated 2025-07-31 23:00 UTC)