Olissipo

Funny you call it magic, what actually does the conversion is Imagick.

In my project I have it integrated in the upload process. You upload a PNG/JPG and it does its thing. Since it's written in PHP (my project), and PHP has an extension to call Imagick, I didn't need to write any complicated code.

You can see on this page if your programming language of choice has any integration with Imagick.

But there's always the command line interface. Depending on your process it may be easier to create a script to "convert all images in a folder", for example.

but 2KB vs 200KB is paltry on even a terrible connection in the 2000s).

You still need to resize the images and choose the right ones (even if only for the device's performance).

So we might as well do that small extra step and add conversion to the process.

What I really wish is that we could get more browsers, sites, and apps to universally support more modern formats to replace the overly bloated terribly performing and never correctly pronounced animated formats like GIF with something else like AVIF, webm, webp (this was a roughly ~60MB GIF, and becomes a 1MB WEBP with better performance), or even something like APNG…

Isn't that the users' fault? And of the websites for allowing those huge GIFs.

Apparently browsers have supported MP4 for a long time.

https://caniuse.com/mpeg4

Even using the highest compression levels, barely any difference. Not worth it

If I understand correctly gzip, brotli and similar are best used to compress text.

Font files also shouldn't be compressed. A TTF file compresses a bit, but a WOFF2 file will be even smaller than that (and WOFF2 also doesn't compress well). So might as well use WOFF/WOFF2

For most of the images that I tried you can only see differences with the images side by side. It's really subtle.

I do have one example for which my config must be bad, compresses a lot but introduces a lot of noise

In case you still can't load the image, for the largest width the JPG file has 229.9KB, WEBP has 123.5KB, AVIF has 72KB.

I'm working on a project which generates images in multiples sizes, and also converts to WEBP and AVIF.

The difference in file size is significant. It might not matter to you, but it matters to a lot of people.

Here's an example (the filename is the width):

Also, using the <picture></picture> element, if the users' browsers don't support (or block) AVIF/WEBP, the original format is used. No harm in using them.

(I know this is a meme post, but some people are taking it seriously)

MultiViewer (which is an unofficial program, mind you) does support Linux, but you need to download the installer manually to install and update.

Other than that it works great

They started blocking access to the F1TV's website on Firefox...

Funny how everything works like it used to when I use an extension to pretend to be Chrome

Fortunately MultiViewer still works

The point is evaluating your stack once in a while. Eventually, you may need to switch or it may be worthwhile, even if you can stick with your current stack at a disadvantage.

For an extreme example, WordPress with crap page builders. It may not have been "that bad" when you started with it. But by now its very much worthwhile to switch. You don't "need to", but you should.

Back to this post, maybe they really are at that point that slowly switching is worthwhile. At least partially, where it makes the most sense (they mention using some microservices written in Go).

Personally I doubt I'll ever reach the switching point. But the trend for PHP devs seems to be switching to Go (when they do switch).

I don't have a favourite new feature, but I'm just learning about the Compound constraint which I'll definitely put to use in the near future.

I do have a favourite deprecation, of Removing the Default Garbage Collector Probability option. I've had weird and spaced out crashes when developing before I knew about this. Apparently this is to remove stale sessions once in a while. According to this comment, Debian based distros already handle it cleanly with a cron job, so I just unset that Symfony setting

As long as optional parameters are placed last, I don't see why not.

PHP8's named parameters lessen the pain of using a function with optional parameters spread around, but I still stick to that rule.