We use webpack and all filenames are just sha hashes of the contents in the production builds. There is no need for the browser to ever ask anything about that file again (unless its purged from the cache...).
We use webpack and all filenames are just sha hashes of the contents in the production builds. There is no need for the browser to ever ask anything about that file again (unless its purged from the cache...).
Invalidating edge caches takes time and/or is expensive (i.e. Cloudfront), so adding the content hash in the file name is a good trick to ensure users always get the correct version of the asset.
I was just pointing out how and with what I use it.
If the appcache.manifest changes, it rechecks all files (or in my case, would only pointpessly re-check those which haven't changed, and download new ones), and the appcache.manifest will change the second a single byte anywhere in the program changes.
It's fantastic.
It's been replaced by Service Workers, but those can get reallly hard to deal with if they start caching themselves (!)
Chrome's devtools has ways to delete old service workers and such, but I've found that on Firefox it's next to impossible to debug.
[0] https://developer.mozilla.org/en-US/docs/Web/HTML/Using_the_...
Not to say service workers aren't the future, but implementing partially adopted features in web pages is poor practice.
But until then we wanted to keep it simple. Especially during development we don't want to have to deal with differences in SW and appcache.