JavaScript module pattern / organization / sub-modules

Question

1. I would like to know what's the difference (advantages/disadvantages) between the following patterns.
2. How can I create sub modules based on the module pattern?

My goal is to have my js organized into multiple files that are lazy loaded but have one namespace.

For example:

SO.global (global.js) SO.global.registration (registration.js) <- load

var SO = function(){

    var CONSTANT = 'Z';

    function createX(){
      alert("create X");
    }

    function getY(){
       alert("get Y");
    }
    return{
      create:createX,
      get:getY
    }
}();

//SO.createX(); 
//SO.getY();

VS.

var SO = (function() {

    var CONSTANT = 'Z';

    function createX(){
      alert("create X");
    }

    function getY(){
       alert("get Y");
    }

    return {
      create:createX,
      get:getY
    }

} ());

Hula

There is no difference between the two examples....one has parens around it but they should do the same thing. – Menis

The additional parens in the second example are being used by some folks to indicate that the function expression is called immediately. – Legume

I think the parens are in the wrong place for that convention though. I believe it's usually written as (function(){...})() – Trustbuster

Answer 1

Have you considered Require.JS? It attempts to provide the following solution:

• Some sort of #include/import/require
• ability to load nested dependencies
• ease of use for developer but then backed by an optimization tool that helps deployment

Require.JS implements the Module/Asynchronous Definition spec defined by Common.JS

Echeverria

Answer 2

Here's a good read: http://snook.ca/archives/javascript/no-love-for-module-pattern, and another: http://lamb.cc/blog/category/javascript/

YUI uses it avidly, as do I, I haven't found any situations where I was restricted by it, and it nicely integrates with the YUI dependency loader for custom Modules.

(Sorry, I realise this isn't a complete answer, but there's some untampered info for you)

Behnken

These links have just added a couple of months on my "skills-todo" pipeline. – Clave

The first link is weird. It's like he is arguing against the use of private variables. – Bonds

@cherouvim, agreed, i'm about... 70% of the way through the brain freak involved (for me anyway) – Behnken

@david, I gleaned the same feeling, which added another 25% of investigative work, including the comments on his article which are interesting also – Behnken

One thing I will say about the Snook article, the objection to the module-pattern--the objection which says that it requires you to edit code to fish out hidden data--is not quite right. There's a surprisingly easy workaround that I use with Firebug. We need only set a conditional breakpoint inside a function with access to the private data, then set the condition on the breakpoint to !console.log(hiddenVar). The breakpoint won't ever break (unless you want it to, in which case, you can remove the !), but causing the function to execute will now log my private data for easy inspection. – Tabethatabib

I could alternatively set the breakpoint condition to (window._hidden = hiddenVar, 0) so I can manipulate or more carefully inspect the formerly hidden data. – Tabethatabib