Does encapsulating Javascript code in objects affect performance?

Question

I am wondering if it is more or less efficient to encapsulate the main body of your JavaScript code in an object? This way the entire scope of your program would be separated from other scopes like window.

For example, if I had the following code in a JavaScript file:

/* My main code body. */
var somevar1=undefined;
var somevar2=undefined;
var somevarN=undefined;

function somefunction(){};

function initialize(){/* Initializes the program. */};
/* End main code body. */

I could instead encapsulate the main code body in an object:

/* Encapsulating object. */
var application={};
application.somevar1=undefined;
application.somevar2=undefined;
application.somevarN=undefined;

application.somefunction=function(){};

application.initialize=function(){/* Initializes the program. */};

My logic is that since JavaScript searches through all variables in a scope until the right one is found, keeping application specific functions and variables in their own scope would increase efficiency, especially if there were a lot of functions and variables.

My only concern is that this is bad practice or that maybe this would increase the lookup time of variables and functions inside the new "application" scope. If this is bad practice or completely useless, please let me know! Thank you!

Answer 1

I’ve no idea what the performance implications are (I suspect they’re negligible either way, but if you’re really concerned, test it), but it’s very common practice in JavaScript to keep chunks of code in their own scope, rather than having everything in the global scope.

The main benefit is reducing the risk of accidentally overwriting variables in the global scope, and making naming easier (i.e. you have window.application.initialize instead of e.g. window.initialize_application).

Instead of your implementation above, you can use self-calling functions to create an area of scope just for one bit of code. This is known as the module pattern.

This has the added advantage of allowing you to create “private” variables that are only accessible within the module, and so aren’t accessible from other code running in the same global object:

/* Encapsulating object. */
var application=( function () {
    var someprivatevar = null// This can't be accessed by code running outside of this function
      , someprivatefunction = function () { someprivatevar = someprivatevar || new Date(); };

    return {
        somevar1: undefined
      , somevar2: undefined
      , somevarN: undefined
      , somefunction: function(){}
      , getInitialized: function () { return someprivatevar; }
      , initialize: function (){/* Initializes the program. */ someprivatefunction(); }
    };

})();

application.initialize();
application.getInitialized();// Will always tell you when application was initialized

Answer 2

I realize you asked a yes or no question. However, my answer is don't worry about it, and to back that up, I want to post a quote from Eloquent Javascript, by Marijn Haverbeke.

The dilemma of speed versus elegance is an interesting one. You can see it as a kind of continuum between human-friendliness and machine-friendliness. Almost any program can be made faster by making it bigger and more convoluted. The programmer must decide on an appropriate balance.... The basic rule, which has been repeated by many programmers and with which I wholeheartedly agree, is to not worry about efficiency until you know for sure that the program is too slow. If it is, find out which parts are taking up the most time, and start exchanging elegance for efficiency in those parts.