ShrinkSafe is a JavaScript code obfuscator brought to you by Dojo. It looks like a useful little tool.
Here’s the dictionary definition of obfuscation:
- To darken or render indistinct or dim.
- To make obscure or difficult to understand or make sense of.
- To confuse or bewilder.
That list is missing number four: to reduce file size.
Code obfuscators strip out unnecessary characters like white spaces, tabs and new lines. This results in smaller file sizes, which is always a good thing. It also makes your files indecipherable (as per the dictionary definition).
Now, some people may view this as a good thing - particularly those coming from a background in Flash. Personally, I find it a bit of a shame. The ability to “view source” has driven most of my learning in CSS, (X)HTML and JavaScript. In fact, in a display of unbridled anthropomorphism, I give “view source” a shout-out in the acknowledgements for the DOM Scripting book.
I like the idea of returning something back into the pool of knowledge that lurks behind the “view source” option so I’ve never bothered stripping out unnecessary characters from my scripts. Weighing up the balance between readability and file size, I usually plump for readability every time. Besides, my typical .js file is often smaller in size than a drop-shadow .gif.
Still, if you find yourself working with large, complex files, economies of scale start to come into play and the balance tips towards optimising your download times. In that case, a tool like ShrinkSafe could come in very handy.
Posted by Jeremy on Thursday, October 13th, 2005 at 1:59am
Comments
If your server gzips everything before sending to the client, then the file size benefits gained by stripping unnecessary white space and whatever else obfuscators do, is minimal. For any other reason, the desire to hide the source code is in inverse proportion to the value of that code to anybody else.
# Posted by Lachlan Hunt on Thursday, October 13th, 2005 at 5:14am
Lachlan, one problem about gZipping is that IE won’t cache. So it’s either "quick’er’ downloads all the time" or "one long download - then quick’est’ downloads for the rest"
I prefer caching so I’d go for the crunching. Just be sure to keep a local backup of the original "readable" file.
# Posted by Dustin Diaz on Thursday, October 13th, 2005 at 7:19am
I’m with Jeremy. The web would be nothing more than hyperlinked physics papers and corporate behemoths if it wasn’t for the first browser manufacturers having the "view source" option, as normal mortals wouldn’t have been able to see what’s under the hood.
In a similar spirit of democracy, Jeremy should really get around to publishing his "marquee tag" unobtrusive JavaScript …
Dustin, I didn’t know about the caching problem in IE, but I figure: tough luck. If a user’s broken browser doesn’t cache things properly and makes their browsing slower, especially when using compression that’s actually designed to make things faster f or everybody else, then that’s not my problem.
# Posted by Lachlan Hunt on Friday, October 14th, 2005 at 1:17am
Lachlan, I think there is a way you can do it with modZip on apache, so I refrain part of my statement. It just won’t cache with gZip (which is the php way of compression). Another draw back is that it’s calling an http request for it everytime. I tried gZipping my style sheet last month and my stats sky-rocketed for my style sheet (yuck). I just never got around to setting up mod_zip…
# Posted by Dustin Diaz on Friday, October 14th, 2005 at 5:07pm
So as the author of ShrinkSafe, I’d like to note that the point was NEVER to write an obsfucator. We don’t strip out newlines or allow the mangling of public API signatures for that very reason. Any file you download that’s been run through ShrinkSafe should still be readable should you open it up in Veknman and say "Pretty Print". I’m somewhat militantly anti-obsfucator, but at the same time, we need latency reducing tools that can be baked into a build process. Hence ShrinkSafe.
As for the advantages (or lack thereof) of mod_deflate and the like, all I can say is that as someone who doesn’t control the eventual deployment environment, I need to make sure that latency is as low as possible regardless of the relative Ops clue of a given user.
# Posted by Alex Russell on Saturday, October 15th, 2005 at 8:55pm
Sorry. Comments are closed.