Someone had a similar discussion a while ago which ended out in the creation of a rails plugin called ‘asset packager’ (http://synthesis.sbecker.net/pages/asset_packager). I think this is part of Rails now (or will be in future) but the underlying concept is probably one that can be ported.

Basically, whilst in development mode you access your files as normal. When your site is set to production mode, it looks for the compressed script files which are built (and compacted into one file as Corey mentioned) using a build script when you update your site.

The compressed files don’t go anywhere near your version control, and as long as you keep your javascript tidy (semi-colons, damnit!) it melds into your workflow.

Couple this (as you’ve said) with server-side compression and you’ve got a nice ‘free’ performance boost.

Like most languages JavaScript should be particularly well suited to the Huffman algorithm of GZip and combining multiple JS files into one could see further gains.

Thanks for the compliments on the posts, trying to keep them more regularly paced than before but I’ve now run out of hashing algorithm filler ;-)

[)amien

Seeing the difference in the ‘gzip’ vrs ‘gzip and minified’ version of the library certainly seems minimal, so you could take it or leave it.

I think Gavri makes a good point. It’s a fairly common and well known optimisation to minify and compress javascript and css files – every little bit helps, especially since we seem to be writing bigger client side files. It’s not exactly premature, but there is credence in your words “measuring the problem and result first”.

We’ve been using YUI-Compressor as an MS Build task using Web Deployment Projects, so the source is minified as part of the release deployment process – and it rocks. It means we can develop and debug with full source, pass QA, then deploy the production ready code. It’s simple, once established takes no additional time, doesn’t interfere with the development process and gives the best performance on the client side. Actually, if you use a fairly descent minifier, you can pick up a few warnings you may have missed during development.

I’m a firm believer that all changes (projects for that matter) should be source controlled. Here, minifying the source has an added benefit of deterring minified files being modified – at least, I’d hope they’d think twice, looking at long lines of code, with the only meaningful member names being on the public side. More than likely their non-source controlled items will be overwritten at the next deployment.

Keep up the good posts (I’ve been subscribed for about 10 posts now :)

Dave

The code output by the minifier and other shrinking tools is incredibly difficult to work with should you need to debug or change it.

Sure you might have another unshrunk copy somewhere but what if somebody has modified the compressed version. How exactly would you diff that?

[)amien

Premature optimization is evil because you optimize with vague notions and at an early stage. At a stage that hinders development.