I think that gzip compression can sometimes really reduce the actual difference between the compression tools to almost negligible in many cases. If this could be shown to be true the majority of the time, then a possible conclusion might be that a best practice would be to lean towards the more conservative compressors. I know that some people have already come to this conclusion and are already saying this, but it’s nice to be able to back it up with some pretty graphs and numbers :)

I’m looking forward to seeing the results of your tool. However, don’t forget that the quality of a JavaScript compression utilitiy cannot be summarized by its level of compression (most often, such tools yield different savings on different files anyway) The most important factor must be the safety and reliability of such a tool (how good is a JavaScript compression tool if it introduces new bugs? These bugs have a cost that must taken into account)

I would like to see a comparison of the JavaScript compression utilities in terms of their cost efficiency i.e. their benefits vs. their cost. However, this may be hard to measure.

Regards

also has the same affect as making a local to the scope.

Sorry to go of on a tangent but can’t help but bring it up when people define var’s in different scopes a they might declare variables in Java etc… as doing so always leads to possibly error prone results, as the way it works if far from expected.

See the Dojo compressed function test() below. See the problem?

function test() {
if (true) {
var test = {};
test.name = ‘Joe’;
}
else {
var test = {};
test.name = ‘Tom’;
}
}

****

function test(){
if(true){
var _1={};
_1.name=”Joe”;
}else{
var _2={};
_2.name=”Tom”;
}
}

I uploaded this morning an update that fixes the problem you are mentioning (the link being the same, make sure you empty your browser cache before downloading the archive) An ‘eval’ in the global scope should not prevent sub-scopes from being obfuscated.

Make sure you check my blog regularly as I will post updates and patches.

Looks like an eval() in the global scope prevents variable name substitution for the rest of the file. Should not be like that, should it?

Don’t hesitate to use the –warn option which will tell you about anything that seems abnormal with your code, or that might reduce the level of compression (typically, the use of ‘eval’ and ‘with’)

As for the YUI Compressor, I tested it and found that my prefered tool, JSJuicer, produces smaller output files. And without rewriting the names of local variables, strangely enough. Maybe the Compressor can’t grasp my code (Prototype.js style classes mostly).

- Indeed, there is no modification to both Rhino and Jargs (which makes updating them a trivial task)
- There is no reason why the classes are packaged in the root package. I’m just too lazy to write com.yahoo…;-) Seriously, I don’t know of any Java code publicly distributed by Yahoo, so I am not aware of any naming convention. However, this might change in a future version.
- If you want to integrate it in your own tool, just look at the code and start hacking it ;-)

http://base2.googlecode.com/svn/trunk/src/apps/packer/packer.html

Dojo compressor is NOT safe. Try e.g. compressing the following, which is valid JS:

if (document.createEvent) {
var event = document.createEvent(“HTMLEvents”);
event.initEvent(“dataavailable”, true, true);
} else {
var event = document.createEventObject();
event.eventType = “ondataavailable”;
}

Dojo compressor doesn’t like that the variable event is redeclared, and the compressed code will produce errors.

I think the funniest example was when I saw someone jumping in to ask the poster if he’d looked at MooTools…on the blog of someone who actually works on Prototype.

Thanks for the kind words. Another area where the YUI Compressor *seems* to do a better job than Packer is when parsing complex variable declarations. For example:

var foo = function () {…}, bar;
// do something with foo and bar…

Packer will not obfuscate ‘bar’ while the YUI Compressor will.

Regards