If you're concerned about the bandwidth used by a complex script, you may want to consider using the
JavaScript Crunchinator at BrainJar.com. This is a tool that removes
extraneous white space, comments, and string breaks from your code, creating something less readable but less bulky.
You can try it on your code using the online demo. (It's also
written in JavaScript, so view the source to see how it works.)
I don't normally recommend using things like this—readable, maintainable code is worth some extra bandwidth—but if
you're serving a complex script on a very busy site, it could make a big difference in bandwidth. That's probably why
Google Suggest uses a similar technique.
Making smaller, crunchier scripts
Reader Comments
(Page 1)2. Er... note to self, read instructions :). It seems A HREF links don't work, so here's the link to mine:
http://www.twinhelix.com/javascript/codetrim/demo/
Hope you guys find it (or any of my other JavaScript projects) useful!
Posted at 5:49AM on Dec 19th 2005 by Angus Turnbull
3. Dean Edwards also released packer 2.0
http://dean.edwards.name/packer/
Posted at 5:49AM on Dec 19th 2005 by John Serris
4. I've had good experience with Dean packer.
Though I've experienced problems with packed scripts in that they can't be checked into my CMS (Clearcase), as it won't accept text files with lines longer than 8000 chars.
Posted at 5:49AM on Dec 19th 2005 by Ken Kolano
5. Virtually all modern servers and clients are able to handle ascii (de)compression via gzip or deflate. As this is done via content negotiation, older clients get plain, uncompressed ascii streams automatically.
C/C++ coded compression engines are faster and more efficient than any interpreted code, thus compression via JS is a nice feat but else a waste of CPU cycles and development work.
If your server deals compressed ascii to the client anyway, compressing the compressed code again via JS is like zipping a file twice, nonsensical.
Posted at 5:49AM on Dec 19th 2005 by Marek Moehling
6. Virtually all modern servers and clients are able to handle ascii (de)compression via gzip or deflate. As this is done via content negotiation, older clients get plain, uncompressed ascii streams automatically.
C/C++ coded compression engines are faster and more efficient than any interpreted code, thus compression via JS is a nice feat but else a waste of CPU cycles and development work.
If your server deals compressed ascii to the client anyway, compressing the compressed code again via JS is like zipping a file twice, nonsensical.
Posted at 5:49AM on Dec 19th 2005 by Marek Moehling
7. Two related bits:
I've long used this tool for bookmarklet dev:
http://subsimple.com/bookmarklets/jsbuilder.htm
And there's a lovely prettifier to get your script readable again after compression:
http://www.prettyprinter.de/
Posted at 5:49AM on Dec 19th 2005 by Jeremy Dunck
1. Hmm, I wrote a very similar script myself for my own projects :).
I just tested BrainJar's and it delivered a similar compression ratio (mine also munches whitespace and un-needed comments/constructs/etc) but mine was several orders of magnitude quicker; BJ's hung Firefox for several minutes when I tested on a larger script. Mine works largely via global regular-expression substitutions and usually takes less than a second to work).
Posted at 5:49AM on Dec 19th 2005 by Angus Turnbull