The core of SuiteScript 2.0 came from the RequireJsand CommonJs background. RequireJS is a JavaScript file and module loader. It is optimized for in-browser use, but it can be used in other JavaScript environment. Using a modular script loader like RequireJS will improve the speed and quality of your code.

Commonjs  defines a module format. Unfortunately, it was defined without giving browsers equal footing to other JavaScript environments. Because of that, there are CommonJS specification proposals for Transport formats and an asynchronous require.

RequireJS tries to keep with the spirit of CommonJS, with using string names to refer to dependencies, and to avoid modules defining global objects, but still allow coding a module format that works well natively in the browser. RequireJS implements the Asynchronous Module Definition (formerly Transport/C) proposal.

A module is different from a traditional script file in that it defines a well-scoped object that avoids polluting the global namespace. It can explicitly list its dependencies and get a handle on those dependencies without needing to refer to global objects, but instead receive the dependencies as arguments to the function that defines the module. Modules in RequireJS are an extension of the Module Pattern, with the benefit of not needing globals to refer to other modules.

The RequireJS syntax for modules allows them to be loaded as fast as possible, even out of order, but evaluated in the correct dependency order, and since global variables are not created, it makes it possible to load multiple versions of a module in a page.

If you have modules that are in the traditional CommonJS module format, then you can easily convert them to work with RequireJS. While testing our code in debugger we noticed that we  need to use require to debug the code or debugging while in console we use require function to load firstly. Example from requirejs org  : The code is similar as we used to write in NetSuite Customization SuiteScripting.

Definition Functions with Dependencies

If the module has dependencies, the first argument should be an array of dependency names, and the second argument should be a definition function. The function will be called to define the module once all dependencies have loaded. The function should return an object that defines the module. The dependencies will be passed to the definition function as function arguments, listed in the same order as the order in the dependency array:

Modules do not have to return objects. Any valid return value from a function is allowed. Here is a module that returns a function as its module definition:

//A module definition inside foo/title.js. It uses

//my/cart and my/inventory modules from before,

//but since foo/title.js is in a different directory than

//the "my" modules, it uses the "my" in the module dependency

//name to find them. The "my" part of the name can be mapped

//to any directory, but by default, it is assumed to be a

//sibling to the "foo" directory.

define(["my/cart", "my/inventory"],

    function(cart, inventory) {

        //return a function to define "foo/title".

        //It gets or sets the window title.

        return function(title) {

            return title ? (window.title = title) :

                   inventory.storeName + ' ' + cart.name;

        }

    }

);

    //Explicitly defines the "foo/title" module:

    define("foo/title",

        ["my/cart", "my/inventory"],

        function(cart, inventory) {

            //Define foo/title object in here.

       }

    );