"I can't reproduce the bug you entered. Clear your cache, you must have the old version of that javascript file."
I don't know how many times I've had to say this as a front-end developer. But the problem of cached outdated JavaScript files is only going to get worse as we get better at separating Structure from Presentation from Behaviour. And it's also worse when you are doing more frequent updates to a production environment (just a dream when it comes to secure apps, but maybe a possibility for ongoing development of internal-facing apps). The biggest problem is that users can't be expected to know how to clear their caches. Things will just break and magically fix themselves if the user even has the patience to wait around until their cached file gets updated.
I googled around and found a theoretical answer in a forum somewhere. Based on what I found here is the solution that Josh and I put into practice:
<script type="text/javascript" src="/js/webLibrary.js
?buildtime=@BUILD_TIMESTAMP@"></script>
...where @BUILD_TIMESTAMP@ is a variable to be replaced by the back-end language / build script of your choice. Here are the issues that this solves:
- Browser does not pull the JS file from cache when there has been a new deployment.
- Browser cache continues to function as it should in between builds (speeding up page loads)
2 comments:
Thanks for the idea. Unfortunately, it did not work for me as the browser kept on caching the javascript anyway.
just to be sure you're doing it right, this one requires some back-end coder intervention, replacing the @BUILD_TIMESTAMP@ with, well, a timestamp, a sequence of numbers representing the time, every time your application is deployed.
Post a Comment