Being on both sides of the fence between server side and client side programmers I hear two different calls to duty. On the server side it’s test, test, test. On the client side it’s get it out the door! Client side testing is absolutely no different from server side testing but since web site widgets are here to stay, where is the emphasis on testing.

This is the first part in a series of creating and testing JavaScript functions and libraries for use across all browsers and in conjunction with other libraries a user may include from other vendors. I mean just because you might write a beautiful library and completely test it, doesn’t mean another vendor doesn’t kill yours. Or is that testable in itself?!?

If you develop in .NET, Java, PHP, or any language that resides on the server to deliver the application I’m sure that you have heard the Test Driven Development (TDD) or Behavior Development Development (BDD) for writing your tests first and then code to make it happen and be bug free. Maybe even validate your producing HTML against the various W3C validator. When it comes to the client side programming of JavaScript you just grab a handy library from the most relevant open-source search. Maybe you test the application in your browser of choice or even use such applications as Selenium.

As the buzz word for today is Web 2.0, in that web sites are “interactive”. Yet the emphasis for applications is still on testing server side code to make sure that the server side programming still operates as expected, although continuing to use or creating client side libraries that are not tested and don’t operate as expected in various browsers. In short no matter how awesome your house is if no one can get to it then what’s the point.

Web 2.0 is not built on the fashion of server side programming, it’s built on the premise that a user can have interaction with a website without the traditional delays as refreshing the page. This means that JavaScript and DHTML is to be incorporated correctly for all browser supported. This requires a paradigm shift in thinking that JavaScript and HTML is a small part of the “total programming” that a web application can have.

Let’s explore the server side programming environment for a moment. On the server side you have a controlled environment. As a programmer you know your environment, you know your current version of the language you are programming in, you know when updates/upgrades are going to be performed. These things are no surprise to you and you know what exactly you can do to optimize your code. Fundamentally, server side programming a a clean room environment here you have total control.

On the client side it’s a bit different. You don’t know everything about the visitor you are try to serve. It’s well known that as far as JavaScript and CSS support across the different browsers isn’t always the best since. Even the difference’s from the same host JavaScript object in Safari and Firefox makes client side programming difficult.

Client side programming is not necessarily about knowing code it’s how to code to prevent crashing in the browsers. Your elegantly written JavaScript library that works beautifully in Firefox but fails in Internet Explorer 7 and completely crashes Internet Explorer 6 will cause you to lose a lot of visitors. It’s the same code, different environments. Certainly it’s easy to say “Firefox” is only the supported browser. Seriously?

Client side testing also about downloading as well. Here the price is doubled for bad code. The first price is for the visitor leaving the site because the download time is to long. Unless the website has a flat usage fee arrangement then most come with a transfer overage stipulation.

Where the script src include statement has a huge effect on how long it will take a site to load. Most sites typically include these just before the ending head tag. If the JavaScript file is huge or is loaded slowly the rest of the page load is severely delayed. Hence the long wait time for the visitor. Off-site JavaScript files suffer server outage that can kill the web page completely.

So a JavaScript file has been called for inclusion to a web page. The file being huge makes the visitor leave, the bandwidth has still been used. Evaluating that how can this be made more efficient without changing the code. You can minify this by removing all the white space from the file. The other thing that really does not need to happen is “cache busting”. Ever since a file(JavaScript, Image, object) with a src url of “my_image?324234″? The query on the end (?324234) is keeping the visitor browser from caching the file. So every time they repeat visit they still get a file download.

I’m all for server side testing in whatever language that’s chosen. If you’re a programmer in those languages you certainly know what I mean. I also love client side programming, yet every job or consultation I have been on takes this area as superficial; at least until the application doesn’t work correctly. More times then naught it’s because a “library” was chosen and not tested before integration.

JavaScript and DHTML client side testing is no different from server side testing. In the next part I’ll describe the initial set up of a library so that you have control of it even if the user of your code includes other vendors.

Just last night I discovered a new pattern for writing encapsulated JavaScript patterns. Christian Heilmann @ Wait Till I Come wrote about the module pattern in the article Show Love to the Module Pattern.

The pattern itself is interesting and would like to test it’s performance. Being that you are creating this on a var object means that after definition it’s immediately available and the new operator is not necessary makes this singleton in nature. Just as JSON pattern objects. However I haven’t tried the test code or built an object as of yet, I wonder how the prototype scoping holds up.

In December I wrote a post about how to encapsulate JavaScript Objects. I knew at the time that the class would be a heavy hitter in terms of performance but never really tested it as such. Being able to encapsulate was such a powerful concept at the time. A recent question about how to write JavaScript Objects made me sit down and run a performance test.

After running the tests what I found not only made me go wooooo but also confirmed some suspicions I had. The question being which style of writing a JavaScript object was the fastest for set-up and creation. Now that’s a tough question to answer, I mean do you use a #1 phillips head screw driver to remove a #3 phillips head screw? I boils down to using the right style for the job at hand.

OK back to the task at hand. I set up a page that created an object that consisted of: loose functions, JSON object, closure object, prototype object, and the encapsulated object. During the test the object will be created and run over an integration of 20000 times. Let me say to compare apples to apples I need to run the loose functions as new during the loop which is not normally done but tests their creation in the scheme of things.

For the results:

Object Test in: FireFox
Loose Functions: 167ms
Prototype Pattern: 109ms
JSON Pattern: 174ms
Closure Pattern: 214ms
Encapsulated Pattern: 596ms

Object Test in: Safari
Loose Functions: 310ms
Prototype Pattern: 272ms
JSON Pattern: 221ms
Closure Pattern: 381ms
Encapsulated Pattern: 417ms

Object Test in: IE7
Loose Functions: 691ms
Prototype Pattern: 198ms
JSON Pattern: 371ms
Closure Pattern: 355ms
Encapsulated Pattern: 596ms

The differences in the above browsers I suspect is primarily due to how they treat the object set-up and the ECMA standards. Definitely building object using the prototype method gains the best performance. Which is understandable and I’ll describe.

Loose Functions:

These are the bread and butter of JavaScript. We learned JavaScript by using these and they are still important. A JavaScript function attached to the global scope and can be used throughout the DOM is a powerful thing. However when a loose function relies on another loose function pandemonium starts to ensure. Loose function grow, duplication starts to happen and explosive global variables ruins the day. So the advantages of loose functions is their one hit wonders. The disadvantages is that when one function relies on another then it’s time to start thinking object relations.

JSON Objects:

Building an object using JSON notation is relatively easy once you get your head around them:

var myObject = {var1 : “”, var2 : “”; someFunction : function(arg) { this.var1 = arg } }

JSON objects are singleton in nature. Once you declare myObject as in above you can not re-declare it without removing the previous object notation. If done on the global scope these objects can be used throughout the DOM as needed. I see the dis-advantages of these objects as not only performance hitters (compared to prototyped) but large classes, especially those with multiple inner function levels as unwieldy. The advantages of these are for small objects that have only a few inner methods.

Closure Pattern:

Closure objects contain inner functions that are created during the instantiation of the object. This is the reason for the longer creation period. A closure object looks like this:

function outerFunction() {
 this.var = “”;
    this.innerFunction();
    function innerFunction() {
        this.var = “Hi”;
    }
}

Closure patterns, as I found, are great for working with large objects that contain a lot of inner or even nested inner function. The dis-advantages of these object is that the instance variables are also publicly accessible. So a lazy programmer can modify a variable directly rather than using the appropriate accessors/mutators or public functions.

Prototype Pattern:

Prototype functions have proved themselves to be the overall performance winners during usage. That is because at declaration:

function myBase() {
    this.variable1 = “”
}
myBase.prototype.setVar = function(x) {
    this.variable1 = x;
}

the setVar object is created independently of the myBase object. Yet it is associated via the myBase prototype. So when another myBase object is instantiated then another setVar object is not created but also associated with the new myBase object. That’s were the speed comes in, you are only creating one object no matter how large your object with prototype scoping is. The dis-advantage to this is that when you need to create dynamic DHTML objects with DOM events it can really be tricky making sure the correct element triggers the event.

Take for instance:

function myObject() {
    this.element = document.getElementById(’someDiv’);
    this.setEvent(this.element);
    function setEvent(obj) {
        obj.onmouseover = function(e) { this.sayHi(); };
    }
    function sayHi() {
        alert(”hi”);
    }
}

This will fail miserably because the reference to “this” in the event function actually references the element “someDiv” which does not have the method sayHi. When doing this type of programming the only recourse I have found is to include the name of the object which means hard coding a page.

var someObject = new myObject(”name”);
function myObject(name) {
    this.name = name;
    this.element = document.getElementById(’someDiv’);
    this.setEvent(this.element);
    function setEvent() {
        var name = this.name;
        obj.onmouseover = function(e) { eval(name).sayHi(); }
    }
    function sayHi() {
        alert(”Hi”);
    }
}

It’s in those associations where the “this” reference can really be a pain and cause the script to crash. Undeniably it’s faster through object re-use.

Encapsulated Patterns:

I am perfectly willing to say that this pattern is slow and is really a beast of burden compared to the others. This pattern creates internal objects just as the closure pattern, and additional objects (as pointers) to the public internal object and attributes. That is why it’s slower.

function myObject() {
    var var1 = “Hi”;    //Private to this instance
    var2 = “There”;  //Shared between instances
    this.NAME = function() { return “myObject” } //Read only attribute

    this.Method1 = myMethod1;   //Public Object to point to internal Object myMethod1
    function myMethod1() {
        alert(”Hi”);
    }
}

However using this method means you can be rest assured that internal attributes and methods are hidden (by function scope) so external scripts don’t modify or access them. The number of bug reports fell drastically from the companies I contracted for because their full time programmers were correctly using the object and could not be lazy.

So it’s not the saying “How to do it” that works it’s “What’s the right way to do it” that works. Singular and small but highly re-used objects may fall into the part of JSON patterns, Multiple instances of same objects on a high traffic site may fall into prototype patterns, intra-net applications may make better use of the encapsulation pattern or in environments where multiple skill levels of programmer’s are involved.