← Feed
@fvsch@hachyderm.io
2026-09-16 05:28 UTC
@gianni@disobey.net @wbrowar@hachyderm.io @nhoizey@mamot.fr It looks like most people agree that JXL is a great efficient general-purpose format, but:
1. Critics of its inclusion in browsers see the general-purposeness as a flaw (because it leads to it being not the most efficient codec vs AVIF for mainstream Web use cases, so why take on the support cost for decades?).
2. Proponents see it as feature because they're betting on JXL as a JPEG-1992 (and PNG) successor, and in practice this successor status requires support in all broadly-used apps, including web browsers and file explorers and document viewers and graphics software.
The thing is, both sides are right and also have some frustrating arguments. I personally hope the proponents are right about the benefits of cross-app support, but it's a gamble and if it doesn't pay off then it's a lot of wasted effort and the critics were right. But not taking a risk is also an opportunity cost for the wider industry, so critics are not automatically right just because there’s a risk and they’re being conservative.
Replies (2)
-
Frustrating arguments include:
- JPEG XL proponents arguing that JXL is on-par or better than AVIF for majority Web use cases, relying on either outdated info or wishful thinking.
- JXL critics exaggerating risks and dismissing long-tail and cross-ecosystem use cases. (E.g. recently Jake Archibald wrote that the “JXL is a nice to have” argument would justify adding browser support for proprietary RAW formats as a nice-to-have — a wildly excessive comparison.)
Open ##5157827
-
@fvsch@hachyderm.io @wbrowar@hachyderm.io @nhoizey@mamot.fr there will be more codecs, and it will be worth it to wait. AVIF is just too good to justify JXL right now, and the general-purposeness is not what holds JXL back, it is a bad set of coding tools. JXL almost included AVIF as its lossy component, but rejected the proposal.
Open ##5157829