Comments on: How we hash our Javascript for better caching and less breakage on updates http://blog.greenfelt.net/2009/09/01/caching-javascript-safely/ Communiqués from the Green Felt developers Sun, 01 Aug 2010 01:52:10 +0000 http://wordpress.org/?v=2.9.2 hourly 1 By: Yuval Kogman http://blog.greenfelt.net/2009/09/01/caching-javascript-safely/comment-page-1/#comment-1409 Yuval Kogman Wed, 09 Sep 2009 17:53:24 +0000 http://blog.greenfelt.net/?p=31#comment-1409 I use a similar technique but instead of minifying dynamically I just use git's hashing: http://blog.woobling.org/2009/06/git-s3-and-rewritemap.html I use a similar technique but instead of minifying dynamically I just use git’s hashing:

http://blog.woobling.org/2009/06/git-s3-and-rewritemap.html

]]> By: Jack9 http://blog.greenfelt.net/2009/09/01/caching-javascript-safely/comment-page-1/#comment-1398 Jack9 Thu, 03 Sep 2009 07:14:06 +0000 http://blog.greenfelt.net/?p=31#comment-1398 http://particletree.com/notebook/automatically-version-your-css-and-javascript-files/ autoVer works (implemented in your scripting language dejour). Changing the filename is the best cache-buster there is, so whatever is easiest for you. http://particletree.com/notebook/automatically-version-your-css-and-javascript-files/

autoVer works (implemented in your scripting language dejour). Changing the filename is the best cache-buster there is, so whatever is easiest for you.

]]> By: Jedediah Smith http://blog.greenfelt.net/2009/09/01/caching-javascript-safely/comment-page-1/#comment-1397 Jedediah Smith Thu, 03 Sep 2009 06:03:07 +0000 http://blog.greenfelt.net/?p=31#comment-1397 To deal with the client-server problem, add an api version number to all api calls and a special failure response that can come from any call telling the client to refresh the whole app. To deal with the client-server problem, add an api version number to all api calls and a special failure response that can come from any call telling the client to refresh the whole app.

]]> By: Isaac Z. Schlueter http://blog.greenfelt.net/2009/09/01/caching-javascript-safely/comment-page-1/#comment-1393 Isaac Z. Schlueter Wed, 02 Sep 2009 17:43:00 +0000 http://blog.greenfelt.net/?p=31#comment-1393 At Yahoo, I've built something like this twice, for two separate projects. There are a few other solutions floating around, but our environments are so often complicated and distributed, it's hard to get a good mix of production speed and development convenience that works in a general way. The problems that I'd see with this approach are that a) you're not concatenating your scripts in production (or maybe you are, and just didn't mention that in the article), and b) you're not loading your scripts from a CDN, meaning that they must be built on every FE box that you deploy on. On my most recent project, http://apps.yahoo.com, we developed a system consisting of these components: a) An INI file mapping the "raw" location to the "prod" location. The entries look something like: "/path/to/script.js: /path/to/script-89fn3902ha8ofh3o8ahfao03ha.js" b) A combo handler script our our CDN server. c) A PHP class that can be called and either spits out the raw javascript files as multiple script tags, or a single script tag pointing at the concatenated files. It allows the developer to customize the settings, so you can test the concatenated scripts by just running the build and pointing it at your local box. d) A build program that concatenates all the scripts in the htdocs/js folder, gives them a hash, pushes to the CDN server (or whichever server you point it at), and creates the INI file for deployment. So, we'd build away in development, happily using our 15 script tags that point at unconcatenated unminified stuff, and then run the build script on it, push the package to our test box, run our tests against the built JS, and finally push to the several production servers. None of this is rocket surgery, and of course, it's unlikely that Green Felt needs to solve the kinds of problems of scale that Yahoo faces. The main point, which I think you've done well, is to figure out a system where developers can iterate quickly, and pages can load even more quickly. At Yahoo, I’ve built something like this twice, for two separate projects. There are a few other solutions floating around, but our environments are so often complicated and distributed, it’s hard to get a good mix of production speed and development convenience that works in a general way.

The problems that I’d see with this approach are that a) you’re not concatenating your scripts in production (or maybe you are, and just didn’t mention that in the article), and b) you’re not loading your scripts from a CDN, meaning that they must be built on every FE box that you deploy on.

On my most recent project, http://apps.yahoo.com, we developed a system consisting of these components:

a) An INI file mapping the “raw” location to the “prod” location. The entries look something like: “/path/to/script.js: /path/to/script-89fn3902ha8ofh3o8ahfao03ha.js”

b) A combo handler script our our CDN server.

c) A PHP class that can be called and either spits out the raw javascript files as multiple script tags, or a single script tag pointing at the concatenated files. It allows the developer to customize the settings, so you can test the concatenated scripts by just running the build and pointing it at your local box.

d) A build program that concatenates all the scripts in the htdocs/js folder, gives them a hash, pushes to the CDN server (or whichever server you point it at), and creates the INI file for deployment.

So, we’d build away in development, happily using our 15 script tags that point at unconcatenated unminified stuff, and then run the build script on it, push the package to our test box, run our tests against the built JS, and finally push to the several production servers.

None of this is rocket surgery, and of course, it’s unlikely that Green Felt needs to solve the kinds of problems of scale that Yahoo faces. The main point, which I think you’ve done well, is to figure out a system where developers can iterate quickly, and pages can load even more quickly.

]]>