JavaScript Boilerplate

README.md

JS Boilerplate

Simple boilerplate I use to start JavaScript projects.

boilerplate.js

// We're cooking with globals, so we use namespaces to avoid conflicts
var Namespace = Namespace || {};
Namespace.Project = Namespace.Project || {};

Namespace.Project.init = function () {	

	

}

// Expecting jQuery, but you could easily change this to some other method of window ready or dom ready
$(function () {

    // Cached selectors
    Namespace.Project.$elm = {};
    
    // Arbitrary data (Comes after selectors so we can use them here)
    Namespace.Project.data = {};

    Namespace.Project.init();

});

    // Do everything in a closure, so we don't affect or create any globals.
    (function ($) {
        var  Project = Project || {};

       Project.init = function () { 



        }
        $(function () {

            // Cached selectors
           Project.$elm = {};

            // Arbitrary data (Comes after selectors so we can use them here)
           Project.data = {};

           Project.init();

        });
    /** uncomment to see Namespace in the global scope for debugging.
        window.Namespace = {
            Project : Project;
        }
    */
    // import either jQuery or Zepto
    }(window.jQuery || window.Zepto);

    /*
    This way you leak nothing at all into the global namespace as it's all inside a closure. You import either jQuery or Zepto     depending on what's supported in the page and even if jQuery is running in compatibility mode it won't break.
    */

If you want even more functionality in your closure I would do this. Just making sure that you have the correct variables when you start. Takes more guessing out of it.

(function( $, window, document, undefined ) {

  // code here

})( window.jQuery || window.Zepto, window, window.document );

Since you never actually pass a value for undefined into your closure, it will be undefined no matter, always giving you the correct value.

@scottbert I like that.

@vernak2539 Thanks! What is the benefit of declaring 'undefined' ?

@nessthehero, the main benefit is in case people set undefined to something other than "undefined". Undefined is something that should always be "undefined" no matter where you use it.

Some people (usually XSS) will purposely try to mess with code and insert values on a page that conflict with what you think you'll be using. This is why closures are so important, and also scope control of course.

If somewhere outside your closure, undefined gets set to "false" or "true" or whatever, now inside your closure you will have the correct value back.

It makes sure you don't have to think about your checks for undefined

// check 1. I have not set randomVar elsewhere
if( randomVar !== undefined ) {
   // do something with your randomVar
}

// if undefined is set to 'true' (bool) you would go into that control structure even if you didn't mean to
// ex) undefined (value of randomVar) !== true (value of undefined)  // results in true; putting you inside the loop

// Better Check that doesn't take into account of what `undefined` is set to
if( typeof randomVar !== "undefined" ) {
   // do something with randomVar
}

@scottbert If you wrap everything in a closure, including your namespace, how would you go about working with multiple files?

In some cases, I create a "global" file that's included on all pages, containing helper methods, and functions I will need elsewhere.

I have been using this pattern lately.

var PROJECT = PROJECT || {};

(function(my){


    /**
     * Do some stuff
     * @return {undefined}
     */
    my.init = function() {

    };


    // DOM Ready, Execute
    $(my.init);


}(PROJECT));

If you want to know whether undefined has been fucked with, you can write:

if (undefined !== void 0) {
  ...
}

Similarly, you can set undefined for yourself with:

undefined = void 0;

Or the old classing as part of your IIFE:

(function (undefined) {
  ...
})();

@raganwald, had no clue about checking undefined with void 0. I guess you learn something new everyday

I find AngularJS and RequireJS solves namespacing issues quite nicely

@mattgoucher I do that as well. I suppose you could take the solution from @scottbert and just leave the global namespace part uncommented so that it remains in the global namespace.

I like using browserify for this kind of thing. You have to do a static build step and async code loading is pretty much out of the question, but at least those requires look nice. :)