Organizing JavaScript code for a website
One problem in your code is that the "modules" aren't standalone. You'd be adding the "modules" for calling into the init every time a new on is made.

To avoid doing so, each module should register itself for init. You can do this by adding a "register" functionality in your singleton.

(function(exports){

    var registry = []; //collection of module

    //adds module to collection
    exports.register = function(moduleDeclaration){
        registry.push(moduleDeclaration);
    }

    //executes every module
    exports.init = function(){
        var registryLength,i;

        registryLength = registry.length

        //loop through each module and execute
        for(i=0;i&lt;registry.length;i++){
            registry[i].call(this);
        }
    }

//use existing namespace or make a new object of that namespace
}(window.Lib = window.Lib || {}));

//To register a module
Lib.register(function(){
    //do what you have to do here
});

//executing the init
Lib.init();


See? The modules register themselves and don't need to be added manually for init. A developer can create a module on a separate file, add it into the page without editing the main Lib singleton.

Also, you'd have to consider what you'd do if you include a module dynamically after init is called. You should have some internal flag to indicate that init was already called, and that dynamically added module should register and execute immediately.



A vaguely known library called KernelJS already does this and contains many more features like core abstraction, pub-sub inter-module communication, register-remove modules, loose coupling pattern and so on. I suggest you try it or base from it.



As an answer to your add-on question of exposing modules, sure you can. However, according to scalability principles, modules or "widgets" as they call them, should not know each exists. This is to prevent tight-coupling and avoid breakage when, for example, you take out a certain module out. 

Also, naming modules isn't good for portability as you are setting a fixed name for a set of code. What if you changed it's name? You'd have to look for all code that depends on that module and change the name.

However, if you want to have named modules and fetching badly, you could expose another function to retrieve a module and return that module if it exists, or undefined or a custom error if it doesn't. Here's modified code for Lib. Since we are using named modules, instead of an array, registry is now an object.

var registry = {}

exports.register = function(name,declaration){
    registry[name] = declaration;
}

exports.init = function(){
    var module,i;

    registryLength = registry.length

    //loop through each module and execute
    for(name in registry){
        if(registry.hasOwnProperty(name)){
            registry[name].call(this);
        }
    }
}

exports.getModule = function(moduleName){

    //default to undefined
    var module;

    //if module exists, assign
    if(registry.hasOwnProperty('moduleName')){
        module = registry[moduleName];
    }

    return module
}

//to register a module
Lib.register('moduleName',function(){
    //module code
});


Additionally, you can call each module's init from Lib's init. Just make sure each module exposes an init function.