Over a period of about six months in 2022, I was nearing the brink of insanity; I would go to bed every single evening and hear a washing machine running in a neighbouring apartment.

Status: 5/9 fixed

I’m a huge fan of the various Cloudflare offerings, and have been impressed time after time with the innovations and solutions offered by CF. This writeup therefore pains me, as I usually don’t have anything negative to say about CF, but after some months in production, and a severe lack of any meaningful reply from the CF Images team addressing any of these concerns (you won’t find a single official response in any of the linked community posts), I find it necessary to inform about some aspects of CF Images that I frankly find both surprising, concerning and disappointing. I will update this list when issues have been addressed.

Update 2022-03-15: The CF Team added a fix for “6. “Direct Creator Upload” is essentially useless” the 15th of February
Update 2022-03-16: The CF Team added a fix for “2. No way to track how many images has been served”, though I’m not certain when. This was brought to my attention by Discord user k8s (thanks!) on the CF Developers Discord
Update 2022-05-31: The CF Team added a fix for “4. Missing CORS header on the served images” at an unknown date
Update 2022-05-31: The CF Team added a fix for “5. Lack of dynamic resizing, only 20 “variants” allowed” sometime in April (?)
Update 2023-09-26: The CF Team addressed “1. Incredibly confusing and nonsensical pricing in a CF context” when they merged Cloudflare Images and Image Resizing, and updated their pricing model.

Earlier this year, when I went from having only Facebook-login on Wishy.gift to allow registrations with email address and password, one of my concerns was how to implement this is a way that protects the data and privacy of my users. I don’t have any ads or analytics on the site, the users can select whatever display name they want, and I never stored the email addresses I got from Facebook when a user registered or logged in - only a hashed^[1] version of the ID. Email addresses and passwords, on the other hand, are a whole other beast, and the consequences of a database breach much worse.

Whether or not something works without JavaScript (JS) is something that pops up in Hacker News comments from time to time - mostly when they don’t.

Who are these people with JS disabled, and why aren’t things working without it? The former are surely a minority, but even so, with NoScript being the 7th most downloaded Firefox Add-on and other browsers and ways of disabling JS existing, these users aren’t negligible. For the latter - I don’t know. Maybe modern web developers are lazy. Maybe they’re overworked, and pressed on time with too low budgets. Maybe supporting noscript is too hard. Maybe they don’t even know JS can be disabled or why anyone would do it.

I don’t claim to have the answer to these questions, but for some time I’ve had an idea on how to accommodate these users in a way that isn’t too much of a burden on the developer. The following is a short exploration of a method to do that, along with a demo showing it off. It’s something I hope to implement for my Wishy.gift, my side-project, at some point in the future, but more importantly, I hope someone can come up with something better.