[econ]

I believe the biggest performance hit lives in je inability to force reload a cached file with js (or even html(!)).

Setting a header only works if you know exactly when you are going to update the file. Except from highly dynamic or sensitive things this is never correct.

You can add ?v=2 to each and every instance of an url on your website. Then you update all pages which is preposterous and exactly what we didn't want. As a bonus ?v=1 is not erased which might also be just what you didn't want.

I never want to reload something until I do.

[mpeg]

This is a solved problem. All modern javascript bundlers append a hash to the filename, so even if cached indefinitely the js that hits the browser will update when it has changed as the url will change.

There are also other solutions if you need to preserve the url that are cleaner than appending a query string, like etags

[econ]

I want clean urls, I don't want to update every page or dynamically stich them together for each page view, I don't want a server cache for dynamically stitched together static content.

These are expensive hacks to work around a lack of basic functionality.

It reminds me of one kid taking something from another and refusing to give it back because they are larger.

People make websites, they think they control what goes on on the page. This isn't unreasonable to think. In fact, everything should be made to preserve that idea.

A situation where they just can't change the page shouldn't exist. Abstracting it away or otherwise working around it doesn't make it any less wrong.

Some browsers have a magic key combo to force reload. I suppose the solution is to put up a modal and ask the user to "reinstall" the web page.

I have a lot of static pages with minimal html/css that thanks to lazy loading and caching consume very little bandwidth. The technology is truly wonderful, clicking around feels like a desktop application.

[mpeg]

I'm not entirely sure what your point is. You don't want the complexity of a server cache but you want "clean urls" – having a hash in a filename does not necessarily make it worse, in fact it's closer to a pure url since one of the principles of hypermedia is that each url should point to a unique resource

Urls like /v2/yourfile.js are probably closer to that philosophy. Or /[hash]/yourfile.js.

[econ]

Turns out we can both be wrong (specially me) fetch() does have various cache options.

[econ]

To needlessly elaborate a bit more.

Any query string may prevent caching in some browsers (not sure which or if they still do)

File paths in my view are to organize files hierarchically not for hash or version numbers.

Html like <img src="logo.jpg"> looks neat and sophisticated. You can teach it in 5 seconds. If more characters are needed I expect something huge in return. For example styling it individually or as a group of things is a huge benefit. lazy loading is also HUGE.

[mpeg]

I've given you a list of options that you can use to cache your simple logo.jpg url: use a bundler that automatically appends a hash (it can be as a querystring if you want, you can do logo.jpg?h=xxxxx, you can use etags so that the client checks with the server if they have the latest version of a resource, you can also use the last-modified headers to instruct the client to send an if-modified-since

I'll give you an extra one I learnt about recently: you can use a custom compression dictionary, although this is only available in chrome right now, which means even when a file needs to be redownloaded the network size is tiny as it's compressed with a custom dictionary that matches a previous version of the file

[iainmerrick]

The standard solution is to have small top-level HTML files with short expiration (or no caching at all), then all the other assets (CSS, JS, images) have content-hashed filenames and are cached indefinitely.

Vite gives you that behaviour out of the box.

[econ]

I design and architect things specifically for the purpose they serve. What you describe, while popular and workable is putting the horse behind the carriage.