> Try it here: Obfuscate and minify your JavaScript code

Minifying

There are other minifiers out there;

[ Link to project removed due to incredibly rude email from its author ]

The parser framework behind my attempt allows a great deal more power at the expense of being a much heftier package. The source code is about 700k, so this is anything but light-weight. The extra power means that, unlike many minifiers, line breaks are not required at all. Any JavaScript program can be stripped down to one, very long line of code. The reason for this is that it performs automatic semicolon insertion. It can do this because rather than just performing a lexical scan of the source, it compiles the full syntax of the program into a parse tree. Of course, a program with a syntax error will not be minified, but then why would you want it to?

Obfuscation

Another advantage of the syntactical parsing is that we stand a better chance of safely altering identifier names. This still has serious limitations though, because the code is still not actually being executed there are many situations that could result in disaster. The current version obfuscates all explicitly named, top-level entities, such as function names, function arguments, labels, and variable declarations. Member expressions are particularly problematic, and so I have not attempted to obfuscate these. I may at some point in future work on improving this, but as this is only a side project, I am not going to hold my breath.

You can always take additional steps in your original code to better preprare for effective obfuscation. Consider this;

var myDocument = document;
var myElement = myDocument.getElementById('myId');

Try it and see

Code highlighting does not require the full syntactical parser, it just uses the tokenizer and does not break when a bad character is found.

What’s in?

When I say full Unicode support, what I mean is that Unicode characters inside string literals and comments were always implicitly supported, but now it can cope with Unicode characters in identifiers too, (as per the ECMAScript standard). Support also includes the use of Unicode escape sequences, although for the sake of speed, the validity of these is not checked. Checking could be done at a later stage when the parse tree is employed to do something useful. The full range of whitespace and line-terminating characters have also been added, although not tested.

Unicode support makes the tokenizing process slower. Because of this it may be switched off if it is not needed. Most programmers with English as their first language are unlikely to use Unicode characters in ‘hand-written’ identifiers, and I have to wonder if anyone has ever done so with an escape sequence.

There are many things that you can write in JavaScript that are perfectly valid syntax, but that you probably never will write. Here are a few that raised an eyebrow or two.

Comma Operator

What would you expect to see if you ran this code in your browser?

var test = [ 'a', 'b', 'c' ];
alert( test[ 0, 1, 2 ] );

You might expect it to be a syntax error, but in fact test[0,1,2] evaluates in this example to "c". The expressions ( 0, 1, and 2 ) are all evaluated, but only the final one can return the single value of the expression.

Similarly pointless constructs:

if( alert("Hello"), alert("World"), false ){
    alert("You will never see this");
}
var a = ( 1, 2, 3 ); // a will be set to 3

The “/” character

The syntax does not discriminate between operand types. For example, you can attempt to divide any expression by any other expression, even if it makes no sense to do so; such as:

['a'] / 2

This will evaluate to NaN, because the array’s value can never be a number, but it is perfectly valid syntax. The real point I’m getting to is that the following is an exception and will raise syntax error:

{ a:1 } / 2;

Why? Because the lexical analyser will expect "/" to be the start of a Regular Expression Literal, which it isn’t. It gets it ‘wrong’ in this case, because the "}" a is tricky so-and-so; it could either be the end of an expression, or the termination of a block statement. The lexical analyser is not a full syntax parser; it knows nothing of the full grammar of the language, and so it makes a choice based on some fairly weak rules.

The following IS valid, but it is not a division operation, it is just a pointless mess:

{ a:1 } / 2 /i;

undefined vs null

undefined is not a literal, or even a reserved word, whereas null is. undefined is a special built-in object, so if you were stupid enough, you could do this:

undefined = true;

This is allowed by the same token that allows you to foolishly do this:

Array = null;
var a = new Array();
// TypeError: Array is not a constructor

Section 7.9 of the ECMAScript language specification details the circumstances under which you are permitted to omit a semicolon in a statement which otherwise requires it. In short, there are situations where this lazy practice is not the end of the world; it is fairly clear what the programmer is trying to do, so it lets you off.

I’ve managed to implement most of these conditions, but not all. I still have some work to do on the more peculiar conditions, but the ones that are relevant to most common practice should be covered. Give it a bash, and let me know if you can break it!

If you don’t know what I’m talking about, consider this:

a = b
c = d

Most JavaScript programmers would be disciplined enough write:

a = b;
c = d;

However, there are some conditions that probably catch us all out.
What is the difference between this:

function xfunc(){
}

and this?:

var xfunc = function(){
}

The former is a Function Declaration, and does not require termination, but the latter is a Function Expression, which in this case forms an Expression Statement and so it requires a semicolon to terminate it. A very common ‘mistake’, but solved quite comfortably by the rules of Automatic Semicolon Insertion, which transform it into:

var xfunc = function(){
};

There are plenty more cases I could discuss, but if you’re really interested, I suggest reading the ECMA-262 specification yourself.

This article is rather old now – the jParser code has been released
–

Despite the glorious sunshine this week, my week off, I managed to put some time into my pet project of developing a full JavaScript parser written in 100% native PHP. Actually, I’ve been developing a generic parser suite for some time, and using it to build a full JavaScript parser was my ultimate goal to be satisfied that it all works and is powerful enough to be useful. I’ve written a bunch of blogs about developing a parser generator in PHP, (click “parsing” to do a tag search).

Before I start wittering on,
Click here to play with the online example of JParser

Here are the main difficulties I encountered while building the JavaScript parser:

1. Performance
Generating the parse table was taking about 30 minutes and using several hundred megabytes of memory. Going back to the drawing board with certain parts of the parse table generator, I’ve managed to get this down to about 7 minutes on my humble Mac Mini.

2. Special rules
The ECMAScript standard states certain special cases in the grammar rules. One of particular note (clause 12.4) says that an ExpressionStatement may not begin with a "{" or a "function". This special rule avoids ambiguity and therefore avoids parse table conflicts, but the rule is effectively outside of the grammar. I’ve finally found the right part of the parser architecture to implement such rules

3. Automatic semicolon insertion
As you probably know just from writing JavaScript, the ECMAScript standard permits the lazy omission of semicolons at the end of some statements, as long as you terminate with a line break instead. This is actually more complex than it sounds, but more to the point, it is another special rule that is not directly a part of the grammar and is handled at parse time.
[UPDATE: Automatic semicolon insertion now implemented, See! ]