^ this

Using AI leads to code churn and code churn is bad for the health of the project.

If you can’t keep the code comprehensible and maintainable then you end up with a worse off product where either everything breaks all the time, or the time it takes to release each new feature becomes exponentially longer, or all of your programmers become burnt out and no one wants to touch the thing.

You just get to the point where you have to stop and start the project all over again, while the whole time people are screaming for the thing that was promised to them back at the start.

It’s exactly the same thing that happens when western managers try to outsource to “cheap” programming labor overseas, it always ends up costing more, taking longer, and ending in disaster

This is why you’re meant to comment your code.

Your code tells you “what”, your comments tell you “why”.

Here’s a good review of comments in the redis codebase: https://antirez.com/news/124

I would advise against using pixels for margin/padding since it’ll have issues for users who have different zoom/text sizes than you do.

Stick to rem for margin and padding.

If you’re still early days with css, it’s worth pointing out that you should use a “css reset” file. It will solve problems for you that you don’t even know exist yet.

This doesn’t seem overly useful.

It’s a list taken out of a bunch of books with no regard for how something can be the best path in one language and a smell in another language.

Look at this page for example: https://luzkan.github.io/smells/imperative-loops

It suggests using functional loop methods (.map(), .reduce(), .filter()) instead of using imperative loops (for, for in, for each) but completely disregards the facts that imperative loops also have access to the break, continue, and return keywords to improve performance.

For example: If I have an unsorted list of 1000 cars which includes a whole bunch of information per car (e.g. color, year manufactured, etc…), and I want to know if there were any cars were manufactured before the year 1980, I can run an imperative loop through the list and early return true if I find one, and only returning false if I haven’t found one by the end of the list.

If the third car was made in 1977, then I have only iterated through 3 cars to find my answer.

But if I were to try this with only functional loops, I would have to iterate through all 1000 cars before I had my answer.

A website with blind rules like this is going to lead to worse code.

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