With both Firefox and Chromium using jxl-rs (Rust-based), I wonder what Apple will do about the libjxl (C++) they already shipped. I know they're doing some memory-safety with Swift, but are they shipping any Rust in their platforms so far? I also wonder if anyone's done benchmark comparisons between both libs.

Also, I was under the impression that after backtracking, Chromium was relying on Mozilla to come up with a Rust port, but it seems it was the reverse. Good on Google Research.

https://hacks.mozilla.org/2026/08/intent-to-ship-jpeg-xl/

> So, we laid down a challenge to the JPEG XL team at Google Research: Build a safe, performant, compact, and compatible JPEG XL decoder in Rust, and we’ll ship it. That challenge was met; Google Research built jxl-rs, and it’s the core of our JPEG XL support in Firefox.

▲

Snafuh 5 hours ago | parent | next [-]

Luca Versari, one of the devs between both libraries, has a performance dashboard to compare performance between the two https://jxl-rs-perf.lucaversari.it/

jxl-rs started to outperform the C++ library 2 months ago.

▲

phire 4 hours ago | parent | next [-]

As much as I enjoy rust, there is no reason why a c++ library can’t be optimised to match the rust implementation.

It’s very rare that the actual performance benefits of rust implementations come from rust itself (though it does often push you to slightly better patterns). They usually come from the fact that rust implementations are usually a second (or 3rd, or 4th) iteration of the design, and the lessons learned help performance.

The other benefit of rust is that the stronger type system makes it easier to iterate and optimise without bugs creeping in. But once optimisations are implemented in rust, there isn’t that much pain to porting them back to c++, as long as someone cares enough to do so.

▲

magicalist 4 hours ago | parent | next [-]

> As much as I enjoy rust, there is no reason why a c++ library can’t be optimised to match the rust implementation.

I don't think anyone is claiming that. I took the GP's point as what was desired was a "safe, performant, compact, and compatible JPEG XL decoder in Rust" and "performant" (as defined as the speed of the c++ version) was passed two months ago.

> They usually come from the fact that rust implementations are usually a second (or 3rd, or 4th) iteration of the design, and the lessons learned help performance.

Sure, and looking at the recent commit histories, the team is focusing on getting the rust version ready for this milestone for obvious reasons, and is less concerned about immediate parity in the c++ codebase.

▲

bawolff 2 hours ago | parent | prev | next [-]

>As much as I enjoy rust, there is no reason why a c++ library can’t be optimised to match the rust implementation

but why would you bother? The rust library is the one that is being chosen to use. There is no point optimizing a library which is not going to be used.

▲

hn92726819 4 hours ago | parent | prev | next [-]

I don't understand why anyone would continue working on the c++ project once the rust one started beating it in performance

	▲	Snafuh 3 hours ago \| parent [-]
		jxl-rs (rust) is just a decoder while libjxl (C++) can also encode. There is a rust encoder in active developing by someone outside the core JPEG XL devs.

▲

pibaker 3 hours ago | parent | prev [-]

I suspect the real reason is safety. Rust isn't bulletproof but it's certainly much better than C++ when it comes to defending against memory corruption related attacks. And when you are building a decoder for untrusted data sent over the internet, this kind of thing matters a lot more.

▲

rfgplk 4 hours ago | parent | prev [-]

If he is one of the devs between both libraries, why is there a performance gap? Why not port the optimizations from one lib to the other? You can even create a pinned agent workflow that automatically translates optimizations between repos. Fairly trivial to implement actually.

▲

AlotOfReading 4 hours ago | parent | next [-]

Just because you can theoretically write equivalent code in both languages doesn't mean two idiomatic implementations in each language will be 1:1 with each other. I haven't looked at the code in question, but some examples of common differences:

A C++ program might do template metaprogramming at compile time and the same thing at runtime in Rust, or vice versa. The C++ version might use virtual functions that rust wouldn't use. The Rust version might simply give more optimization information to the backend. The C++ version might use fairly awful parts of the stdlib like iostreams or shared_ptr that rust simply implements better. Etc.

Or maybe they're just focused on the rust implementation as they should be.

	▲	josephg 2 hours ago \| parent [-]
		Yep. Also: The rust borrow checker makes it difficult to implement tree like structures with pointers like you would in C or C++. Safe rust trees are (imo) best written using vecs. Rust makes function arguments noalias. Rust adds runtime array bound checks. Rust and C++ do iteration quite differently. Rust encourages map/filter/reduce. I suspect this results in different assembly. Doing a “unity build” in rust is really easy (codegen-units=1). In C++, you need to make heavy modifications to your build system and sometimes your source too. But with some time you could probably port the optimisations across. If anyone has some spare tokens, Claude can be quite good at doing this sort of work. Show it both repositories and tell it to make the C++ code just as fast as rust.

▲

NewJazz 4 hours ago | parent | prev [-]

Because developers of security critical code don't flippantly merge LLM changes for marginal performance gain, and their time is incredibly valuable.

▲

saagarjha 3 hours ago | parent | prev | next [-]

Shipping unsafe C++ is easier on Apple platforms than Rust. This seems unlikely to change anytime soon.

	▲	dlahoda 2 hours ago \| parent \| next [-]
		I do not feel so. Not only Rust does C API, but Objective-C the way it allows to call Apple platform and call Apple compatible functions back. Also well integrated Rust programs(with platform calls and low level hardware access) are well compiled without Apple SDK. 3-4 kicking Rust solutions are easy findable in this area.
	▲	josephg 2 hours ago \| parent \| prev [-]
		Is it? I wrote a pure rust iOS app recently. It uses native controls, and looks and feels great. iOS and iOS-sim are both very well supported targets by the rust compiler.

▲

deadbunny 5 hours ago | parent | prev [-]

Apple is gonna do what apple wants.

▲

cute_boi 5 hours ago | parent | next [-]

And their Safari browser is the worst. It doesn’t properly support PWAs or many other features because they want to maintain tight control over their App Store.

▲

dlahoda 2 hours ago | parent | next [-]

My wife, son and me not using Safari. Do not see how Safari relates to App Store.

We use App Store.

	▲	SR2Z an hour ago \| parent [-]
		The point of a PWA is that instead of downloading an actual binary app, you essentially get a webpage that runs like it was an app. They can be installed from anywhere and are safe by nature because they're really just webpages. That was the original conception of iPhone apps, until Steve Jobs realized just how much money could be made from the app store. Now you get to pay Apple a 30% cut for the privilege of installing software on your own device!

▲

arkon_hn 4 hours ago | parent | prev | next [-]

Not to mention how updates are tied to OS updates...

▲

dlahoda 2 hours ago | parent | next [-]

What Updates tied? App Store updates use same networking and storage as OS? Why it is bad?

	▲	2 hours ago \| parent [-]
		[deleted]

▲

tengwar2 3 hours ago | parent | prev [-]

Hasn't been the case for some time.

	▲	spartanatreyu 2 hours ago \| parent [-]
		Not true. MacOS releases a new version each year, the current MacOS landscape looks like: - MacOS Sequoia (previous version, everything works as expected) - MacOS Tahoe (current version, broken experience, basically Apple's "Windows Vista/8 moment") - MacOS Golden Gate (next version, fixes what was broken in Tahoe, comes out in a month) I'm on MacOS Sequoia because I have things that can't be broken by updating to Tahoe. I also cannot test how my websites/webapps will work in a month, because Safari's beta (called Safari Technology Preview) only works on Tahoe and Golden Gate. I cannot wait a month to update to Golden Gate because Golden Gate drops support for my iMac. And I can't test the new version of Safari on my Windows or Linux devices because Safari isn't available for them. I can test the Webkit browser, but that doesn't include the Safari specific changes that apple makes which I need to be able to test. --- So, I can't test Safari until I wait a month and purchase a new apple machine. (Oh by the way, apple keeps cancelling orders for new machines)

▲

nchmy 4 hours ago | parent | prev [-]

who are the knuckledraggers that are downvoting this comment? Its completely factual.

Significantly more on that here: https://infrequently.org/series/browser-choice-must-matter/

	▲	chuckadams 4 hours ago \| parent [-]
		Maybe because they don't want to see this thread dragged down into an open-ended gripe-fest against Apple, especially when it's concerning a feature Apple did ship before everyone else.

▲

llm_nerd 5 hours ago | parent | prev [-]

What a funny tangent to go off on.

JXL was dead. Apple is who brought it back to life[1], and the only reason Chrome resurrected JXL, and now Firefox followed their path, is because Apple pushed JXL support to a billion plus devices.

I know people like complaining about Apple, but there's a "read the room" kind of moment where people just seem to either not know the context or are just knee jerking.

[1] Worth noting that Apple used the reference implementation, libjxl, and that project still remains the reference implementation with the Rust port being experimental (and of course Apple deployed JXL support over a year before the Rust port even existed). Maybe they'll switch to it at some point, but it's a bit premature to complain about.

▲

ChoosesBarbecue 3 hours ago | parent | next [-]

I believe Firefox was the first to put out a standards position about adopting jxl if a Rust implementation happened. Chromium only aligned their position this year I believe, prior to that, it was a complete rejection.

Which is to say, Chrome followed Firefox here.

(Yes, I know Google Research implemented jxl-rs, but then, they also implemented jxl. Chrome’s position appears independent of them.)

▲

spartanatreyu an hour ago | parent | prev | next [-]

> JXL was dead. Apple is who brought it back to life

No, it was actually the PDF Association.

They added JXL to the PDF standard.

If google wanted to maintain support for displaying PDFs, they would need to add support for JXL.

	▲	NewJazz an hour ago \| parent \| next [-]
		* wanted to maintain support for displaying jxl images that are embedded in PDFs
	▲	llm_nerd an hour ago \| parent \| prev [-]
		The PDF consortium added JXL to the PDF spec two years after Apple deployed support to billions of devices. To anyone ackchyually paying attention to the JXL spec, lamenting that this superior format wallowed in obscurity (largely, it should be noted, because Google dumped it, and so many others just follow the leader of Google), Apple actually completely changed the path of the format's adoption.

▲

deadbunny 5 hours ago | parent | prev [-]

I wasn't complaining, it's a factual statement made sarcasticly.

Things apple do because apple do:

- make a mouse you can't use while charging it

- gets bored of the power inefficency L of x86, makes the fastest arm cpu that causes x86 manufacturers get serious about power

- hey, those f keys? what if useless strip

- decades ahead in panel tech and refuses to compromise

▲

concinds 4 hours ago | parent | next [-]

I don't see what this has to do with the topic, sorry.

	▲	wongarsu 4 hours ago \| parent [-]
		Their point is that Apple is the Nintendo of computing. They don't care what others do, they just do their own thing. Which produces some great things and some stupid things. They also don't care whether you think what they are doing is great or stupid, they just continue doing their thing Which then tracks back to the beginning of the thread: the correct answer to whether apple will adopt jxl-rs or keep libjxl is "who knows, no point trying to predict them". Which is not a value judgement How you square all of that with the iPhone regularly copying features Android had for years is your decision. Might be a symptom of the same, might be that this all was an entirely inaccurate description of Apple

▲

_joel 4 hours ago | parent | prev | next [-]

That useless strip could play lemmings and doom, it wasn't all bad

▲

tombert 2 hours ago | parent | prev [-]

> make a mouse you can't use while charging it

I'm not one to usually defend Apple-ism, but it always felt that this was such a nothing-burger. The mouse charges in like fifteen minutes and lasts for weeks. I don't have a work Macbook (or job :) ) right now, but when I did I would just occasionally plug it in while I went to the bathroom. It really was not nearly as annoying as everyone said it was.

	▲	spartanatreyu 2 hours ago \| parent [-]
		Remember all those times you needed to make a change to something a few minutes before it was submitted/presented? Imagine if you couldn't, because you needed to charge your mouse first.