Automated Minifying, Munging, and JavaScript and CSS Versioning

swainn

unread,

Dec 1, 2016, 12:57:42 AM12/1/16

to Tethys Platform

@shawncrawley and I had a good discussion about the trouble of browser caching scripts and how to get around users needing to do hard refreshes when you make updates to your scripts. There are a few solutions out there that you can find on stack overflow like these:

http://stackoverflow.com/questions/1922910/force-browser-to-clear-cache

http://stackoverflow.com/questions/8347595/htaccess-how-to-force-the-clients-browser-to-clear-the-cache

The problem with the first solution is that some browsers don't cache resources with query strings in them ever (e.g. myfile.js?version=11), which means you would take a performance hit. The problem with renaming your file all the time is it becomes difficult to track history of the file in your versioning software. On a somewhat related note, it is also a best practice to minify and munge (m&m) js and css files to decrease the size of the files and increase the speed of page loads. @erice has made a bash script that we use at Aquaveo that m&ms some of our scripts using a Google tool. With that insufficient background, I have the following proposals:

(1) We create a new tethys cli tool that will automatically m&m all js and css files for an app and in the process name the m&m'ed files with a timestamp (e.g. myfile20160215.min.js) and clear out older m&m'ed files. For bonus points, this command line tool would only m&m files that have changed.

(2) We create a new template tag as an alternative for the static tag that would:

(a) load the original source file when debug = True (e.g. myfile.js) and load the m&m'ed version of the file when debug = False (e.g. myfileXXXXXX.min.js) if it exists. This gives you the ability to debug your scripts when you are developing and maximizes resource load speeds and obfuscation for production use.

(b) smartly detect the time stamped portion of the m&m'ed file and replace accordingly upon template render to prevent needing to manually change the reference in all the templates that use the files every time they are updated.

The workflow would be that the developer runs the m&m when a css or js file changes and new m&m files are generated for the ones that changed. The developer uses the custom static tag to load all static files using the name of the source file as they do now. With this approach, your original source file keeps the same name always, and can be appropriately tracked in your version control. Only the m&m'ed versions of the scripts have their names changed frequently, which doesn't matter much because they are unreadable.

Thoughts?

Scott Christensen

unread,

Dec 1, 2016, 10:30:36 AM12/1/16

to swainn, Tethys Platform

I like the idea of having a m&m cli tool, and the idea of a template tag that would dynamically switch between the original file and the m&m version based on the value of the debug setting.

However, I wonder if there might be a more simple solution for updating js/css files than time-stamping. I may be showing my ignorance here, but it seems like it would be a much simpler solution to configure the server to set expiration headers for js/css files:

http://stackoverflow.com/questions/4141643/how-do-i-set-expiration-on-css-js-and-images

http://serverfault.com/questions/23157/setting-expires-headers-for-static-content-served-from-nginx

Pros:

- much simpler solution to the problem that requires less Tethys code to be written and maintained

Cons:

- Having an expiration interval requires a balance between having browsers to reload staticfiles even when they have not changed, and having to wait until the files expire to get the newer version if they have changed.

--
You received this message because you are subscribed to the Google Groups "Tethys Platform" group.
To unsubscribe from this group and stop receiving emails from it, send an email to tethysplatfor...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/tethysplatform/6eca9e45-213e-4120-b5ea-e09d40078bb1%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Scott D. Christensen, PhD

Research Civil Engineer

Information Technology Laboratory

US Army Corps of Engineers