3 ms·
The problem with using WASM is that because of their cache segmentation, every site that wants to render JXL would have to redownload the WASM decoder from scra
by mike_hearn 4y ago
The problem with using WASM is that because of their cache segmentation, every site that wants to render JXL would have to redownload the WASM decoder from scratch, and every page load that wants to render it would presumably have to JITC it from scratch too.
The WASM model doesn't seem to be a good replacement for browser plugins. Amusingly, when Chrome killed off plugins one of the rationales they gave was "reducing code complexity". The enormous bloat in the code and HTML5 specs that followed did many things, but reducing Chrome's code complexity isn't one of them.
- edflsafoiewq 4y agoThe problem with using WASM is it doesn't create an ecosystem where you can save the JXL, open it in a editor, upload it yourself, etc. like a normal image file.
- twotwotwo 4y agoA JXL contributor says full JXL (not just the recompression) can fit in 174kB, and thinks a smaller version could fit in 50: https://news.ycombinator.com/item?id=33414678 https://news.ycombinator.com/item?id=33414678 If you have large JPEGs it's not hard to earn the bandwidth cost back. I am definitely curious about other aspects of WASM performance including speed on first run.