> 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).
> (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.
> 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.
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!
Oh, no, why do alternative web browser engine devs love Discord so much? The Ladybird project also does this… that's certainly a barrier to entry for would be contributors attached to free software and software freedom… It's a shame, I suspect the intersection between people like this and people interested in alternative web browser engines is not small (comparatively speaking)…
Anyway, it's nice to see alternative web browser engines appearing like this. We need browser tech that does not rely on Big Ad funding. Even better if they cooperate on some common libraries like this.
Thanks for working on such things.
Web browser engines have always interested me, I might one day jump in.
Ironically the rationale for using Discord is that people are more likely to join it! It may be a case that this depend on the community one is targeting. Discord is popular among Rust developers, but perhaps less so among browser developers. If Zulip is more acceptable to you, then I also hang out in the Linebender Zulip [0]
Linebender [1] is an open source collective whose 2D renderer (Vello [2]) and text layout library (Parley [3]) we have adopted (and are actively contributing back to) as another part of our "make everything modular" strategy in Blitz.
> Ironically the rationale for using Discord is that people are more likely to join it!
Everybody says this, this ends up being a self-fulfilling prophecy :-)
I guess it's difficult to avoid if the whole rust community is on it (which I didn't know, that's quite bad news for me xD)
> Linebender [1] is an open source collective whose 2D renderer (Vello [2]) and text layout library (Parley [3]) we have adopted (and are actively contributing back to) as another part of our "make everything modular" strategy in Blitz.
You keep on mentioning cool stuff you are working on!
I'll be sure to check these things out. I wouldn't mind installing Zulip (actually, I'm quite interested in trying it at some point) should I start working on these stuff one day.
> I guess it's difficult to avoid if the whole rust community is on it (which I didn't know, that's quite bad news for me xD)
The actual compiler development is also on Zulip (https://rust-lang.zulipchat.com/). And I still consider the /r/rust subreddit the real hub of the rust community in genreal. But I'm about 20 different Discord servers for various specific Rust projects (help!).
> I wouldn't mind installing Zulip (actually, I'm quite interested in trying it at some point) should I start working on these stuff one day.
A quick mention that you don't actually need to install Zulip: you can just use the web version, although you probably do want the app on mobile (the desktop version is just a wrapper of the website, but the mobile app is Flutter-based).
(also true of Discord, although it remains less free and open)
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!
We do have the networking abstracted behind a trait (so people can bring their own implementation if they want), but we need something for testing (and it's convenient for users if we provide a default option for them too). I would also note that our networking support is a pretty thin layer (~200 LoC) around the https://docs.rs/reqwest/ crate. As well as HTTP, reqwest is handling things like cookies and form encoding for us.
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?
> 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.
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.
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.
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).
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.
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
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
> 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.
すごい！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.
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.
I know it’s usually taken as a given around here that Electron is slow, and many of the big-name apps using it are cited as examples with good reason.
From working on a Tauri app myself for a few years (video editor) I just think the blame is misattributed. These things are not inherently slow. Slower than native? Maybe, probably, at the level of milliseconds. Visibly laggy? No, that’s the badly-written UI code’s fault. (see also: the latest iterations of the macOS System Settings UI, where the search box lags like crazy)
A webview can be extremely responsive. It won’t be if you treat it like a web page (where clicking buttons fires off HTTP requests) or if you let the JS framework code get out of hand, but those are not the fault of the wrapper.
If you like building with HTML/CSS/JS then I’d recommend doing some perf experiments to see how far these tools can take you. Of course if you don’t want to use that stack then pick something else :)
If you’re building photoshop, the main UI will probably be canvas anyway, where drawing is fully under your control, no matter which framework you go with. That stuff can be very fast or very not-fast depending on how the code is written.
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)
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)
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.
> 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.
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
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?
> 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
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.
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.
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.
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.
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.
> 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
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.
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.
> […] 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.
> 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.
> 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.
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.
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.
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.
Using WebKit (even JavaScriptCore) and working with Apple wouldn't be the worst thing to my eyes as a Firefox/FOSS user. Duopoly isn't great but it's better than a monopoly.
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.
It is difficult to get people to pay for it. People happily pay for 10€ beer but asked ”friends” about how to bypass WhatsApp’s 0,99 lifetime licenses.
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.
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.
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.
> 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.
I'm sure there are plenty of people who will pay for it even though its being given away for free. Maybe not enough to replace the income from google but its worth a shot trying a fund raising drive.
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.
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
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.
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.
If we take a look at the results, I'm not convinced she is a good guy just because she was there at the beginning. There is a chart with her salary going up and Firefox usage going down. Looks like an X.
If anything, how come she didn't make it a success on the very limited market?
Even if she wasn't a bad actor in the beginning, she could have changed her opinion and be seduced by the money.
Just for comparison: a few people made a completely new engine in a few years. Task often thought as impossible (they had 200k USD for the start). Mozilla started servo, then when they saw its going well, decided to abandon it?
So what was Mozilla spending the money on? Many have requested the ability to donate for Firefox development, but it was never allowed: they (she?) wanted to distribute the donation money on things they thought were important?
For years they made decisions that the uses hated. How else to explain this?
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.
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.
> 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.
> 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.
The irony being that lots of the complainers then went to Google Chrome to "show it to those corporate Mozilla people".
I am constantly amazed at the amount of virol directed at Mozilla, especially from people who openly admit to use chrome as their primary browser. I can respect people like Stallman who stick to their principles to a fault (and I would argue indiscriminately), but I really don't get how people can criticise Mozilla for integrating Pocket and use that as a justification to start using Chrome. That seems like a huge cognitive dissonance.
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.
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?
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.
> 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.
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.
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.
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.
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.
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.
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.
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).
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).
> so 402/653 is spent on the core activities you favour
I don't think that's correct. IIUC, Software Dev was 260M for Mozilla + Mozilla Corporation + Mozilla Foundation + MZLA Technologies Corp. + Mozilla Ventures + Mozilla.ai. With large increase of 40M from 2023 to 2022 so I'd bet a good chunk of that is going to Mozilla.ai knowing how the rest of the corporate world is acting right now.
Like the Chrome Mobile team is 40 people [1]. I can't image that web + support is going to more than 4x that so you get to ~160 people which at 300k a head is 48 million. I don't see how out of the 6 organizations that 93% (700/750) of the employees are working on FireFox and not a different thing.
48 million just in salaries against the $494 million that Google gave Mozilla in 2023 just seems like it should be extremely possible to save at least half of it. Sure, we've gone beyond the initial ~$150M but for all (?) of Mozilla's life the payments from Google have covered software development [3] and for Safari the payments were in the billions so if Mozilla focused on making a better browser with higher market share their payments would go up as well.
So one of several teams working on Chrome Mobile (so not the rendering engine, JavaScript engine, etc...) was 40+ people. That tells us nothing about the size of the overall Chrome team.
I have seen comments on HackerNews that estimated 1000-4000 people working on Chrome at Google, but without a sound basis. Chromium had ~800 individuals author a commit, that's probably as close as we can get to actual hard facts.
The Platform Division which includes Chrome was 20.000+ but it's pure guesswork to break out numbers for Chrome for that.
Honestly my prior is that the vast majority of software dev work at Moz goes towards Firefox, I don't see any evidence to the contrary, including in terms of products released/developed. A modern browser is an enormously complex engineering feat, nothing else Moz releases is in that ballpark.
I guess bottom line is that we don't really know the exact breakdown.
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.
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.
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?
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.
I can't believe how this is common knowledge, this arrangement between Google and Mozilla as a weak and incompetent "competitor" propped up to avoid being accused of monopoly and anti-competitive practice. Why isn't it considered a form of fraud, not even with extra steps - a direct relationship. Maybe there's enough plausible deniability that it's hard to prove criminal intent.
In the browser space, what Apple is doing is awfully manipulative of the market too. It's almost like this situation is being willfully ignored and effectively encouraged by regulators.
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
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.
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.
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.
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.
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.
> Chromium merged almost 900 CLs ... Ladybird had 7
Imagine being in your annual review and your boss has a chart of your performance compared to your peers and it's just the count of PRs you merged. You begin to protest that merged PRs is not a good metric for contributions, then he switches to the next slide which is just this comment you made on HN...
I'm not even proximal to webdev, can someone explain why people keep making pages using new stuff? I get why google keeps adding things, but why do people use it? Well over half the pages I go to look better without js. HN looks identical.
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.
WebKit runs on Windows, the Windows port just needs work to bring it up to the level of the Linux port. I got every JIT tier enabled in JavaScriptCore [1] and enabled libpas (the memory allocator). The Windows port is moving to Skia in line with the Linux port.
Really just needs more people (and companies) pushing it forward. Hopefully Kagi will be contributing improvements to the Windows port upstream.
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.
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.
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.
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.
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).
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.
> 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.
If anything, Ladybird is an independent implementation of the web standards, and the devs have identified and helped solving quite a few bugs and and ambiguities in the standards, which benefits everyone, from browser devs including the big guns to web developpers and users.
I think the browser attempts are all wrong trying to "cover all edge cases" they should focus on being able to transform any and all dark patterns down into something simpler.
Hell starting out as extracting text, pictures, video for all nightmare sites. Then slowly add whatever features dont actually lead to dark patterns
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.
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.
> 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
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.
Linux started under circumstances of Linus wanting to learn 386 assembler. He got two processes writing alternating As and Bs to demonstrate 386 multitasking. Linus had to find SunOS docs etc to copy system call signatures from. It's truly an accidental success story, and while Linus is smart & capable he sure as hell did not "know what he was doing", the whole point was to learn and fiddle with it.
Starting a new browser project without a solid security architecture seems just a bad idea to me. It's such a hostile operating environment. Personal computing in the early 90s was a very different place.
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.
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.
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.
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?
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.
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.
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.
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."
> 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.)
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.
Or rather, the FAQ shows one influential person over language decisions:
"The choice of language was not so much a technical decision, but more one of personal convenience. Andreas was most comfortable with C++ when creating SerenityOS, and now we have almost half a million lines of modern C++ to maintain."
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.
> 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.
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).
Is that so bad though? It's essentially what's already the case and as you said the developers already have an incentive to avoid making such bugs. Most developers are only going to target a single browser engine anyways, so bug or not any divergence can cause end users problems.
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.
Bugs are proportional to lines of code. More browser implementations with result in many more bugs. All the effort of reimplementing multiple times would be better put towards security a single browser engine if security is what you are trying to go after. Also you don't need a single exploit due to defense in depth of browser engines. You have to chain multiple exploits together.
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).
It is disliked by a vocal minority, and of that minority even fewer actually have their own opinion based off the current version of mv3 as opposed to mindlessly parroting others. If it was a true issue then others would be maintaining mv2 support long term. In regards to monopolies in terms of control what is important is the product, browser, market share itself as opposed to that of the browser engine.
> 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.
> 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.
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.
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.
"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
Form a design team to reduce the amount of primitives in html such that I can do everything that html + css does but with the minimum amount of primitives.
Something tells me with that approach you'd get emergent complexity that different people handle in a different manner, eventually leading to strong incentive to add new, higher level primitives. That's one of driving forces behind current state of HTML and JS and why JQuery and TABLE layouts went out of fashion. Sounds like a people thing, not a technical one.
There will always be stronger incentive to create higher level entities.
It’s just you need to create an initial set of primitives such that those higher level entities can be formed as a composition of the initial set of primitives.
So maybe not even start with html. Create the set of primitives such that I can create custom tags that does exactly what html does.
Like react is the sort of a framework that allows for composition of tags. But the problem is we have too many primitives.
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.
> 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…]
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/
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.
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)
Thanks!
> Personally, I hope to pitch in as soon as I have some spare time available.
Amazing - maybe see you around :)
Oh, no, why do alternative web browser engine devs love Discord so much? The Ladybird project also does this… that's certainly a barrier to entry for would be contributors attached to free software and software freedom… It's a shame, I suspect the intersection between people like this and people interested in alternative web browser engines is not small (comparatively speaking)…
Anyway, it's nice to see alternative web browser engines appearing like this. We need browser tech that does not rely on Big Ad funding. Even better if they cooperate on some common libraries like this.
Thanks for working on such things.
Web browser engines have always interested me, I might one day jump in.
Linebender [1] is an open source collective whose 2D renderer (Vello [2]) and text layout library (Parley [3]) we have adopted (and are actively contributing back to) as another part of our "make everything modular" strategy in Blitz.
[0]: https://xi.zulipchat.com/ [1]: https://github.com/linebender [2]: https://github.com/linebender/vello [3]: https://github.com/linebender/parley
Everybody says this, this ends up being a self-fulfilling prophecy :-)
I guess it's difficult to avoid if the whole rust community is on it (which I didn't know, that's quite bad news for me xD)
> Linebender [1] is an open source collective whose 2D renderer (Vello [2]) and text layout library (Parley [3]) we have adopted (and are actively contributing back to) as another part of our "make everything modular" strategy in Blitz.
You keep on mentioning cool stuff you are working on!
I'll be sure to check these things out. I wouldn't mind installing Zulip (actually, I'm quite interested in trying it at some point) should I start working on these stuff one day.
Thanks again!
The actual compiler development is also on Zulip (https://rust-lang.zulipchat.com/). And I still consider the /r/rust subreddit the real hub of the rust community in genreal. But I'm about 20 different Discord servers for various specific Rust projects (help!).
> I wouldn't mind installing Zulip (actually, I'm quite interested in trying it at some point) should I start working on these stuff one day.
A quick mention that you don't actually need to install Zulip: you can just use the web version, although you probably do want the app on mobile (the desktop version is just a wrapper of the website, but the mobile app is Flutter-based).
(also true of Discord, although it remains less free and open)
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?
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.
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.
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…
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).
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.
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
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
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.
https://github.com/iced-rs/iced/pull/2777
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.
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.
iced is generic over the Renderer type
From working on a Tauri app myself for a few years (video editor) I just think the blame is misattributed. These things are not inherently slow. Slower than native? Maybe, probably, at the level of milliseconds. Visibly laggy? No, that’s the badly-written UI code’s fault. (see also: the latest iterations of the macOS System Settings UI, where the search box lags like crazy)
A webview can be extremely responsive. It won’t be if you treat it like a web page (where clicking buttons fires off HTTP requests) or if you let the JS framework code get out of hand, but those are not the fault of the wrapper.
If you like building with HTML/CSS/JS then I’d recommend doing some perf experiments to see how far these tools can take you. Of course if you don’t want to use that stack then pick something else :)
If you’re building photoshop, the main UI will probably be canvas anyway, where drawing is fully under your control, no matter which framework you go with. That stuff can be very fast or very not-fast depending on how the code is written.
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)
[0] https://makepad.nl
[1] https://makepad.dev
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.
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
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).
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.
https://github.com/w3c/csswg-drafts/issues/6203
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.
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/
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
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.
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.
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.
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.
It started out as something to make elevators more reliable. Not even joking (mostly).
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.
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.
https://thisdayintechhistory.com/08/06/apple-and-microsoft-c...
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.
edit: I mean dumping Gecko for Chromium, not Servo.
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.
Sure, only nerds would pay for it, but not all products have to capture 100% market share.
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.
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.
(They don't even block the streams, only logins. I can watch, but not spend money. Perfectly reasonable.)
> 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.
I would not be happy to pay that much for a beer
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.
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
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.
If anything, how come she didn't make it a success on the very limited market?
Even if she wasn't a bad actor in the beginning, she could have changed her opinion and be seduced by the money.
Just for comparison: a few people made a completely new engine in a few years. Task often thought as impossible (they had 200k USD for the start). Mozilla started servo, then when they saw its going well, decided to abandon it?
So what was Mozilla spending the money on? Many have requested the ability to donate for Firefox development, but it was never allowed: they (she?) wanted to distribute the donation money on things they thought were important?
For years they made decisions that the uses hated. How else to explain this?
[0] https://en.m.wikipedia.org/wiki/Stephen_Elop
Very little about Mozilla makes sense --- until you follow the money.
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.
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.
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.
I am constantly amazed at the amount of virol directed at Mozilla, especially from people who openly admit to use chrome as their primary browser. I can respect people like Stallman who stick to their principles to a fault (and I would argue indiscriminately), but I really don't get how people can criticise Mozilla for integrating Pocket and use that as a justification to start using Chrome. That seems like a huge cognitive dissonance.
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.
For which they are compensated very well.
It just doesn't make sense does 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.
Someone said "It’s coming on Linux (scheduled for March 2026). See https://kagi.com/changelog#6479".
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.
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.
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).
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).
I don't think that's correct. IIUC, Software Dev was 260M for Mozilla + Mozilla Corporation + Mozilla Foundation + MZLA Technologies Corp. + Mozilla Ventures + Mozilla.ai. With large increase of 40M from 2023 to 2022 so I'd bet a good chunk of that is going to Mozilla.ai knowing how the rest of the corporate world is acting right now.
Like the Chrome Mobile team is 40 people [1]. I can't image that web + support is going to more than 4x that so you get to ~160 people which at 300k a head is 48 million. I don't see how out of the 6 organizations that 93% (700/750) of the employees are working on FireFox and not a different thing.
48 million just in salaries against the $494 million that Google gave Mozilla in 2023 just seems like it should be extremely possible to save at least half of it. Sure, we've gone beyond the initial ~$150M but for all (?) of Mozilla's life the payments from Google have covered software development [3] and for Safari the payments were in the billions so if Mozilla focused on making a better browser with higher market share their payments would go up as well.
[1]: https://mdwdotla.medium.com/some-thoughts-on-running-success...
[2]: https://assets.mozilla.net/annualreport/2024/mozilla-fdn-202...
[3]: https://en.wikipedia.org/wiki/Mozilla_Corporation#Finances
I have seen comments on HackerNews that estimated 1000-4000 people working on Chrome at Google, but without a sound basis. Chromium had ~800 individuals author a commit, that's probably as close as we can get to actual hard facts.
The Platform Division which includes Chrome was 20.000+ but it's pure guesswork to break out numbers for Chrome for that.
Honestly my prior is that the vast majority of software dev work at Moz goes towards Firefox, I don't see any evidence to the contrary, including in terms of products released/developed. A modern browser is an enormously complex engineering feat, nothing else Moz releases is in that ballpark.
I guess bottom line is that we don't really know the exact breakdown.
And yet, somehow, they still struggle to secure adequate funding for Firefox itself, while millions are allocated to executive salaries and various advocacy initiatives.
Almost no technical aspect of Firefox have anything to do with how much money Google pays them.
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?
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...
In the browser space, what Apple is doing is awfully manipulative of the market too. It's almost like this situation is being willfully ignored and effectively encouraged by regulators.
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.
Google knows it shouldn't be developing a browser. This paltry pocket change protects their pane of glass moat.
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...
https://data.firefox.com/dashboard/user-activity
In any case it doesn't really matter much anymore since apparently she left Mozilla around February.
They're ahead of Servo already anyway, and better funded.
Imagine being in your annual review and your boss has a chart of your performance compared to your peers and it's just the count of PRs you merged. You begin to protest that merged PRs is not a good metric for contributions, then he switches to the next slide which is just this comment you made on HN...
Orion adding Windows support (getting WebKit running on Windows again) would be pretty good too.
Really just needs more people (and companies) pushing it forward. Hopefully Kagi will be contributing improvements to the Windows port upstream.
[1] https://iangrunert.com/2024/10/07/every-jit-tier-enabled-jsc...
They are already quite competitive.
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.
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.
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.
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.
Hell starting out as extracting text, pictures, video for all nightmare sites. Then slowly add whatever features dont actually lead to dark patterns
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
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.
Starting a new browser project without a solid security architecture seems just a bad idea to me. It's such a hostile operating environment. Personal computing in the early 90s was a very different place.
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.
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
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.
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/LadybirdBrowser/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.
I'd love to know more about this.
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."
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.)
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.
"The choice of language was not so much a technical decision, but more one of personal convenience. Andreas was most comfortable with C++ when creating SerenityOS, and now we have almost half a million lines of modern C++ to maintain."
Source: ladybird.org FAQ
I ran Dogemania on Chrome until 1400 images at steady 60 FPS at which point I got bored and closed the tab.
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.
Chromium hit below 60fps at around 4000 and below 30fps at 6000 but used my integrated intel GPU all the time.
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.
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).
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).
It is disliked by a vocal minority, and of that minority even fewer actually have their own opinion based off the current version of mv3 as opposed to mindlessly parroting others. If it was a true issue then others would be maintaining mv2 support long term. In regards to monopolies in terms of control what is important is the product, browser, market share itself as opposed to that of the browser engine.
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.
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.
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.
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.
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.
HTML and css is not it. The sheer complexity is what causes all the bs.
It’s just you need to create an initial set of primitives such that those higher level entities can be formed as a composition of the initial set of primitives.
So maybe not even start with html. Create the set of primitives such that I can create custom tags that does exactly what html does.
Like react is the sort of a framework that allows for composition of tags. But the problem is we have too many primitives.
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…]
Most languages have a way of saying "I haven't handled this case yet; just exit the program if you get here".
Reading an invalid index, thats a panic.