Programming

17000 readers

94 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

snowe

Ategon

[email protected]

223

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

submitted 2 weeks ago* (last edited 1 week ago) by [email protected] to c/programming

271 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

[–] spartanatreyu 13 points 1 week ago (1 children)

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).

[–] [email protected] 4 points 1 week ago (1 children)

didn't google include jpeg-xl support already in developer versions of chromium, just to remove it later?

[–] spartanatreyu 2 points 1 week ago (1 children)

Chromium had it behind a flag for a while, but if there were security or serious enough performance concerns then it would make sense to remove it and wait for the jpeg-xl encoder/decoder situation to change.

It baffles me that someone large enough hasn't gone out of their way to make a decoder for chromium.

The video streaming services have done a lot of work to switch users to better formats to reduce their own costs.

If a CDN doesn't add it to chromium within the next 3 years, I'll be seriously questioning their judgement.

[–] [email protected] 1 points 1 week ago

Chromium had it behind a flag for a while, but if there were security or serious enough performance concerns then it would make sense to remove it and wait for the jpeg-xl encoder/decoder situation to change.

Adobe announced they were supporting it (in Camera Raw), that's when the Chrome team announced they were removing it (due to a "lack of industry interest")