spartanatreyu

QOI is just a format that's easy for a programmer to get their head around.

It's not designed for everyday use and hardware optimization like jpeg-xl is.

You're most likely to see QOI in homebrewed game engines.

Are you not made primarily of water?

The syntax is only difficult to read in their example.

I fixed their example here: https://programming.dev/comment/12087783

I fixed it for you (markdown tables support padding to make them easy to read):

|markdown|table|
|--------|-----|
|x       |y    |

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.

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

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

That's 41 degrees for everyone who doesn't measure things in bird per gun.

You should put this in codepen so people don't need to clone a repo to see it.

For example, here's a 3d css-only thing I was fiddling with: https://codepen.io/spartanatreyu/pen/yPyNjw?editors=0100

You keep saying "relevance", and now other things like "gimmick" and "marketing".

Why are you so focused on "relevance"?

They're completely unrelated to Deno.

Node had problems, ts-node had problems, Deno fixes those problems for developers.

Separately, Bun trades solving some problems for solving other problems.

Developers are free to choose between runtimes based on what problems they encounter.

Personally I use node for existing web projects and deno for data processing and to compile scripts into redistributable binaries.

No one's asking nor wondering why you find looking at things in the sky beautiful.

They're asking why you're ascribing meaning to an arbitrary number of days. Months aren't subjective, they're arbitrary.

What to know about blue supermoons:

1. They literally mean nothing.
2. The change is imperceptible to everyone.
3. Expect useless clickbait slop about it until it passes.

stdlib.io is a data process/vis library, not a standard library.

jQuery was a DOM/Utility DX library (and also a compatibility layer before all browsers finally focussed on standards), not a standard library.

Deno people are trying so fucking hard to be relevant. It’s embarrassing. Bringing nothing to the table has been their MO from day 1.

Let's examine that.

Deno has always been:

(parapharing) "Hi, I'm the creator of Node and want to make it better but can't get everyone on board with the changes. So I'm going to create a new JS runtime. Node will need to implement these improvements to keep up or everyone will switch away from node. Either way, developers win."

We know it's been that way since he was a month into Deno's development in his famous talk: 10 Things I Regret About Node.js

Deno [...] Bringing nothing to the table [...]

Have a look through each of those 10 points he brought up, then compare that to node before, and node now. It's pretty clear he gave them the swift kick in the ass to start making those changes. We win. That's clearly a success.