I follow the methodology outlined on the Enterprise jQuery site:

Their example demonstrates how private and public properties and functions can be declared within a self-executing anonymous function.

(function( skillet, $, undefined ) {
    //Private Property
    var isHot = true;

    //Public Property
    skillet.ingredient = "Bacon Strips";

    //Public Method
    skillet.fry = function() {
        var oliveOil;

        addItem( "\t\n Butter \n\t" );
        addItem( oliveOil );
        console.log( "Frying " + skillet.ingredient );
    };

    //Private Method
    function addItem( item ) {
        if ( item !== undefined ) {
            console.log( "Adding " + $.trim(item) );
        }
    }
}( window.skillet = window.skillet || {}, jQuery ));

To access the public members, you simply use skillet.fry() or skillet.ingredients.

An interesting feature is that you can extend the namespace using the same syntax.

//Adding new Functionality to the skillet
(function( skillet, $, undefined ) {
    //Private Property
    var amountOfGrease = "1 Cup";

    //Public Method
    skillet.toString = function() {
        console.log( skillet.quantity + " " +
                     skillet.ingredient + " & " +
                     amountOfGrease + " of Grease" );
        console.log( isHot ? "Hot" : "Cold" );
    };
}( window.skillet = window.skillet || {}, jQuery ));

The third undefined argument

The third argument, undefined, defines the variable with the value undefined. In older browsers or JavaScript versions, the global-scope variable undefined was mutable, allowing anyone to change its value. By not assigning a value when creating the namespace, the third argument ensures that the variable undefined defaults to its standard value within the function's scope.

Here's another approach that I find slightly less restrictive than using the object literal form:

var ns = new function() {

    var internalFunction = function() {

    };

    this.publicFunction = function() {

    };
};

This method is similar to the module pattern, allowing you to expose all functions as public without the strict structure of an object literal, whether you prefer it or not.

Is there a more efficient way to accomplish this task?

A possible solution would be:

let customNamespace = customNamespace || {};

This can be followed by:

let customNamespace = customNamespace || {};
customNamespace.Widget = {display:'Hello World'};
customNamespace.Function = function(input) 
{
    alert(input);
};
with(customNamespace)
{
   Function(Widget.display);
}

When constructing it, I typically create a closure:

var MYNS = MYNS || {};

MYNS.subns = (function() {

    function privateMethod() {
        // Perform confidential operations or construct internal components.
        return "Message";
    }

    return {
        someProperty: 'prop value',
        publicMethod: function() {
            return privateMethod() + " stuff";
        }
    };
})();

As time has passed, my approach has evolved, and I now prefer structuring the closure in this manner:

var MYNS = MYNS || {};

MYNS.subns = (function() {
    var internalState = "Message";

    var privateMethod = function() {
        // Perform confidential operations or construct internal components.
        return internalState;
    };
    var publicMethod = function() {
        return privateMethod() + " stuff";
    };

    return {
        someProperty: 'prop value',
        publicMethod: publicMethod
    };
})();

This method makes the public API and implementation clearer for me. Consider the return statement as a public interface to the underlying functionality.

In order to ensure that multiple JavaScript files can coexist in an application, it is important for each file to be able to access or create the namespace object without interfering with other files' functionality...

For example, one file may want to utilize the namespace namespace.namespace1:

namespace = window.namespace || {};
namespace.namespace1 = namespace.namespace1 || {};

namespace.namespace1.doSomeThing = function(){}

Meanwhile, another file may need to use the namespace namespace.namespace2:

namespace = window.namespace || {};
namespace.namespace2 = namespace.namespace2 || {};

namespace.namespace2.doSomeThing = function(){}

These individual files can work independently or together without causing conflicts.

In his book titled JavaScript Patterns, Stoyan Stefanov demonstrates various techniques including creating auto-generated API documentation comments and adding methods to custom object prototypes.

/**
* Sample JavaScript application
*
* @module sampleApp
*/

/** @namespace Namespace for SAMPLEAPP classes and functions. */
var SAMPLEAPP = SAMPLEAPP || {};

/**
* A utility for mathematical operations
* @namespace SAMPLEAPP
* @class math_utility
*/
SAMPLEAPP.math_utility = {

    /**
    * Adds two numbers
    *
    * @method add
    * @param {Number} a First number
    * @param {Number} b Second number
    * @return {Number} Sum of the two inputs
    */
    add: function (a, b) {
        return a + b;
    },

    /**
    * Multiplies two numbers
    *
    * @method multiply
    * @param {Number} a First number
    * @param {Number} b Second number
    * @return {Number} Product of the two inputs
    */
    multiply: function (a, b) {
        return a * b;
    }
};

/**
* Creates instances of Person objects
* @class Person
* @constructor
* @namespace SAMPLEAPP
* @param {String} firstName First name
* @param {String} lastName Last name
*/
SAMPLEAPP.Person = function (firstName, lastName) {

    /**
    * The first name of the person
    * @property firstName
    * @type String
    */
    this.firstName = firstName;

    /**
    * The last name of the person
    * @property lastName
    * @type String
    */
    this.lastName = lastName;
};

/**
* Get the full name of a Person
*
* @method getFullName
* @return {String} First name concatenated with last name
*/
SAMPLEAPP.Person.prototype.getFullName = function () {
    return this.firstName + ' ' + this.lastName;
};

This is the method I typically employ:

var customNamespace = {}
customNamespace._initialize = function()
{
    var staticData = "This data is accessible to all functions within this namespace"

    function MyCustomClass()
    {
       // Different classes can be defined here
       this.publicMethod = function()
       {
          //Perform actions
       }
    }

    // Another option is to use a prototype.
    MyCustomClass.prototype.anotherPublicMethod = function()
    {
        //Perform actions
    }

    function privateActions()
    {
    }

    function publicActions()
    {
       // Code that may utilize other public and private functions
    }

    // List of items to expose publicly
    this.publicActions = publicActions
    this.MyCustomClass = MyCustomClass
}
customNamespace._initialize()

// The following code snippet could potentially reside in another file
customNamespace.subSection = {}
customNamespace.subSection._initialize = function()
{
   // Construct sub-section namespace
}
customNamespace.subSection._initialize()

External scripts can interact as shown below:

var myInstance = new customNamespace.MyCustomClass();
var anotherInstance = new customNamespace.subSection.SomeOtherClass();
customNamespace.subSection.publicOtherActions(someInput);

After user106826 shared a link to Namespace.js, I discovered that the project has since relocated to GitHub. The new repository can be found at smith/namespacedotjs.

I've incorporated this handy JavaScript tool into my current project and it's proven to be both lightweight and adaptable for managing namespacing as well as loading modules/classes. While it's been quite useful, I do wish there was an option to import a package into a specific namespace of my choosing, rather than just the global namespace... but that's a minor concern.

With Namespace.js, you can first declare the namespace and then define objects/modules within it:

Namespace('my.awesome.package');
my.awesome.package.WildClass = {};

Alternatively, you have the option to declare the namespace along with its contents in one go:

Namespace('my.awesome.package', {
    SuperDuperClass: {
        saveTheDay: function() {
            alert('You are welcome.');
        }
    }
});

For additional examples on how to use Namespace.js, take a look at the example.js file located in the source.

Example:

let app = {};
app.utilityModule = (function(){

    let self = {};
    self.initialized = false;

    self.init = function(){
        setTimeout(self.onTimeout, 1000)
    };

    self.onTimeout = function(){
        alert('onTimeout')
        self.initialized = true;
    };

    self.init(); /* Automatically initializes */
    /* You can also trigger initialization by calling 'app.utilityModule.init();' from outside the module. */
    return self;
})()

If desired, you can create a local variable named same, similar to how self is used, and assign local.onTimeout for private functionality.

The Module design pattern was initially created to offer a combination of private and public encapsulation for classes in traditional software development.

When utilizing the Module design pattern, it can be beneficial to establish a basic template to facilitate getting started with it. This template typically includes components for namespace management, along with definitions for public and private variables.

In JavaScript, the Module pattern serves to simulate the concept of classes by enabling the inclusion of both public and private methods and variables within a single object. This approach helps isolate specific elements from the global scope, reducing the risk of function name conflicts with other scripts on the page.

var myNamespace = (function () {

  var myPrivateVar, myPrivateMethod;

  // Initialize a private counter variable
  myPrivateVar = 0;

  // Define a private function that logs arguments
  myPrivateMethod = function( foo ) {
      console.log( foo );
  };

  return {

    // Public variable
    myPublicVar: "foo",

    // Public function utilizing private elements
    myPublicFunction: function( bar ) {

      // Increment private counter
      myPrivateVar++;

      // Call private method using bar argument
      myPrivateMethod( bar );

    }
  };

})();

Benefits

What makes the Module pattern a preferred choice? Firstly, it offers a cleaner approach for developers transitioning from an object-oriented background compared to true encapsulation, especially in a JavaScript context.

Secondly, it supports private data, allowing public parts of the code to interact with private ones while preventing external access to the class's private components.

Drawbacks

One drawback of the Module pattern is that altering visibility requires modifications to all instances where the member is accessed since public and private members are accessed differently.

Additionally, it's not possible to access private members in subsequently added methods of the object. Despite these drawbacks, the Module pattern remains valuable and, when employed effectively, has the potential to enhance application structure.

The Revealing Module Pattern

Building upon the Module pattern, let's explore a refined version - Christian Heilmann’s Revealing Module pattern.

Heilmann introduced the Revealing Module pattern due to his frustration with repeating the main object's name to call a public method from another or access public variables. He also disliked switching to object literal notation as required by the Module pattern to expose desired elements publicly.

This innovation involves defining all functions and variables in the private scope, then returning an anonymous object containing references to private functionality intended for public use.

An illustration of implementing the Revealing Module pattern is shown below

var myRevealingModule = (function () {

        var privateVar = "Ben Cherry",
            publicVar = "Hey there!";

        function privateFunction() {
            console.log( "Name:" + privateVar );
        }

        function publicSetName( strName ) {
            privateVar = strName;
        }

        function publicGetName() {
            privateFunction();
        }


        // Expose public pointers to
        // private functions and properties

        return {
            setName: publicSetName,
            greeting: publicVar,
            getName: publicGetName
        };

    })();

myRevealingModule.setName( "Paul Kinlan" );

Advantages

This pattern promotes script syntax consistency and enhances readability by clearly indicating which functions and variables may be accessed publicly at the module's conclusion.

Disadvantages

An issue with this pattern arises if a private function references a public one; overriding the public function becomes challenging in case of updates. The pattern primarily pertains to private elements and does not apply to public members, particularly functions.

Moreover, public object members referencing private variables must adhere to the restriction on patching discussed earlier.

If you're in need of keeping things private:

var mySecretSpace = (function() {

  //Hidden treasure
  var publicScope = {};

  //Hidden treasure
  var hiddenGem = "aaa"; 

  //Visible treasure
  publicScope.visibleGem = "bbb";

  //Unveiled method
  publicScope.revealMethod = function() {
    this.hiddenMethod();
  };

  //Concealed method
  function hiddenMethod() {
    console.log(this.hiddenGem);
  }

  //Disclose only the public parts
  return publicScope;
}());

mySecretSpace.revealMethod();

Or if secrecy isn't a concern:

var yourNamespace = {};

yourNamespace.publicMethod = function() {
    // Do something...
};

yourNamespace.publicMethod2 = function() {
    // Do something...
};

yourNamespace.publicMethod();

To create namespaces in JavaScript, you can define a simple function like this.

function createNamespace(namespace) {
    var obj = this, parts = namespace.split("."), part;

    while (parts.length > 0) {
        part = parts.shift();

        if (typeof obj[part] === "undefined") {
            obj[part] = {};
        }

        obj = obj[part];
    }

    return obj;
}

// Example of how to use the function
createNamespace("example.namespace").value = "I am a value!";

While I may be fashionably late by 7 years, I delved into this realm around 8 years ago and accomplished quite a bit:

The ability to efficiently create nested namespaces is crucial for maintaining organization and manageability in complex web applications. It is equally important to uphold the integrity of the JavaScript global namespace, avoiding pollution, and ensuring existing objects are left intact along the namespace path.

The solution I implemented back in circa-2008 was as follows:

var namespace = function(name, separator, container){
  var ns = name.split(separator || '.'),
    o = container || window,
    i,
    len;
  for(i = 0, len = ns.length; i < len; i++){
    o = o[ns[i]] = o[ns[i]] || {};
  }
  return o;
};

This snippet doesn't directly establish a namespace but rather provides a mechanism for creating them dynamically.

A more compact version in one line would be:

var namespace=function(c,f,b){var e=c.split(f||"."),g=b||window,d,a;for(d=0,a=e.length;d<a;d++){g=g[e[d]]=g[e[d]]||{}}return g};

An example of usage is shown below:

namespace("com.example.namespace");
com.example.namespace.test = function(){
  alert("In namespaced function.");
};

Alternatively, it can be combined into a single statement:

namespace("com.example.namespace").test = function(){
  alert("In namespaced function.");
};

Both variations can then be executed with the following call:

com.example.namespace.test();

If legacy browser support isn't necessary, an updated implementation could look like:

const namespace = function(name, separator, container){
    var o  = container || window;
    name.split(separator || '.').forEach(function(x){
        o = o[x] = o[x] || {};
    });
    return o;
};

I recommend caution when exposing namespace directly to the global space. Implementing it within a closure would provide better encapsulation. An example of this approach is demonstrated below:

(function(){
const namespace = function(name, separator, container){
var o = container || window;
name.split(separator || '.').forEach(function(x){
o = o[x] = o[x] || {};
});
return o;
};
const ns = namespace("com.ziesemer.myApp");

// Optional:
ns.namespace = ns;

// Further extend, work with ns from here...
}());

console.log("\"com\":", com);

In a larger application, defining this function once during page load suffices for client-based web apps. Subsequent files can reuse the function if needed. Even if re-declared multiple times, the impact is minimal due to the concise nature of the code, especially when minified.

Inspired by Erlang's modules, I developed a unique approach called namespace for structuring my JavaScript code. This method allows me to create a global namespace within a closure and expose specific functions within that namespace.

By using the namespace function, I can easily bind functions to a root object without having to define them first. For example, in the code snippet below, I am creating a namespace called "images" and binding the functions previous and next to it:

(function(){

  namespace("images", previous, next);
  
  function previous(){ ... }

  function next(){ ... }

  function find(){ ... } // A private function

})();

When moving my libraries to new projects, I found myself constantly changing the top-level namespace. To simplify this process, I now use a small helper function for defining namespaces that is open source.

global_namespace.Define('startpad.base', function(ns) {
    var Other = ns.Import('startpad.other');
    ....
});

You can read more about the benefits in my blog post. The source code is also available for download.

One advantage I particularly appreciate is the isolation between modules regarding load order. This enables you to reference an external module before it's loaded, and the object reference will be populated once the code is ready.

Here is my preferred syntax for defining namespaces.

var MyNamespace = MyNamespace|| {};

 MyNamespace.MyClass = function (value) {
        this.value = value;
        this.getValue = function(){
                          return this.value;
                       };
    }

var instance = new MyNamespace.MyClass(46);
alert(instance.getValue());

You can view and edit the code on jsfiddle: http://jsfiddle.net/rpaul/4dngxwb3/1/

It appears that there might be an overuse of code for a relatively straightforward issue. Creating a repository seems unnecessary in this case. Instead, consider using a concise one-liner function:

namespace => namespace.split(".").reduce((last, next) => (last[next] = (last[next] || {})), window);

Give it a shot :

// --- definition ---
const namespace = name => name.split(".").reduce((last, next) => (last[next] = (last[next] || {})), window);

// --- Implementation ----
const c = namespace("a.b.c");
c.MyClass = class MyClass {};

// --- Check the result ----
console.log("a : ", a);

Learn about JavaScript ES6 Modules Namespace imports

// shapes.js
export { name, draw, calculateArea, calculatePerimeter };

// app.js
import * as Shapes from './utils/shapes.js';

// draw a shape
let shape1 = Shapes.draw(myCanvas.context, 50, 150, 80, 'blue');
Shapes.calculateArea(shape1.dimensions, resultContainer);
Shapes.calculatePerimeter(shape1.dimensions, resultContainer);

This code snippet fetches all the exports from shapes.js and organizes them under an object Shapes, creating a targeted namespace for easy access.

Lately, I've been really liking this particular pattern:

var namespace = (function() {
  
  // make certain methods public
  return {
    a: internalA,
    c: internalC
  }

  // keep the rest private
  
  /**
   * Full JSDoc
   */
  function internalA() {
    // ...
  }
  
  /**
   * Full JSDoc
   */
  function internalB() {
    // ...
  }
  
  /**
   * Full JSDoc
   */
  function internalC() {
    // ...
  }
  
  /**
   * Full JSDoc
   */
  function internalD() {
    // ...
  }
  
})();

The return statement could be placed at the end, but having it before the function declarations makes it easier to understand the purpose of the namespace and what API is available.

Using function expressions in this way can make it difficult to identify which methods are exposed without reviewing the entire code.

While Jaco Pretorius' solution is impressive, I decided to enhance the functionality of the "this" keyword by directing it towards the module/namespace object. Here's my take on it:

(function ($, undefined) {

    console.log(this);

}).apply(window.myNamespace = window.myNamespace || {}, jQuery);

JavaScript currently lacks a built-in way to handle namespaces, but TypeScript fills that gap.

For instance, you can implement namespaces in TypeScript like this (playground):

namespace Stack {
    export const hello = () => console.log('hi')
}

Stack.hello()

If you're unable to switch to TypeScript, you can still follow the pattern used by TypeScript when transpiling namespaces to JavaScript:

var Stack;
(function (Stack) {
    Stack.hello = () => console.log('hi');
})(Stack || (Stack = {}));
Stack.hello();

For more information, check out:

• TS - Namespaces
• TS - Namespaces and Modules

Utilizing a Makefile allows for this functionality.

// prelude.hjs
billy = new (
    function moduleWrapper () {
    const exports = this;

// postlude.hjs
return exports;
})();

// someinternalfile.js
function bob () { console.log('hi'); }
exports.bob = bob;

// clientfile.js
billy.bob();

I find that employing a Makefile is advantageous once the codebase reaches around 1000 lines, as it enables me to easily comment out large sections of code by modifying just one line in the makefile. This simplifies experimentation and adjustments. Additionally, with this approach, the namespace declaration only occurs once in the prelude, making modifications straightforward without repeating it within the library code.

A handy shell script for real-time browser development alongside a makefile:

while (true); do make; sleep 1; done

By adding this as a 'go' task in the makefile, you can simply run 'make go' to automatically update your build as you continue coding.

In continuation of Ionuț G. Stan's response, I would like to highlight the advantages of keeping code uncluttered by utilizing

var ClassFirst = this.ClassFirst = function() {...}

var Namespace = new function() {
    var ClassFirst = this.ClassFirst = function() {
        this.abc = 123;
    }

    var ClassSecond = this.ClassSecond = function() {
        console.log("Accessing another class in the namespace in a cluttered manner: ", new Namespace.ClassFirst().abc);
        console.log("Accessing a class in the same namespace more elegantly: ", new ClassFirst().abc);
    }
}

var Namespace2 = new function() {
    var ClassFirst = this.ClassFirst = function() {
        this.abc = 666;
    }

    var ClassSecond = this.ClassSecond = function() {
        console.log("Accessing another class in the namespace in a cluttered manner: ", new Namespace2.ClassFirst().abc);
        console.log("Accessing a class in the same namespace more elegantly: ", new ClassFirst().abc);
    }
}

new Namespace.ClassSecond()
new Namespace2.ClassSecond()

Expected Output:

Accessing another class in the namespace in a cluttered manner: 123
Accessing a class in the same namespace more elegantly: 123
Accessing another class in the namespace in a cluttered manner: 666
Accessing a class in the same namespace more elegantly: 666

I have developed a new namespacing tool that functions similarly to packages or units in other programming languages. This tool enables you to create a JavaScript package and reference it from other parts of your code:

hello.js File

Package("hello", [], function() {
  function greeting() {
    alert("Hello World!");
  }
  // Share the greeting function with other packages
  Export("greeting", greeting);
});

Example.js File

Package("example", ["hello"], function(greeting) {
  // Use the greeting function here
  greeting();  // Shows an alert with "Hello World!"
});

Only the second file needs to be included on the webpage. The dependencies (like the hello.js file in this example) will automatically load and the exported objects from those dependencies will populate the arguments of the callback function.

You can learn more about this project at Packages JS.

Utilizing it on its own can be done like this:

var X = X|| {};
X.Y = {};

X.Y = {
    element1: null,
    element2: null,
};

X.Y.element1 = function () {
    //..
}

X.Y.element2 = function () {
    //..
}

When working with JavaScript, there are no built-in methods for managing namespaces. Developers must create their own methods to define and organize namespaces within their codebase. At our company, Oodles technologies, we follow a specific procedure to handle this.

One key step is registering a namespace using the following function:

// Function to Register Namespaces
function registerNS(args){
 var nameSpaceParts = args.split(".");
 var root = window;

 for(var i=0; i < nameSpaceParts.length; i++)
 {
  if(typeof root[nameSpaceParts[i]] == "undefined")
   root[nameSpaceParts[i]] = new Object();

  root = root[nameSpaceParts[i]];
 }
}

To create a namespace, simply call the above function with the desired namespace separated by a dot. For example, if your application is named "oodles," you can create namespaces like this:

registerNS("oodles.HomeUtilities");
registerNS("oodles.GlobalUtilities");
var $OHU = oodles.HomeUtilities;
var $OGU = oodles.GlobalUtilities;

This results in a structured representation of your namespaces like this:

var oodles = {
    "HomeUtilities": {},
    "GlobalUtilities": {}
};

In this setup, namespaces such as "oodles.HomeUtilities" and "oodles.GlobalUtilities" are registered. To access these namespaces, aliases like $OHU and $OGU are created.

These variables act as shortcuts for initializing the namespaces. So, when defining a function within the HomeUtilities namespace, it would look something like this:

$OHU.initialization = function(){
    //Your Code Here
};

To call this function anywhere in the script files, you would use:

$OHU.initialization();

Similarly, other namespaces can be managed using similar techniques. This approach helps keep the code organized and easy to maintain.

We hope this explanation is helpful for understanding namespace management in JavaScript!

One of my habits is using function myName() as property storage and then var myName as a "method" holder...

I'm not sure if this approach is considered legitimate, but it works for me! I always rely on my PHP logic, and things just seem to fall into place. :D

function myObj() {
    this.prop1 = 1;
    this.prop2 = 2;
    this.prop3 = 'string';
}

var myObj = (
 (myObj instanceof Function !== false)
 ? Object.create({
     $props: new myObj(),
     fName1: function() { /* code..  */ },
     fName2: function() { /* code ...*/ }
 })
 : console.log('Object creation failed!')
);

if (this !== that) myObj.fName1(); else myObj.fName2();

You can also approach this in a more organized way by checking before object creation, which is a much better practice:

function myObj() {
    this.prop1 = 1;
    this.prop2 = 2;
    this.prop3 = 'string';
}

var myObj = (
    (typeof(myObj) !== "function" || myObj instanceof Function === false)
    ? new Boolean()
    : Object.create({
        $props: new myObj(),
        init: function () { return; },
        fName1: function() { /* code..  */ },
        fName2: function() { /* code ...*/ }
    })
);

if (myObj instanceof Boolean) {
    Object.freeze(myObj);
    console.log('myObj failed!');
    debugger;
}
else
    myObj.init();

Check out the reference to this: JavaScript: Creating Object with Object.create()

By default, JavaScript does not have support for namespaces. This means that any element you create (such as a function, method, object, or variable) will become global and potentially pollute the global namespace. For example, if we define two functions without using namespaces:

function func1() {
    console.log("This is the first definition");
}
function func1() {
    console.log("This is the second definition");
}
func1(); // This is the second definition

In this scenario, the second function definition will always be called. Utilizing namespaces can help prevent name collision issues.