yes, it’s pretty good. Let’s say I had more fun building mine
As per the gzip suggestion, problem is if you gzip your javascript IE (at least up to version 6, don’t know about version 7) will not be able to use it. Sometimes it works, sometimes it’s not able to execute the javascript, and sometimes it even crashes.

So if even if you gzip your javascript, that will be of no use to the most part of your users.

JavaScript library in a rather big project (using prototype and scriptaculous):
original script file: 369 K
compressed with gzip -9: 83 K

(I sloppily missed it earlier as there was no autodetect code in place for it.)

I’ve been poring through and tweaking the Google Maps code numerous times too, but it has always been a high time cost endeavour, at least on the levels I have been digging; the widget creation code, event, image+transparency and maptile handling subsystems to name a few places where very little publically named method, and most of all, parameter names, are strewn about. It’s just as painful every time. I probably would not be as passionate about this if I had not been through any of that.

But you are right about your tools in development being interesting from a higher level of development perspective; there are lots of things they could do that presently available javascript creation supporting toolkits do not offer.

Nope, I guess you are not the only one that think it

But I do not think removing extra stuff in javascript changes substantially the openness of the web. You are already entitled to follow the copyright of javascript code, and there are a lot of pretty printers for javascript out there. In fact, I will put a pretty printer along the compressor.

Sure it will not bring back comments and renamed names, but it is more than enough to make javascript code understandable. For instance, I regularly read / modify google maps code without even running it through a prettifier.

As you said, compressing javascript code with mod_deflate wins over removing extra stuff hands down. But these are cumulative wins. Wether you should do the “removing extra stuff” pass depends on your particular situation. And to some people the slight obfuscation provided by this pass is a feature instead of a bug.

The thing is that I am mostly interested in the “extra size optimizations” I hinted above, in point 5. I am using prototype.js and script.aculo.us, and these libraries are huge. I want for my tool to remove unused parts of these libraries, and collapse all the used files on a single one. That is why I went all the way to write my own parser.

Currently downloading 4 or 5 javascript files at the same time stress a bit navigators, and I want the front page to show as fast as possible.

I know there is a balance to keep here. Having javascript splitted in several files helps if the base ones are cached among the whole website. However I hope the end result to be so tiny for total time to be dominated by the number of files, but I will certainly have to measure it.

Last, and I should confess that was the main point to start the parser, it looks like a cool project with some potential. I may grow it to a full javascript engine, and coupled with a html parser it may be a nice tool to debug some javascript problems that are not easy to debug with today tools, as memory leaks in some browsers, or warnings when you use features that will not run on old browsers, and so on.

Btw, I have already fixed the parsing of the regular expressions with the hack I outlined above, and this morning I had an idea to insert virtual semicolons as needed, let’s see if it works…

Thank you for your comments Johan!

Cheers,

Have you measured gains (okay, drops) in page weight, using both techniques? Just starting out with some imperfect sluggish hack such as the BrainJar crunchinator (which does not treat regexps, or even comments, very well) and comparing the results with what gzip -9 does to the same page? Last time I tried, gzip won by a margin.