I don't agree. If a file has not been updated then the only cost is the time it takes to check the modification date of the file. When you do update files in production the attached timestamp forces browsers to pull the most recent version, which is a good thing.
I've seen plenty of cases where a browser continues to use a cached CSS file after its been updated on the server.
Aaron
Joe Ruby MUDCRAP-CE wrote the following on 21.09.2006 08:33 :
[...] I don't understand why people are doing all this updating in production -- that's just bad practice.
Ok, but... This helps when you upgrade the production with a new release. The problem is not the update frequency but only the fact that updates happen.
Lionel.
Joe Ruby MUDCRAP-CE wrote:
Lionel Bouton wrote:
Joe Ruby MUDCRAP-CE wrote the following on 21.09.2006 08:33 :
[...] I don't understand why people are doing all this updating in production -- that's just bad practice.
Ok, but... This helps when you upgrade the production with a new release. The problem is not the update frequency but only the fact that updates happen. Sure, but how bad is the browser caching problem? It seems like it usually takes (me) not more than a couple of reloads to grab the latest version from the server.
Joe
On the other hand, how bad is the 'bad URL' problem? It should be fine if the URL is a bit dirty since Rails creates it itself.. and the problem is not a user like YOU who does the refresh. It is users who don't know that they could/ should. Rails ensures that loading updated resources is the responsibility of the browser. But, it seems we may end up disagreeing on this issue 
Cheers Mohit.