> 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.
nicoburns · 3h ago
> 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!
dingi · 3m ago
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!
echelon · 5h ago
Questions for the Rust UX experts:
Is Dioxus (or Leptos) much more performant than Tauri/Electron?
I want to (1) build blindingly fast, low-latency, super performant UX for users, which precludes Tauri/Electron (something I'm currently using and unhappy about), but I also want to (2) maintain developer velocity, (3) have access to nice UX primitives and widgets, and (4) have it look nice and modern.
Javascript/browser-oriented frameworks make requirements 2-4 easy, and it has the side benefit of also making hiring easy (not a requirement per se). But the results feel so bloated and anti-Desktop/native. It gobbles up RAM and renders slowly, even when best practices are used. It's the very definition of a double-edged sword.
Are these four requirements simply impossible to satisfy together for native Rust UX toolkits right now?
Rust's egui looks amazing, but I doubt you'd be able to build a very complicated UX with it. Or if you could, it might take you half a year to deliver.
Iced also looks cool, but looks less featureful.
Are there any "non-browser" Rust UX toolkits that aren't dated GTK/KDE frameworks, but that can build graphically-oriented (not just text/button widget) programs?
If I were building a "slimmed down photoshop", are there any Rust GUI toolkits to reach for? Or if I were incorporating a Bevy or 3D render pane?
jpc0 · 4h ago
> I want to (1) build blindingly fast, low-latency, super performant UX for users, … (2) maintain developer velocity, (3) have access to nice UX primitives and widgets … (4) have it look nice and modern.
Find me when you find this, because I actually think it is impossible.
I think there is fundamentally too much inherent complexity to abstract away to keep 2 and not sacrifice 1. Specifically for something properly cross platform.
If you are only targeting MacOS or windows then I think it’s absolutely possible but then you are using the wrong language, nothing against rust at all on that, the platform defaults are just swift / C# for those use cases.
And I’m not sure but unless you are just using a gtk/Qt style framework you would absolutely run into a11y problems that you would need to build around yourself.
Sounds like you probably want egui though… if your primary UI is a big canvas that needs to be hardware accelerated and interaction is just to assist that use case egui is probably a good bet for you. But you wouldn’t be hiring web devs to do that.
cosmic_cheese · 1h ago
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.
rollcat · 2h ago
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.
airstrike · 5h ago
I'm super biased in favor of iced.
Yes, there are missing features (it's not even version 1.0 yet!) but I think the number is very small now and the solution is usually to fill in the gaps yourself—which is possible because iced is totally modular
I've made a spreadsheet editor and a slideshow editor with it so "slimmed down photoshop" seems feasible although admittedly you will likely need to get deep into the renderer (possibly write your own renderer traits and there), but I suppose you're comfortable with that given your goal.
If you're not allergic to Discord, come join us. It's a helpful, awesome tight community IMHO
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
goku12 · 3h ago
> 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.
airstrike · 4h ago
In that case, I'm happy to let you know your info is outdated. CJK/IME support has landed.
すごい！Japanese is one of our localization targets, so this is amazing!
I'm building a graphically heavy app, so two more questions:
1) Is iced appropriate for building a canvas-type drawing app with image inclusions? Right now we're using Konva.js and we'd be losing a tremendous amount of out of the box flexibility in porting to iced, but the performance wins would be a major selling point.
2) Can you include Bevy panes? We're also doing some 3D visualization, and we currently use Three.js. But we have a lot of Bevy experience too.
airstrike · 1h ago
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.
usrusr · 1h ago
Makepad is neither gtk generation nor browser based. Might check the "just text/button widget" box though, I'd certainly place it on the minimalistic end of the spectrum. (haven't worked with makepad, just enjoyed the demo)
rapnie · 1h ago
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.
Slint recently added Bevy support. I’ve been keeping an eye on it since I’ve used Qt and love working in Qml.
echelon · 2h ago
Slint cites Javascript. Is it another Electron/Tauri-like?
jenadine · 1h ago
Slint does not use a browser. Instead, it has its own runtime written in rust and uses a custom DSL to describe the UI.
It has API for different programming language.
For Javascript, it uses node or deno for the application logic, and then spawn the UI with its own runtime without the browser.
In a way it is the opposite which took the JS runtime out of electron to replace it with a Rust API, while Slint keeps the JS runtime but swaps the browser for its own runtime (for the JS dev point of view)
Narishma · 1h ago
No, it's like Qt and QML.
explodingwaffle · 1h ago
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
nicoburns · 4h ago
> 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.
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?
nicoburns · 6h ago
> 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
nielsbot · 5h ago
I wish there was a CSS analyzer that would give tips like this based on your CSS.
fouronnes3 · 5h ago
Or a straight up fork of CSS that removes the legacy stuff and fixes wrong defaults so that tips like this are unnecessary in the first place.
mort96 · 5h ago
I don't think it's necessarily a wrong default, just one which prioritizes usability/ease of programming over performance.
nielsbot · 1h ago
Or maybe a v2 syntax mode? Akin to `"use strict";` in JS.
nashashmi · 6h ago
How do you propose standards to the web groups?
I want to propose CSS-inheritance—by-name (#box {inherit:$(#menu)})
and the reintroduction of marquee tags for horizontal scrolling (a frequently used UI pattern on shopping sites).
nicoburns · 6h ago
> How do you propose standards to the web groups?
I'm not sure. I tried opening an issue at https://github.com/w3c/csswg-drafts but that didn't get me very far. I suspect it's a case of making connections and then getting yourself an invite to present at a meeting.
pxeger1 · 5h ago
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.
dleeftink · 6h ago
(Just say yes, you have to look it up all the time so we don't feel as bad)
rockwotj · 6h ago
To me, this is like asking if having built a sql engine if you write SQL differently.
I think the answer is yes. Having a strong understanding of the underlying engine helps you debug and optimize more quickly
Needing reference stuff never changes unless it’s so frequently used.
piker · 6h ago
Do you not worry that instead it will lead to feature bloat and fragmentation? If you’re going to strike at Google, you need laser focus.
nicoburns · 6h ago
Not really. Everything has a spec, so it's pretty clear what's in scope and what isn't. Also, we don't have time for bloat with our team size. We have to be laser focussed on what actually makes a difference to real websites. It's Chrome that has bloat!
Also the specs don't change much (there are additions, but almost always backwards-compatible), so once written the code shouldn't need too much maintenance.
I see it as writing a piece of foundational infrastructure. You can write your own HTTP library. But you don't need to: there are high-quality libraries readily available (e.g. curl or hyper). Similarly for HTML parsers or 2D graphics rendering. Nobody's done that for web layout yet (except arguably React Native's Yoga [0], but that's much less ambitious in terms of how much of the spec it attempts to support), so everybody has to write their own. But it's possible so we're doing it.
[0]: github.com/facebook/yoga/
afavour · 5h ago
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.
01HNNWZ0MV43FF · 4h ago
> 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
AdmiralAsshat · 5h ago
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.
GuB-42 · 58m ago
Mozilla is nothing like Xerox, if anything Google is the new Xerox: they have way too much money so they throw it at R&D side projects without a business plan.
The big one for Google is transformer models, they basically invented LLMs only to play catchup with OpenAI later.
Mozilla successes have always been focused on the web browser, from the very beginning. Even the name reflects that: "Mozilla" stands for "Mosaic killer", Mosaic was the leading web browser at the time. They beat Mosaic with Netscape, they beat IE with Firefox, beating Chrome was their mission, and Rust and Servo were their weapons. It is sad that they dropped the ball.
Like Xerox (and Google), Mozilla tried doing some side projects, but unlike Xerox, they didn't have money to burn from their quasi-monopolies, and I can't think of anything particularly innovative coming from Mozilla that isn't a browser. I don't consider Rust to be a side project, it is a programming language for writing a browser, that it is useful for projects other than a web browser is a happy side effect.
bee_rider · 46m ago
> […] 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.
calibas · 4h ago
> It's mind-boggling that for a company so often seemingly playing catch-up with Google, Mozilla actually leapfrogged Google in the browser development space for a time, and then...decided it wasn't worth pursuing any further.
Google has been Mozilla's main source of revenue since around 2006. For Mozilla to exist, all they have to do is keep Google happy.
It's kind of a nice deal for Mozilla, despite being a huge conflict of interest.
rollcat · 2h ago
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.
godshatter · 4h ago
If Mozilla decides to dump Gecko, then it's time for a hard fork and an abandonment of Mozilla. Maybe it's time now.
edit: I mean dumping Gecko for Chromium, not Servo.
goku12 · 1m ago
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.
nicce · 5h ago
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.
uncircle · 4h ago
I've heard the same thing about monetising search engines. Kagi didn't get the memo, and last I've heard they're turning a profit.
Sure, only nerds would pay for it, but not all products have to capture 100% market share.
danelski · 4h ago
But independent browsers need this metric. Good luck convincing website owners to test against your non-chromium browser with 0.3% market share.
drdaeman · 1h ago
I'm not tracking what's currently going on with the underwater portion of frontend iceberg. Are things still like it was in late '00s and early '10s, where browsers still had plenty of their unique implementation quirks and non-standard features, and plenty of sites were relying on those?
Back in the day, it was not entirely unheard of having two significantly different frontend implementations - one for IE, another for Netscape, with quite unhealthy amounts of parser hacks to hide code from the browsers.
Possibly naively, but I think it's not that bad nowadays? (At least it wasn't so in late '10s.) Some things are Chrome-only, or Apple-only, but I rarely see "not supported in your browser" - the majority of features is generally standards compliant, and all those newcomer engine problems (like in the article) are mostly because there's a lot to implement.
nicce · 9m ago
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.
WD-42 · 2h ago
Okay but if everyone building the websites are using the browser with 0.3% market share it won't matter.
nicce · 1h ago
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.
rollcat · 2h ago
Twitch randomly blocks Chromium.
(They don't even block the streams, only logins. I can watch, but not spend money. Perfectly reasonable.)
tux3 · 2h ago
Huh? That's crazy, I've never been blocked on Firefox, which is much smaller. And packed with privacy addons.
yjftsjthsd-h · 5h ago
And it's impossible to get people to pay for it when you give them no way to pay for it.
> 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.
CivBase · 4h ago
You can donate, but who's going to pay $10 for beer when the same stuff is being given away for free?
yjftsjthsd-h · 4h ago
No, you can't. You can donate to the Mozilla Foundation, but you cannot donate to the Mozilla Corporation to actually fund Firefox development.
LtdJorge · 3h ago
Exactly. You can donate to a bunch of management people with multiple million dollars compensation that are running the company into the ground.
No comments yet
skinkestek · 5h ago
Some did. Some like me lined up eagerly to pay the $1 yearly license and would have been happy to pay for my family too.
bowsamic · 1h ago
> People happily pay for 10€ beer
I would not be happy to pay that much for a beer
dimal · 2h ago
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.
criticalfault · 3h ago
This is only fair.
Mozilla doesn't deserve to survive. New players deserve our support, like servo and ladybird.
Even with an enormous budget from Google (500M, I think per year) they managed to ruin everything, including Firefox, the thing bringing them those 500M.
To me it looks as if Baker is an undercover person put there to sabotage Mozilla. Tldr: funded by Google, made absolutely everything in her power to run it into the ground
mariusor · 3h ago
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.
It's still baffling to me that Mozilla threw out Firefox's technical future
Very little about Mozilla makes sense --- until you follow the money.
StopDisinfo910 · 7h ago
The string of departures and how people communicated around them let me think it’s something a lot less nefarious: Mozilla looked like an extremely political company at the time.
Servo was extremely good at communication with their very frequent news letter and Rust had a lot of wind in its sails, I wouldn’t be surprised if that ruffled the wrong feathers. Mozilla is very much still managed by what remains of its old guards - by that I mean what hasn’t been poached - especially at the top.
That would be pure incompetence from the top management but not malice.
xpe · 6h ago
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?
bornfreddy · 3h ago
The way this world is going, you shouldn't attribute to incompetence what can be attributed to malice.
jqpabc123 · 6h ago
That would be pure incompetence from the top
For which they are compensated very well.
It just doesn't make sense does it?
nicoburns · 3h ago
No, but it's not mozilla-specific. It's true of almost every large corporation.
xpe · 6h ago
The end of Pocket is just another sad example.
As an April fools joke, Mozilla should announce that they are discontinuing Firefox in order to focus on their core business, which is a beautiful abstraction: the Platonic ideal of discontinuing popular products.
paulryanrogers · 6h ago
Strange. I remember reading nothing but complaints about Pocket when they bought and integrated it. I guess it grew on people.
Octoth0rpe · 5h ago
Even if you dislike Pocket, its purchase/deprecation is an example of Mozilla failing to effectively use its capital.
windsurfer · 5h ago
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.
0points · 1h ago
Not strange, satisfied people don't usually run around declaring how perfectly OK everything is.
chimeracoder · 5h ago
> Strange. I remember reading nothing but complaints about Pocket when they bought and integrated it. I guess it grew on people.
They bought Pocket to assuage complaints from people that they were "selling out" by including an optional button in Firefox (which never even loaded any code until it was clicked) that allowed you to set up an integration with your Pocket account and send articles there. They were clear that no data was sent to a third party unless you explicitly clicked it and went through the steps to set it up.
Despite that, purists were unhappy that Firefox was doing literally anything at all with a third party, so Mozilla decided to buy Firefox in an attempt to put those complaints to rest, since it would no longer be a third party.
In the end, those purists didn't stop complaining - they just moved on to different complaints. If you're curious to see for yourself, you can look up the conversations on HN and cross-reference the usernames against other topics involving OSS purism and Firefox.
In the end, everyone lost: longtime Pocket users lost a product that they had enjoyed because it got acquired by a company that never really had an active interest in the product itself, Firefox lost because of the negative PR which contributes to their declining market share, and Mozilla lost because of the massive waste of money this was.
wtallis · 2h ago
> 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.
coredog64 · 5h ago
That they're being bought by Google so that they can focus on the Platonic ideal of discontinuing popular products.
Gualdrapo · 7h ago
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.
ac29 · 5h ago
> nor why The Linux Foundation gives little to no support at all to it
The Linux Foundation is mostly a dumping ground for dead and dying projects. Particularly they seem to specialize in abandoned commercial open source projects.
I dont think the Foundation provides much, if any, developer funding for these projects. They list $193M in "project support" expenses but host over 1000 projects.
bitwize · 5h ago
I thought that was the Apache Foundation?
k__ · 4h ago
Many Apache projects are still well maintained.
f311a · 6h ago
WebKit is a nice competitor, too. Look at Orion browser, it's a pretty decent competitor. Although they only target macOS, WebKit can be used on Windows and Linux, too.
bobajeff · 5h ago
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.
fhd2 · 6h ago
They don't get donations from Google, but get paid to include Google as the default search engine, right?
No important difference though. Mozilla tried to switch to Yahoo a few years back and backpedaled. In terms of what users expect, they don't have a lot of options. Google OTOH could do without the users Firefox has left. And I've personally observed Google strong arm "partners". Not sure I see a conspiracy here, but I'm pretty sure that if Google asks for concessions, Mozilla will see what they can do.
johnisgood · 6h ago
You are right, it is not a "donation", more like a business arrangement or something. I am not sure it is limited to "be the default search engine" though.
LtdJorge · 3h ago
It is
Certhas · 6h ago
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.
lesuorac · 5h ago
At what point could FireFox had just invested the money from Google into the SP500 and then just ran the company off of passive income?
Like for 150M$ I bet you could fund browser development for at least a decade and that was just 1 year of income. (of course also burn the entire $150M).
Certhas · 8m ago
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).
skinkestek · 5h ago
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.
Certhas · 7m ago
What do you even mean? They have adequate funding. Financially they are doing extremely well.
cozzyd · 3h ago
Wait until you see executive salaries at other companies that make browsers.
olalonde · 7h ago
What do you mean? Doesn't most of Mozilla's revenue come from Firefox?
nextaccountic · 7h ago
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.
sirwhinesalot · 7h ago
Mozilla is basically paid by Google to have a multi-platform non-Blink browser around they can point to when accused of being a monopoly.
Having a quality browser is not required, merely it existing. So why waste money on novel web engine experiments when you can have AI conferences in Zambia?
jqpabc123 · 6h ago
Living large and loving life --- by selling out.
ObscureScience · 7h ago
How do you think Firefox is making money, since it has no payed features? Hint: it has Google search as the default search engine.
olalonde · 7h ago
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.
0x000xca0xfe · 6h ago
> The fewer people use Firefox, the less money they get from Google
This is not reflected in the numbers, at least from what I've found: 300m/year in 2011[1], 400+m/year in 2020[2], 485m/year in 2025[3].
You’re the one who didn’t follow the money: they’ve made more from Google as their market share has decreased. Neat incentive, huh?
atoav · 7h ago
Nope it comes from Google.
camdroidw · 7h ago
It's wrong to name names without prood but after a point you start doubting your understanding of the world and at this point I'm beginning to suspect Mitchell Baker is a plant
bobajeff · 7h ago
I think without Mitchell Baker there would probably not have been a Mozilla. I'm fuzzy on the history but I believe she was the lawyer who originally set up the organization.
badsectoracula · 6h ago
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.
ObscureScience · 7h ago
While it's hard to know what comes of it, there is also https://ladybird.org/ to challenge to monopoly of Blink.
YmiYugy · 7h ago
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.
xdfgh1112 · 5h ago
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.
sirwhinesalot · 6h ago
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.
paddim8 · 53m ago
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).
badsectoracula · 6h ago
Larger teams do not necessarily mean you get stuff faster. If anything after some point, a large team can be hard to get things moving and have tons of issues with communication.
throw839340949r · 6h ago
Ladybird has better results in web rendering tests than Servo, and slowly is gaining on Firefox.
They are already quite competitive.
fabrice_d · 5h ago
Ladybird is extremely slow, it's far from being competitive at all.
iotku · 4h ago
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.
paddim8 · 52m ago
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.
ramon156 · 2h ago
Very unfair to look at ladybird and call it slow, when its not even alpha and shouldn't be used yet
mrob · 3h ago
All browsers are fast enough once you block all the useless web bloat.
bowsamic · 1h ago
But Ladybird's explicit goal is to work on the "real web", i.e. without blocking all that bloat
materielle · 3h ago
I think there are two things to keep in mind.
1) Apple and Firefox have enough resources to implement the most recent web standards. When you see a feature which goes un-implemented for too long, it’s almost surely because nobody was even working on it because of internal resourcing fights.
2) Devs aren’t created equal. It’s possible for a team of 8 people to be 10x more productive than another team of 8.
bornfreddy · 3h ago
> 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.
f311a · 6h ago
What's wrong with Webkit? It's super fast. I tested Orion browser recently.
MrDrMcCoy · 2h ago
Good implementations are hard to come by outside Apple's ecosystem.
keysdev · 5h ago
It was the similar sentiment with 0xide.
jonkoops · 5h ago
I have to be honest that I don't really understand the appeal of Ladybird from a purely technical perspective. It is written in C++, just like all the existing engines (yes there is some Swift, but it is negligible), so what benefit does it provide over Gecko or Blink? With Servo, I can see there is a distinct technical design around security and parallelism.
BrawnyBadger53 · 5h ago
There is more to a project this massive than its choice of language. For me though it's mostly about breaking from the monopoly and putting a check on Google's influence over browser space.
mdaniel · 4h ago
> There is more to a project this massive than its choice of language
For writing a game, or Figma replacement, or some cutesy something that runs on your machine without requiring network access, probably. For one of the most impactful applications that downloads untrusted code from the Internet and executes it without any confirmation whatsoever, the language for sure does matter. "Chrome RCE" is a phrase that strikes fear, and it's not a rare occurrence. I'll point out that Google is not lacking some of the most skilled security researchers and tooling in the world, so I wish the Ladybird folks godspeed doing their own "does this build have vulns?" work
paddim8 · 50m ago
Well that's why they're going to rewrite parts of the code where those things are more likely in Swift
rollcat · 2h ago
Many many factors to consider. Simplistic take: KHTML was picked up by Apple because of its clean design and codebase; there's an extra 30 years of accumulated improvements in C++; you don't write stuff in Rust 1.0 either.
Also: Andreas has worked on Webkit/Blink. He knew what he was doing when he started the project, even if it was "just for fun". Linux started under similar circumstances.
Perz1val · 2h ago
Rust does not produce magic in the assembly code. It does not even produce faster assembly code. Rust toolchain on it's own does not even produce assembly code. It just passes that to LLVM that does THE ENTIRE optimization. Without LLVM (written in C++) doing the heavy lifting, Rust is probably slower than V8 (written in C++) running JavaScript. There's no technical marver in Servo compared to Ladybird. I don't understand the yapping how a language makes projects good/bad, despite it being proven completely false again and again. The appeal is in independence and politics around the project.
jcranmer · 2h ago
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.
willi59549879 · 7h ago
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.
Buttons840 · 4h ago
I couldn't find any information beyond that Tweet I linked.
jm4 · 4h ago
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.
Buttons840 · 2h ago
> [Rust] was basically the one to beat until they figured out it wasn't going to work.
Here are some key quotes:
"something that matters to us a lot is OO. Web specs & browser internals tend to be highly object-oriented, and life is easier when you can model specs closely in your code."
"So what I’ve done is I’ve asked a bunch of people to “Please implement these things in a couple of different languages. And then we can talk about how that went, what you liked about each language, and which one you would like to work in every day.” And what we ended up with was that people were initially excited to work in Rust, because there’s a lot of hype, and it’s like a popular language… And you would think that it’s the greatest thing since sliced bread… And in many ways it is, if what you want is sliced bread. Or I don’t know where I’m going with that. But it works well for a lot of things."
"But it turns out it’s not ideal for building a browser… Because the browser stack sits on top of this API that was designed in the ’90s, inspired by Java and XML and stuff like that at the time. This ‘90s API, and it set the core of the web stack. And it’s super object-oriented, and it’s just hard to express all that stuff in Rust, because Rust doesn’t lend itself to object-oriented programming. It doesn’t have inheritance, for example, which is a very fundamental building block."
"And so what happened was I asked people to write in Rust, and they were initially excited, and then they came back frustrated. And nobody had a good time working in Rust, as far as I understood, when doing anything but trivial programs that like take an input and transform it into something else. The moment you try to model something, sort of in a browser space, it just became tedious."
"So we looked at some other languages, and the one that everybody has liked so far has been Swift. So it’s a bit of an unlikely candidate, but we decided to look at it, because it is a safe, modern language, that has great object-oriented programming capabilities. I would say it’s even better than C++ in many ways. And it’s a little weird, because it feels like an Apple product almost, but they’ve been making great strides on Linux and Windows. Especially now, the upcoming Swift 6 is looking like it’s going to be a really good release on other platforms as well… So that’s sort of where the ship is pointing right now. We haven’t committed to it, because we’re still figuring out how to do some things, but it’s been really positive, and everybody’s enjoyed working in it, myself included. It’s been fantastic. So that’s sort of what we’re looking at."
zozbot234 · 1h ago
> 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.)
Perz1val · 2h ago
Andreas has said that in some video I watched at some point, can't pinpoint it, but I can confirm jm4 didn't make it up
Perz1val · 2h ago
Why when a project is written in Rust it has to make the headline? Seems like the focus is proving that people behind a project can write Rust more than to just write good software. Does anybody outside Rust circle care? Servo to me is a prime example of that. Web standards are made around heavy use of OOP, often assuming garbage collection, so a browser is the final achievement, a holy grail and an ultimate flex for a Rust programmer. Even I think that it will be impressive. Realistically Servo will never be a real browser, probably will end up as a rendering engine for some Rusto-electronium, but that's still huge. Anyways, rant over, wish them luck
qwertycrackers · 1h ago
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.
rrgok · 3h ago
> 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.
rollcat · 2h ago
> 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.
merelysounds · 2h ago
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).
mrob · 3h ago
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.
uyzstvqs · 1h ago
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.
oaiey · 5h ago
Describing Servo as "new" is a stretch ;)
timbit42 · 3h ago
It started later than the other engines and it seems to have a number of great ideas the other engines haven't adopted yet.
kookamamie · 7h ago
> The Dogemania test ran at a smooth 60 FPS on my M4 Pro MacBook Pro until reaching around 400 images
I ran Dogemania on Chrome until 1400 images at steady 60 FPS at which point I got bored and closed the tab.
specproc · 7h ago
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.
lvass · 2h ago
For me it was stable 120fps on firefox at 2200 and 60fps at 3200, using 200W in my RX 6750XT.
Chromium hit below 60fps at around 4000 and below 30fps at 6000 but used my integrated intel GPU all the time.
empath75 · 2h ago
Chrome has thousands of developers working it. That is a lot of man hours for small optimizations.
bravesoul2 · 6h ago
If dogemania keeps the images still after animation isn't it embarrassingly optimizable? Why cant an Amiga do infinity of these?
kookamamie · 5h ago
It did! Infinite bobs.
postalrat · 3h ago
I thought it was more like: rust made for the web browser Servo.
Rakshith · 3h ago
its really sad to see what mozilla turned into. a competitive browser company to activism. no wonder its core product started to wane
sdcoffey · 7h ago
All-time opener
ninetyninenine · 5h ago
I feel guis have taken a wrong turn. We need a simple composable language. I want entire theorems built from the least amount of axioms possible.
HTML and css is not it. The sheer complexity is what causes all the bs.
bataleon · 4h ago
Please bring this to iOS. WebKit is broken.
samtheprogram · 4h ago
If you think WebKit is broken, you should actually download a build of Servo and try it out.
fHr · 4h ago
I see Rust I upvote
zellyn · 6h ago
> the MacRumors home page crashed after some scrolling
I know there’s a ton going on, with GPUs and rendering and all kinds of things, but I guess because Rust’s memory safety and “no null pointers!” are so constantly hyped (especially in conversations about Go), that I’m always surprised when you fire up a Rust app and do something and it crashes out…
[To be clear, I’m a big fan of modern sum types, and like to imagine an alternate reality where Go had them from the start…]
IshKebab · 6h ago
When they say "it crashed" they probably mean it panicked or just failed to render; not a segfault.
Most languages have a way of saying "I haven't handled this case yet; just exit the program if you get here".
jpc0 · 3h ago
Rust also doesn’t consider DOS a failure condition.
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)
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.
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.
[0] https://makepad.nl
[1] https://makepad.dev
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)
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.
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.
edit: I mean dumping Gecko for Chromium, not Servo.
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.
No comments yet
I would not be happy to pay that much for a beer
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.
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
[0] https://en.m.wikipedia.org/wiki/Stephen_Elop
Very little about Mozilla makes sense --- until you follow the money.
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?
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.
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).
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...
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.
Orion adding Windows support (getting WebKit running on Windows again) would be pretty good too.
They are already quite competitive.
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.
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.
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.)
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.
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.
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).
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.
HTML and css is not it. The sheer complexity is what causes all the bs.
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.