4 ms·
Shouldn't this be called "Immutable Resources" rather than immutable web apps? Sure with JS the resources make up the app, but that index.html is still mutable,
by jarfil 8y ago
Shouldn't this be called "Immutable Resources" rather than immutable web apps? Sure with JS the resources make up the app, but that index.html is still mutable, so no much different from an "index.php?section=whatever".
Setting such long expiry times on the cache also sounds like a great way to pollute browser caches with obsolete resources.
- daxterspeed 8y agoBrowsers have to worry about cache pollution already, I'm sure existing heuristics are more than capable of handling this use case. I agree with your first complaint however. This seems like an over-complicated way of assuring that browser caches don't bite you.
- tracker1 8y agoIt's pretty much a free option for most environments for modern web applications. Webpack can be configured to drive a version or hash based output easily.
- Illniyar 8y ago"Setting such long expiry times on the cache also sounds like a great way to pollute browser caches with obsolete resources. " Setting "forever" caching is standard practice for web development for many years. The browser doesn't really cache these forever - it is merely a hint to the browser that the resource won't change and you don't have to check it again. In fact, the more resources you can put with such caching the better both for you and the browser's speed.
- ams6110 8y agoYou really can't control how long something stays in a browser cache. The user can clear it at any time. Mine are cleared every time I close the browser.
- Illniyar 8y agoLike I said the header isn't to control how long something stays in the cache. It's to control how often the browser needs to check if the content changed.
- GeorgeO84 8y agoYes the name is too encompassing. Almost click-baity for what it is.