Hacker News new | past | comments | ask | show | jobs | submit login

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.




"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.


You 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.


Like 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.


Browsers 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.


It'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.


Yes the name is too encompassing. Almost click-baity for what it is.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: