Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

I think it would make more sense to support the existing implementation than to start yet another one.

As for why jxl-oxide can't be used yet — it just isn't mature enough yet. They're still finding unimplemented or incompatible features, and have some unoptimized code.

JPEG XL is big and complex – it is designed to have every feature of every competing codec (from vector graphics to video), and beat them all on compression in every case, so it's a half a dozen of different codecs in a trench coat.



I believe that analysis is unfair or imprecise

libjxl decoder is 3-5x smaller in binary and 10x smaller in specification text size than an avif decoder


But it has an insane API. I wanted to support jxl encoding, but eventually gave up. Too complicated for average users


Could it be improved by having a wrapper for simple uses?


Why start from zero then if jpeg xl is big and complex?




Consider applying for YC's Winter 2026 batch! Applications are open till Nov 10

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: