Node.js(CommonJS module specification) and require.js(AMD- asynchronous module definition)

After reading Node.js-apress book, I found out here’s the difference explained what was before node.js which has commonJS module specification and its ‘require()’ function for loading modules.

The traditional way use to import/load module in node.js is:

// Code Snippet to Show Loading Two Modules Using CommonJS
var foo = require('./foo');
var bar = require('./bar');
// continue code here

This behavior is acceptable in
a server environment where it is considered a part of the bootstrap process for your application. You mostly require things when starting your server and afterward these are returned from memory.

About AMD : async module definition

However, if the same module system is used in the browser, each require statement would need to trigger an HTTP request to the server. This is an order of magnitude slower and less reliable than a file system access call.
Loading a large number of modules can quickly degrade the user experience in the browser. The solution is async, in-parallel, and upfront loading of modules. To support this async loading, we need a way to declare that this file will depend upon ./foo and ./bar upfront and continue code execution using a callback. There is already a specification for exactly this called async module definition (AMD).

// code snippet to show loading two modules using AMD
define(['./foo', './bar'], function(foo, bar){
// continue code here
});

The define function is not native to the browser. These must be provided by a third-party library. The most
popular of these for the browser is RequireJS (http://requirejs.org/).

Playing with AMD

To export something from a module, you can simply return it from the define callback. For example, let’s create afile foo.js that exports a simple function, as shown in code

 // amd/play/client/foo.js
define([], function () {
var foo = function () {
console.log('foo was called');
};
return foo; // function foo is exported
});

To be upfront about all the modules we need in a file, the root of the file contains a call to define. To load modules ./foo and ./bar in app.js in the same folder, the define call will be as shown in code below

// amd/play/client/app.js
define(['./foo', './bar'], function (foo, bar) {
// use foo and bar here
});

define can take a special argument called exports, which behaves similar to the exports variable in Node.js.
Let’s create the module bar.js using this syntax, as shown in code below

amd/play/client/bar.js
define(['exports'], function (exports) {
var bar = exports.log = function () {
console.log('bar.log was called');
};
});

Note that you can only use exports to attach variables you want to export (for example, exports.log = /*something*/), but you cannot assign it to something else (exports = /*something*/) as that would break the reference the exports variable monitored by RequireJS. This is conceptually quite similar to the exports variable in Node.js. Now, let’s complete app.js and consume both of these modules, as shown in code below

// amd/play/client/app.js
define(['./foo', './bar'], function (foo, bar) {
foo();
bar.log();
});

The real benefit of using this alternate (AMD) syntax for modules becomes evident when we look at the network tab within the chrome debug tools, as shown in Figure

Converting Node.js into browser code

Here we actually use require() function:

As you can see, there are significant differences between the browser module systems (AMD) and the Node.js module
system (CommonJS). However, the good news is that the Node.js community has developed a number of tools to take
your CommonJS / Node.js code and transform it to be AMD / RequireJS compatible. The most commonly used one
(and the one on which other tools rely) is Browserify (http://browserify.org/).
Browserify is a command line tool that is available as an NPM module.
already have npm available. To install Browserify as on the command line tool, simply execute the command (Note: On Mac OS X you need to run this as root (sudo npm install –g browserify).

CommonJS Specifications :

1. In a module, there is a free variable “require”, that is a Function.
2. The “require” function accepts a module identifier.
3. “require” returns the exported API of the foreign module.
4. If there is a dependency cycle, the foreign module may not have finished executing at the time it is required by one of its transitive dependencies; in this case, the object returned by “require” must contain at least the exports that the foreign module has prepared before the call to require that led to the current module’s execution.
5. If the requested module cannot be returned, “require” must throw an error.
6. The “require” function may have a “main” property that is read-only, don’t delete and represents the top-level “module” object of the program. If this property is provided, it must be referentially identical to the “module” object of the main program.
7. The “require” function may have a “paths” attribute, that is a prioritized Array of path Strings, from high to low, of paths to top-level module directories.
8. The “paths” property must not exist in “sandbox” (a secured module system).
9. The “paths” attribute must be referentially identical in all modules.
10. Replacing the “paths” object with an alternate object may have no effect.
11. If the “paths” attribute exists, in-place modification of the contents of “paths” must be reflected by corresponding module search behavior.
12. If the “paths” attribute exists, it may not be an exhaustive list of search paths, as the loader may internally look in other locations before or after the mentioned paths.
13. If the “paths” attribute exists, it is the loader’s prorogative to resolve, normalize, or canonicalize the paths provided.
14. In a module, there is a free variable called “exports”, that is an object that the module may add its API to as it executes.
15. modules must use the “exports” object as the only means of exporting.
16. In a module, there must be a free variable “module”, that is an Object.
17. The “module” object must have a read-only, don’t delete “id” property that is the top-level “id” of the module. The “id” property must be such that require(module.id) will return the exports object from which the module.id originated. (That is to say module.id can be passed to another module, and requiring that must return the original module).
18. The “module” object may have a “uri” String that is the fully-qualified URI to the resource from which the module was created. The “uri” property must not exist in a sandbox.

For More Detail of practical approach , I suggest to read this blog of a google developer — @Addy Osmani

https://addyosmani.com/writing-modular-js/

Hope that this was good resource to provide useful information all about module specifications in JS.

Till then its ALWAYS BLUE ! ALWAYS BLUE ! ALWAYS BLUE …(going to miss bachman)