JavaScript Applications, pt 2

Updated: Continued in pt 3, Optimization and Compilers

As my last post on this topic was remarkably content-free (by that I mean technically :)) for an article of its size, I thought I'd make this one a little denser. There's nothing I'll cover that's not in most every JavaScript tutorial of any sanity or advancement, but hopefully I can help make the "why?" a little clearer when all is said and done.

First, by way of some definitions, JavaScript is a strong, dynamically typed language. By that I mean that variables can be assigned, well, anything, and each "thing", during run-time, knows explicitly what type it is. We would say a compiled language like C is a weak, statically typed language because types are enforced at compile-time, and "things" don't implicitly know what type they are (e.g. you can forcibly change and/or override "types" in C).

JavaScript, like most dynamically typed languages, is generally an interpreted language. Resolution from instruction to machine code happens during program execution, usually through explicit (i.e. software decoded) instruction dispatching. I say "generally" because compilers like Flash (yes, the Flash authoring tool is a JavaScript compiler) and JScript.NET show that it doesn't HAVE to be an interpreted language. Still, there are limits to what a compiler can do because the dynamism implies that much of the object information is only available at run-time.

From a performance perspective, JavaScript (as in the browser) is 500 to 1000 times slower than compiled C code. To put that in context, imagine your 5 GHz Pentium IV ran at the same speed as your 4.77mhz original IBM PC. Yes, the one with 4 colors, and a 40x25 character display (ok, 80x25 in "high-res" mode). In practice, the delta is somewhat offset by the fact that the rich display engine, parser, and ancillary high-level functions connected to the interpreter run muuuuuch faster than anything your 4.77mhz 8086 PC could do.

The Microsoft JScript interpreter in IE and the Spider Monkey interpreter in Firefox run at about the same speed, roughly. Each are faster at some basic computing tasks, though I'd give the edge to IE hands down, performance-wise. Conversely, DOM access in Firefox seems faster, while layout and display in IE is usually better. So it all tends to wash out in the end - performance-wise. Incidentally, in some special cases, JScript.NET and the like (as in, like Flash 8.5) can do significantly better, but those paths have their own VERY hidden traps (which I'll explain some examples of in detail in a future post).

JavaScript has some nice attributes:
- Its truly dynamic: no compiler, easy to learn
- Error resistant: it generally just keeps working
- Ubiquitous runtime: the browser, et al
- Flexibility: simple rules, complex patterns, e.g. functions are objects
- Standardization: ECMA 262 - Javascript is often called "ECMAScript"

And on the downside:
- Its truly dynamic: no compiler - means no compile time errors
- Error resistant: it generally keeps working - which makes design holes hard to find
- Ubiquitous runtime: except its buggy as crap-all
- Flexibility: simple rules, complex patterns, e.g. functions are objects - what does that actually mean?
- Opaque costs: performance and memory (hah! - you thought I was going to say "Standardization" :P)

There's a lot of power afforded in the dynamism of the language. It allows for very flexible design patterns (remember we discussed that notion?), as with function callbacks for example, which are common in UI development.

In JavaScript, you can do things like:
(notice the DYNAMIC internal/nested function definitions)

function myFunc(a)
{
if (a==1) {
function internalFunc(b) {return a+b;}
}
else {
function internalFunc(b) {return a*b;}
}
return internalFunc(a+a);
}

v1 = myFunc(1); //v1 = 3
v2 = myFunc(2); //v2 = 8

Let's parse this in a bit more detail, because it captures much of the problem and opportunity in JavaScript.

First, you should understand that declaring a function is no different than declaring a variable, and has all of the associated scoping rules in effect. What this means is that "function myFunc(a) {...}" is really the same as "myFunc = function(a){...}" - its JUST a declaration of a function object and assignment to a global variable, in this case "myFunc".

A lot of the confusion arises from the abstraction of dynamic execution on top of (essentially) C-like syntax. Although functions in JS look like blocks of executable code (in the compiled-once, block-of-memory sense), they're really just dynamic objects. And when you declare a nested function, as we did above, the assignment of that function to the locally scoped variable "internalFunc" happens during each and every execution of the function. So why is this a problem?

Two factors make this an issue.

One, JavaScript is a dynamic language, as we said. Even properties on objects are strongly, dynamically bound. Translation? Each instance of each variable on each object creates a property pair hashtable entry on that object. The memory usage can grow quickly. It can easily be more than 64 bytes for property assignments, PER property, PER object instance, NOT counting the length of the property string itself.

Two, as noted in this basic tutorial on object-oriented JavaScript programming, here's how you might make a simple, custom JS object:

function Circle(radius) {
function getArea() { return (radius*radius*3.14); }
function getCircumference() { return (radius*2*3.14); }
this.radius = radius;
this.getArea = getArea;
this.getCircumference = getCircumference;
}
var c = new Circle(5);

See the problem?
This code will essentially create locally scoped variables in the stack frame (the nested functions) and assign them to dynamic properties each time this "Circle" object is created. That is, although the inner functions are not PARSED each time you create a "Circle", new instances of the inner functions are assigned to new dynamic properties on the new object instance EACH time you construct the object, wasting both time and space.

JS has a built-in solution to this, called the "prototype" property, and I'll discuss how that works - and how its different and distinct from class derivation. Part of understanding the distinction, in the trivial case, comes from the (obvious) understanding of basic JS optimization, that:

for (i=0; i<100; i++) a.b.c.d(v);

...is a lot slower, at least in JavaScript, than:

var f=a.b.c.d;
for (i=0; i<100; i++) f(v);

...because after all, JS is a dynamic language. I'll provide some specific JavaScript performance tips and JavaScript benchmarks to make the points clearly.

More soon(-ish).