>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.

> 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.

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.

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

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.

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

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.)

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

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

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/

of course these are all fairly controversial claims

- people dispute it compresses meaningfully better the types of images typically found on the web.

- progressive decoding is increasingly less useful on the internet as more and more connections become latency limited instead of bandwidth limited. jpeg & png (Although png's version has a cost i think) both support progressive decoding. However the last time i saw an image actually progressively decode was probably mid 2000s.

-flexibility in file formats is usually a bad thing. look at tiff.

personally i think jxl is massively overhyped. Its not horrible by any means, but its only marginally better than existing stuff, at best.

avif also supports lossless, but it's so inefficient it might as well not exist.

Lossless webp is a completely different image format compared to lossy webp, even though they come under the same file extension. Unlike lossy webp, it's a good image format that has excellent compression ratio compared to png. I've often been using it for screenshots to avoid damaging text clarity and still maintain acceptable file size.

jxl has excellent support for both lossy and lossless cases, and can replace both lossy avif (even if somewhat less efficient at low file sizes), and lossless webp.

Note also that converting jpeg to jxl is 100% reversible, you can convert it back to exactly the same image (byte for byte identical) if you need to.

> [JPEG XL can] display much larger images than AVIF can

Does it do tiles? What about pyramids (i.e. precomputed downscaled images, think mipmaps)? Right now the state of the art for truly large images (medical, geospatial, scanned artworks) seems to be JPEG (and I think also JPEG 2000?) tiles in TIFF containers, which would be fine except nobody seems to agree on how exactly to express the pyramids.

One particularly interesting (to me, at least) approach using progressive decoding was described by Jake Archibald ( https://jakearchibald.com/2025/present-and-future-of-progres... ).

If browsers extended `srcset` with support for HTTP Range requests, we could use a progressive-encoded jpg (xl or not) file as the source for multiple detail levels.

A device with a small screen would request the first 10kb of the image, while one with a medium screen might fetch 40kb.

The big advantage of that - for sites with many images - is a much better cache hit-rate for a given CDN spend.

Additionally, if you've already fetched a small version of an image and then want to view a bigger version, you've already got partial content downloaded & can fetch only the rest of the file.

Webp lossy is better (compresses more with higher quality image results) than jpeg at everything except smooth gradients at high quality settings according to the research I remember doing. Webp lossy can't seem to get rid of banding until you go ultra high quality settings. Jpeg can show blue skies without banding at much more reasonable quality settings. So webp is better at anything where smaller files is preferred, like all website usage. Jpeg is better for long term storage of very high quality lossy compressed images.

I chose webp for long term storage of scanned documents in our SaaS product, as size reduction was more important than no banding.

Also webp has excellent support in modern software and operating systems. So that's not a drawback any more. JpegXL will be the best of all worlds choice in a few years when software support is good.