Hacker News Reader

Comment by dragonwriter | Hacker News Reader

So, what you are saying is that JPEG-XL is superior, as long as your use case is insensitive to whether the majority of web users can view your content?

View on HN

I get it but 2+ billion Apple device users is not nothin’.

They can render JPEG-XL; everything else will render the fall back format like JPEG or WebP.

Teams & developers will likely only chose a single format if they can, the one that most browsers support, because doing some content negotiation is more code, more work. It doesn't take away anything from the parent point though, if JPEG-XL is more performant it could reduce bandwidth requirements.

> because doing some content negotiation is more code, more work

It's actually not more work. The user's browser automatically handles the content negotiation and only downloads the image format it understands:

    <picture>
      <source srcset="photo.jxl" type="image/jxl">
      <source srcset="photo.webp" type="image/webp">
      <img src="photo.jpg" alt="Product photo" loading="lazy">
    </picture>

macOS, iPadOS and iOS get the JPEG-XL image, device that can handle WebP get that and everything else gets JPEG.

There are several image delivery services that will provide the best image format depending on the device that's connecting.

I mean if you define superior not in terms of its technical merits but because of its blessed status by Google. It's not a terrible format but it is very much "what is the worst quality we can reasonably get away with to save on bandwidth." Such a thing does have its uses.

At some point you have to be pragmatic and meet users where they are but doesn't mean you have to like that Google did throw their weight around in a way that only they really can.

> I mean if you define superior not in terms of its technical merits

“Technical merits” are rarely, for anything, the sole measurement of fitness for purposes.

Even for purely internal uses, internal social, cultural, and non-technical business constraints often have a real impact on what is the best choice, and when you get out into wider uses with external uses, the non-technical factors proliferate. That's just reality.

I understand the aesthetic preference to have decisions only require considering a narrow set of technical criteria which you think should be important, but you will make suboptimal decisions in the vast majority of real-world circumstances if you pretend that the actual decision before you conforms to that aesthetic ideal.

just fuking use a poly fill to add support of JPEG XL. Or store JPEG XL and convert on the fly to JPEG to supply it to browsers that don't support JPEG XL.

> just fuking use a poly fill to add support of JPEG XL. Or store JPEG XL and convert on the fly to JPEG to supply it to browsers that don't support JPEG XL.

Doesn't a polyfill imply more Javascript running on the device?

Only until the browser gets updated and then the polyfill stops being invoked automatically. It's self-healing.

Tt's a WASM . And really isn't very big. So if you need to store and serve many images files, potentially big images like in an preservation & diffusion software (like the stuff that I'm working), I felt that I could afford to pay the extra few KiBs on that WASM.

No need to bring JavaScript into it.

In HTML, use `<picture>`: https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/...

In CSS, use `image-set()`: https://developer.mozilla.org/en-US/docs/Web/CSS/image/image....

Reply on news.ycombinator.com