Your Guide to Writing Large-Scale Javascript Applications

What is peculiar in Javascript is that it is designed for many types of applications. Noobs can learn it in minutes. They can just go write little validation code insided web pages. Advanced web applications also rely heavily on Javascript. It is even taken beyond the web paradigm. Now you can find Javascript running on servers, inside desktop applications, and even on hand-held devices.

This explains the ongoing war between Javascript interpreters, V8, SquirrelFish (and SquirrelFish Extreme) and TraceMonkey. Each engine fights to dominate the market. Actually this is so important as web applications are becoming a lot more complex and old-style Javascript engines are dying out of performance. Embedded devices also need performant Javascript engines due to their limited resources.

When your Javascript application grows in size, you will find it very difficult to maintain because the language is designed to be written in a simple way, no enforcements or conventions of any type. Actually, you will most probably end up with a very bad code. To avoid this and to write neat, maintainble and scalable Javascript applications, I have brainstormed with myself and wrote down the following guidelines. Some of them are general and can be applied to any programming language, not necessarily Javascript. I will be constantly adding to these guidelines as I forumalate them.

1. Use classes instead of separate global functions.
   One may simply write an old C-style program around functions. The good, although old, news is that Javascript can be written in an object-oriented (OO) style. Although there are no explicit class definitions or inheritance, you still can work around this and define your own classes with both public and private access to data members and member functions. As implied by the OO design, your application will neatly grow as it goes. I will not discuss how to write classes but you can see the these examples and see these useful links (1 and 2 or google it).
2. Don't pollute the global context, always use namespaces/singletons.
   If you strictly followed the previous point of the OO design, you will end up with a lot of class names. These class names are nothing but global variables, we approach the start point again. You can create namespaces to hold class definitions inside. For example:
   
var MyPackage = {
MyClassA: function() {...},
MyClassB: function() {...}
}

This way, we have just hidden MyClassA and MyClassB inside MyPackage namespace. To instanciate objects we write:

x = new MyPackage.MyClassA().

Note also that similarly we can write a singleton class:

var MySingleton = {
method1: function() {...},
method2: function() {...},
variable1: 10,
variable2: "hello"
}

You access singleton members as:

MySingleton.method1()
MySingleton.variable1

and so on.

3. Make your functions anonymous and give them variable names.
Functions in Javascript may be anonymous as well as named. For example you can define a function like this:

function myfunc() {...}

You can also write:

function() {...}

The latter form can be used as a closure or as an inline function. See this, this and that for more information about closures.
Being an inline function you can set it to a variable:

var myfunc = function() {...}

This form may seem equivalent to the named form example above. However, they are not always equivalent. It is interpreter-specific. In IE JScript (I think it was IE6), named functions are always given their name regardless of their scope. This has the side effect of defining the function name as a global variable name. Take this example for more clarification:

if (a > 1)
function foo() {...}

In bad interpreters (Micro$oft JScript for example) foo is always a global variable of type function. It can be called in all cases not only if a > 1!
Need a dangerous scenario? Take this example:

if (typeof foo == 'undefined')
function foo() {...}

Suppose you need to check whether a function is defined or not, and if not define it your own way. This could happen inside a large application where you test if some sources are included and act accordingly. This will not work as expected due to the missbehavior of such interpreter. I faced this problem when writing some code that checks if prototype was included or not. So I wrote:

if (typeof $ == 'undefined')
function $(element) {return document.getElementById(element)}

The result was my $ always overriding prototype's $!
The solution is easy, just use:

if (typeof $ == 'undefined')
var $ = function (element) {return document.getElementById(element)}

This way, $ will not be defined unless it is already defined before.


4. Keep your files small, don't worry about number of files.
As a general practice, don't place more than 1 class definition in a file. Consider Java public classes where you cannot define more than 1 public class in a file and file name should be the same as that public class. If this has changed in current specification, please tell me as I am not an active Java developer. This will add to modularity and will make your classes more liable to reusability.


5. Never use alerts for debugging.
Debugging Javascript code using alerts always proves to be not practical. It pauses execution until the user dismisses the alert. You cannot just put 10 alerts and have them displayed each run waiting for you to dismiss them! Sometimes it is invalid to log through alerts. Suppose you need to simulate real time performance while you are having multiple threads, for AJAX requests as an example. Alerts will ruin the synchronization of threads because they pause their owning threads. Its worth noting that text inside alerts are limited to the display area.


6. Always use log messages for debugging.
A better solution for debugging, still not the best, is using log messages rather than alerts. Logging debug information has many benifits of not blocking the running thread, playing the 10 messages with no code interruption and simulating the real time performance of threads. If you are inside a web page, you can log to some text area by modifying its value property. In Jiggy, you can use the global function log() to throw away any message to the console. It is important to note that logging is not only for debugging. You have to log your application activity for inspection afterwards. This may help you enhance its performance or monitor user activity.


7. Consider using dynamic log-levels when your logs become bloated.
Following the logging paradigm will render your log stream unreadable. When you add a new log line it will not be noticed among tens and hundreds of other log lines. Thinking of disabling older log lines is not the best solution, you may need to come back and debug something old. By enabling/disabling log lines you will be uncommenting/commenting some code. As a general practice code inside comments is highly discouraged. Actually you will need to debug several aspects continuously, like requests sent/received on network. Thats why log levels are for. However, I don't mean here the basic 4 levels that are widely used: Error, Warning, Info and Debug. These levels are placed according to severity of log. What I mean here is dynamically creating log levels according to different aspects of your application logic. For example, you may have aspects called "Network", "Database", "Rendering", "Flow" and such. Lets call them log aspects as opposed to log levels. When you log any message you define its aspect from these aspects. You may also combine an aspect with one of the 4 basic log levels mentioned above. When you wish to debug warnings from the network aspects you enable Warning level and Network aspect from a central configuration file. Such file may turn on and off all aspects and levels for your application. For example:

var ENABLE_LOGS = true
var DEBUG_ASPECT_NETWORK = true
var DEBUG_ASPECT_DATABASE = false
...
var DEBUG_LEVEL_ERROR = false
var DEBUG_LEVEL_WARN = true
...

and in your log lines:

LOG("message here", DEBUG_ASPECT_NETWORK && DEBUG_LEVEL_WARN)

where LOG is simply defined as:

var LOG = function(message, enabled)
{
if (ENABLE_LOGS && enabled) log(message)
}

You can add debug aspects and levels dynamically as your application grows. You can enable/disable aspects and levels as required without commenting/uncommenting your code.


8. If you are working inside a web browser, consider a Javascript debugger. For Firefox there is Venkman and Firebug. If your log mechanism didn't help you, you may consider a real debugger which steps you into your code and helps you inspecting variables.
   

Thats all for now, stay tuned for a more focused post about writing large-scale Jiggy applications!