News for hackers. Stuff that matters.
Re:Don’t use JPEG-XR on the Web by m-p-3 on Monday December 31, 2018 @11:27AM (#18795260)
I hate that most websites are so heavy. I enjoyed browsing on my Kobo eReader but loading times of several seconds to a minutes makes it cumbersome. I limit my browsing to "lite" websites and HN suits that well. I also use the Pocket service because it's builtin and reduce the computational need required to read an article.
Re:Don’t use JPEG-XR on the Web by vanderZwan on Monday December 31, 2018 @11:36AM (#18795306)
> I hate that most websites are so heavy.

Most of which has nothing to do with compression format, to be honest. No image compression format is going to save us from websites that use 2000x2000 sized photos for 200x200 author thumbnails.

Re:Don’t use JPEG-XR on the Web by jrockway on Monday December 31, 2018 @12:17PM (#18795562)
As far as I can tell, nobody has ever made it easy to fix this problem. I don't believe there is any webpack (etc.) plugin that will just recompress images for you. You have to do it manually. As a result, people don't do it, even those that have a proper "build process" for their website.

Maybe I should write one, I guess.

Re:Don’t use JPEG-XR on the Web by mbell on Monday December 31, 2018 @12:42PM (#18795749)
This has been a solved problem for years in some frameworks, e.g. all the major image upload handling libraries in Rails have this built in an it's very easy to use. There are also plenty of webpack plugins for static assets:

https://github.com/metalabdesign/sharp-loader

https://github.com/herrstucki/responsive-loader

https://github.com/tcoopman/image-webpack-loader

(and many more, just grabbing a few examples)

Re:Don’t use JPEG-XR on the Web by JimDabell on Monday December 31, 2018 @12:48PM (#18795784)
Webpack also warns you about large assets by default, although the limit is 250KB, which isn't great.
Re:Don’t use JPEG-XR on the Web by idle_zealot on Monday December 31, 2018 @01:00PM (#18795866)
https://github.com/tcoopman/image-webpack-loader exists. The plugin will recompress png, jpeg, and svg images, as well as optionally converting the first two to webp. That said, it seems to have a persistent bug where jpegs are always converted to webp while retaining their original extention, and the maintainer doesn't seem to have the time to fix it or merge pull requests. If you wanted to help them out with that, they'd likely be amenable.

Something that I've not seen is a plugin/loader that will automatically use the <picture> tag to make available multiple auto-generated source images and a fallback <img>. It'd be great to be able to

import myImage from 'res/img/my_img.png'

and have myImage be a string like

<picture><source srcset="[generated-name-of-my-image.webp]"><img src="generated-name-of-my-image.png"]></picture>

Re:Don’t use JPEG-XR on the Web by hiccuphippo on Monday December 31, 2018 @03:09PM (#18796670)
Flif gives you a lower resolution image of you download only part of the file. Keep downloading and the image gets better resolution. If browsers supported it, they could have settings so you download partial images when roaming or the full file when on wifi.
Re:Don’t use JPEG-XR on the Web by vanderZwan on Monday December 31, 2018 @12:27PM (#18795628)
Are you seriously suggesting that image resizing to match expected output size is an unsolved problem?
Re:Don’t use JPEG-XR on the Web by robin_reala on Monday December 31, 2018 @06:25PM (#18797757)
As per the guidelines:

Please respond to the strongest plausible interpretation of what someone says, not a weaker one that's easier to criticize. Assume good faith.

Re:Don’t use JPEG-XR on the Web by lucb1e on Monday December 31, 2018 @03:56PM (#18796958)
> No image compression format is going to save us from websites that use 2000x2000 sized photos for 200x200 author thumbnails.

This sounded like an obvious truth but I think you're wrong!

JPEG has progressive rendering, so a browser could easily decide to stop once it has rendered enough for the image size. Once you zoom or if it's used elsewhere, it can render a little more.

Re:Don’t use JPEG-XR on the Web by dempseye on Monday December 31, 2018 @06:27PM (#18797772)
You still have to download it all, though. Right?
Re:Don’t use JPEG-XR on the Web by ben_w on Monday December 31, 2018 @06:56PM (#18797942)
Technically no, but JPEG divides the image into 8x8 segments (does that vary by channel? Can’t remember) so using full resolution images as thumbnails will still suck everyone’s bandwidth like correctly resized .bmp files
Re:Don’t use JPEG-XR on the Web by lucb1e on Tuesday January 01, 2019 @07:38AM (#18799956)
That's the point of progressive rendering, it renders less and less blurry the more the image loads. On slow connections with big images, I've seen the effect in the wild.
Re:Don’t use JPEG-XR on the Web by 75dvtwin on Monday December 31, 2018 @07:46PM (#18798160)
do you have by any chance, some numbers of the website size (js + images) that make it slow on Kobo?