There are two versions of the compressor
Some thought and hints:
The first one is useful in most cases (reducing the overall size of symbols and strings by using a lookup. This is a simple and trivial rearrangement of the data structure describing your Hype file. Putting such a symbol compressed file in a Zip-Container results in a smaller file than the unprocessed file (overall project ZIP size and also
mod_deflate benefit). So, this kind of optimization makes nearly always sense but relies on regular symbols or similar text strings being used across scences to show results.
The second compressor currently called "ZIP-EDITION" needs some more evaluating and this is what this sections is mainly about: The ZIP-EDITION compressor can now also handle any JS library (in those case it doesn't add the decompressor (4,4kb) and only returns the JS in a GZIP compressed and Base64 encoded manner. The logic thus far is that if you need smaller files the ZIP-EDITION compressor can produce them through additional compression. The result is a binary file that can't be embedded into an ASCII file (as half of that ASCII syntax is reserved). Hence, we need to encode the full byte array into an ASCII compatible realm. The most common used and MIME compatible way of doing this is using Base64. This adds 33% overhead as we need more Bytes to describe the binary data. The compressor also respects the RFC2045 standard that demands splitting lines into 500 char max chunks. This adds 3% of newline and quote data. Then we need the decompressor at around 4,4kb. All this adds up but in most cases we are still smaller than the original file at face value. Meaning if you need a smaller file this is for you but zipping this file produces a bigger file then zipping the original. Hence, if you need smaller individual files to pass some test or client demand or your goal is reduced storage or some added obfuscation is needed this compression is for you. On the other hand ... if overall ZIP size of your entire project is the optimization goal refrain from using ASCII file base compression.
If your server uses
mod_deflate (as mentioned by @jonathan) I would also only use the symbol compression version as the on-the-fly zipping applied to the additional Base64 overhead most probably doesn't yield better results. The symbol compression is respected by
mod_deflate, so you gain benefits. Another approach currently not implemented is using a more efficient Binary to ASCII encoding. There is ASCII85 (only adds 25% overhead) and yEnc (adds only 7-10% overhead). Either of these isn't MIME certified, but I will try to add them in the future anyway as an option if viable (they are used in USENET protocols and elsewhere). Hence, they are broadly used and would bring the compressor much closer to native zip values but because of the missing certification I mentioned this under the red dot.
Eventually, I will consolidate the compressor versions and add the different optimizations as toggle switches (if time allows it).