[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