http://razorsharpcode.blogspot.com/2010/02/lightweight-javascript-and-css.html

Works well for me.

Create a file, call it js.php, that can be invoked like this:

What it should do is:
1. Hash together the entire Query string and treat the MD5 hash as a filename.
2. If that file exists in the cache, compare the modification time of each file in the Javascript directory: Eg, “DOM.js”, “animations.js”, “pages/home.js”
3. If ANY of the files have a modification time greater than the archived file, or the archive doesn’t exist, (re)build it:
a. Read each javascript file
b. Use a regular expression to kill comments and blank lines.
c. Concatenate all the files together, in order, into one file (You’ll get better gzip compression this way too).
d. Store two versions of this file in your cache directory — one as .js, and another gzipped copy as .gz
4. Serve the appropriate file depending on whether the user’s browser explicitly supports compression in the accept header.

This will seriously reduce both transmission time and processing time, and since it is a dynamic script, browsers are MUCH better at expiring the content and checking for a new version when users visit the page — important if you are updating your site a lot. Once you feel that a set of scripts is stable, you can send the appropriate headers to make the client’s browser stop polling for new versions every time. And you can always compress / obfuscate the scripts beforehand

Even though it makes things unreadable, its true, 50-75% savings on code sizes for deployed JS as opposed to the source makes things faster (there are people still out there who don’t have whopping ADSL links or OC-48 lines)

(I credit the people who’s code I have used to work out parts – thats just common courtesy)

If the world were a nice place where everyone played nicely together and credited their sources, we wouldn’t have to do this, but I get fed up with people taking the code from OnOneMap (http://ononemap.com) and using it to attempt to build a rival service without crediting us for it.

I’ve not found a good compressor yet, but I’m still looking.

http://dojotoolkit.org/~alex/js_with_compress.jar

This is a modified version or Rhino (the Mozilla JS interpreter written in Java). We (the Dojo project) have added a “compressor” method to the built-in Decompile class. Since we’re operating on the token stream from the parser, this system is somewhat less prone to errors and “overzealousness”. A new “-c” flag sends the “compressed” version of the input to stderr. Normal invocation is:

java -jar js_with_compress.jar -c in.js > out.js 2>&1

This tool will NOT mangle your public APIs. We’re using it as a part of the build process in Dojo and it’s been working well for some time now. It’s much less error prone than the regexp-based stripper we used in netWindows.

Source for the tool (i.e., a zipped up version of my anonymous CVS checkout) is available in the same directory as the Jar file.

Regards

Java and JavaScript are as much alike as Car a Carpet.

If you just want to strip comments and stuff you could try using the c preprocessor. If you’re serving over gzip compression having expressive variable and function names shouldn’t hurt you too much.

Could you have stubs that auto-load additional chunks of javascript on the fly?

In qooxdoo we use a self written python script for compression and extraction of documentation in the style of javadoc or doxygen. It works well on multiple depending files. But it does not shorten variable or function names.

Al.

Maybe there’s a php script somewhere for this?

#Now quite intrigued at the idea#…..Hmmm, off to Google! #Laughs#