The attempt to provide a second JPEG-XL implementation has stalled. Two independent implementations are the bar for a web standard. AVIF meets it, JPEG-XL does not.

There has been enough 3rd party interest to create multiple AV1/AVIF implementations. JPEG-XL has its original team (doing great work), and then… commenters lamenting, but nobody else invested enough to actually to write the code.

Browsers' goal is not just to have every benchmark-winning format. They also need to minimize attack surface, risk of bug-compatibility (which is why one and only implementation is not sufficient), and watch out for long-term costs of code size, maintenance, and technical debt. New codecs can be added at any time, but can never be removed.

AV1 got in, because video really needed an answer to the looming threat of patented expensive H.265. There was a risk of repeating the pains of H.264 support, and this time without Cisco's licensing loophole. Then AVIF got in, because AV1 was already in. It's that simple.

Not to mention the complexity is mostly offloaded to the maintainers of the library itself, not the browser that calls it.

I wish Mozilla had gone ahead and enabled it by default in Firefox, as I'd hoped it would. Still salty it didn't happen (yet, at least). It seems like such a clear choice to developers that there's actually people being vocal about it (as evidenced by the sparse but constant stream of e.g. posts on HN about browser image codecs, which is a topic _no one_ finds sexy otherwise), but browser vendors still won't budge. It's weird to see them say "sure it's better, but it's not better enough than the alternatives". There's a large enough discrepancy in my own perception of the merits of jxl and that of the people making choices for browsers that I genuinely wish I understood them, because it feels like I'm missing something.

I still convert my pictures to jxl locally and, and the space savings are enough of a reason to go through the trouble of converting - it just seems like a no-brainer that it'd be even more valuable on the web, as bandwidth savings are generally even more important than disk storage, and then there's still the plethora of other features on top of that.

>Obviously, this is a case of them showing favoritism toward codecs based on the IP owners of those codecs.

I am sorry it is hard for me to not take a jab at this considering their codec is patent free so their should be zero IP owners. /s

Anyway JPEG XL is a miniture project physically. A compressed wasm binary is around 175 kB. I don't think complexity is an issue there. [1]

[1] https://twitter.com/jyzg/status/1633504595094773765

[deleted]