If you didn’t know it before, Port80 Software does dabble in client-side tools. One such little project of ours called w3compiler brings up lots of questions about JavaScript compression and obfuscation.

The basic premise of w3compiler is to prepare HTML, JavaScript, CSS and other source files for optimal Web site/application delivery. In order to optimize core Web site files for fast download, a variety of techniques can be employed, depending on the file type. For example, in (X)HTML files, you can remove most white space, comments, and unused tags such as extratags. CSS is fairly similar. JavaScript, however, presents a totally different set of possibilities and challenges. Of course, you can remove white space and some dead code statements here like you can in HTML and CSS. You can also shorthand statements (for example, x=x+1 would become x++, with a whopping 2 byte savings – hey, every 1 and 0 counts on the wire, right?). It may not seem like much, but it adds up, particularly with more complex AJAX-style applications.

A challenge we sometimes face here at Port80 is explaining exactly what we are doing with JavaScript in the w3compiler. Well, first off, w3compiler does safely remove white space, which indeed can make code look a little harder to decipher and make it much smaller. Yet, the software does a number of other things, namely variable renaming and object remapping.

In the case of variable renaming, you might have a variable like usersFirstName, and the tool might remap that variable everywhere across the entire Web site/app to uF or something similar. Variables include function names and such, so there could be quite a bit to rename across an entire site…

Object remapping is a bit different. For example, you might have repetition of:

The remapping of objects is done intelligently so as to not to increase code size or break the site — so the w3compiler has to understand usage of the code, much like a Web browser would parse the file. One downside: you do pay a slight browser memory penalty and potentially performance penalty at run time as the object is copied into the local browser’s memory space — but it is negligible and offset in most cases by the reduction in code size from optimization.

Delving deeper into the balance between JS speed optimization and obfuscation, let’s review a more complex example. Given JavaScript like:

Now, you might look at this code and exclaim, “Great, now it’s real difficult for people to steal my hard work in JavaScript!” Well, that’s somewhat true. The reality is that if you really wanted to make things harder, you might have variables not l and l1, but l1l1ll0l0l and l11l1ll0101 — which are, as they say, a bit difficult to just eyeball and then unroll the code. You might go further and run some simple obfuscation against the code like escaping the code:

Combo the two or do some other types of encodings, and you make it harder and harder to figure out what is going on with your JavaScript. This is the idea of obfuscation — making it so much of a pain for the potential thief so they move on to easier targets. Of course, with those digital assets that people want (like free video games, serial numbers, etc.), programmers can really add amazing obfuscation and copy protection — and folks will still spend quite a lot of time cracking away at this stuff. This is not to say that you shouldn’t attempt to obfuscate with a tool like w3compiler, but let’s be realistic about the protection JavaScript obfuscation provides…

In the case of w3compiling, we balance the need for speed with the need for protection — so far, we favor speed.

– J.A. @ Port80

P.S. The new version of w3compiler 2.0 is in internal BETA. If you want to be on the public beta team, just send an e-mail to beta@port80software.com.