Thanks for this. I’ve recently used this and ran into a slight snag. Because jsmin strips all comments, among other things, it was rendering conditional compilations useless, which was a pain since in some case it will actually crash the browser. I’ve yet to try and come up with a solution, but hopefully i’ll find the time for it soon.

It wasnt that jsmin wasnt working, but rather working too well :-).

Just curious how this specs up to Dean Edward’s Packer’s minification process? I’m not talking about the base62 encoding in an eval) statement, I mean the ‘none’ encoding option that attempts to do similarly what JSMin does. Just curious about your thoughts/feedback.

Pax, - Stan

I haven’t actually used Packer, but based on what I’ve read, it sounds like it generally achieves a higher compression ratio than JSMin. The flipside is that JSMin is faster and much simpler to implement.

Thanks for jsmin.
Can we expect the add of an option to preserve conditional comments ?
Or perhaps I can find somewhere a modified version ?

When you have a line, var = x + +y, the minifier removes the space between the plusses, so you will get x++y which isnt valid javascript.
Can this be fixed?

var = x + +y isn’t valid JavaScript to begin with. Did you mean var foo = x + ++y;?

This is why ++ is considered harmful; there are too many situations in which it results in ambiguity even when a parser is behaving correctly. Please use += 1 instead, or at least add parens to disambiguate the operation: var foo = x + (++y);

Yeah i meant that. Can you explain how this sometime does not work? It’s a basic operation which is possible for years, should be pretty straight forward?

Douglas Crockford explains the reasons behind this and many other JavaScript pitfalls you should avoid on his website, in his book JavaScript: The Good Parts, and in this video.