16

Do you have a step in your deployment process that minifies JS? Do you have any sort of preprocessor for your JavaScript that allows you to leave in comments and console.logs and then have them automatically stripped out? Is your JavaScript machine generated by GWT or Script#? Do you use ANT or another tool to automate deployment?

I see a lot of JavaScript that looks like it comes right out of the editor, complete with lots of white space and comments. How much of that is due to not caring about the state of the deployed code, and how much is due to the spirit of the open web?

Jeremy Cron
  • 2,404
  • 3
  • 25
  • 30
Nosredna
  • 83,000
  • 15
  • 95
  • 122
  • 2
    If compression rate is what you're worried about, this page has a nice overview of the ratios some tools achieve with some of the most popular javascript libraries: http://compressorrater.thruhere.net/. – ChristopheD Jun 04 '09 at 19:09
  • I was wondering about this myself recently, from the perspective of "best practice". The IT geek in me says that the web server should be handling compression, not the developer. I did some cheap profiling on mootools and found that pre-compressing with YUI or whatever produces a marginal size improvement over and above standard gzip, which is what the web server would use. But is this margin worth the hassle and the potential offense against the "spirit of the open web"? – Ben Dunlap Jun 04 '09 at 19:16
  • @Ben Dunlap: that's when you do both: minify AND gzip. You can minify with a production build script, and the server takes care of gzipping for you. – montrealist Jun 04 '09 at 19:19
  • 2
    @dalbaeb, yes I know -- that's exactly what I was testing; sorry if it was unclear. I took the minified version of mootools and gzipped it and then compared the result to a gzip of the raw version of mootools. The difference was fairly slight and so my question is: if the web server should be gzipping all responses anyway, what do I gain by minifying? Because I know what I *lose* by minifying: code clarity for third-party readers, and my time (when I have to make changes to release code). I'm trying to do a cost/benefit analysis, I guess. – Ben Dunlap Jun 04 '09 at 19:39
  • What you gain by minifying would depend on how much code you have. Even having shorter variable/function names could sometimes cut down on overall size and download time. We're talking about milliseconds here, that is true. But the less user waits, the better. Besides, if you're only minifying for production, you'll still have your readable 'dev' version you can work on. Clarity for third-party readers - yes, this will suffer. Again, it depends on how valuable that is to you. – montrealist Jun 04 '09 at 19:51
  • I find it highly valuable. Personally it would drive me crazy if I found a really beautiful site and wanted to explore their CSS, did a quick wget, and then found it minified, or worse, obfuscated. And don't get me started on Javascript. I used to work on a web proxy system and often had to walk through JS to find out why our proxy wasn't getting along with a web app. This was before minifying was popular, but obfuscating was some developers' best friend then. Ugh. Of course those were pre-Firebug days as well... – Ben Dunlap Jun 04 '09 at 20:15

13 Answers13

11

I usually check it out with JSLint to make sure it is bug-free, then pack it/encode it with YUI compressor.

Gad
  • 41,526
  • 13
  • 54
  • 78
  • 1
    Just to note, but JSLint doesn't actually check the script to ensure it is bug from from a operational standpoint (e.g. that range test is checking the right range) but to double check the syntax to make sure you didn't do anything wrong. – rjzii Jun 04 '09 at 19:22
4

My steps include:

  1. I write Javascript using TextMate with the Javascript Tools bundle installed. This JSLint's my files on every save and notifies me when errors occur.
  2. I use Sprockets to automatically concatenate my various Javascript files.
  3. I run the resulting concatenation through jsmin to generate a minified version.

I end up with a concatenated lib.js file and a minified lib.min.js file. One I use for development, one for production. TextMate commands help automate it all.

I'm still looking for a good solution to actually (unit) test my scripts.

avdgaag
  • 41,292
  • 7
  • 29
  • 26
  • Do I have to know Ruby to use Sprockets? Or can I just install Ruby and learn Sprockets? – Nosredna Jun 04 '09 at 22:52
  • @Nosredna: You don't have to know Ruby, but it helps to customize it. I call Sprockets from a Ruby script, but it also has a command line tool. – avdgaag Jun 04 '09 at 22:55
  • On a side note, the windows "equivalent" of TextMate is e-texteditor, which also jslints the files. – Gad Apr 08 '10 at 11:32
2

FWIW, here's an interesting mini-benchmark on various ways you can minimize your Javascript source:

http://www.ericmmartin.com/comparison-of-javascript-compression-methods/

In short:

  • gzip compression in HTTP protocol really makes a difference (although you need to pay a CPU cost at the server side)
  • minification (removal of whitespace/comments, change of variable names etc.) also helps, and if you want best result, use it together with gzip compression
  • js-based decompressors are most likely useless - while you might get smaller size, the CPU overhead on the client is significant.
yacoob
  • 811
  • 1
  • 11
  • 20
2

Check out YUI Compressor its a console app that you can use to minify (strip out comments, whitespace etc..) and also obfuscate your javascript files.

Rob
  • 3,026
  • 4
  • 30
  • 32
2

JSMin it from Douglas Crockford. We've got it hooked up as a macro in Studio as well as a post build item for some of our larger projects

Mcbeev
  • 1,519
  • 9
  • 9
1

For one of our products, we concatenate all Javascript files together (most files are used on most pages, so this makes sense for us) and use Javascript::Minifier. This has given us a pretty nice speed boost.

Chris Simmons
  • 1,843
  • 1
  • 12
  • 18
1

A lot of it is probably due to not caring about people that might be viewing your pages on slower machines with slower connections and assuming that everyone has a 50Mbps line and three Gigs of RAM.

We are minifying our (hand-written + plugins, jQuery, etc.) JS as a part of the build process in .NET environment. No preprocessor, this is something we should definitely be doing once time permits.

P.S. By the way, we're not using console.log, as this will break IE. Instead we have a simple wrapper function, something like:

function log(stuff) {
    if (window.console && window.console.log) {
        console.log(stuff);
    }
};
montrealist
  • 5,593
  • 12
  • 46
  • 68
  • 1
    What kind of JavaScript libraries are you writing, where minify would actually have a non-trivial effect on the end-user's free RAM? – Ben Dunlap Jun 04 '09 at 19:18
  • Yes, that's true, sorry. Please disregard the RAM bit. Minifying has no effect on RAM of course, I just threw in the matter of writing quality code for no reason. – montrealist Jun 04 '09 at 19:56
1

I have a PHP script that does it on the server side and keeps a cache of whatever it pulls from the source folder(s).

Nolte
  • 1,096
  • 5
  • 11
0

There's also a .NET port of YUI Compressor which allows you to:-

  • intergrate the minification/file combining into Visual Studio post-build events
  • intergrate into a TFS Build (including CI)
  • if you wish to just use the dll's in your own code (eg. on the fly minification).
Pure.Krome
  • 84,693
  • 113
  • 396
  • 647
0

I thought I would share my approach to js deployments. Have a look at this blog post: http://www.picnet.com.au/blogs/Guido/post/2009/12/10/Javascript-runtime-compilation-using-AspNet-and-Googles-Closure-Compiler.aspx

This also includes code to compile (using google's closure compiler) at runtime (when needed).

Thanks Guido

gatapia
  • 3,574
  • 4
  • 40
  • 48
0

One word- packer

Alec Smart
  • 94,115
  • 39
  • 120
  • 184
  • Most of the libraries have moved away from packer and to a minifier with gzip. Packer uses up valuable time as the code unpacks itself. – Nosredna Jun 04 '09 at 18:59
0

Light a candle, whisper a prayer against IE6 errors, and click "go". Does that count? :)

Some Canuck
  • 846
  • 7
  • 13
0
  1. I don't minify my own javascript code since text tends to gzip/compress well.
  2. I would minify a very large (say > 100 kb) javascript library (but then again I probably would not want to be using such a large library (or just ship what i use)).

I tend to believe that a lot of the javascript-minification is (in reality) done to achieve some sort of (futile) obfuscation of javascript code instead of the proclaimed end-user performance gain.

ChristopheD
  • 112,638
  • 29
  • 165
  • 179
  • 2
    If there's a lot of comments in the code, one might use minify as a convenient stripper of comments. – Nosredna Jun 04 '09 at 20:02