Programming

17313 readers

357 users here now

Welcome to the main community in programming.dev! Feel free to post anything relating to programming here!

Cross posting is strongly encouraged in the instance. If you feel your post or another person's post makes sense in another community cross post into it.

Hope you enjoy the instance!

Rules

Follow the programming.dev instance rules
Keep content related to programming in some way
If you're posting long videos try to add in some form of tldr for those who don't want to watch videos

Wormhole

Follow the wormhole through a path of communities [email protected]

founded 1 year ago

MODERATORS

[email protected]

217

Which protocol or open standard do you like or wish was more popular? (lemmy.ml)

submitted 2 months ago* (last edited 2 months ago) by [email protected] to c/[email protected]

264 comments fedilink hide all child comments

There are a couple I have in mind. Like many techies, I am a huge fan of RSS for content distribution and XMPP for federated communication.

The really niche one I like is S-expressions as a data format and configuration in place of json, yaml, toml, etc.

I am a big fan of Plaintext formats, although I wish markdown had a few more features like tables.

you are viewing a single comment's thread
view the rest of the comments

[–] [email protected] 18 points 2 months ago (1 children)

Basically smaller file sizes than JPEG at the same quality and it also automatically loads a lower quality version of the image before it loads a higher quality version instead of loading it pixel by pixel like an image would normally load. Google refuses to implement this tech into Chrome because they have their own avif format, which isn't bad but significantly outclassed by JPEG-XL in nearly every conceivable metric. Mozilla also isn't putting JPEG-XL into Firefox for whatever reason. If you want more detail, here's an eight minute video about it.

[–] [email protected] 13 points 2 months ago

I'm under the impression that there's two reasons we don't have it in chromium yet:

Google initially ignored jpeg-xl but then everyone jumped on it and now they feel they have to create a post-hoc justification for not supporting it earlier which is tricky and now they have a sunk cost situation to keep ignoring it
Google today was burnt by the webp vulnerability which happened because there was only one decoder library and now they're waiting for more jpeg-xl libraries which have optimizations (which rules out reference implementations), good support (which rules out libraries by single authors), have proven battle-hardening (which will only happen over time) and are written safely to avoid another webp style vulnerability.

Google already wrote the wuffs language which is specifically designed to handle formats in a fast and safe way but it looks like it only has one dedicated maintainer which means it's still stuck on a bus factor of 1.

Honestly, Google or Microsoft should just make a team to work on a jpg-xl library in wuffs while adobe should make a team to work on a jpg-xl library in rust/zig.

That way everyone will be happy, we will have two solid implementations, and they'll both be made focussing on their own features/extensions first so we'll all have a choice among libraries for different needs (e.g. browser lib focusing on fast decode, creative suite lib for optimised encode).