state of webp-hero and contribution wishlist

[chase-moskal]

thanks to fixes by the fine folks at google, i've reworked the libwebp build and finally have it working again. this unblocks further development on webp-hero, so i'm now prepared to merge incoming pull requests. i don't have many spare cycles these days to implement new features, but if anybody is looking to contribute, there are some things on my mind:

• conditional loading of the whole library — the currently recommended strategy in the readme is alarmingly wasteful, because it will load the entire bundle (94 KB), even on new browsers which already support webp. i think we should create some kind of wrapper which avoids loading the whole library when webp is supported

• complete support for all image types — i'd love for polyfillDocument to work on css background images and picture elements. i know some folks with forks have done work in this area: i would be interested to merge a rebased pull request for this functionality

• detect webp by mime-type — we should explore whether or not it's possible to detect webp images by their mime-type instead of by their file extension. we need to confirm that this can work for image elements, css images, and picture elements also. this would be a great improvement to webp-hero

• web workers for browsers that support it — i see that ie11 should support web workers. if we could add this as a progressive enhancement, it might couple nicely with conditional loading of the whole library to greatly improve performance and user experience

i'm still thinking about revisiting breaking refactors sketched out in #19 before releasing a v0.0.0, but these days i don't have the time to consider taking on that project. so for the time being, i'm planning to just keep maintaining -dev versions while avoiding breaking changes, accepting new incoming pull requests

    👋 chase

[homerjam]

Awesome work on this. I would possibly add some kind of MutationObserver to run the polyfill when the dom changes.

In terms of priority I think background image support is most important, followed by web workers.

Hopefully I'll find some time to contribute soon! Thanks again!

[chase-moskal]

note: async decoding operations should be queued, rather than returning a busy error 😛

[Nantris]

Converting other images to WebP is probably beyond the scope of this project - but with Safari and virtually everyone else supporting WebP now it seems like maybe the time to undertake that if that's of interest to the development team.

[chase-moskal]

@slapbox i agree, and i think some of the techniques of webp-hero could be used to create a really fantastic image converter app that runs 100% clientside -- imagine just dragging and dropping any image onto the webpage, then just click to download whichever format you want it in (webp, avif, jpg, png, etc)

i think it would be best for such an effort to be a part of a new project inspired by webp-hero, rather than redesigning webp-hero.

[Nantris]

Thanks for your great work and for continuing to develop and maintain it @chase-moskal!

We're working on a mobile app that runs code inside of a Webview and someday I'd love to be able to encode images that users insert into the app.

There may be some project like that that already exists, but I found none actively maintained with more than 3-4 downloads per week on npm - whereas your project has over 8k weekly downloads.

Thanks again for your great work. If you ever decide to start work on this, please do give me a ping!