Write Bulletproof JavaScript

While display issues have long been the bane of a web developer’s existence, current web development projects tend to have much more client side interactivity, focusing ever more attention on the reliability and resilience of the JavaScript you write to deliver the complete interactive experience. Many things can cause unexpected errors in your carefully crafted code.

However, there are a few things that you can do to make sure that your site degrades gracefully and still provides a basic level of functionality when something in the browser goes wrong. The following snippet of code illustrates a few best-practices for defining your JavaScript namespaced modules.

if(typeof namespace !== "undefined") {
    var namespace = {};
}

namespace.module = (function($) {
    var _privateInit = function() {},
    _privateAction = function() {},
    _hiddenAction = function() {};
    
    return {
        init: _privateInit,
        action: _privateAction
    };
})(jQuery);

Let’s begin with the first if statement. It checks to make sure that the object we are using for our namespacing of all of our modules exists. If it does not exist, it creates it in the global scope here. This particular piece of code can be reused in each and every module that you create that is part of the same namespace without having to worry about overwriting the namespace object.

I am utilizing the Revealing Module pattern here to help isolate any errors or exceptions that may inadvertantly be thrown by my code. If an exception were to be thrown in the global scope, nothing in the global scope that was evaluated after the exception would be evaluated, leaving much of your JavaScript unable to be executed by the browser. Using modules that are narrowly focused on a single piece of functionality help to reduce the damage than an unexpected JavaScript error can cause.

Whenever you get around to actually using your module, namespace.module, there are a couple of precautions you should take as well. The first is that you should always call your module as seen in the snippet below.


if(typeof namespace !== "undefined" && typeof namespace.module !== "undefined" && typeof namespace.module.init === "function) {
    namespace.module.init();
}

The if statement above may be a bit overly protective of the code, making sure that all of the parents of the init() function exist and that namespace.module.init is actually a function and not a string or another random object before trying to execute it as a function. This also serves the situation where your namespace.module is provided in a separate JavaScript file from where it is being called, making us unsure of whether that file was successfully loaded or not. When using the namespacce.module in our separate script file, we want to make sure it exists before we attempt to use it so that we prevent any errors from popping up if something happens on the network and the file does not load in time.

If you truly want to write bulletproof JavaScript, you should be checking each function call to internal functions to ensure they exist and if they are in namespaces that the namespaces and modules exist before they are refrenced. Not all JavaScript applications are that sensitive to not ever having an unhandled error, but if yours is, you should do all you can to protect it.

Related Posts

Jul 10, 2014
One minute

Ignore Whitespace Not Available in BitBucket Pull Requests

When looking for an online location to use as the host for source code, many people by default look at GitHub, as it seems to be the most well-known option out there, and is free for open source projects. However, if you would like your source code to be kept private, or would rather use Mercurial instead of Git, GitHub may not be the place for you. Instead, I would suggest BitBucket as your source code repository provider.

Jan 7, 2015
2 minutes

JavaScript Can Have An Interesting Interpretation of Order

There is an interesting little quirk with the way in which JavaScript decides which function it should execute next. You see, while the JavaScript engine has a single thread of execution, it creates the illusion of multiple simultaneous processes running at once by utilizing a queue of functions to execute. This means that every time you make a call to a function in your JavaScript, there is no absolute guarantee that it will be the next piece of code run, as there may have been other events triggered that beat your custom function onto the execution queue.

Apr 1, 2014
One minute

Hover Effects in JavaScript?

One of the things that can be annoying when looking at someone else’s code is when a more complex technology is used to solve a problem that can be handled more simply with another method.

An example of this is when you utilize JavaScript to implement a hover effect on some elements. I know of one scenario when you would need JavaScript to trigger a hover effect, and that would be when you want to trigger the hover effect with a touch event. However, in this case, the elements that would be affected by this hover effect are hidden on any mobile device, so the touch events would be unneeded for this hover effect.